Path: koobera.math.uic.edu!djb
From: djb@koobera.math.uic.edu (D. J. Bernstein)
Message-ID: <1996Sep1600.47.44.4875@koobera.math.uic.edu>
Date: 16 Sep 1996 00:47:44 GMT
Newsgroups: alt.security,comp.security.unix,comp.security.misc,comp.security,comp.protocols.tcp-ip
Subject: Re: SYN Flooding [info]
References: <51bt5b$gho@client2.news.psi.net> <51h312$n9p@picasso.op.net> <51hh8o$ohn@netnews.upenn.edu> <51i13f$i3d@picasso.op.net>
Organization: IR

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