Re: I don't need no stinking firewall!

[William Pitcock <nenolod () systeminplace net>]

On Tue, 2010-01-05 at 16:24 -0500, Robert Brockway wrote:
> 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.

As someone who worked for a startup several years ago working on solving
precisely the problem of having a reliable firewall/IDS solution infront
of the server, I'm going to have to disagree with your disagreement.

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

ACLs in the router hardware handle this.  Your average datacentre
switch, even a small one can handle stateless ACL checks in hardware.

Also ACLs don't protect you from the bad guys, especially if you're
incompetent.  What my team found was that it was infact -impossible- to
sanely do DPI infront of a server and also survive a DDoS attack.  DDoS
attacks are a big problem these days, in case you didn't notice.

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

ACLs in the router hardware handles this.  Doing it on a firewall
provides no additional security, and may infact decrease network
performance and throughput.  Additionally, predictive firewalls can be
gamed.

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

ACLs in the router hardware as well as blackholed /32s in the route
table of the router handle this.  Doing it on a firewall provides no
additional security and *will* decrease network performance and
throughput.  Routers are built for large route tables and make use of
RADIX tries and other optimizations that hardware server-oriented
firewalls do not typically have.

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

I am not sure what makes you believe that.  The ability to rate limit
incoming data at the server level would definitely not prevent a DoS. 

The ability to rate limit outgoing data would cause a DoS of anything
other than DoS traffic that is hosted on the server.

The basic rule here is "you can't filter more than your port speed", and
if your port is getting hit with 1.3gbit of DDoS and your port is only
1gbit, you're still offline.

> (5) Signature based blocking.   

LOL.  Signature based blocking is the biggest scam since the 1980s when
IDS technology was first invented.  It doesn't work.  It is snake oil.
The only type of 'signature' that would work would be a list of all
known botnet IPs, and you're never going to get that.

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

As mentioned above, predictive firewalls can be gamed and cheated to
make themselves DoS the downstream network.  Keep in mind DoS does not
mean the same as "packet flooding", DoS means "denial of service", so if
it chokes, service is denied.

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

It's a known problem with firewalls in general.  You have to keep in
mind that all firewalls mechanically do the same thing -- they proxy
packets from one port to another port depending on various rules.

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

Adding the firewall infront of a server can reduce network throughput to
that server by up to 80% depending on what checks it is doing, and how
fast it can do the checks.  There are no hardware firewalls that can
*really* do DPI at 10GE linerate that I know of, for example.

William