Re: SYN floods continueh

[Avi Freedman <freedman () netaxs com>]

> > 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

- - - - - - - - - - - - - - - - -