RE: Active response... some thoughts.

• Previous message: sstover: "RE: Active response... some thoughts."
• Maybe in reply to: Abe L. Getchell: "Active response... some thoughts."
• Next in thread: Talisker: "Re: Active response... some thoughts."
• Reply: Talisker: "Re: Active response... some thoughts."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Thu, 23 Jan 2003 17:45:07 -0800
From: "Kohlenberg, Toby" <toby.kohlenberg@intel.com>
To: "Ron Gula" <ronald.gula@verizon.net>, <focus-ids@securityfocus.com>

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
>

• Next message: Abe L. Getchell: "RE: Active response... some thoughts."
• Previous message: sstover: "RE: Active response... some thoughts."
• Maybe in reply to: Abe L. Getchell: "Active response... some thoughts."
• Next in thread: Talisker: "Re: Active response... some thoughts."
• Reply: Talisker: "Re: Active response... some thoughts."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]