cisco Reflexive ACL's vs. ESTablished
Henry Yen
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 <he...@panix.com>
netcom shell refugee '94. he...@netcom.com,henr...@netcom.com
Hicksville, New York
-
[To unsubscribe, send mail to majo...@lists.gnac.net with
"unsubscribe firewalls" in the body of the message.]
Henry Sieff
It does for TCP sessions; the _established_ keyword can only be used
w/ tcp sessions (since udp and other protocols mostly are). For the
sessionless protocol, reflexive has to rely on a timeout period, which
ain't perfect obviously.
Describing end-of-session: (from
http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113e
d_cr/secur_c/scprt3/screflex.htm#xtocid87134
"Temporary reflexive access list entries are removed at the end of the
session. For TCP sessions, the entry is removed 5 seconds after two
set FIN bits are detected, or immediately after matching a TCP packet
with the RST bit set. (Two set FIN bits in a session indicate that the
session is about to end; the 5-second window allows the session to
close gracefully. A set RST bit indicates an abrupt session close.)
Or, the temporary entry is removed after no packets of the session
have been detected for a configurable length of time (the timeout
period).
For UDP and other protocols, the end of the session is determined
differently than for TCP. Because other protocols are considered to be
connectionless (sessionless) services, there is no session tracking
information embedded in packets. Therefore, the end of a session is
considered to be when no packets of the session have been detected for
a configurable length of time (the timeout period"
> 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.
Well, yeah. But, the only way to protect against that is to proxy the
connection with app-aware stuff. _Established_ won't work with UDP,
and reflexive depends on timing out the entry to protect you.
>
> 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.
They do say in the documentation that for tcp sessions, the same
criterion as _established_ are used to define session state. IF you
need better, you'll need to go app-aware.
Henry Sieff
Richard Pitcock
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: fire...@lists.gnac.net
Cc: bn...@marconi.com.au; cbre...@sover.net
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 <he...@panix.com>
netcom shell refugee '94. he...@netcom.com,henr...@netcom.com
Hicksville, New York
Ben Nagy
> From: Henry Sieff [mailto:hsi...@orthodon.com]
[...]
> > -----Original Message-----
> > From: Henry Yen [mailto:he...@panix.com]
[...]
> > greetings. back in july, 2000, BNagy and CBrenton
> > asserted/agreed that
> > cisco Reflexive ACL's (in IOS 12.0 and up), worked like this:
[...]
> > 3. Incoming packets are tested against this state table
> > for source/dest
> > port, source/dest IP and the presence of the ACK or RST
> >
> > 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
> >
> > 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.
UDP is always going to be exposed (no established concept). The extra
exposure would be with TCP connections. It's quite common, for example, for
TCP/80 sessions to be left hanging open in case more data needs to be sent.
This means that a spoofed packet (or compromised server) could well have a
free ticket to whatever internal source port the query came from.
The main risk is with services that send and recieve on the same port, using
TCP (only these will have TCP listeners, so they're the only ones where it's
useful to be able to send a basic SYN). I can't think of one offhand - can
anyone else?
[...]
> > 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.
>
> They do say in the documentation that for tcp sessions, the same
> criterion as _established_ are used to define session state. IF you
> need better, you'll need to go app-aware.
>
> Henry Sieff
Do you have a ref for that, Henry? I couldn't find that stated, either.
When I get some free time in the lab I might knock up a test. Don't count on
it, though. 8)
Any Cisco dev guys still lurking here?
Cheers,
--
Ben Nagy
Network Security Specialist
Marconi Services Australia Pty Ltd
Mb: +61 414 411 520 PGP Key ID: 0x1A86E304
acs
abomination?
--- Richard Pitcock <rpit...@rlpenterprises.com>
wrote:
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
iCefoX
estimate how much memory or horse power required for a set of ACL. It's
understand that the use of ACL would impact the packet forwarding
performance of a router.
Cheers