-----Original Message----- From: Brian Keefer [mailto:chort@smtps.net] Sent: Wednesday, January 06, 2010 3:12 PM To: Brian Johnson Cc: NANOG list Subject: Re: I don't need no stinking firewall!
<SNIP>
It's quite possible to flood the state table on a device with a fraction of the pipe's capacity, in which case a stateful device will fall over where a stateless device would not have. This type of
will definitely degrade the service it's aimed at, and probably degrade other services sharing the same pipe, but won't _necessarily_ kill
attack them
as is the case when a stateful gateway falls over.
This would depend on the nature of the DDoS (how it was crafted). I would agree that a DDoS designed to fill a state table would do this. However, a DDoS can also be designed with large packets to fill up the capacity of the connection. In this case it would depend on the amount of bandwidth available. If total bandwidth / packet size > state table size (rough formula), then your assertion is valid. But if not, then it may be flawed. This goes back to the idea that the network design/goals/intent is an unknown quantity in every statement made on this matter.
Typical scenario is $badguys DDoS one of your webservers. If the gateway is stateless, your webservers grind to a crawl, but your DNS, e-mail, VOIP, etc probably still function to a degree. Contrast that with site-wide outage if your gateway was stateful and crashed/rebooted/refused to pass traffic due to having the state table filled.
I'll give this to you, but this still depends on the previous point. I know that under minimum packet sizes and using a pipe with > 200 Mbps capacity, I have seen a statefull firewall handle a large DDoS just fine. The problem was that the packets that needed to get in to the host couldn't, because the bandwidth was fully utilized. I also know that if the state table on said device were to be filled, the box wouldn't crash or reboot. It would just queue or drop the packets until a state slot became available. The scope of the state table was so large though that it would take a lot more traffic than the operation would ever purchase to fill it up. Remember YMMV. :)
You're not going to be able to stop $sophisticated_badguy from enumerating your services no matter how fancy your gear is. Could you detect a distributed portscan that looks at 5000 proto/IP/port combos per day, across your IP space, each probe coming from a different IP?
I
really doubt it. If you have services listening, someone is going to find them.
So the port scan would tell them about services I want there to be access to. I'm OK with that to a large extent. In practice if I do detect a port scan (usually from a single IP address), this would lead me to take prerequisite steps to block a future attack.
IMO you're better off making sure only the services you intend to provide are listening, and that those services are hardened appropriately for public exposure.
OK. This is obvious to anyone with experience in these things. But I also believe in a layered approach. It never hurts to add more layers to prevent human error or even internal breaches as the different systems are under the control of different equipment (servers, routers, switches, security devices). It's like two supports holding up something without knowing if the other one is doing its job. Both need to pull the full weight in case the other fails.
This topic has probably run it's course; everyone has different opinions and takes away different lessons from their experience. I think it's valuable to challenge the common assumptions (everyone
knows
you need a stateful firewall!) now and then to make sure they actually make sense.
I agree. I just don't want anyone to go throw out their statefull firewalls because you, I or somebody else maybe would do it differently. Or because we have a different type of network or size of network or even goals of our network. So here's the brunt of it... Understand what statefull firewalls are and what they do, every network is different and YMMV. Now, let's go get a beer. :) - Brian CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, copying, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you.