Re: SYN flood protection strategies (Was: Post connection SYN)

[Paul Robertson <proberts () patriot net>]

On Fri, 17 Oct 2003, Mikael Olsson wrote:

> Paul Robertson wrote:
> > Mikael Olsson wrote:
> > > OR you set up the firewall to answer SYNs on behalf of the server
> > > and wait for the handshake with the client to complete before doing
> > > the handshake with the server [...]
> >
> > You'd still want some sort of rate limit to stop floods and broken
> > clients, unless you think a ring buffer solves that probelm?  Otherwise,
> > you've just moved flood protection from N servers to less than N
> > firewalls, no?
>
> I've moved the problem from servers with perhaps as low as 5 embryonic
> SYN sockets per port, that block for a full minute when the list is 
> full, to a firewall that can handle hundreds of thousands of states, 
> embryonic or not, and knows to nuke old embryonic SYNs when the 
> state table is full.

I'd hope in this day and age that any machine serving content to the 
public at large would be slightly more resiliant than that...

> Yes, there are TCP stacks that handle SYN floods much better than
> what I described above (the linux crowd will undoubtedly cheer in with
> "all the world is a linux box!" here), but those that do handle it well
> enough on their own simply don't need the firewall to do SYN flood 
> protection for them -- right?

Um, the point wasn't that the N to <N move was necessarily bad, just that 
you're either stuck with rate limiting of some sort, or a ring buffer of 
some sort, or you've recreated the problem all over again, just in a 
different place.

I happen to think that rate limits are interesting when applied to this 
sort of thing, because if you can add additional information (such as 
originating AS from an radb sort of thing) then you can provide some 
semblance of QoSishness...

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
proberts () patriot net      which may have no basis whatsoever in fact."
probertson () trusecure com Director of Risk Assessment TruSecure Corporation

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards