Home page logo
/

bugtraq logo Bugtraq mailing list archives

Re: SYN Flooding [info]
From: perry () piermont com (Perry E. Metzger)
Date: Mon, 16 Sep 1996 08:47:24 -0400


Alan Cox writes:
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

No it doesn't. Not at all. This only impacts the timeout on the infant
connection queue. Even on the slowest links, you typically get an ACK
to the SYN-ACK within a couple of RTTs, and even if you throw away the
PCB, you will probably get another SYN from the counterparty
shortly. (Its true that some links can't do one packet per RTT, but
Van Jacobson's algorithm dies on those links anyway). Provided you
don't jocky the adaptive timeout below, say, five seconds, you
are probably just fine. Things that last the full timeout are
typically going to be the bad guy and not the good guy.

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.

Thats not particularly useful. Any solution that will stop random
source SYNs will probably stop non-random ones pretty easily.

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

Well, there is a timeout already -- you probably want to adaptively
lower the thing to try to maintain no more than a target number of
open infant connections, remembering to kick out existing connections
that are older than the new timeout in order to clear the queue.

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 ?

Hopefully in three years most of the world will be agressively
filtering.

Perry



  By Date           By Thread  

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