Re: [Fwd: Slowloris]

[Dirk-Willem van Gulik <di...@webweaving.org>]

(moved to dev@ - as this issue is now perfectly public).

Ben Laurie wrote:
> Dirk-Willem van Gulik wrote:
>> Ben Laurie wrote:
>>> What does that matter? If you need to do it less to Apache, then Apache
>>> is broken in comparison to the others.
>>>
>> Completely agreed - no need to get into a spitting match as to whom is
>> most broken. We had the same problem in 96 or so - and they where a
>> total pain to deal with. Options of dealing with this can be
>>
>> -    Very agressive timeouts and intentionally delaying/increasing the
>> cost of
>>      the TCP setup - but you are in freebsd/solaris style kernel filters.
>>
>> -    Very agressive timeouts generally - but you penalize the 14k4 modem
>> users.
>>
>> -    Binning users after a while in such a group - but then you penalize
>> certain
>>      ISPs or NAT-blocks.
>>
>> -    Not do much - but a graded response when you get resource tight; i.e.
>>      start prioritizing 'active' connections over slow ones. Either by
>> making the
>>      timeouts an exponentional function of the load or by some simple
>> binning
>>      (which is what we did in phase 2).
>>
>> -    Hand off (too) inactive conncetions to something cheaper - this is
>> what
>>       we did in the final phase - using a single thread, select() loop
>> with fixed buffer
>>      footprint. However that used a solaris inter process 'file
>> descriptor passing'
>>      message - which I guess is out of vogue now.
>
> Why? This is actually quite in vogue for security reasons :-)

Sounds I have missed something. Blush :) (Especially after reading up on 
all the work in openbsd :)!).

Having read up on it a bit - so fair to conclude that the mechanism for 
passing file descriptors between processes is now a solid cross platform 
thing ? But I am no seeing something easy in APR ? Do we have modules 
already doing this ?

>> And really - in this
>> day and
>>      age you propably want to tell your
>> switch/router/network-piece-of-kit/dog
>>      to move the TCP to another machine.

And I have no idea if there are any API's for this which are cross vendor.

>> -    Seriously rewrite apache/add a worker which mimics the
>> accept_filter.ko
>>      of freebsd somewhat in that it as a single threaded async select() loop
>>      which buffers things up until they are cooked enough (i.e. the
>> client has
>>      enough skin in the game) to hand off to a real worker.
>>
>> Any more approaches possible ?

Dw

Re: [Fwd: Slowloris]

[Christian Folini <ch...@netnea.com>]

On Mon, Jun 22, 2009 at 02:23:12PM +0200, Dirk-Willem van Gulik wrote:
>>> -    Seriously rewrite apache/add a worker which mimics the
>>> accept_filter.ko
>>>      of freebsd somewhat in that it as a single threaded async select()
>>> loop
>>>      which buffers things up until they are cooked enough (i.e. the
>>> client has
>>>      enough skin in the game) to hand off to a real worker.

Is not this mechanism limited to HTTP and misses HTTPS? So I
do not think it can be a general solution.

I am not an apache developer, but would not the event mpm be of
some use in this case?

Otherwise, I see a lack of granular timeout values. RSnake's
latest take can be fought with a low KeepAliveTimeout
(-> http://ha.ckers.org/blog/20090620/http-longevity-during-dos/)
One should be able to assign timeouts to other request phases too.
And it should be possible to set these timeouts in a way that a
subsequent header or a single post payload byte is not resetting
them to zero again.

Just my 2 cents

Christian Folini

-- 
If you shut your door to all errors truth will be shut out.
--- Rabindranath Tagore