On Tue, 25 Jul 2000, Ben Nagy wrote:
> Personally, I trust reflexive access lists more than CBAC.
The best tools are the tools you know best.
> Reflexive access lists are _not_ a kludge - on the contrary, they work in
> the traditional manner for a stateful packet filter. When a new connection
They are a primitive and early workaround for the open 1023+ port problem,
and they don't inspect the contents of a packet. It's version of
statefulness is derived from whether the ACK is set, there is no table of
connections kept--therefore there is no true statefulness. It is a
kludgey attempt at state monitoring. They are intended to allow
internally derived connections to work despite changing ports, e.g. active
ftp.
> is opened from inside the network an entry is written into a temporary ACL
> in RAM which allows return traffic with the inverse source/dest ports etc.
Not really.
>
> I'm fairly sure that it's _just_ an ACL though - therefore it wouldn't have
> the capacity to check sequence numbers, make sure that only packets with
> flag combos that are legal for the current TCP state etc etc.
It is just a reflexive ACL, yes. No state tables, no inspection of the
internals of packets.
>
> CBAC has some really good features - frag reassembly, session audit trails,
> "inspection" of some simple protocols, dealing with active FTP properly etc.
> The trouble is that it can only do these things up to a certain point. You
> can send so many frags that the router stops reassembling them. You can
> space your bogus commands over such a length of time that the router gives
> up on holding onto the packets that contained the start of the illegal
> command etc etc.
True, but everything only provides a measure of protection. I agree
that CBAC is not the perfect solution, but I don't know of one. CBAC is
cheap and effective as far as it goes, but it doesn't go very far--maybe
15 application layer inspection modules built-in, and no method to easily
extend it.
> Basically I'd rather have a simple, almost certainly correctly coded
> mechanism that I understand than some nebulous inspection engine which can
Absolutely, if you understand it, it is a better tool for you to use.
> only play with a teeny bit of RAM while filtering. There is no docco that
> I've seen which tells you which stuff is filtered and there is nothing I've
Doing a 10 second search for CBAC at www.cisco.com gives me:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t5/iosfw2/iosfw2_2.htm
This document gives details such as a complete list of supported
protocols:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t5/iosfw2/iosfw2_2.htm#xtocid1359517
> seen that indicates that there are versions of the inspect engine itself so
> I have no assurance that it's a "live" product in terms of development.
AFAIK, CBAC is indeed static. It has been ported to the larger routers,
but it hasn't changed much lately. Reflexive ACLs have not changed in
years either though.
>
> Most people use edge routers as either a packet filter for a small, low-risk
> network or as a fast first line of defence for another style of firewall.
Yep. CBAC is not meant for edge routers. I believe it is meant for
slightly used internet routers for small businesses--ISDN BRI, a few T1's,
etc.
>
> With this in mind, I usually promote CBAC as a very small increase in
> security over reflexive ACLs and (when I use it) tend to only inspect frags
> and tcp/udp/ftp.
It is a *major* increase in security, but only for a limited number of
protocols, and its performance hit is considerable. It's usefulness is
definitely limited.
> > "Established" is not stateful in any sense of the word. It
> > was an early
> > kludge that was followed by reflexive access lists, another kludge.
> >
> > The FW IOS uses CBAC for true stateful inspection. CBAC
> > works well, but
> > has two problems: it is a tool, and depends upon the skill
> > and knowledge
> > of the person using it; and stateful inspection is completely
> > baffled by
> > tunnelling hacks that use ICMP, SSH, HTTPS, and other protocols
> > (e.g. Loki).
> >
> >
--Patrick Darden
--Internetworking Manager
--Athens Regional Medical Center
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
