Re: Ambiguities in TCP/IP - firewall bypassing
From: Florian Weimer (Weimer@CERT.Uni-Stuttgart.DE)Date: 10/21/02
- Previous message: Jeff Moss: "Call For Papers Announcement: Black Hat Windows Security"
- In reply to: Aaron Hopkins: "Re: Ambiguities in TCP/IP - firewall bypassing"
- Next in thread: David Wagner: "Re: Ambiguities in TCP/IP - firewall bypassing"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: Aaron Hopkins <lists@die.net> 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
- Previous message: Jeff Moss: "Call For Papers Announcement: Black Hat Windows Security"
- In reply to: Aaron Hopkins: "Re: Ambiguities in TCP/IP - firewall bypassing"
- Next in thread: David Wagner: "Re: Ambiguities in TCP/IP - firewall bypassing"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|