Date: Tue, 24 Sep 1996 08:01:37 -0700 From: "David E. Tweten" <tweten@frihet.com> To: freebsd-security@FreeBSD.org Subject: Re: comments on the SYN attack Message-ID: <199609241501.IAA05721@ns.frihet.com>
next in thread | raw e-mail | index | archive | help
Andreas.Gunnarsson@emw.ericsson.se said: >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. This sounds similar to another idea relayed to me by a friend, except that the relayed idea looks like it could work the first time. I like it because it follows what I call the Henny Youngman principle of engineering, "If if hurts when you do that, then don't do that." Under a SYN flood, it definitely hurts to have to remember SYNs long enough to pair them with the final ACK. The relayed message follows. What do you think of it? From: djb@koobera.math.uic.edu (D. J. Bernstein) Date: 16 Sep 1996 00:47:44 GMT Subject: Re: SYN Flooding [info] Bruce Momjian <root@candle.pha.pa.us> wrote: > I was suggesting that when the queue is full, you assume the hacker is > attacking you and delete the uncompleted SYN connection requests from > the queue. In the past ten seconds, you've received 1000 SYNs, but you can only remember 10 SYNs. Even if you responded to all 1000 SYNs, each person trying to connect has only a 1% chance of being one of the lucky SYNs that you remembered. So at least 99% of the incoming connections will fail. This is true no matter what strategy you used to decide which SYNs to remember. See? Anyway, PANIX's problem is easy to solve: eliminate the queue. Don't create the TCB until the ACK comes back. To prevent ACK floods, create the outgoing sequence number as a one-way hash of the incoming information (IP addresses, port number, and sequence number), followed by a secret key, followed by a counter that changes every minute. When the handshake comes back, compute the same hash using the last few counters, and throw away the packet if it doesn't match one of the results. Otherwise, set up the TCB, if it doesn't already exist. SMOP. Now, if someone can't see your outgoing packets, he'll have only a one-in-a-billion chance of creating a false connection. Surely he doesn't have enough bandwidth to sustain a denial-of-service attack this way. > Why can't he be tracked down anyway? Because he's probably just sneaking into computer rooms at some fundamentally insecure site like MIT, logging on as root, starting the attack, and never touching the same computer again. ---Dan -- David E. Tweten | 2047-bit PGP Key fingerprint: | tweten@frihet.com 12141 Atrium Drive | E9 59 E7 5C 6B 88 B8 90 | tweten@and.com Saratoga, CA 95070-3162 | 65 30 2A A4 A0 BC 49 AE | (408) 446-4131 Those who make good products sell products; those who don't, sell solutions.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609241501.IAA05721>