Re: I don't need no stinking firewall!

[Robert Brockway <robert () timetraveller org>]

On Tue, 5 Jan 2010, Dobbins, Roland wrote:

> In the most basic terms, a stateful firewall performs bidirectional 
> classification of communications between nodes, and makes a pass/fail 
> determination on each packet based on a) whether or not a bidirectional 
> communications session is already open between the nodes and b) any 
> policy rules configured on the firewall as to what ports/protocols 
> should be allowed between said nodes.
>
> Stateful firewalls make good sense in front of machines which are 
> primarily clients; the stateful inspection part keeps unsolicited 
> packets away from the clients.
>
> Stateful firewalls make absolutely no sense in front of servers, given 
> that by definition, every packet coming into the server is unsolicited 
> (some protocols like ftp work a bit differently in that there're 
> multiple bidirectional/omnidirectional communications sessions, but the 
> key is that the initial connection is always unsolicited).
>
> Putting firewalls in front of servers is a Really Bad Idea - besides the

Hi Roland.  I disagree strongly with this position.

> fact that the stateful inspection premise doesn't apply (see above),

The problem is that your premise is wrong.  Stateful firewalls (hereafter 
just called firewalls) offer several advantages.  This list is not 
necessarily exhaustive.

(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.

(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.

(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.

(4) Rate limiting.  The ability to rate limit incoming and outgoing data 
can prevent certain sorts of DoSes.

(5) Signature based blocking.   Modern firewalls can be tied to intrusion 
prevention systems which will 'raise the shields' in the face of 
certain attacks.  Many exploits require repeated probing and this provides 
a way to stop the attack before it is successful.

> rendering the stateful firewall superfluous, even the biggest, baddest 
> firewalls out there can be easily taken down via state-table exhaustion;

Do you have any evidence to support this assertion?  You've just asserted 
that all firewalls have a specific vulnerability.  It isn't even possible 
to know the complete set of architectures (hardware & software) used for 
firewalls so I don't see how you can assert they all have this 
vulnerability.

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.

> an attacker can craft enough programmatically-generated, well-formed 
> traffic which conforms to the firewall policies to 'crowd out' 
> legitimate traffic, thus DoSing the server.  Addtionally, the firewall 
> can be made to collapse far quicker than the server itself would 
> collapse, as the overhead on the state-tracking is less than what the 
> server itself could handle on its own.

Again, I don't believe such a global claim can be made given the wide 
variety of architectures used for firewalls.

Cheers,

Rob

--
I tried to change the world but they had a no-return policy
http://www.practicalsysadmin.com