D/DoS mitigation hardware/software needed.

Darren Bolding darren at bolding.org
Tue Jan 5 07:38:38 UTC 2010

I actually agree with most of this, but want to correct a clearly
inadvertent error below, and make a couple of points.

PCI DSS does not require a "Web application firewall".  It requires that OR
an independent audit of all code within PCI scope by a third party.  If a
WAF is used, it "only" need be deployed in such a manner as to protect
devices inside of PCI scope (depending on design, this may or may not
include everything that has public exposure).  The powers that be specified
additional methods by which PCI compliance could be satisfied other than
just these two after the wailing of the masses.  I don't know off the top of
my head if those other methods will be acceptable in 2010.

Personally, I believe a DOS detection/prevention system is typically going
to be best placed between screening routers/switches and the next L3/L4
aware device- generally you will want it (or them) to be as close to your
ingress edge as you can put it- why allow DOS traffic to go further
downstresm?  So I suspect Roland and I agree on that fwiw.

Earlier, Roland mentions load-balancers and firewalls as both being
susceptible to state-table overflows.  Certainly this is possible and
happened in the past, and it argues for a DOS prevention device being in
front of them.  At least one modern high-end load balancer handles this well
and is in front of a large number if not the majority of major sites.  It is
possible to build equipment that can handle vast numbers of state entries
and handle lookups into them in very attractive big O's.  It is also
possible to build systems that gracefully handle table exhaustion and enter
into aggressive reaping modes.  This has been empirically proven to me wrt
load-balancers.  Some device is going to have to handle the state and insert
itself into the path- even if that is a lone webserver.  I maintain that
there is no reason to believe that it is not possible for a firewall to do
that as well as a load-balancer.

As for whether you should have a stateful firewall in front of a production
web server farm, I understand Roland's point.  However, I will say that
there are many reasons why people put firewalls in front of webservers- to
name some:

* 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?
* Location for IDS/IDP.
* Connection cleanup, re-assembling fragments, etc.
* SYN flood protection, etc.
* Single choke point to block incoming traffic deemed undesirable.
* Single log point for inbound connections for analysis and auditing
* Allows outbound traffic enforcement.
* Allows conditional inbound traffic from specific approved external hosts-
e.g. a partner.
* Some firewalls allow programmatic modification of configurations with all
the benefits/pain that brings.  This is alongside traditional CLI and GUI
* 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.
* Yeah, auditors like it.

I'm not at all adverse to putting transparent proxies in front of your
website.  CDN vendors aren't either.  I will say that I have had several bad
experiences with WCCP not working as expected and failing non-gracefully.

I am not saying its always a good idea to have a stateful firewall in front
of your web servers, I'm saying that there are reasons why you might want to
and in my experience it is common.


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

> On Jan 5, 2010, at 10:18 AM, Suresh Ramasubramanian wrote:
> > 5 Ditch the stateful firewall and exclusively use a netflow device
> NetFlow analysis is very useful for network visibility, and
> detection/classification/traceback.  There are both open-source and
> commercial NetFlow collection and analysis systems available (full
> disclosure:  I work for a vendor of both NetFlow analysis and DDoS
> mitigation solutions); however, they don't provide mitigation, which is
> where S/RTBH, flow-spec, and/or IDMS come into play.
> PCI DSS iatrogenically *requires* that a 'Web application firewall' be
> placed in front of Web servers which process credit card information (PCI
> DSS completely ignores availability, and contains a number of
> recommendations which are actually harmful from an opsec standpoint).
>  Running mod_security or its equivalent on the front-end Web servers
> themselves fulfills this requirement without putting a stateful DDoS
> chokepoint in front of the servers.
> It's also a really good idea to front Web servers with a tier of
> caching-only transparent reverse proxies; Squid is a good choice for this,
> as well as various commercial offerings.  WCCPv2 clustering (supported by
> Squid and several commercial caching/proxying solutions) allows this tier to
> be scaled horizontally in order to meet capacity demands.
> -----------------------------------------------------------------------
> 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