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
