On Wed, 26 Jul 2000, Ben Nagy wrote:
> I'm sorry, but that's just completely false. Reflexive ACLs are stateful.
Ben, we disagree on our definition of stateful. RACLs do not store
session information (e.g. tcp sequence numbers), they are easily spoofed
(e.g. using nscan syn/ack sets--the ability is built into the scanner to
take advantage of RACLs and "established" based EACLs)
> This is how they work:
>
> 1. A packet leaves an interface with 'reflect' in an ACL
> 2. An entry is written into a dynamic ACL (Call this a STATE TABLE) with the
> reverse source / destination ports and IP addresses
Your definition of stateful is nifty, and I can dig it. However, I
don't believe it is a commonly accepted industry standard.
Cisco's definition, as applied to the PIX and CBAC, is:
Each time a TCP connection is established from an inside host accessing
the Internet through the... Firewall, the information about the connection
is logged in a stateful session flow table. The table contains the source
and destination addresses, port numbers, TCP sequencing information, and
additional flags for each TCP connection associated with that particular
host.
<snip>
In order for hackers to penetrate the firewall to an end client, they
would have to obtain not only the IP address, but also the port number and
the TCP sequence numbers. This scenario is very unlikely because
Cisco's... Firewall randomizes the TCP sequencing numbers.
<snip>
With UDP---a connectionless service---there are no actual sessions, so the
software approximates sessions by examining the information in the packet
and determining if the packet is similar to other UDP packets (for
example, similar source/destination addresses and port numbers) and if the
packet was detected soon after another similar UDP packet. "Soon" means
within the configurable UDP idle timeout period.
>
3. Incoming packets are tested against this state table for source/dest
> port, source/dest IP and the presence of the ACK or RST bit. When FIN packet
> is seen, or after a timeout period, the connection is timed out and removed
> from the state table.
ACK bits are too easily spoofed to be relied upon. That is why RACLs was
a first attempt that Cisco advises not using, except in cases that CBAC
will not work and a PIX is unacceptable.
>
> On a box with reflexive ACLs set up, do a 'sh ip access-lists' - the
> temporary ACL is the "table of connections".
>
> On a side note - Reflexive ACLs _break_ active FTP and anything else that
> uses callbacks on different ports.
Good deal. Thanks.
>
> >
> > > 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.
> >
>
> Not really in what sense? That's _exactly_ how they work.
I was being picky with your use of inverse. I apologize.
> [snip]
> >
> > > 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.
>
> I actually understand both, as far as there is real documentation for the
> internals of the CBAC - but I love being patronised. Makes me feel even
I really apologize for coming across wrong here. Didn't mean to sound
patronising. I was being sincere--the best tool is the tool you work best
with.
> younger. ;) I'm actually suggesting that low complexity and full
> documentation is the way to go when building trusted, auditable security
> solutions.
However, although I agree with the KISS sentiment, your implication that
CBAC is more complex than RACL is incorrect. CBAC is simple, easily
implemented, very well documented, and secures very well. On the other
hand, it is very very limited, non-extensible, and power-hungry.
>
> >
> >
> > > 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
> >
> >
> [snip]
> > This document gives details such as a complete list of supported
> > protocols:
> >
> > http://www.cisco.com/univercd/cc/td/doc/product/software/ios12
> 0/120newft/120t/120t5/iosfw2/iosfw2_2.htm#xtocid1359517
>
> OK, that's not exactly what I meant. I'm talking about this sort of thing:
>
> "CBAC inspection recognizes application-specific commands (such as illegal
> SMTP commands) in the control channel, and detects and prevents certain
> application-level attacks."
>
> What attacks? What illegal commands? Are they listed? Do they update them?
The documentation has more details. You just have to dig.
>
> It's fine to _support_ protocols, but another thing to _secure_ them. I'm
> going to try very hard to stay off the soapbox, but suffice to say that not
> enough people seem to understand that very important distinction.
CBAC does as good a job securing the protocols it supports as any firewall
box. It takes a full system to do a better job--and part of that system
is people like you and me who understand how things work, and look for
anomalous packet/application/network behavior.
>
> [snip]
>
> >> 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.
>
> OK - what do you consider to be the "major" security increase in using CBAC
> instead of Reflexive ACLs? Are you simply asserting that the
> application-level inspection is good and worthy of trust?
I think having network through application layer security is better than a
kludgey version of network based security. That's what stateful
inspection is all about.
CBAC adds true statefulness and payload inspection to ACLs. Much more
powerful tools when utilized properly.
--
--
--Patrick Darden Internetworking Manager
-- 706.354.3312 [EMAIL PROTECTED]
-- Athens Regional Medical Center
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
