Bugtraq mailing list archives
Re: Ambiguities in TCP/IP - firewall bypassing
From: Florian Weimer <Weimer () CERT Uni-Stuttgart DE>
Date: Mon, 21 Oct 2002 11:50:42 +0200
Aaron Hopkins <lists () die net> 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 Weimer () CERT Uni-Stuttgart DE University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898
Current thread:
- Re: Ambiguities in TCP/IP - firewall bypassing, (continued)
- Re: Ambiguities in TCP/IP - firewall bypassing Benjamin Krueger (Oct 18)
- Re: Ambiguities in TCP/IP - firewall bypassing Alun Jones (Oct 18)
- RE: Ambiguities in TCP/IP - firewall bypassing John Fitzgerald (Oct 19)
- Re: Ambiguities in TCP/IP - firewall bypassing Tony Finch (Oct 19)
- Re: Ambiguities in TCP/IP - firewall bypassing Alan DeKok (Oct 18)
- Re: Ambiguities in TCP/IP - firewall bypassing Luis Bruno (Oct 19)
- Re: Ambiguities in TCP/IP - firewall bypassing Lyndon Nerenberg (Oct 21)
- Re: Ambiguities in TCP/IP - firewall bypassing Benjamin Krueger (Oct 18)
- Re: Ambiguities in TCP/IP - firewall bypassing cbrenton (Oct 19)
- Re: Ambiguities in TCP/IP - firewall bypassing Aaron Hopkins (Oct 19)
- Re: Ambiguities in TCP/IP - firewall bypassing Florian Weimer (Oct 22)