Re: I don't need no stinking firewall!

["Dobbins, Roland" <rdobbins () arbor net>]

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