|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: SYN floods continueh
> > 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 - - - - - - - - - - - - - - - - -
|