From owner-freebsd-security Fri May 14 13:51:35 1999 Delivered-To: freebsd-security@freebsd.org Received: from foobar.franken.de (foobar.franken.de [194.94.249.81]) by hub.freebsd.org (Postfix) with ESMTP id B236E14EAD for ; Fri, 14 May 1999 13:51:15 -0700 (PDT) (envelope-from logix@foobar.franken.de) Received: (from logix@localhost) by foobar.franken.de (8.8.8/8.8.5) id WAA22501; Fri, 14 May 1999 22:50:01 +0200 (CEST) Message-ID: <19990514225001.A22317@foobar.franken.de> Date: Fri, 14 May 1999 22:50:01 +0200 From: Harold Gutch To: Brett Glass , Matthew Dillon Cc: Jared Mauch , Thamer Al-Herbish , security@FreeBSD.ORG Subject: Re: Forwarded from BUGTRAQ: SYN floods against FreeBSD References: <199905140438.VAA97604@apollo.backplane.com> <4.2.0.37.19990513161529.00c1e3f0@localhost> <4.2.0.37.19990513202450.0444fca0@localhost> <199905140438.VAA97604@apollo.backplane.com> <19990514072546.A20779@foobar.franken.de> <4.2.0.37.19990514133829.0461e220@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <4.2.0.37.19990514133829.0461e220@localhost>; from Brett Glass on Fri, May 14, 1999 at 02:05:51PM -0600 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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 -- 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