Re: Active response... some thoughts.

From: Talisker (talisker@networkintrusion.co.uk)
Date: 01/27/03

  • Next message: Jordan K Wiens: "Re: NetScreen IDS (X-post)"
    From: "Talisker" <talisker@networkintrusion.co.uk>
    To: "Kohlenberg, Toby" <toby.kohlenberg@intel.com>, "Ron Gula" <ronald.gula@verizon.net>, <focus-ids@securityfocus.com>
    Date: Mon, 27 Jan 2003 19:10:06 -0000
    
    

    Hi Toby (LTNS)
    I'd agree, there are some risks with active response. The best one I have
    seen so far is when an analyst wrote a funky little signature that reset ALL
    TCP, now known as the "clear your desk and go home signature". However, we
    were also inband reporting, guess what, the only way to stop it was to jump
    in a car and drive over there and unplug the box.

    Another problem with crafted resets through the stealth interface is being
    able to convince the security accreditors that your IDS is not bypassing the
    firewall.
    I have recently seen one of the vendors produce a Stealthy inline TAP that
    allows crafted resets to be inserted back through the TAP. As I have
    mentioned their name quite a bit over the past few weeks and I wish to
    appear unbiased please contact me off list for further information.

    Going back to the original post I think Ron's solution (as always) holds a
    lot of merit and is used by at least one other vendor. Though Marty's
    solution of sending back at the TTL of the offending packet is cool, though
    I would add a few. I'm sure SecureNetPro crafts and sends the resets both
    ways through the stealth interface.

    take care
    -andy

    Taliskers Network Security Tools
    http://www.networkintrusion.co.uk
    ----- Original Message -----
    From: "Kohlenberg, Toby" <toby.kohlenberg@intel.com>
    To: "Ron Gula" <ronald.gula@verizon.net>; <focus-ids@securityfocus.com>
    Sent: Friday, January 24, 2003 1:45 AM
    Subject: RE: Active response... some thoughts.

    I looked at the whole active response thing a while ago and have yet
    to see anything that changes my basic opinion-
    very few events are well defined enough to trust an automated response
    that could cause problems for a customer. The coolest response I've
    seen was from Dragon which can send false/funky responses to an attacker
    when it sees a scan going on.

    It will be a long time before I think IDSs will be trustworth enough to
    use such technology frequently.

    (all opinions are my own and in no way reflect the views of my employer)

    toby

    > -----Original Message-----
    > From: Ron Gula [mailto:ronald.gula@verizon.net]
    > Sent: Monday, January 20, 2003 8:01 PM
    > To: focus-ids@securityfocus.com
    > Subject: Re: Active response... some thoughts.
    >
    >
    > I have not looked at this problem in a while, but why not
    > just send your reset
    > packets to the target host and not the attacker? That way
    > nothing comes
    > from the NIDS to the attacker directly.
    >
    > Ron Gula, CTO
    > Tenable Network Security
    >
    > At 01:37 PM 1/16/2003 -0500, 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]--[R
    > outer]--[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
    >