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.