From owner-freebsd-security Thu Sep 19 21:57:18 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA10133 for security-outgoing; Thu, 19 Sep 1996 21:57:18 -0700 (PDT) Received: from psychotic.communica.com.au (gw.communica.com.au [203.8.94.161]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA10092 for ; Thu, 19 Sep 1996 21:57:10 -0700 (PDT) Received: from communica.com.au (newton@frenzy [192.82.222.1]) by psychotic.communica.com.au (8.6.12/8.6.9) with SMTP id OAA08686; Fri, 20 Sep 1996 14:23:50 +0930 Received: by communica.com.au (4.1/SMI-4.1) id AA09567; Fri, 20 Sep 96 14:23:18 CST From: newton@communica.com.au (Mark Newton) Message-Id: <9609200453.AA09567@communica.com.au> Subject: Re: comments on the SYN attack To: imp@village.org (Warner Losh) Date: Fri, 20 Sep 1996 14:23:17 +0930 (CST) Cc: security@FreeBSD.org In-Reply-To: <199609200409.WAA25123@rover.village.org> from "Warner Losh" at Sep 19, 96 10:09:54 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Warner Losh wrote: > : (4) How do we fix this once and for all? > : > : Unfortunately, this is a vulnerability in the design of TCP. > > Question: Wouldn't randomly dropping SYN packets when the above limits > are triggered "help" the problem. I'd suggest that keeping the SYN list sorted by arrival time and dropping the oldest SYN whenever resources are scarse would be a better solution (it's more deterministic, for a start. Also, one of the evil things about random number generators is that they're not random...) However, even that won't "solve" the problem: A determined SYN bomber would merely have to ensure that he sent packets quickly enough to make the queue cycle completely within the 200mSec or so that one can reasonable expect a SYN-SYN/ACK-ACK exchange to take (keep the un-ACK'ed SYNs walking thorugh the list LED-chaser style). That's a somewhat higher transmission rate than the one required to cause denial of service under current implementations, but it's still well within the realms of possibility :-/ If the bomber isn't that determined, dropping the oldest SYN will ensure that those SYNs which aren't the oldest (eg: the one you just planted onto the queue by typing "telnet hostname") don't get dropped unless load is exceptional. > 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? Indeed. And as the CERT advisory this morning pointed out (and as the firewalls list has been discussing for over a week), if ISPs would put anti-spoofing access lists on their *OUTBOUND* interfaces then they could ensure that if SYN bombing isn happening it isn't from their site. - mark --- Mark Newton Email: newton@communica.com.au Systems Engineer Phone: +61-8-8373-2523 Communica Systems WWW: http://www.communica.com.au