> -----Original Message-----
> From: Joe Dauncey [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, 17 June 2000 1:59 AM
> To: David Leach
> Cc: <
> Subject: Re: CISCO Firewall Feature Set
> 
> 
> David,
> 
> From the work I have done looking at it, the hub of the 
> Firewall Feature Set (Or CiscoSecure Integrated Software as 
> they now call it) is basically access control lists. The 
> access control lists are quite good, because they'll stop all 
> packets bang dead, but it is kind of scary that they seem to 
> be the hub of the 'feature'.

As opposed to what? IOS-FW claims to be a stateful packet filter with some
application level inspection capabilities and some frills. SPFs are always
going to be based on ACLs, right? PIX / FW-1 / ipfilter are the same sort of
thing in that they keep a table of which packets to allow and which to deny.

IOS-FW is configured quite differently from the normal IOS ACLs - it's much
more akin to CBAC.

> 
> The main problem we have seen from our concerns is that the 
> logging on the router is awful. [snip]

Yeah, logging is always going to be a weak point of this sort of solution.
YOu can indeed log whatever you want with permit or deny entries in the ACLs
but that undermines the inspect engine so it probably isn't a great idea.
You can log alerts etc from the inspect engine though. Check out the docs on
CCO.

> 
> One of the other main issues is the current limitations of 
> CBAC, which doesn't really handle a lot of protocols. The 
> application filtering is trivial in some cases. For example, 
> SMTP is hardcoded to allow EXPN and VRFY straight through as 
> permitted commands, even though they can lead to information 
> leaks. There is no way to change that. It is also limited to 
> UDP and TCP traffic, which means

Yeah - sucks. Also, if you want to sneak commands through that aren't
allowed by the inspect engine you can send one character per packet and
space them out over some period of time - on a busy router this will work
because it can only keep so much state in the buffer.

Personally I don't have much faith in the inspect engine for app level
filtering - I usually inspect TCP, UDP, ICMP and fragments. I don't mind
turning on inspect for HTTP / SMTP etc but I don't particularly trust it.

I think one of us is confusing CBAC (Context Based Access Control) which is
available on the base IOS image (Don't know which version, but it's in IP in
the 12.0 T train) with the inspect engine which is only in IOS-FW. The
inspect engine does in fact do context based access control, but will also
look at fragments, do java blocking, check out SMTP HTTP H323 etc etc - that
sort of thing. The inspect engine also does alert based actions and logging.

> that if you want to allow ICMP or anything else you have to 
> start poking holes in your access lists, which can be dodgy ! 
> CBAC is supposed to check outgoing packets and then open a 
> hole in your access list to allow their responses back in. It 
> does this very well, and very responsively.

CBAC will do quasi-stateful ICMP for ECHO / ECHO_REPLY. You only need to
have ACL holes for incoming unsolicited ICMP - sadly this _does_ include
errors for legit sessions.

> 
> There are also some anti-DoS measures, which are quite good. 
> They've got some fairly flexible rules to govern inbound SYN 
> connections and the like.
> 
[snip]
> I do both, and I deal with both, so I have seen it a lot, and I 
> have seen, time after time, router people get it wrong. That 
> is not to say that there aren't a lot of people who can sit 
> in the middle, but I would be very hesitant about asking a 
> load of router configurators to take over my firewalls !!

Uh....YMMV. I'd put it like this - people that don't have security skills
shouldn't be messing with security solutions. There are many router people
without security skills. My personal experience is that I have seen as many
or more firewall people without security skills - which I find even scarier.
;)
> 
> Anyway, I hope this bit of personal opinion is of some use. 
> The IOS is really much better a firewall that I ever 
> expected, but I am still testing it and forming a final opinion.

I like to think of it as a good, cheap option for small networks with low
exposure (few externally visible services) or as a front line screen in
front of another type of firewall.

> 
> Cheers,
> Joe
> 
> (personal opinions, represent only myself, etc....)
> 
> David Leach wrote:
> 
> > Has anyone used the FFS or can give recommendations for or 
> against?  A router engineer I'm trying to work with has 
> suggested replacing all the firewalls in a proposed design 
> with routers and Access control lists.  I feel confident that 
> I have the information necessary to make the argument against 
> doing that.  However, I don't want to be caught off guard by 
> somehting I don't know much about.

Depends which firewall. Depends what sort of networks they're in front of.
Depends on patterns of use. You may well be right, but it would be bad to
assume that "firewalls are better than routers with ACLs" as a blanket rule.

> >
> > Any help is greatly appreciated.
> >
> > Dave Leach, MCSE+ I
> > Systems Security Engineer
> > EWA, Information and Infrastructure Technologies

Cheers,

--
Ben Nagy
Network Consultant, Volante IT
PGP Key ID: 0x1A86E304  Mobile: +61 414 411 520  
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]

Reply via email to