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 <rdobbins@arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken