Mitigating the Slowloris DoS attack

[Andreas Krennmair]

Hello everyone,

Previously, I had contacted the Apache Security Team about a possible 
mitigation of the Slowloris DoS attack. I was referred to this mailing list to 
discuss non-private security issues.

For those who are still unaware of the Slowloris attack, it's a 
denial-of-service attack that consumes Apache's resources by opening up a 
great number of parallel connections and slowly sending partial requests, 
never completing them. Since Apache limits the number of parallel clients it 
serves (the MaxClients setting), this blocks further requests from being 
completed. Unlike other "traditional" TCP DoS attacks, this HTTP-based DoS 
attack requires only very little network traffic in order to be effective.  
Information about the Slowloris attack including a PoC tool was published 
here: http://ha.ckers.org/slowloris/

I thought for some time about the whole issue, and then I developed a 
proof-of-concept patch for Apache 2.2.11 (currently only touches the prefork 
MPM), which you can download here: http://synflood.at/tmp/anti-slowloris.diff

The basic principle is that the timeout for new connections is adjusted 
according to the current load on the Apache instance: a load percentage is 
computed in the perform_idle_server_maintenance() routine and made available 
through the global scoreboard. Whenever the timeout is set, the current load 
percentage is taken into account. The result is that slowly sending 
connections are dropped due to a timeout, while legitimate, fast-sending 
connections are still being served. While this approach doesn't completely fix 
the issue, it mitigates the negative impact of the Slowloris attack. Even 
under heavy load, legitimate requests are still being served, even though it - 
in my tests - in took a bit longer than usual. And the kind of heavy load that 
I needed to slow down Apache was already quite traffic-intensive, i.e. it 
defeated one of Slowloris' goals, namely having a low "traffic footprint" that 
would make the attack hard to detect.

Please be aware that the patch mentioned above is of proof-of-concept quality: 
the numbers in the adjust_timeout() function were chosen more or less 
arbitrarily, just tuned well enough to successfully mitigate the impact of a 
Slowloris attack in my testing environment.

Regards,
Andreas