I totally agree with you. This first point the lack of tunning of httpd.conf, this kind of attack crash default setup of httpd.conf but a well setup server is harder to kill, specially if you have decreased timeout. With 5 seconds as timeout and a good tuning, slowloris fail...
More granular timeout and maybe adaptative timeout is also IMHO a good way to improve resistance to this kind of attack. 300 seconds is too much and maybe this value could be modified in default httpd. A POST request with a body can have far more reason to be slowed because of the amount of data and time it takes to transfer. a simple GET request contains only headers and should be sent in one time, no need to wait long time here... Matthieu Joe Orton wrote: > On Mon, Jun 22, 2009 at 09:48:46PM -0700, Paul Querna wrote: >> On Sun, Jun 21, 2009 at 4:10 AM, Andreas Krennmair<a...@synflood.at> wrote: >>> Hello everyone, >> ..... >>> 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. >> Mitagation is the wrong approach. >> >> We all know our architecture is wrong. > > Meh. There will always be a maximum to the number of concurrent > connections a server can handle - be that hardware, kernel, or server > design. If you allow a single client to establish that number of > connections it will deny service to other clients. > > That is all that "slowloris" does, and you will always have to mitigate > that kind of attack at network/router/firewall level. It can be done > today on Linux with a single trivial iptables rule, I'm sure the same is > true of other kernels. > > The only aspect of "slowloris" which claims to be novel is that it has > low bandwidth footprint and no logging/detection footprint. To the > former, I'm not sure that the bandwidth footprint is significantly > different from sending legitimate single-packet HTTP requests with > single-packet responses; to the latter, it will have a very obvious > footprint if you are monitoring the number of responses/minute your > server is processing. > > Regardless, the only thing I've ever wanted to see changed in the server > which would somewhat mitigate this type of attack is to have coarser > granularity on timeouts, e.g. per-request-read, rather than simply > per-IO-operation. (one of the few things 1.3 did better than 2.x, > though the *way* it did it was horrible) > > Regards, Joe >
