[3357] in bugtraq
Re: SYN Flooding [info]
daemon@ATHENA.MIT.EDU (Alan Cox)
Mon Sep 16 15:02:58 1996
Date: Mon, 16 Sep 1996 10:01:37 +0100
Reply-To: Alan Cox <coxa@cableol.net>
From: Alan Cox <coxa@cableol.net>
X-To: perry@piermont.com
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@netspace.org>
In-Reply-To: <199609132011.QAA14741@jekyll.piermont.com> from "Perry E.
Metzger" at Sep 13, 96 04:11:48 pm
> 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
