RE: I don't need no stinking firewall!

["Brian Johnson" <bjohnson () drtel com>]

> -----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
attack
> will definitely degrade the service it's aimed at, and probably
degrade
> other services sharing the same pipe, but won't _necessarily_ kill
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.