ak at synflood
Jun 21, 2009, 4:10 AM
Views: 1368
Permalink
|
|
Mitigating the Slowloris DoS attack
|
|
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
|
Mitigating the Slowloris DoS attack
