Re: [fw-wiz] SYN flood protection strategies (Was: Post connection SYN)
From: Paul Robertson (proberts_at_patriot.net)
To: Mikael Olsson <firstname.lastname@example.org> Date: Fri, 17 Oct 2003 11:54:33 -0400 (EDT)
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
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 D. Robertson "My statements in this message are personal opinions
email@example.com which may have no basis whatsoever in fact."
firstname.lastname@example.org Director of Risk Assessment TruSecure Corporation
firewall-wizards mailing list