From owner-freebsd-hackers Sun Oct 6 18:35:04 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA24580 for hackers-outgoing; Sun, 6 Oct 1996 18:35:04 -0700 (PDT) Received: from pinky.junction.net (pinky.junction.net [199.166.227.12]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA24574 for ; Sun, 6 Oct 1996 18:35:01 -0700 (PDT) Received: from sidhe.memra.com (sidhe.memra.com [199.166.227.105]) by pinky.junction.net (8.6.12/8.6.12) with ESMTP id RAA16832 for ; Sun, 6 Oct 1996 17:48:56 -0700 Received: from localhost (michael@localhost) by sidhe.memra.com (8.6.12/8.6.12) with SMTP id SAA01745 for ; Sun, 6 Oct 1996 18:30:14 -0700 Date: Sun, 6 Oct 1996 18:30:13 -0700 (PDT) From: Michael Dillon To: freebsd-hackers@freebsd.org Subject: Re: TCP SYN attacks - a simple solution (fwd) Message-ID: Organization: Memra Software Inc. - Internet consulting MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ---------- Forwarded message ---------- Date: Sun, 6 Oct 1996 16:30:14 -0700 From: Matthew Kaufman To: rex@cs.su.oz.au, bugtraq@netspace.org, nanog@merit.edu, iepg@iepg.org Cc: matthew@nic.scruz.net Subject: Re: TCP SYN attacks - a simple solution Original message <199610062314.TAA29781@merit.edu> From: rex@staff.cs.su.oz.au (Rex di Bona) Date: Oct 7, 8:10 Subject: TCP SYN attacks - a simple solution > ... > I propose a solution where the initial sequence number is calculated > (not random), and is based on a cryptographic calculation of the > senders Initial Sequence Number, the ports, and a "per boot" > secret number. In this way the initial packet can be discarded, > and on receipt of the third SYN packet can be recalculated. ... The idea has been floated before, and I believe it to be the right solution to this problem. However, I have some suggested improvements: 1. The use of a "per boot" secret number allows an attacker to poll your machine to deduce the secret, and then attack you with that knowledge. A solution to this problem is to use a rapidly changing secret, the pattern of which cannot be easily deduced, and a sliding window of acceptance. (If the hash doesn't match the current scheme, but matches the scheme we were using in the past N seconds, then accept the packet) The change interval needs to be short enough that, by the time an attacker has been able to compute the next number, the window for accepting that has closed. 2. The TCP specification allows data to ride along with the initial SYN, and requires that after the three-way handshake, that the data be presented to the application layer. One solution is to realize that very few implementations take advantage of this, and simply not accept this form of SYN. A second solution is to NOT ack the data that is riding along, but the TCP state machine definition has some holes here which may not work for all implementations. The solution of buffering those SYN's which contain data is unacceptable, because attackers will simply switch to sending SYNs with data. I believe that switching to this sort of scheme would also thwart most attacks which rely on sequence number prediction, and save memory significantly over schemes which simply increase the number of TCBs allowed. -matthew kaufman matthew@scruz.net ps. I've been meaning to write this entire scheme, with the enhancements I propose here, as a draft specification, but I keep getting interrupted by flooded phone rooms and the like this weekend. *sigh*