RE: Active response... some thoughts.

From: Alan Shimel (alan@latis.com)
Date: 01/27/03

  • Next message: mb_lima: "RE: Active response... some thoughts."
    Date: Sun, 26 Jan 2003 21:45:14 -0700
    From: "Alan Shimel" <alan@latis.com>
    To: "Ralph Los" <RLos@enteredge.com>, <detmar.liesen@lds.nrw.de>, <abegetchell@qx.net>, <focus-ids@securityfocus.com>
    

    Ralph

    I agree! Most security experts I have spoken to agree with you as well. However, Netscreen IDS features TCP reset as a major feature of their product and sell prospective customers on it. I don't get it personally but we were forced to implement and support it just to match the feature for those customers who demanded it

    alan

    Alan Shimel
    VP of Sales & Business Development
    Latis Networks, Inc.

    303-642-4515 Direct
    516-857-7409 Mobile
    303-642-4501 Fax

    www.stillsecure.com
    Reducing your risk has never been this easy.
    . . .
    The information transmitted is intended only for the person
    to which it is addressed and may contain confidential material.
    Review or other use of this information by persons other than
    the intended recipient is prohibited. If you've received
    this in error, please contact the sender and delete
    from any computer.

    -----Original Message-----
    From: Ralph Los [mailto:RLos@enteredge.com]
    Sent: Friday, January 24, 2003 10:39 AM
    To: 'detmar.liesen@lds.nrw.de'; 'abegetchell@qx.net'; 'focus-ids@securityfocus.com'
    Subject: RE: Active response... some thoughts.

    Gentlemen,

            I can't agree more. I implement and support IDSes at some very
    large companies and even some small ones, and TCP-Reset is not a widely
    popular nor, IMHO, effective strategy. First off, as the email mentions
    below, the attacker can just simply hack his stack to ignore the
    resets...hey, it's possible. Also, TCP-Resets can create a storm of packets
    between your attacker and your IDS, effectively decreasing the effectiveness
    of the IDS you have.

            Picture this...you have an attacker who figures our you have an
    IDS...woo hoo, right? Well, the attacker then proceeds to think that it's
    better to just wipe you off the 'net than to hack your box, less effort that
    way. How trivial would it be to write a script (for those that can code) to
    continue to supply large-quantities of packets at the target host. These
    packets get intercepted by the IDS and it starts to send out huge quantities
    of TCP-Resets. The router in-between starts to see utilization go up, up,
    up until you have a saturated circuit - and what's worse, you're partly to
    blame. I can't afford to have an instance where my clients call me to tell
    me my IDS has participated in a DoS against their 'net. For this reason I
    stick with NetworkICE's (ISS, who?, heh) Guard product. It's in-line, fast
    and does the trick. I'm not sure if you guys have used IntruVert's product
    large-scale, but I'm working with them to do some testing...sounds like a
    competitor to Guard.

            Anyway - the point sir, we well made, and well taken. But I have to
    say that in 75%+ of my managed networks, I don't care because I wouldn't
    implement at TCP-Reset product anyway :)

    Just my personal, very humble opinion
    Ralph

    -----Original Message-----
    From: detmar.liesen@lds.nrw.de [mailto:detmar.liesen@lds.nrw.de]
    Sent: Tuesday, January 21, 2003 2:17 AM
    To: abegetchell@qx.net; focus-ids@securityfocus.com
    Subject: AW: Active response... some thoughts.

    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.
      ... 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)
    • Re: Active response... some thoughts.
      ... It is good to remember that many IDS implementations send ... TCP RST to the two endpoints in the communication. ... the attacker can just simply hack his stack to igno ... stack such that resets are being ...
      (Focus-IDS)