Using established with the permit command in a access list will filter TCP
packets based on whether the ACK or RST bits are set. It will only work with
TCP.
Reflexive access lists, however, will filter using more criteria. For
example, source and destination addresses, port numbers are checked as well
as session information. At the completion of the session, reflexive access
list entries are removed differently based on the protocol.
For TCP the entry is removed 5 seconds after two set FIN bits are detected,
or immediately when a set RST bit is detected in a packet. The entry is also
removed when after no session packets have been detected for a set time that
is configurable.
For UDP and other protocols, the end of the session is based on the timeout
setting only.
Hope this helps
Rich Pitcock
-----Original Message-----
From: Henry Yen
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: 5/2/01 4:49 AM
Subject: cisco Reflexive ACL's vs. ESTablished
greetings. back in july, 2000, BNagy and CBrenton asserted/agreed that
cisco Reflexive ACL's (in IOS 12.0 and up), worked like this:
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.
as is well-known, the ESTablished keyword for cisco access-lists is
explicitly documented to test for ACK/RST. but i couldn't find
explicit documentation that Reflexive does the same, as is proposed
in point (3.), above. i understand that the there is a reverse ACL
entry dynamically created, but are we sure that it _also_ encompasses
the ACK/RST checking inherent in ESTablished?
specifically, if it doesn't, then it seems to me that there is an
improper backchannel created, as it then would allow a remote
server (obviously compromised) to start a "new" conversation
as long as you could trick your protected-behind-reflexive-ACL-router
into initiating the session. in particular, conversations such
as UDP 53 and 123 come to mind.
i looked all over and couldn't find _explicit_ documentation stating
that dynamic reflexive entries also have EST. in fact, a "sho ip
access"
does not include that in the reflext/evaluate dynamic ACL list.
if you can point me to such documentation, or blow up the notion
of this being a (very slight) exposure, i'd be very grateful.
--
Henry Yen <[EMAIL PROTECTED]>
netcom shell refugee '94. [EMAIL PROTECTED],[EMAIL PROTECTED]
Hicksville, New York
-
[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.]
