0

I am developing a website that has user registration. I already built some rate-limit protection techniques using nginx and at a lower level using iptables, but I am worried about real-world attacks like ip-spoofing or DDoS.

The only solution I know is Google's CAPTCHA which is even used by big companies like Reddit and Gitlab. The problem is that it's not friendly on mobile and tablet devices, and in addition it puts visitors off.

Is there any known clean and cheap method for HTTP POST request floods? I thought to add a temporary random token to POST parameters that is stored also on my server for one or two seconds using Redis to check whether the request is automated (i.e. fast) or by a human (slow). I don't want to convince myself this is a reliable solution since I am no security expert.

  • You could use CAPTCHA, but not by default, but only if you detect some suspicious activity (like lots of requests from same IP). CAPTCHA should be then enforced for that IP only. Other users should not be affected. – stanko Jan 16 '17 at 12:46
0

I am struggling to imagine how this provides any protection against ip-spoofing. Regardless IP-spoofing on a TCP connection is hard to achieve - I would recommend you ignore it for now.

In terms of DOS protection, I would urge caution. The more sophisticated your measures for protection, the more they become a bottleneck and hence exploitable by DOS.

I thought to add a temporary random token to POST parameters that is stored also on my server for one or two seconds

Sounds rather expensive to me. You really want to minimise the amount of information you are capturing/attempting to store about potential DOS requests.

One solution is to put the storage cost back on the client: Create a cookie on the browser in an earlier page containing serverside encrypted values indicating some attributes about the client (such as the IP address or ASN, browser...) and a millisecond level timestamp using javascript and validate it in the POST request.

Note that you need to think about how you would validate an IP address which can span more than one session.

Dropping the cookie and using javascript validates that the client is a browser (or a fairly sophisticated facsimile) which has visited other pages on your site. A short interval between the timestamp generation and the cookie being presented would indicate a scripted attack.

rate-limit protection techniques using nginx and at a lower level using iptables

I will assume that you have ensured that these do not have a capacity impact and you have resized your conntrack table.

  • The cookie solution sounds like a good idea. I can then track the IP if it violated the timestamp condition. Thank you! – Ejonas GGgg Jan 16 '17 at 14:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.