I don't need no stinking firewall!
Dobbins, Roland
rdobbins at arbor.net
Wed Jan 6 04:23:28 UTC 2010
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 at arbor.net> // <http://www.arbornetworks.com>
Injustice is relatively easy to bear; what stings is justice.
-- H.L. Mencken
More information about the NANOG
mailing list