Messages in this thread | ![/](/images/icornerl.gif) | | Date | Sun, 27 Oct 1996 08:31:43 -0500 (EST) | From | Dan Merillat <> | Subject | Re: ICMPs & syn flood fix to prevent spoofing (previously "nuke?") |
| |
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
| ![\](/images/icornerr.gif) |