Bugtraq mailing list archives
Re: SYN Flooding [info]
From: coxa () cableol net (Alan Cox)
Date: 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
Current thread:
- SYN Flooding [info] Christopher Klaus (Sep 13)
- Re: SYN Flooding [info] Perry E. Metzger (Sep 13)
- Re: SYN Flooding [info] Alan Cox (Sep 16)
- Re: SYN Flooding [info] Perry E. Metzger (Sep 16)
- Re: SYN Flooding [info] Alan Cox (Sep 16)
- Re: SYN Flooding [info] Alan Cox (Sep 16)
- Re: SYN Flooding [info] Perry E. Metzger (Sep 13)
- Re: SYN Flooding [info] Alan Cox (Sep 16)