Date: Thu, 19 Sep 1996 22:09:54 -0600 From: Warner Losh <imp@village.org> To: security@FreeBSD.org Subject: comments on the SYN attack Message-ID: <199609200409.WAA25123@rover.village.org> In-Reply-To: Your message of Thu, 19 Sep 1996 01:10:53 PDT
next 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609200409.WAA25123>