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...


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

Reply via email to