Slowloris has been getting quite a lot of attention recently. So what is it, and should we be worried?
Well, it’s a Denial of Service (DoS) attack over HTTP. We’ve been aware of the method for some time, and it has been discussed in public. As far as I know it’s not been happening in the wild. Nevertheless, it is something we should take seriously: probably more so than we have hitherto done.
I’ve been test-driving it over the weekend against Apache on OpenSolaris and Linux platforms.
The bad news is that it can indeed take a badly-configured apache server down, and the worse news is that that includes a low-traffic out-of-the box configuration. Even with the Event MPM, slowloris can tie up one worker thread per connection.
The good news is that slowloris itself runs out of steam long before Apache. With the Worker or Event MPM, it’s trivial to handle more connections than slowloris can make. Running both slowloris and apache on the same box, I was able to observe slowloris eating over 99% of the CPU, while apache effortlessly responded to requests even as it shared the remaining <1% with all the normal trappings of a Gnome desktop.
The other good news is that all the above was without any of the defences available for apache, such as mod_evasive (which specifically defends against DoS attacks).
I’ll write this up at more length elsewhere, including probably an article in the apache httpd wiki.
[POSTSCRIPT] Don’t take any of the above as definitive. It just describes my experimenting with it when the story broke. Other people have reported different experiences. Use an accept filter and use mod_reqtimeout, and look for more recent posts on the subject.