On Jan 6, 2010, at 4:24 AM, Robert Brockway wrote: > Hi Roland. I disagree strongly with this position.
You can disagree all you want, but it's still borne out by real-world operational experience. ;> > The problem is that your premise is wrong. Just what about my premise is wrong? Nothing in your message repudiates - or even addresses - a single thing I've said. ;> > Stateful firewalls (hereafter just called firewalls) offer several > advantages. Not in front of servers, they don't. Clients, yes. Servers, no. > This list is not necessarily exhaustive. No, it doesn't include all - or even any - of the reasons firewalls are inappropriate for placement in front of servers, not by a long shot. ;> > (1) Security in depth. In an ideal world every packet arriving at a > server would be for a port that is intended to be open and listening. > Unfortunately ports can be opened unintentionally on servers in several > ways: sysadmin error, package management systems pulling in an extra > package which starts a service, etc. By having a firewall in front of the > server we gain security in depth against errors like this. Stateless ACLs in router/switch hardware capable of handling mpps takes care of this. > (2) Centralised management of access controls. Many services should only > be open to a certain set of source addresses. While this could be managed > on each server we may find that some applications don't support this well, > and management of access controls is then spread across any number of > management interfaces. Using a firewall for network access control reduces > the management overhead and chances of error. Even if network access > control is managed on the server, doing it on the firewall offers > additional security in depth. Stateless ACLs in router/switch hardware capable of handling mpps takes care of this. > > (3) Outbound access controls. In many cases we want to stop certain types > of outbound traffic. This may contain an intrusion and prevent attacks > against other hosts owned by the organisation or other organisations. > Trying to do outbound access control on the server won't help as if the > server is compromised the attacker can likely get around it. Stateless ACLs in router/switch hardware capable of handling mpps takes care of this. > (4) Rate limiting. The ability to rate limit incoming and outgoing data > can prevent certain sorts of DoSes. Rate-limiting during a DDoS - i.e., an attack against state and *capacity* - is absolutely the *worst* thing one can possibly do, in almost all circumstances. Yet another security myth which is easily disproved via hands-on operational experience. > (5) Signature based blocking. Signatures are obsolete before they're ever created; 15 years of firewalls and so-called IDS/'IPS', and the resultant hundreds of millions of botted hosts, pretty much put paid to this canard. > Modern firewalls can be tied to intrusion > prevention systems which will 'raise the shields' in the face of > certain attacks. These systems are worse than useless, they're actively harmful; they form DDoS chokepoints themselves, drastically increase the attack surface, and can also be gamed. > Many exploits require repeated probing and this provides a way to stop the > attack before it is successful. In the same way that powering off the server ensures perfect confidentiality and integrity of its data, applications, and services. ;> > Do you have any evidence to support this assertion? Yes - many years of watching the biggest, baddest firewalls choke and die under trivial DDoS. Including the better part of a decade working for the largest firewall vendor in the world. > You've just asserted that all firewalls have a specific vulnerability. No, I've asserted that all stateful firewalls created in the history of the world to date, commercial or open-source, are based upon a specific *fundamental architectural premise* which precludes their placement in front of servers. This isn't the same as saying they've a *vulnerability*. I'm saying they're unsuited to be placed in front of servers. > I don't see how you can assert they all have this > vulnerability. Again, I'm not asserting they've a vulnerability. I'm asserting that it doesn't make much sense to pound nails with a monkey-wrench. ;> > In any case, my experience tells me that a DDoS will be successful due to > exhaustion of available network capacity before it exhausts the state > table on the firewall. My experiences defending against DDoS attacks from the 1990s to the present nanosecond indicate otherwise. ;> > Again, I don't believe such a global claim can be made given the wide variety > of architectures used for firewalls. Again, *all* stateful firewalls produced to date share a fundamental architectural premise which renders them unsuitable for placement in front of servers. In fact, one major firewall vendor recently implemented a 'stateful inspection bypass' feature as a direct result of this issue; apparently, one is supposed to purchase their $100KUSD 10gb/sec stateful firewall, wedge it into one's network (forcing artificial and undesirable traffic symmetry in order to do so) . . . and then *disable* the stateful inspection one supposedly purchased it to perform in the first place, heh. ;> ----------------------------------------------------------------------- Roland Dobbins <rdobb...@arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
