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 requirements. * 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 interfaces. * 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. --D On Mon, Jan 4, 2010 at 7:31 PM, Dobbins, Roland <rdobb...@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 <rdobb...@arbor.net> // <http://www.arbornetworks.com> > > Injustice is relatively easy to bear; what stings is justice. > > -- H.L. Mencken > > > > > -- -- Darren Bolding -- -- dar...@bolding.org --