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
I spoke with Ivan Ristic (the author of mod_security) about using mod_security for this, and no, it won't work. He says and I confirmed that it runs too late. In fact, I think most modules run too late (including other things like .htaccess directives banning that IP address). I haven't tried every module out there and every configuration, but the only one that seems like it might work is Event MPM, and only because Slowloris is not distributed. It will work, eventually, it's just that one machine running Slowloris can't do the job in that circumstance. For more reasons this might be a big deal read the following two blog posts:
http://ha.ckers.org/blog/20090504/using-denial-of-service-for-hacking/
http://ha.ckers.org/blog/20090620/http-longevity-during-dos/
It's not new - I agree, but it is a problem that should get fixed.
...em darknet.org.uk, wooga.drbacchus.com, hackaday.com e ...
There's mod_antiloris to defend against slowloris.