[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

Andreas Krennmair

[0]: http://ha.ckers.org/slowloris/

Reply to: