Protect yourself against Dos attacks

Question

This might be something more suited for Serverfault, but many webdevelopers who come only here will probably benefit from possible answers to this question.

The question is: How do you effectively protect yourself against Denial Of Service attacks against your webserver?

I asked myself this after reading this article: http://isc.sans.org/diary.html?storyid=6601

For those not familiar, here's what I remember about it: a DoS attack will attempt to occupy all your connections by repeatedly sending bogus headers to your servers.

By doing so, your server will reach the limit of possible simultanious connections and as a result, normal users can't acces your site anymore.

Wikipedia provides some more info: http://en.wikipedia.org/wiki/Denial_of_service

Answer 1

This probably belongs on serverfault, you may have more success there.

Answer 2

Short answer:

You cannot protect yourself against a DoS.

And i dont agree it belongs on serverfault since DoS is categorized as a security issue and is definetly related to programming

Answer 3

For this specific attack (as long as the request is GET) based a load balancer or a WAF which only bases full requests to the webserver would work.

The problems start when instead of GET POST is used (which is easy) because you can't know if this is a malicious POST or just some really slow upload from an user.

From DoS per se you can't really protect your webapp because of a simple fact. Your resources are limited while the attacker potentially has unlimited time and resources to perform the DoS. And most of the time it's cheap for the attacker to perform the required steps. e.g. this attack mentioned above a few 100 slow running connections -> no problem

Answer 4

Asynchronous servers, for one, are more or less immune to this particular form of attack. I for instance serve my Django apps using an Nginx reverse proxy, and the attack didn't seem to affect its operation whatsoever. Another popular asynchronous server is lighttpd.

Mind you, this attack is dangerous because it can be performed even by a single machine with a slow connection. However, common DDoS attacks pit your server against an army of machines, and there's little you can do to protect yourself from them.

Answer 5

There's no panacea, but you can make DoS attacks more difficult by doing some of the following:

• Don't (or limit your willingness to) do expensive operations on behalf of unauthenticated clients
• Throttle authentication attempts
• Throttle operations performed on behalf of each authenticated client, and place their account on a temporary lockout if they do too many things in too short a time
• Have a similar global throttle for all unauthenticated clients, and be prepared to lower this setting if you detect an attack in progress
• Have a flag you can use during an attack to disable all unauthenticated access
• Don't store things on behalf of unauthenticated clients, and use a quota to limit the storage for each authenticated client
• In general, reject all malformed, unreasonably complicated, or unreasonably huge requests as quickly as possible (and log them to aid in detection of an attack)
• Don't use a pure LRU cache if requests from unauthenticated clients can result in evicting things from that cache, because you will be subject to cache poisoning attacks (where a malicious client asks for lots of different infrequently used things, causing you to evict all the useful things from your cache and need to do much more work to serve your legitimate clients)

Remember, it's important to outright reject throttled requests (for example, with an HTTP 503: Service Unavailable response or a similar response appropriate to whatever protocol you are using) rather than queueing throttled requests. If you queue them, the queue will just eat up all your memory and the DoS attack will be at least as effective as it would have been without the throttling.

Some more specific advice for the HTTP servers:

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