Mitigating the Slowloris HTTP DoS Attack

Enterprise IT security staffs looking for some mitigation for the newly released HTTP DoS tool may have a few options. The analysts at the SANS Internet Storm Center are recommending that organizations running Web servers that are vulnerable to the tool’s attack make some basic configuration changes to their servers to help mitigate the effects of the attack.

Enterprise IT security staffs looking for some mitigation for the newly released HTTP DoS tool may have a few options. The analysts at the SANS Internet Storm Center are recommending that organizations running Web servers that are vulnerable to the tool’s attack make some basic configuration changes to their servers to help mitigate the effects of the attack.

The new attack, which uses a tool created by security researcher Robert Hansen, known as Rsnake, takes advantage of some characteristics of the Apache Web server to keep a number of HTTP connections open for long periods, effectively denying service to legitimate users of the site. The attack concept has been written about before, but the tool itself, called Slowloris, is new.

“It basically uses a concept of keeping an HTTP session alive indefinitely (or as long as possible) and repeating that process a few hundred times. So in my testing, against an unprotected and lone Apache server, you can expect to be able to take it offline in a few thousand packets or less on average, and then you can let the server come back again as soon as you kill the process. It also has some stealth features, including a method of bypassing HTTPReady protection,” Hansen wrote in a blog post about the tool.

“Typical flooding attacks require tons and tons of packets and end up denying service to other applications as a result. By creating a flood of TCP requests, sure you can take down an upstream router, or a web server, but it’s overkill if you really just want to take down a single website. Slowloris does this without sending an overabundance of TCP or HTTP traffic, and it does so without increasing the load significantly, or in any other way hurting the box (assuming other things aren’t tied to the HTTP processes – like a database for instance). This appears to only affect certain types of webservers (generally those that thread processes, like Apache, but not like IIS).”

The SANS analysts suggest that sites running Apache look at the TimeOut value, which defines the amount of time that Apache will wait for an HTTP GET request. From the SANS ISC Diary:

“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.”

SANS also mentions that using an Apache module such as mod_limitipconn, which limits the number of connections that can come from one IP address. This also can prevent legitimate users who may be using a proxy from visiting the site, though.

 

Suggested articles