Re: SYN Flooding [info]

[perry () piermont com (Perry E. Metzger)]

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