Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 6 Oct 1996 18:31:20 -0700 (PDT)
From:      Michael Dillon <michael@memra.com>
To:        freebsd-hackers@freebsd.org
Subject:   Re: TCP SYN attacks - a simple solution (fwd)
Message-ID:  <Pine.BSI.3.93.961006183107.1501D-100000@sidhe.memra.com>

next in thread | raw e-mail | index | archive | help

---------- Forwarded message ----------
Date: Sun, 6 Oct 1996 20:09:40 -0400 (EDT)
From: Avi Freedman <freedman@netaxs.com>
To: Matthew Kaufman <matthew@scruz.net>
Cc: rex@cs.su.oz.au, bugtraq@netspace.org, nanog@merit.edu, iepg@iepg.org,
    matthew@nic.scruz.net
Subject: Re: TCP SYN attacks - a simple solution

> 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.

I figure that if you steal 4 to 12 bytes for mss storage, 2^20 is still
enough possibilities that you can just rotate your secret every minutes
and test against the old one for 30 seconds...

> -matthew kaufman
>  matthew@scruz.net

Yes.

> 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*

Hopefully there will be a working implementation of this by week's end.
Jeff Weisberg has code which runs on sun3s and (soon, I hope) on other
Suns under SunOS.

This has always seemed to me to be the best way to do things, though an
OS patch to go to hashed-entry into arrays of PCBs is a definite win to
back-implement into SunOS (for example) in general.

Avi




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.93.961006183107.1501D-100000>