[4322] in North American Network Operators' Group
Re: SYN floods continueh
daemon@ATHENA.MIT.EDU (Avi Freedman)
Thu Sep 12 06:19:40 1996
From: Avi Freedman <freedman@netaxs.com>
To: steve@barstool.com (Steven L. Johnson)
Date: Thu, 12 Sep 1996 05:17:27 -0400 (EDT)
Cc: alexis@panix.com, nanog@merit.edu
In-Reply-To: <199609120405.AAA18683@johnson.jvnc.net> from "Steven L. Johnson" at Sep 12, 96 00:05:54 am
> > Anyway. Point is this: We can't take too much more of this, nor can our
> > customers. I have yet to hear *anyone* come up with any ideas even remotely
> > reasonable for how to deal with this situation, long term, except for the
> > filtering that Avi, Perry, and I have been promoting these last few days.
>
> If hardening all hosts against forged source address SYN attacks is not
> feasible then perhaps providing a hardened device in front of server
> farms is. How about something that spoofs the TCP connection setup,
> uses minimal resources for unconfirmed TCP connections and perhaps more
> aggressively times out these connections when under attack. Basically
> this firewall would not forward a SYN packet to a server from an unknown
> host until that host had properly ACKd a SYN ACK from the firewall. The
> resulting connection would require that the firewall adjust seq/ack
> numbers before forwarding the packets between the host and server as
> the pseudo random seq number used in the initial SYN ACK from the firewall
> to the host will be different from that proposed eventually by the server.
> And it makes sequence guessing attacks much harder as well.
>
> An idea?
I've been focusing on routing for the last year and not kernel hacking, but
a better data structure (methinks for the whole kernel) for pending
embryonic connections is required. Hacking algorithms is easy; kernel data
structures hacking requires me to find my design & imp of the BSD os book.
> -Steve
Avi
