Date: Fri, 14 May 1999 22:50:01 +0200 From: Harold Gutch <logix@foobar.franken.de> To: Brett Glass <brett@lariat.org>, Matthew Dillon <dillon@apollo.backplane.com> Cc: Jared Mauch <jared@puck.Nether.net>, Thamer Al-Herbish <shadows@whitefang.com>, security@FreeBSD.ORG Subject: Re: Forwarded from BUGTRAQ: SYN floods against FreeBSD Message-ID: <19990514225001.A22317@foobar.franken.de> In-Reply-To: <4.2.0.37.19990514133829.0461e220@localhost>; from Brett Glass on Fri, May 14, 1999 at 02:05:51PM -0600 References: <199905140438.VAA97604@apollo.backplane.com> <Pine.BSF.4.05.9905131824250.267-100000@rage.whitefang.com> <4.2.0.37.19990513161529.00c1e3f0@localhost> <Pine.BSF.4.05.9905131824250.267-100000@rage.whitefang.com> <4.2.0.37.19990513202450.0444fca0@localhost> <199905140438.VAA97604@apollo.backplane.com> <19990514072546.A20779@foobar.franken.de> <4.2.0.37.19990514133829.0461e220@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, May 14, 1999 at 02:05:51PM -0600, Brett Glass wrote: > Any technique that requires the originator to receive your > SYN-ACK and generate a specific response before you commit > resources is acceptable. Heck, you don't even really need > a cryptographically strong hash for this. Is Linux really > doing one MD5 per SYN? If so, I can think of a few other > techniques that would give us a speed advantage. We'd be > able to beat them in the benchmarks while still providing > good protection against SYN flooding. > Ah, that's a very good point, I never thought of the speed-question. > One question about "the Linux way of doing it" as described > below. What happens if the secret just happens to be modified > right after the SYN-ACK? Could be you'd drop a connection or > two that was legitimate. Seems like you'd need to test against > an old AND a new secret to avoid the race condition, especially > in the presence of congestion. > Yes, I'd guess so - I haven't had a look at the code itself, so I don't know wether this is actually done, but I'd guess so. > One more point. According to the original BUGTRAQ message, > a cleanup routine is causing problems when the system is > under heavy load. At first glance, this looks like a > consistency problem; the code may be traversing a data structure > that changes out from under it. We need to fix this regardless > of how we handle SYN floods. > This is certainly true, I have no idea why the subject of this thread changed to "How to handle SYN floods" this quickly. I just happen to have read the Linux mailinglist-archives about "their" way to handly SYN-floods only a few weeks ago, found it fairly interesting, so I wondered if there were any actual negative points about it. But you are right - back to the original topic. I checked my 2.2.8 boxes and flooded them with 1 Million SYN packets taking about 1 minute, so that's (roughly) 16000 SYNs per second. I did not manage to kill them with this. bye, Harold -- <Shabby> Sleep is an abstinence syndrome wich occurs due to lack of caffein. Wed Mar 4 04:53:33 CET 1998 #unix, ircnet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990514225001.A22317>