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

Reply via email to