Re: Active response... some thoughts.

From: Martin Roesch (roesch@sourcefire.com)
Date: 01/26/03

  • Next message: Christopher Lyon: "RE: Active response... some thoughts."
    Date: Sat, 25 Jan 2003 23:27:36 -0500
    To: abegetchell@qx.net
    From: Martin Roesch <roesch@sourcefire.com>
    
    

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Off the top of my head I can think of a quick and effective fix for
    this problem. Since we keep state on TCP connections with stream4
    these days, it should be pretty trivial to record the TTL of packets
    transiting the segment that the NIDS is on and use that TTL for any
    response packets sent. This way it looks "natural" and we don't have
    to worry about TTL "fuzzing" caused by a PRNG.

    If stream4 is turned off, then we're back to the PRNG route.
    Additionally, if you're worried about "missing" the TTL because you're
    resetting on the SYN packet, you need to remember that you shouldn't
    ever do an active response on the SYN packet with Snort! If you've got
    a rule that is meant to enforce policy via session kills you should
    never key on the SYN packet, if you "miss" on the first packet you
    don't get another chance. Traditionally we like to wait for the
    session to become established and then let the detection engine kill
    the connection:

    alert tcp $HOME_NET $SOME_PORT -> any any (flags: A; resp: rst_all; ...)

    This way if the session kill misses on the first attempt, it'll keep
    trying until the session is dead.

    If we were feeling really adventurous we could implement a persistent
    "kill this session tag" that lasts until the session is gone, that way
    you can start trying to kill the session on the SYN packet if desired
    without having to rely on continuous detects by the rules engine. This
    could be done pretty easily by extending the tagging mechanism or
    implementing a similar mechanism in a separate subsystem.

          -Marty

    On Thursday, January 16, 2003, at 01:37 PM, Abe L. Getchell wrote:

    > 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
    >
    >
    - --
    Martin Roesch - Founder/CTO Sourcefire Inc. - (410) 290-1616
    Sourcefire: Enterprise-class Intrusion detection built on Snort
    roesch@sourcefire.com - http://www.sourcefire.com
    Snort: Open Source Network IDS - http://www.snort.org

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.1 (Darwin)

    iD8DBQE+M2O8qj0FAQQ3KOARAkG5AJ4ptaHSPCCgyWyIRavbpcKjAX125gCdE5S4
    lhaIFET7TwSp/pZbrufKBlQ=
    =DU/S
    -----END PGP SIGNATURE-----



    Relevant Pages

    • 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.
      ... 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)
    • 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... ... > 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)