Slowloris
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.
Posted on June 21, 2009, in apache. Bookmark the permalink. 7 Comments.
niq's soapbox 
Soon after reading about the method Slowloris uses to instigate a DoS, I threw together a tool that utilizes a similar system to perform a similar attack. The modified version is written in Python, and gives a large amount of control over threads, which drastically reduces the memory footprint. Additionally, it allows the user to adjust the bandwidth usage and payload size, allowing this form of attack to overflow server memory at the same time.
These additions can turn a trivial attack into a full-fledged DoS attack. I would be interested in seeing how effective your setup with the Worker or Event MPM is against it. If you are interested in trying it out, send me an email.
Cheers,
Motoma
Just as a note, I have also been analysing this problem
and mod_evasive is unable to mitigate this attack.
I am going to see if mod_security can help defend against
this attack.
Tested out my latest version against the Apache Worker MPM; regardless of the setting I selected in the Apache config, I found no issue overwhelming the server with an exorbitant number of connections.
I did not see the behavior you described: when used on separate machines, Apache processes were trying to use over 1 GB of memory (the test system’s max), while the script used up 50 MB. The Apache system had a load average of 817.71, but the source machine read the script as utilizing less than 1% of CPU.
Just to follow up on this, I’ve started drafting something at http://wiki.apache.org/httpd/DoS . That’s a wiki, so contributions welcome.
Motoma – I won’t take you up on your offer, for the time being at least. It’s apache I’m interested in, and from that PoV one attack script is equivalent to another.
My only issue with your post on the Apache HTTPD Wiki is that you seem to downplay the threat of this form of attack by addressing the limitations of one implementation of the attack.
The problem to be addressed, in my mind, is not increasing the number of connections allowed; rather, we should focus on removing the artificial limitation on the number of connections. If another version of the script can launch thousands of connections from a single machine, then even the increased connection limit in the Worker MPM won’t help against an attacker.
If Apache were instead to limit only the amount of memory its processes take up, then the relatively low memory consumption of this attack would make it highly unlikely to affect servers.
Pingback: mod_noloris: defending against DoS « niq’s soapbox
Pingback: Apache 웹 서버에 대한 "slowloris"DOS 공격을 가장 잘 방어하는 방법은 무엇입니까? 역 프록시 - How IT