Date: Fri, 20 Sep 1996 11:36:08 -0500 (CDT) From: Karl Denninger <karl@Mcs.Net> To: imp@village.org (Warner Losh) Cc: security@freebsd.org Subject: Re: comments on the SYN attack Message-ID: <199609201636.LAA14219@Jupiter.Mcs.Net> In-Reply-To: <199609200409.WAA25123@rover.village.org> from "Warner Losh" at Sep 19, 96 10:09:54 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > : (4) How do we fix this once and for all? > : > : Unfortunately, this is a vulnerability in the design of TCP. A fair > : number of protocol experts are musing over ways to fix this. > : The best solutions to date require an authenticated IP layer. > : > : There are changes being made to the Internet infrastructure which will > : make it more difficult for attackers to operate without detection, but > : for the time being, without a change to the TCP protocol or the addition > : of authentication below TCP, there simply is no "solution" that isn't as > : bad as the problem itself, despite the claims of "anti-SYN" product > : vendors. > > Question: Wouldn't randomly dropping SYN packets when the above limits > are triggered "help" the problem. The reasoning is that if I'm trying > to establish a connection, I'll send a SYN packet, then another and so > on until I time out. Since I'm generating multiple good SYN packets, > losing one or two of them won't hurt. However, dropping bogus SYN > packets under heavy load will help to reduce that load somewhat. The > longer the queue is, the more likely it should be that a SYN gets > dropped. > > Much like the RED routers that were recently researched by LNLL. > > Or has this been considered and a flaw been found? > > Generally, one can't prevent the SYN packets from arriving at your > machine for serves one provides to the net. However, one can be > intellegent about what one listens to, can't one? > > Warner Let's examine this idea: You have a listen queue of size "N". If your queue is full and you receive another packet, you drop the *OLDEST* (first in) connection and add the new SYN. The effect of this is that the *probability* will favor the "bad guy" getting dropped, and the legitimate users will likely get serviced *before* they get all the way to the end of the queue -- assuming it is a reasonable length (say, 200-300 entries). Worst case is that a legit connection will have to be retried (SYN reissued) if it *does* get dropped, but given a reasonable RTT to the other end this just shouldn't happen (the ack to the other and and the ack back to you should happen first). This is "radiation hard" against anyone with even a reasonably good net connection; if they guy is behind a DS-3 you're honked regardless (unless you make the queue positively huge, and that has other bad effects since the tcbs are forward-linked in a list and must be searched sequentially) but even in that case recovery is instantaneous when the flooding stops. Vernon proposed this and has tested something similar. I am looking into the code changes (they look somewhat ugly due to the possibility of locking requirements) to do this in FreeBSD. Its not a 5 minute patch, but it certainly looks like something I can cook up and test if nobody else has in a few hours. I ALSO understand there may be a version of this patch floating around already for FreeBSd. If it exists, I'd like to at least look at and validate it in our labs. Thanks. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1 from $600 monthly; speeds to DS-3 available | 23 Chicagoland Prefixes, 13 ISDN, much more Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | Home of Chicago's only FULL Clarinet feed!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609201636.LAA14219>