Aaron Hopkins <[EMAIL PROTECTED]> writes: > On Sat, 19 Oct 2002, Florian Weimer wrote: > >> "established" in Cisco parlance does not mean "SYN unset", but "ACK or RST >> set". This means that the impact for non-Linux hosts (which do not react >> to SYN-RST packets according to Paul's survey) is less severe if your >> filters run IOS. > > This is true for IOS up through 11.3. The 12.0, 12.1, and 12.2 > documentation claims:
> established: (Optional) For the TCP protocol only: Indicates an > established connection. A match occurs if the TCP datagram > has the ACK, FIN, PSH, RST, SYN or URG control bits set. > The nonmatching case is that of the initial TCP datagram to > form a connection." This documentation is quite misleading. Our experiments with a 12.1 version suggests that RST and/or ACK bits cause the packet to pass. > If the documentation is correct, then you can fool IOS 12.0+ "permit tcp any > any established" at the top of an access list into letting you make > connections to any port on at least Linux 2.4.19, Solaris 5.8, FreeBSD 4.5, > and Windows NT 4.0, as reported by Paul Starzetz in the post starting this > thread. The SYN,FIN combination is filtered (it's permitted by the RFC if you read it carefully, I think, and some systems can cope with it). > Thats not necessarily true. At least with current IOS (12.2, perhaps > earlier), you can specify "permit tcp any any ack" instead of "permit tcp > any any established" to work around this bug entirely and retain almost all > functionality. Interesting, thanks. It's not documented for 12.1. The CLI accepts it, though. I'll check if it's properly supported. This approach is much more general than reflexive access lists (which can break long-lasting interactive sessions because of the timeouts involved). -- Florian Weimer [EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898
