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.


Reply via email to