> -----Original Message-----
> From: Patrick Darden [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, 26 July 2000 4:58 AM
> To: Ben Nagy
> Cc: [EMAIL PROTECTED]
> Subject: RE: cisco Established keyword
>
> On Tue, 25 Jul 2000, Ben Nagy wrote:
[snip]
>
> > 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.
I'm sorry, but that's just completely false. Reflexive ACLs are stateful.
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
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.
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.
>
> > 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.
[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
younger. ;) I'm actually suggesting that low complexity and full
documentation is the way to go when building trusted, auditable security
solutions.
>
>
> > 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?
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.
[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?
>--Patrick Darden
>--Internetworking Manager
>--Athens Regional Medical Center
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.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
