Date: Fri, 14 May 1999 14:05:51 -0600 From: Brett Glass <brett@lariat.org> To: Harold Gutch <logix@foobar.franken.de>, 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: <4.2.0.37.19990514133829.0461e220@localhost> In-Reply-To: <19990514072546.A20779@foobar.franken.de> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. 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. --Brett At 07:25 AM 5/14/99 +0200, Harold Gutch wrote: >On Thu, May 13, 1999 at 09:38:16PM -0700, Matthew Dillon wrote: > > The only way to mitigate the SYN flooding problem on the host side is to > > greatly increase the size of the listen queue, but even this does not work > > too well. > > >What about the Linux way of doing it, that is by creating an >MD5-hash over the source- and destination IP and port and a >secret which is incremented say every minute and using the result >as a base for the own sequencenumber. > >You don't lose a socket before you get the third handshake >packet and you can verify the sequencenumber using MD5 again. > >I found this idea to be quite interesting when reading about it >the first time, and I currently don't see any negative side >effects from it. > >The FreeBSD approach (just discarding the oldest socket in >SYN_RCVD state when the backlog gets too high) works often enough >aswell, but might cause problems if the flooder sends you more >SYNs than your backlog can handle in a shorter timeframe than >your SYN|ACK needs for it's way back to somebody who tries to >establish a normal connection and his answer back to you takes. > >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 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?4.2.0.37.19990514133829.0461e220>