I don't need no stinking firewall!

Joe Greco jgreco at ns.sol.net
Fri Jan 8 16:48:03 UTC 2010


> All,
>     This thread certainly has been educational, and has changed my 
> perception of what an appropriate outward facing architecture should be.
> But seldom do I have the luxury of designing this from scratch, and also 
> the networks I administer are "small business's".
> My question is at what size connection does a state table become 
> vulnerable, are we talking 1mb dsl's with a soho firewall?
> Or as I suspect we are talking about a larger scale?
> I know there are variables, I am just looking for a "rule of thumb".
> I would not want to recommend a change if it is not warranted.
> But when fatter and fatter pipes become available at what point would a 
> change be warranted.

For small pipes, a simple DoS is trivial enough to jam up the works
without worrying about the state table size.

However, that doesn't mean it isn't smart to get a handle on it. 

The biggest question may be pipe size:  this variable controls the total
possible PPS that can be tossed at the firewall.

If you consider a technology such as 10base-T Ethernet, that's 10 megabits
per second.  When you add up the IFG, MAC preamble, dest/src, MAC type,
payload, and CRC, the smallest Ethernet frame is 84 bytes.  10M/(84*8) =
14880 frames per second.

Now let's say you want to block a SYN flood from hitting your server 
(nobody need tell me that there are obvious problems with this; this 
is an educational exercise).  If your firewall is configured to expire
state table entries for partially opened connections after 15 seconds,
the speed of ethernet combined with the 15 seconds means you need a
table that's 225,000 entries large.

But wait.  If they're blowing 14880 frames per second at you, that
Ethernet's quite full.  You're already getting DoS'ed by capacity.

Further, what happens when the attack moves to simply fully opening
connections?  Your state table is tiny for that...

I know this is NANOG, and it's network-centric.  However, fundamentally,
a stateful firewall fuzzes the boundary between network and server.  It
is taking on some duties that have typically been the responsibility of
the server.  So I'm going to go off on a tangent and say that it may be
useful to consider the state of the art in server technology.

A good UNIX implementation (OpenBSD, FreeBSD, maybe Linux ;-) ) will be
hardened and further-hardenable against these sorts of attacks.  The
server *already* has to do things such as tracking SYN's, except that
they no longer have to - they can issue cookies back and then simply 
forget about it.  If the cookie is returned in the ACK, then a 
connection is established.  A proper implementation of this means that
a server using SYN cookies has an infinitely large SYN queue; packets 
on the network itself are actually the queue.  The technique works and 
scales at 1Mbps as well as it does at 10Gbps.  

Putting a stateful firewall in front of that would be dumb; the server
is completely capable of coping with the superfluous SYN's in a much
more competent manner than the firewall.

I won't go into this in more detail.  You can look to see what the IRC
networks are doing to protect themselves.  They're commonly beat up and
have learned most of the best defense tricks around.

A stateless firewall that can implement filtering policies in silicon
is absolutely a fantastic thing to have, especially when faced with a
DoS for which you can write rules.  Put your servers behind one heck of
a good stateless firewall, and run a well-tuned OS.  You'll be a lot
more DoS-resistant.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.




More information about the NANOG mailing list