Protect yourself from Dos attacks

Question

This might be more appropriate for Serverfault, but many of the web developers who come here are likely to get possible answers to this question.

Question: How do you effectively protect yourself from Denial Of Service attacks against your web server?

I asked myself about this after reading this article.

For those who are unfamiliar, here is what I remember about this: the DoS attack will try to occupy all your connections by repeatedly sending dummy headers to your servers.

Thus, your server will reach the limit of possible simultaneous connections, and as a result, ordinary users will no longer be able to connect to your site.

Wikipedia provides additional information: http://en.wikipedia.org/wiki/Denial_of_service

Answer 1

There is no panacea, but you can make DoS attacks more complex by doing the following:

• Do not limit your willingness to perform expensive operations on behalf of unauthenticated customers.
• throttle test attempts
• Throttle operations are performed on behalf of each authenticated client and place their account in a temporary lock if they do too much time in too short a time.
• You have a similar global throttle for all non-authenticated clients, and be prepared to lower this setting if you find an attack in the process.
• You have a flag that you can use during an attack to disable all unauthenticated access.
• Do not store things on behalf of unauthenticated clients, and use a quota to limit storage for each authenticated client
• In general, reject all distorted, unreasonably complex or unreasonably huge requests as quickly as possible (and write them down to help in detecting an attack).
• Do not use a clean LRU cache if requests from unauthenticated clients can evict things from this cache, because you will be susceptible to cache poisoning attacks (where a malicious client requests a lot of different infrequently used things, causing them to evict all useful things from your cache and do much more work to serve your legitimate customers)

Remember that it’s important to explicitly refuse rejected requests (for example, with an HTTP 503: Service Unavailable response or a similar response that matches any protocol you use), rather than queues in suppressed requests. If you queue them, the queue will simply eat all your memory, and the DoS attack will be at least as effective as without throttling.

Some more specific recommendations for HTTP servers:

• Make sure your web server is configured to reject POST messages without an accompanying Content-Length header and reject requests (and throttle an abusive client) that exceed the specified Content-Length , and reject requests using a Content-Length that is unreasonably long for maintenance, that POST (or PUT ) is aimed at

Answer 2

For this particular attack (assuming the GET request) is based on a load balancer or WAF that only supports full requests to the web server.

Problems begin when instead of GET POST is used (which is easy) because you cannot know if this is a malicious POST or just a very slow download from the user.

From DoS per se, you cannot really protect your webapp due to a simple fact. Your resources are limited, while an attacker has potentially unlimited time and resources to perform DoS. And most of the time, it’s cheap for an attacker to take the necessary steps. for example this attack mentioned above, several 100 slow connections -> no problem

Answer 3

Asynchronous servers, for example, are more or less protected from this particular form of attack. For example, I serve Django applications using the Nginx reverse proxy, and the attack does not seem to affect its operation. Another popular asynchronous server is lighttpd.

Remember that this attack is dangerous because it can even be performed on the same machine with a slow connection. However, regular DDoS attacks break your server into an army of machines, and you can do little to protect yourself from them.

Answer 4

Short answer:

You cannot protect yourself from DoS.

And I do not agree that it belongs to the server file, since DoS is classified as a security problem and is definitely related to programming