Re: [fw-wiz] CIsco PIX vulnerable to TCP RST DOS attacks

From: Mikael Olsson (mikael.olsson_at_clavister.com)
Date: 05/05/04

  • Next message: Karl Mueller: "RE: [fw-wiz] Cannot send mail" 
    To: "Ahmed, Balal" <balal.ahmed@capgemini.com>
Date: Wed, 05 May 2004 15:01:27 +0200

    "Ahmed, Balal" wrote:
    >
    > If a PIX, or any other firewall/device for that matter, is performing
    > NAPT/Hide NAT/PAT/NAT then as far as the TCP conversation is concerned is it
    > a connection end point or a transit device ?

    Conceptually, it is a transit device, however ...

    > [...] Having said this, I have seen PIX's teardown
    > connections on seeing a RESET-O arrive from the outside. Does this mean that
    > the PIX IS susceptible to the TCP RST vulnerability due to the way Cisco
    > have implemented NAT?

    It used to immediately tear down connections immediately upon receiving
    any RST with matching IPs and ports. This was changed back in 2000:
    http://www.cisco.com/warp/public/707/pixtcpreset-pub.shtml
    where they verify the sequence number of the RST.

    However, as far as I know (though note that I'm in no way a
    cisco/pix expert) they'd still tear down the connection immediately
    upon receiving a RST, so this would still make the NAPT implementation
    vulnerable to a sequence sweep of RSTs. Assuming you know the
    source port, that is.

    HOWEVER, predicting the source port on a busy NAPT is no fun - you go
    from ~32K packets * a few ports to try to ~32K packets * 64K ports [1].
    This is quite a lot of packets. Just trying all of them in a meaningful
    time would mean a packet rate comparable to an all-out DDoS, which is
    an attack in and of itself - and a much more "meaningful" one, at that.

    I still believe that the #1 impact of this vulnerability, as seen in an
    Internet-wide perspective, is killing BGP sessions in core routers.
    Do it a few times to trigger route flap detection, and you'll isolate
    large chunks of the net from eachother, or, worst case, from the rest
    of the Internet. 

    -- 
Mikael Olsson, Clavister AB
Torggatan 10, Box 393, SE-891 28 ÖRNSKÖLDSVIK, Sweden
Phone: +46 (0)660 29 92 00   Mobile: +46 (0)70 26 222 05
Fax: +46 (0)660 122 50       WWW: http://www.clavister.com
[1] possibly divided by the number of simultaneous connections to the 
    same endpoint if "killing some connections for the fun of it" is 
    all you're after.
_______________________________________________
firewall-wizards mailing list
firewall-wizards@honor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
  • Next message: Karl Mueller: "RE: [fw-wiz] Cannot send mail"

    Relevant Pages

    • RE: [fw-wiz] CIsco PIX vulnerable to TCP RST DOS attacks
      ... Cisco have advised me that PIX Images need to be upgraded to special release ... RST packets and discard out of state RST packets. ... It would be nice to have a detailed breakdown and analysis from Cisco ... It used to immediately tear down connections immediately upon receiving ...
      (Firewall-Wizards)
    • Re: port 0 not stealth
      ... >>Obviously this is more secure than sending RST, ... >>port scans, since they will need to time out if no reply is received. ... Not sending an RST does not hide your computer at all. ... > connections from any other hosts than the one it connected to in the ...
      (comp.security.firewalls)
    • Re: TCP RST handling in 6.0
      ... The argument for switching it back off would be that the RST attack ... that the average user has many such connections open and thus will ... effects (attack resistance vs. compatibility) are hard to trade off. ... e.g., through spoofed ICMP packets. ...
      (freebsd-net)
    • Re: weird scans from port 80
      ... > current connection' supposed to mean in the context of a *NEW* packet?? ... cannot all be represented so connections in the CLOSED ... connection not in your table is in the CLOSED state. ... a RST bit must be responded with a RST packet. ...
      (comp.os.linux.security)