Apache Dos

I think that there is no perfect solution for everyone.
Depending on the configuration of the webserver (which MPM, what number of MaxClients etc), the number of legitimate clients, whether or not you have many clients using connections behind NAT or proxies, whether or not you use an Apache or Squid reverse-proxy, how many concurrent connections every single hosted website usually needs per IP and many others the "perfect" solution may be hard to find, may require a well planned testing plan and may also require a lot of skills.

For people that don't really know what to do, just try all of the suggestions of the ISC diary and around the Web; try all of them alone, then try to combine them.

For people that don't have a testbed and can't try out the public PoC (http://www.milw0rm.com/exploits/8976) just wait for a fix release of Squid and Apache, it shouldn't take long and it's better to have a small chance to be hit that to take the server down every time you test it.
 
Someone wrote a temporary patch for Apache2 with MPM prefork (see http://isc.sans.org/diary.html?storyid=6622), I modified it to work with both MPM prefork and MPM worker. It's available at http://www.tillo.ch/temp/anti-slowloris.diff and is working perfectly.

If you use CustomBuild, just enter /usr/local/directadmin/custombuild, download the diff file there, copy the file configure/ap2/configure.apache into custom/ap2/configure.apache, paste "patch -p1 -i ../anti-slowloris.diff" as second line just after "#!/bin/bash" and run "./build apache".

You will see some debugging messages in /var/log/httpd/error_log and any attempts to DoS your webserver with the "slowloris" exploit will be vain. Enjoy.
 
Do you recommend this be made a part of DirectAdmin?

Does it have any downside?

Jeff
 
Thank you Tillo! I don't plan to deploy the patch unless needed but it is good to have an option if it does become necessary.
 
I'll take a look and test it on my non-critical server. Will report back (interested in the "downside" as well).
 
I recommend it to be part of CustomBuild for Apache 2.2.x-2.2.11 (and to be tested on 2.0.x). Of course without both "ap_log_error" functions present on the patch, which are there only for debugging and shouldn't be set in a production server. My server-wide error log is filling ten times faster than before because of those messages.

The downside is that if a server is misconfigured and the amount of concurrent users often approaches the number of maximum users connected, the Timeout value will dynamically reach low values and any user with very slow Internet links is going to have some problems connecting.
If, instead, a server is configured to have enough (+30%) idle listening processes/threads there won't be absolutely no problem. This is the case for most users with a default config.

Let's make an example: the default Timeout of a CustomBuild Apache2 install is 60 seconds and the MaxUsers is 450. If there are 405 concurrent users most of the time (only 10% idle listening processes/threads), the timeout will be 3.75 seconds (Timeout/16) for the 405th user and if his browser takes more than that to download a single page object, it will timeout. The solution in this case would be of course to raise the Timeout or MaxUsers value.
 
Last edited:
Well, the first thing I'm seeing is that it has generated 94 lines in error_log during the first 10 minutes. I can see this killing your /var partition... ;)

Will keep an eye on it and do some testing.
 
tillo said:
Of course without both "ap_log_error" functions present on the patch, which are there only for debugging and shouldn't be set in a production server. My server-wide error log is filling ten times faster than before because of those messages.
Click to expand...

Just noticed this and will compile Apache again with the patch you provided without the debugging messages. Thanks.

On my test server it's not an issue (although we DO get huge amount of hits mainly from search engines ATM, but the server has plenty of free disk space), but I have a client who is really short on available disk space and wouldn't want to kill their /var with stuff like this..
 
One customer had the same issue.

Here is another way to fix it quickly:

Code: 
# wget ftp://ftp.monshouwer.eu/pub/linux/mod_antiloris/mod_antiloris-0.4.tar.bz2
# tar xvf mod_antiloris-0.4.tar.bz2
# cd mod_antiloris-0.4/
# apxs -a -i -c mod_antiloris.c

By the way, yes the fix work; however I did tested to attack one box with another one from the same LAN both server got 20GB RAM and 10 GbE port cards and the server being attacked any suffers of little slow-down processing in Apache.
 
You must log in or register to reply here.
Back
Top