Re: ICMPs & syn flood fix to prevent spoofing (previously "nuke?")

Dan Merillat (Dan@merillat.org)
Sun, 27 Oct 1996 08:31:43 -0500 (EST)


On Wed, 23 Oct 1996, Alan Cox wrote:

> Date: Wed, 23 Oct 1996 22:25:10 +0100 (BST)
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> To: cowzilla@gwbbs.northeast.net
> Cc: zac@tombstone.hp.net, linux-kernel@vger.rutgers.edu
> Subject: Re: ICMPs & syn flood fix to prevent spoofing (previously "nuke?")
>
> I've not seen such changes, but I'd be happy to add contributed code that
> smart checks the body of ICMP errors to see if they look real. It will stop
> the most clueless. At the end of the day only the beating of sense into big
> providers to filter fake source addresses coming FROM their networks will
> solve these problems for good. Unfortunately it doesn't make them thousands
> of dollars so they don't seem to give a shit.

Well... dunno about that. MCI was screaming their lungs out about the
SYN-flood crap... apparently it was hurting them bigtime. So perhaps they
will lean on the others. (dream on, I know...) ;-(

> > One final thing: I would also think it would greatly help linux's image
> > if the syn flood protection patch became a standard feature of the kernel
> > (the strong one that uses encryption to generate munged sequence numbers
> > instead of dropping random connections from the queue). This would make
>
> The encryption based one doesnt currently work right. It breaks big windows,
> TTCP some stacks etc. I've been intentionally avoiding it.

Hmm... what all does it break? I thought it only kicked in when the queue was
full. Oh well, the random-drop-largequeue works well anyway.

(And where is the list about syn-securesequence? I know I saw something
about it.)

--Dan