No doubt you’ve heard of Slowloris, the HTTP DOS tool that will take down an Apache web server. I recommend reading the update at that site, which describes in some detail how it works.

Note that this condition is also covered in the Apache documentation, and, according to svn, that was put in:

r369825 | slive | 2006-01-17

So we’ve known about it for a *long* time.

What I can’t figure out is whether it’s really not that big a deal, or if I’m dismissing the importance because I’ve known about it for so long. I’ve known for a *long* time that you can take down an Apache server with nothing more than a telnet client. You telnet to port 80, issue a partial HTTP request, and then bg the process, then do it again.

The way that the attack works is that Apache then waits for the rest of the request, until it hits the timeout (configurable with the Timeout directive). This completely ties up that listener, so that it can’t answer any other inbound requests. Unfortunately, by default, Timeout is set to 300. And Apache only has a finite number of available waiting processes (Configurable by MaxClients.) So you do that MaxClient times within Timeout seconds, and, viola, the server is now no longer able to respond to inbound requests.

That’s exactly what the slowloris tool does, in a more automated fashion.

So, what to do about it?

Well, set Timeout lower. And use mod_evasive to limit the number of connections from one host. And use mod_security to deny requests that look like they were issued by this tool. However, that last one doesn’t really help, because it’s trivial to change the signature of requests from this tool.

On the other hand, this attack – or exploit, if you want to call it that – has been around for years, and hasn’t been a very popular attack vector. What this tool has done is not so much discovering an attack – we already knew about it – but let the larger number of script kiddies know about it. So presumably we’ll see it happen more often than we used to.

So, what to do about it longer term? Well, in Apache 3.0, or 2.4, with the event mpm and asynchronous IO, it will apparently be a non-issue. Another of the *many* compelling reasons to upgrade to 2.4 just as soon as it releases – something else that I need to write more about in the coming days.

Additional resources:

Niq’s response
Apache security documentation
Slowloris website
mod_evasive