OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Bugtraq archives for 3rd quarter (Jul-Sep) 1996: Re: SYN Flooding [info]

Re: SYN Flooding [info]

Alan Cox (coxacableol.net)
Mon, 16 Sep 1996 10:01:37 +0100 

> This helps, but isn't sufficient. The real fix in the Berkeley kernel
> is to us a more efficient infant connection queue than a simple linked
> list, and for the code to adaptively lower the timeout down after the
> size of the open connection queue passes a high watermark. Some

Adaptively lowering the timeout is interesting. It means I lose foreign
email from slow links like Germany and don't notice the attacks so easily
but it definitely has scope. I'll play with this. At the moment Im using
a simple pair of rules in test

1,      No class C net may hold over 1/3rd of the queue. This is to stop
        non spoofed attacks and runaway machines. That fixes attacks from
        providers with half a brain or higher.

2.      Start enforcing a timeout on connect attempts when the queue is over
        33% full.

Im currently politely closing rather than resetting the links I time out until
I've finished looking at the implications of RFC1337 and draft-heavens.

> experiments tend to indicate that with a fews simple fixes like these,
> most machines can actually sustain more packets than an attacker is
> likely to be able to throw at them. At that point, the real problem

For now. What in 3 years time when every big provider is on multiple T3's,
ATM, SMDS whatever ?

> simple linked list to find the connections to kill them. With a hash
> table, you could handle the RSTs fast -- but then, the kernel wouldn't
> fall over when bombarded in the first place.

And the RST's are an issue for data corruption and sequence space reuse.

Alan