> -----Original Message-----
> From: Henry Sieff [mailto:[EMAIL PROTECTED]]
[...]
> > -----Original Message-----
> > From: Henry Yen [mailto:[EMAIL PROTECTED]]
[...]
> > 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
> > bit. [...]
> >
> > 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.[...]
> >
> > 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
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
