Bug#533661: Mitigating the Slowloris HTTP DoS attack
Hello everyone,
Recently, the Slowloris HTTP DoS attack[0] was published, an HTTP-based
Denial-of-Service attack against webservers that consumes resources by opening
a big number of parallel connections and slowly sending incomplete requests
over them. This is a very effective way of DoSing a webserver without
generating a lot of network traffic or putting a high load on the web server
itself, thus making it harder to detect compared to "traditional" DoS attacks
against webservers. Apache 1.x and 2.2.x were shown to be vulnerable against
this kind of attack.
The key concept of the Slowloris attack is slowly sending small parts of an
HTTP request, while the HTTP request is never actually completed. In contrast,
the great majority of legitimate HTTP clients try to send the complete HTTP
request as quickly as possible. Given these assumptions, I developed a simple
but effective proof of concept patch that mitigates this issue in Apache
2.2.11 (the latest stable 2.2 release) as far as possible.
This patch is available under the following URL:
http://synflood.at/tmp/anti-slowloris.diff
The method my PoC patch follows is that it adapts the request timeouts
depending on the current load on the webserver: it regularly computes a load
percentage which describes the ratio of processes that currently process HTTP
requests to the total number of available processes (the PoC patch is prefork
MPM only, but should be easily adaptable to the worker MPM, too). When the
load percentage reaches certain thresholds, the total request timeout is
continuously lowered. At a load of 96 % or higher, the request timeout is set
to a maximum of 1 second (at higher loads even lower), which makes slow
senders quickly run into timeouts. This behaviour frees resources for quick
senders (which are assumed to be legitimate clients in this scenario). In
order to work around this behaviour for an attacker, the delay between sending
packets must be reduced, which defeats one of the main goals of the Slowloris
attack, namely keeping the overall "footprint" of network traffic low.
Even in the worst case (the attacker keeps its delay times very low, I tested
it with slowloris.pl and a delay of 1 second, which already generates a lot of
traffic), legitimate requests are still being responded to correctly, even
though request completion takes noticeably longer than usual. So, the patch is
neither the final nor a perfect solution, but it is practical and demonstrates
that protection against the Slowloris attack can be achieved.
Regards,
Andreas Krennmair
References:
[0]: http://ha.ckers.org/slowloris/
Reply to: