Home page logo
/

bugtraq logo 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



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault