I have completed the respondinator project to my liking, which is rare. I have been able to squash all issues that have come up, protect it against specific types of attacks, and clean up the code to my liking. I added integration tests to make sure I don’t break anything, and I have pushed the changes to a public GitHub repository. You can find the code base at the following location:
Below will be the final instructions moving foward until any changes are made:
Adding routes (POST)
String response route:
JSON response route:
Updating routes (PUT)
Use the key that was provided in the POST or PUT
Retrieving route (GET)
Additional NGINX update
This issue was brought to my attention by a specially crafted Go application that my associate built specifically to take down my application. I was able to prevent further attacks by this application by modifying my base NGINX configuration to rate limit requests. Due to the fact that I use CloudFront in front of my origin, I had one of two choices. Use the binary representation of the IP address in NGINX to block the requests (less memory usage), or block based on X-Forwarded-For address (more memory usage). I chose the former, due to the fact that these applications are running in memory constricted containers.
What happened before adding the set_real_ip_from options was that it was rate limiting each CloudFront edge IP address instead of the true client IP. After setting these options, I no longer see the CloudFront IP address, and all IPs are replaced with the true client IP. I’m still not sure that I want to keep it this way, as it may be useful at some point to know the CloudFront edge IP that’s hitting the site.