AW: Active response... some thoughts.

From: detmar.liesen@lds.nrw.de
Date: 01/21/03

  • Next message: Ron Gula: "Re: Active response... some thoughts."
    From: detmar.liesen@lds.nrw.de
    To: abegetchell@qx.net, focus-ids@securityfocus.com
    Date: Tue, 21 Jan 2003 08:17:06 +0100
    
    

    You already outlined the drawbacks very well.

    As you said

    * You give valuable information to the hacker
    * The attacker could modify his IP-stack such that resets are being ignored

    IMHO TCP-reset is a cool technology, but I would always prefer silent packet
    dropping by using an inline-device for this purpose, e.g. snort-inline with
    iptables or RealSecure Guard.

    It's better to create a "blackhole" than flooding the attacker with tcp-resets
    anyway.

    Some other reasons:
    * Generating tcp resets can decrease the performance of your IDS a great deal,
    especially on fast links. Depending on the protocol in use you probably have to
    reset lots and lots of resets (check out VNC as an example). To be sure you must
    reset both client and server, which increases the performance issues.
    * As you outlined, tcp-resets can tell the attacker that your site is running an
    IDS, whatever flavour shall be irrelevant right now. If the attacker knows that
    your IDS is sending out resets he can use this information in order to blind the
    IDS by generating lots and lots of fake attacks to several hosts. Thus the
    attacker can decrease the performance of the IDS, DoS your servers and create so
    much noise (both on your network and your IDS) that you will no longer be able
    to determine what's the real attack. At least it's getting much more
    complicated.

    IMHO the drawbacks of tcp-reset exceed the pros by far.

    Greetings,

    Detmar Liesen

     -----Ursprüngliche Nachricht-----
    Von: Abe L. Getchell [mailto:abegetchell@qx.net]
    Gesendet: Donnerstag, 16. Januar 2003 19:37
    An: focus-ids@securityfocus.com
    Betreff: Active response... some thoughts.

    Greetings all,
            Yesterday I was discussing one of my favorite topics with a
    friend who works at Enterasys. We were discussing intrusion detection
    systems and active response; the use of IDS sensors to detect attacks
    and either make a policy change on a firewall or actively respond to
    intrusions itself (through the use of TCP resets, ICMP port and network
    unreachable's, etc). While discussing the benefits and drawbacks we
    both feel come along with this technology, I mentioned a specific issue
    I had with a sensor directly responding to detects, and he said it was
    something that he had never thought of before. After poking around for
    a while in the list archives, I can't find anywhere where it's
    mentioned, even when discussing this particular topic. I find it hard
    to believe that I'm the first one to think of this, because there are
    much smarter people on this list than me, but I'm curious to know what
    the community here thinks about this...
            Basically, it's possible for an attacker to calculate where an
    IDS sits on an organization's network by looking at the TTL in the IP
    header of the TCP reset or ICMP error message he receives in response to
    an attack. For example, let's say we have the following network setup:

    [Server]--[Router]--[Router]--[IDS]--[Firewall]--[Router]--[Router]--[At
    tacker]

            The attacker is trying to break into the server and the sensor
    has a signature that resets the connection when it sees the exploit he's
    trying to use. When the attacker sends his exploit to the target
    server, it doesn't work. Since this is a smart attacker, he grabs a
    packet capture to find out exactly what's happening and sees that his
    connection is being reset. He notices that in the resets the TTL in the
    IP header is 252 compared to 250 for normal responses. Knowing now that
    an IDS must be using active response to keep him from exploiting the
    target server, he wants to find out where this sensor resides.
    Referencing the source code of his favorite IDS (and mine - Snort 1.9.0
    from http://www.snort.org/ (SHAMELESS PLUG)), he finds the following
    bits of code in sp_respond.c:

    libnet_build_ip(TCP_H, 0,
                    libnet_get_prand(PRu16) /* IP ID */ ,
                    0 /* fragmentation */ , 255 /* TTL */ , IPPROTO_TCP,
                    0, 0, NULL, 0, tcp_pkt);

    libnet_build_ip(ICMP_UNREACH_H, 0,
                    libnet_get_prand(PRu16) /* IP ID */ ,
                    0 /* fragmentation */ , 255 /* TTL */ , IPPROTO_ICMP,
                    0, 0, NULL, 0, icmp_pkt);

            He sees that these bits of code build the IP header for the TCP
    reset and ICMP unreachable messages that the IDS uses for active
    response. Knowing from this code that the TTL is statically set to 255
    and hence, that's what it was when the reset left the NIC of the IDS, he
    can then easily trace the path backwards through each hop (assuming
    there's no asymmetric routing happening) and determine on what segment
    the sensor resides by using simple addition! This information is
    invaluable to the attacker for future attacks against the network, and
    he now knows where he should focus his attack if he wants to disable the
    sensor itself.
            I posted a message about this on the Snort developers list quite
    some time ago, which got a good discussion going, but we couldn't come
    up with a good solution to this problem. I believe the best idea that
    we can up with was to randomize the TTL, though if an attacker would see
    a whole bunch of resets come back with TTL's that wildly jump around,
    that would be a clue that the organization he is attacking is using
    Snort... and telling an attacker what IDS you're using, is of course, a
    bad thing. Another good idea was to let the user specify (in a
    configuration file somewhere for those that don't build from source) a
    TTL that they wanted to use... obviously you'd want to use some
    off-the-wall number like 213 or so. The attacker wouldn't know what hop
    to count back too because he wouldn't know what the TTL was originally
    set too.
            Please note that I'm only using Snort as an example here because
    it's the only IDS software that I have the source code for and could
    easily pull an example from. I believe, but am not _sure_, that
    probably all IDS software is affected by this specific issue. Of
    course, this is just another good reason _not_ to use active response...
    or if you must, just break the connection on the internal side. The
    attacker could manipulate his TCP stack not to honor resets anyway.
    Thoughts?

    Thanks,
    Abe

    --
    Abe L. Getchell
    Security Engineer
    abegetchell@qx.net
    


    Relevant Pages

    • RE: Active response... some thoughts.
      ... Subject: AW: Active response... ... It's better to create a "blackhole" than flooding the attacker with tcp-resets ... Generating tcp resets can decrease the performance of your IDS a great deal, ... IDS, whatever flavour shall be irrelevant right now. ...
      (Focus-IDS)
    • RE: Active response... some thoughts.
      ... Subject: Active response... ... Netscreen IDS features TCP reset as a major feature of their ... between your attacker and your IDS, ... The attacker could modify his IP-stack such that resets are being ignored ...
      (Focus-IDS)
    • RE: Active response... some thoughts.
      ... between your attacker and your IDS, ... of the IDS you have. ... Subject: AW: Active response... ... The attacker could modify his IP-stack such that resets are being ignored ...
      (Focus-IDS)
    • Re: Active response... some thoughts.
      ... Subject: Active response... ... > drops the packet on the wire before it gets past the in-line IDS. ... Active-response is great if you have a signature for it ... the attacker can just simply hack his stack to ignore the ...
      (Focus-IDS)
    • RE: Active response... some thoughts.
      ... Resets can create a storm of packets ... there are many ways to bypass IDS sensors. ... the attacker then proceeds to t ... > Subject: AW: Active response... ...
      (Focus-IDS)