SANS ISC: Apache HTTP DoS tool mitigation - SANS Internet Storm Center

• SANS Site Network
  • Current Site
  • Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

If you've been following our diaries or any other IT Security related news, you probably know about the Apache HTTP DoS tool that was released on Thursday (see the original diary at http://isc.sans.org/diary.html?storyid=6601).

We received some information from our readers and I did a bit more testing so I decided to put up a diary with possible mitigation options – I hope to update the diary as we receive more stuff.

So, to recap the previous diary: the tool works by exhausting Apache processes; this is done by sending incomplete request headers so Apache keeps waiting for the final header line to arrive, the tool instead just sends a bogus header to keep the connection open. Besides Apache (both versions 1.x and 2.x), Squid is also affected. Knowing how many servers running on Apache there are, this makes the tool very dangerous since it doesn't require absolutely any knowledge from the attacker – all he/she has to do is run the tool and the target site goes down. So, what mitigation options (if any) we have?

First of all, those running some load balancers or reverse proxies in front of their Apache installations should check if they are really vulnerable or not – it's possible that the proxy is not affected by this vulnerability.

If you are running a standalone Apache server (as probably most web hosters are), you still have some mitigation options, but you should be very careful about them. NOTE: Test all these options thoroughly first as they might impact legitimate access to your server!

The TimeOut Directive, described at http://httpd.apache.org/docs/2.2/mod/core.html#timeout is the most important option here. It defines how long Apache will wait to receive a GET request, or amount of time to wait between receiving packets on POST requests. This is particularly interesting for POST requests and warrants additional research to see if the tool can be modified further to attack such, hardened servers.

So, the default for TimeOut is 300 seconds – 5 minutes – for a GET request to arrive. This means that the DoS tool can keep one connection tied up for up to 5 minutes, after that it has to open another connection. Since the default number of connections is 256 the tool can easily exhaust this. I did some testing with lowering this value down to 5 seconds – this might be too low because some slow clients will not be able to get the web page so don't blindly put this in your configuration files. Anyway, since the tool has the option for specifying timeout, I put it to 4 seconds to see if the attack still worked. And sure, it worked fine, but the tool had to send much more traffic. My measurements showed that in order to DoS an Apache server with TimeOut set to 5 seconds the tool needed about 2MB of traffic per minute. That is only ~45 kb/sec which makes this attack even more dangerous – a lone DSL user might DoS a big site. However, the TimeOut directive is still probably the best mitigation option.

Another possibility is also to use a module, such as mod_limitipconn, which limits the number of connections from one IP address. Again, use this with caution since you might prevent legitimate visitors if they are coming from behind a proxy. Also, this option is only partially good – sure, it will stop a script kiddie without other resources from DoS-ing your web site, but an advanced attacker can easily run the tool from dozen of machines.

And this is, unfortunately, more or less what we have at the moment. I will do more research on the scenario with the POST request and TimeOut directive – will post an update if I find something interesting. If you did some research and have workarounds please let us know.

--
Bojan