SYN floods continueh
Avi Freedman
freedman at netaxs.com
Thu Sep 12 09:17:27 UTC 1996
> > 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
More information about the NANOG
mailing list