D/DoS mitigation hardware/software needed.

Darren Bolding darren at bolding.org
Tue Jan 5 10:04:47 UTC 2010

Comments inline.

To reiterate- my entire point is that stateful firewalls are at least
sometimes useful in front of large websites.  Something of a veer off of the
original topic, but not an at all useless exercise IMHO.

On Mon, Jan 4, 2010 at 11:47 PM, Dobbins, Roland <rdobbins at arbor.net> wrote:

> On Jan 5, 2010, at 2:38 PM, Darren Bolding wrote:
> > * Defense in depth.  You've never had a host that received external
> traffic ever accidentally have iptables or windows firewall turned off?
>  Even when debugging a production outage or on accident?
> Again, policy should be enforced via stateless ACLs in router/switch
> hardware capable of handling mpps.  'Stateful inspection' where in fact
> there is no useful state to inspect is pointless.

Stateful policies help protect against misbehaving software, operations
error, malicious internal activity, external attackers and
trojans/viruses/bots making outbound connections to arbitrary ports anywhere
on the Internet.  Seems to have a point to me.  See my previous point about
blocking outbound connections.

If you allow internal hosts to make connections out to any port on any ip,
then perhaps this point is invalid.  But lots of people _don't_ allow
outbound from any to any/any, and thats a good thing in my book.

As for performance, you can get .9mpps stateful firewalls for reasonable
prices, and gear exists that can scale up to 15mpps.

> * Location for IDS/IDP.
> Non-sequitur, as these things have nothing to do with one another (plus,
> these devices are useless, anyways, heh).
The gear I'm talking about above supports IDP on the same platform.  If I am
going to deploy an IDP, why wouldn't I choose one that is flow based so it
blocks attacks rather than send out panicked RST's in response to attacks,
and which has a stateful firewall included (yes, any flow based IDP is
essentially a stateful firewall, and I suspect that a well managed IDP with
customized rules is similar in functionality to what WAF's do out of the
box.  In fact one vendors WAF product functionality pre-trained out of the
box is snort rules)

> > * Connection cleanup, re-assembling fragments, etc.
> Far, far, far better and more scalably handled by the hosts themselves
> and/or load-balancers.

Huh, I would have sworn I've seen fragment based attacks on certain linux
kernels and Windows systems.  I'm sure it won't ever happen again.

Load-balancers may be a good place for this, but there are good reasons that
you would prefer to have this taken care of as close to ingress as possible.
 For example, if you want to compare packet flows of a connection on either
side of a load-balancer, it is easier to do that if the incoming connections
have already been cleaned up.

> > * SYN flood protection, etc.
> Firewalls simply don't handle this well, marketing claims aside.  They
> crash and burn.

I believe that to have been true in the not so recent past, I don't think it
is true of more recent equipment.

> > * Single choke point to block incoming traffic deemed undesirable.
> Again, policy should be enforced via stateless ACLs in router/switch
> hardware capable of handling mpps.

A firewall with easier to use CLI, web UI, management station and API is a
much easier way to implement this and offers lots of control for time-of-day
based ACL's, etc. etc.  I like screening routers, and in a DOS situation I
would recommend blocking as close to ingress as possible (preferably outside
your own network!) but for typical blocking of nuisance connections, full
featured firewalls that can be integrated with a configuration change
tracking tool are a better way to go.

And what about when the way of identifying undesirable traffic is something
other than the source/dest ip/port such as a URI?  (more of an argument for
an IDP than a simply stateful firewall)

> > * Single log point for inbound connections for analysis and auditing
> requirements.
> Contextless, arbitrary syslog from firewalls and other such devices is
> largely useless for this purpose.  NetFlow combined with server/app/service
> logs is the answer to this requirement.

Really?  How does netflow show me that a packet was dropped because of rule
X?  Or permitted because of rule Y?  It's great at showing me data about the
flow that was extant, but it doesn't tell me the context of the enforcement
performed on it.  I can assure you that there is a use in looking over
denied packet logs.  Firewall logs provide _more_ context than netflow.

For DOS detection I get that netflow is probably the best tool to use- not
arguing that- you made the statement that stateful firewalls are always
useless in front of large websites/webservers.

I am saying that they are usefull, at least some of the time, and that it is
common for them to be deployed in that manner.

> > * Allows outbound traffic enforcement.
> Again, policy should be enforced via stateless ACLs in router/switch
> hardware capable of handling mpps.

So you advocate allowing any packet with ACK set into the internal network?
Again, stateful firewalls make this much less of a management headache.

> > * Allows conditional inbound traffic from specific approved external
> hosts- e.g. a partner.
> Again, policy should be enforced via stateless ACLs in router/switch
> hardware capable of handling mpps.

See above :^)

> > * Some firewalls allow programmatic modification of configurations with
> all the benefits/pain that brings.  This is alongside traditional CLI and
> GUI interfaces.
> Ugly, brittle, siloed, to be avoided at all costs.

But doing the same thing across hundreds or thousands of web servers via
automated systems = good?
Personally I like being able to authorize a lower-tech-savvy member of
another team to initiate a temporary configuration change via a tool rather
than have to wait for the calvary to show up.


> * In some/many cases a zone based firewall configuration can be much
> easier to work with than a large iptables config.  Certainly the management
> tools are better.
> Again, policy should be enforced via stateless ACLs in router/switch
> hardware capable of handling mpps.


> > * Yeah, auditors like it.
> Education is the answer here.
> ;>

If only....

> -----------------------------------------------------------------------
> Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
>    Injustice is relatively easy to bear; what stings is justice.
>                        -- H.L. Mencken

--  Darren Bolding                  --
--  darren at bolding.org           --

More information about the NANOG mailing list