Re: Thoughts on the new Cisco ASA 5500 firewalls

[Chris Byrd <cbyrd01 () gmail com>]

Marcus J. Ranum wrote:

> The problem with that approach is that in order to make a wise decision
> about trade-offs and compromises you need to understand what you
> are measuring - and virtually nobody does that. They just jump to
> "Well, we CAN'T compromise on performance so we'll put a
> swiss-cheese 'stateful' firewall in because their powerpoints say
> they're really FAST and their competitors are really slow and we
> don't really even KNOW what loads our network really handles anyhow
> so since we're so completely ignorant we'll buy the SHINY one."
>  
Every vendor in the security space has marketing departments, and the 
job of marking folks has always been to overhype products, so try to not 
let it bother you so much.  The trick is in seperating the wheat from 
the chaff.

I doubt that 'virtually nobody' models traffic and understands traffic 
loads, at least I'd hope not.  However, I do agree that on Internet 
facing firewalls the performance problems are often downplayed or 
overhyped, depending on what suits the Suits.  Most good network designs 
include firewalls in the interior of the network, and often that is 
where the performance bottlenecks occur.

> > Most implementations of stateful firewalls are backed up by application proxies on the most popular protocols such as 
> > HTTP and FTP.
> >    
>
> Yeah, because they suck. :)
>  
Are you proposing that all security functions should be consoldated into 
a single device?  If not, I don't see why stateful firewalls lack of 
application proxies means that 'they suck'.  Security controls should be 
implimented at several layers of the network.

> > The purpose of the DI firewall in this case is to remove the "low hanging fruit" of worms, network scans, etc., and let 
> > the application proxy catch the rest.
> >    
> No, you're wrong.
>
> What's going on is that network managers are going to put these
> "deep inspection" devices in place, feel safe, and never make any
> effort to understand if they are effective or not.
>  
That is why security professionals have jobs, to guide them to better 
decisions.  Will some network managers make the wrong decision?  Sure.  
But that won't be a first.

> You fell for it too. Observe your comment above:
> "worms, network scans, etc."
> *WHICH* worms? Hey, some of these "deep inspection" devices
> know how to block 12 different worms! WOW!  *WHICH* scans?
> Guess what? NONE of them block scans. Go find me a "deep
> inspection" firewall that "knows" how to block scans. They don't
> block scans because a lot of scans look like Chuck's 'legitimate'
> traffic and cannot be blocked. They don't block denial-of-service
> attacks - except for a few that aren't being used anymore like
> ping-of-death that are easy to detect.
>
> So you're already talking like this device does something useful
> and haven't made any assessment as to what it actually does
> and whether that'd be useful to you in the first place.
A simple NAT router can block some worms and scans.  A properly 
configured stateful firewall blocks more.  Even if  a DI firewall only 
blocked an additional 12 worms with signatures, that would be 12 more 
than the stateful firewall.  Am I saying that this should be the only 
line of defence for a company?  Not at all. Most companies have 
something that looks like this:

Internet --> Screening router --> IPS --> Stateful FW --> Application 
proxies/AV/Content filter --> Host-based IPS

... and that is on top of all the other security controls such as 
rulesets, AV, policies, device hardening, patching, etc.

Also, note that an application proxy cannot stop ANY attack or payload 
that conforms to protocol specifications, unless it has been configured 
to do so.  For an example, take a look at skape's paper on tunneling 
traffic through HTTP via hijacking IE to load an ActiveX control at: 
http://www.uninformed.org/?v=1&a=3&t=pdf

> > Further, proxy firewalls have their downsides.  Application proxies are implemented in general purpose processors, 
> > limiting their overall performance.
> >    
>
> They are? *ALL* of them? Really? Why?
>  
Because I have not seen an application proxy firewall that impliments 
the proxies in ASICs, FPGAs, or other logic chips, hence the assertion 
that they are done in gereral purpose processors.  For example, the 
Sidewinder G2 runs Sendmail for SMTP proxying.  If you know of an 
exception to this, please share it with us.

> Have you measured what happens to a "deep inspection"
> firewall when you turn on URL screening and it's no longer going through
> the fast path in the switch and is being vectored instead to the
> general purpose processor running Web Trends? 'Cuz that's what
> happens.
>  
No, but I doubt it's much worse than doing the same on a proxy fw.  
Signatures and "basic" protocol conformance can be implimented in ASICs, 
something that Cisco is claiming to have done.

> > An application proxy must be written for every possible protocol.
> >    
>
> So does a "deep inspection" module, if it's "deep" in any sense
> of the word. Look at something like NetScreen's documentation
> on their current firewall - it has "deep inspection" for 6 whole
> Internet application protocols! WOW!  What does it do with
> protocols it doesn't have "deep inspection" for? Well, it lets
> the traffic scream right through, doesn't it? WOW! That sounds
> to me like 'default permit' which is idiot quality security.
>  
I havn't looked at Juniper's fw specifically, but I doubt that they 
ignore their stateful firewall rules if traffic doesn't match a 
supported DI protocol, and I have a hunch that they have a default deny 
any rule at the end of their rulebase.

>  
>
> > Encrypted traffic often defies proxying.
> >    
>
> Encrypted traffic always defies "deep inspection"
>  
You've got a good point there.  As much as I'd like to point out that 
several IPS products can use a pre-loaded private key for an "authorized 
MITM" to analyze the traffic, so could proxy firewalls.

>  
>
> > And, despite best intentions, sometimes applications don't always follow protocol rules.
> >    
>
> Yes, and when they don't, they should be blocked and
> investigated.
>  
Good luck selling that to management for the line-of-business 
applications.  Anyone else on the list able to make the "I don't care if 
you need it, you can't have it, because the firewall I chose doesn't 
support it" proposition work?  I've got a hunch the answer is no, 
illustrated by the Sidewinder G2 having a stateful traffic filter for 
unsupported application traffic.

- Chris
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards