Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
Re: SYN Flooding [info]Alan Cox (coxacableol.net)
Mon, 16 Sep 1996 10:01:37 +0100
- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Dan Stromberg: "Re: BUG in /bin/bash"
- Previous message: Aggelos P. Varvitsiotis: "Re: BUG in /bin/bash"
- In reply to: Perry E. Metzger: "Re: SYN Flooding [info]"
- Next in thread: Perry E. Metzger: "Re: SYN Flooding [info]"
> 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