From owner-freebsd-security Mon Sep 23 01:28:57 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA24334 for security-outgoing; Mon, 23 Sep 1996 01:28:57 -0700 (PDT) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA21971 for ; Mon, 23 Sep 1996 01:23:43 -0700 (PDT) Received: from glacier.wise.edt.ericsson.se (glacier-ext.wise.edt.ericsson.se) by mail.crl.com with SMTP id AA16032 (5.65c/IDA-1.5 for ); Mon, 23 Sep 1996 01:24:11 -0700 Received: from poem.emw.ericsson.se (poem.emw.ericsson.se [136.225.97.22]) by glacier.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-0.9) with SMTP id IAA29878; Mon, 23 Sep 1996 08:47:58 +0200 (MET DST) Received: from shakespeare.emw.ericsson.se (shakespeare.emw.ericsson.se [136.225.97.10]) by poem.emw.ericsson.se (8.6.12/8.6.12) with SMTP id IAA21081; Mon, 23 Sep 1996 08:44:41 +0200 Received: from scyld.nis.gsunix (scyld.emw.ericsson.se) by shakespeare.emw.ericsson.se (4.1/LME-DOM-2.2.4) id AA17983; Mon, 23 Sep 96 08:51:39 +0200 Received: from localhost by scyld.nis.gsunix (SMI-8.6/SMI-SVR4) id IAA01617; Mon, 23 Sep 1996 08:48:36 +0200 Date: Mon, 23 Sep 1996 08:48:35 +0200 (MET DST) From: Andreas Gunnarsson X-Sender: qmwagu@scyld Reply-To: Andreas Gunnarsson To: Warner Losh Cc: Darren Reed , security@FreeBSD.org Subject: Re: comments on the SYN attack In-Reply-To: <199609230114.TAA28187@rover.village.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I just had an idea... How about caching the ACKs from the source and then give the next SYN for that host (perhaps combined with the destination port?) a better chance for survival? The problem that some programs give up when they receive an RST won't be solved since it's already too late, but in that case the odds are better the user will probably retry soon enough to take advantage of the higher probability. It'll have to be a little more to it than that though, since it would be possible to generate a ACK flood accompanying the SYN flood. I'll steal Figure 7 from RFC 793: TCP A TCP B 1. CLOSED LISTEN 2. SYN-SENT --> --> SYN-RECEIVED 3. ESTABLISHED <-- <-- SYN-RECEIVED 4. ESTABLISHED --> --> ESTABLISHED 5. ESTABLISHED --> --> ESTABLISHED Basic 3-Way Handshake for Connection Synchronization Figure 7. We see that there is a way to distinguish genuine ACKs from forged ones. The number 300 is provided by TCP B, and if TCP B makes the number depending on source host address, source port and destination port number as well as the clock, it could cache the ACKs that lie within a reasonable range. Forging hosts won't know the algorithm (it could be randomized in a clever way, and the algorithm could be changed when an attack is detected) and fake ACKs would have little chance to guess a sequence number (32 bits) in the accepted range. As I already said, this will only help after the damage is done, but future connections will benefit from the knowledge that the host is probably a friendly one. I don't know if this approach would be good enough to be worth implementing. The ACK cache will need some memory which could otherwise be used by the SYN cache, and there are probably other problems I haven't foreseen. Andreas ------------------------------------------------------------------------------ Andreas Gunnarsson andreas.gunnarsson@emw.ericsson.se