Date: Mon, 23 Sep 1996 08:48:35 +0200 (MET DST) From: Andreas Gunnarsson <Andreas.Gunnarsson@emw.ericsson.se> To: Warner Losh <imp@village.org> Cc: Darren Reed <avalon@coombs.anu.edu.au>, security@FreeBSD.org Subject: Re: comments on the SYN attack Message-ID: <Pine.GSO.3.92.960923082022.1588B-100000@scyld> In-Reply-To: <199609230114.TAA28187@rover.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 --> <SEQ=100><CTL=SYN> --> SYN-RECEIVED
3. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
4. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED
5. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK><DATA> --> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.3.92.960923082022.1588B-100000>