IDS mailing list archives
RE: Active response... some thoughts.
From: "Christopher Lyon" <cslyon () netsvcs com>
Date: Sun, 26 Jan 2003 00:58:10 -0800
Don't forget that the active responses on Snort as well as ISS comes from the management interface. Granted this is only on stealth interface installation on Snort but in ISS you can select which interface it will come from. I know that most people, for security reasons, manage there sensors from a separate network or segment so tracking down which segment you are sniffing should be a little more difficult for an attacker since the event that triggered the active response comes from a different segment. Besides, the only information that he would get would be a hop count for the management interface and if the management interface isn't secured by a firewall and/or has open access from the outside, you have other problems. Another thought on this, so an attacker gets an active response, figures out the hop count, he might be able to figure out what segment it is detecting him on but can he disable the sensor if the interfaces are in stealth. Can he use invasion tactics to bypass the sensor? Can he DOS the sensor out of existence? Sure all the above and I know there are other way to bypass this but if the attacker is smart and if he knows what he is doing then he would be watching any responses coming back to him for his actions. If he gets a consistent active response based on attacking different hosts on different segments and figuring out which segments get active responses and which don't, and then he doesn't need a TTL to figure out what segment the sensor is on. The big thing is that he will know you are using an IDS sensor. The only reason that I see a need to do an active response is if you are doing a policy modification on a firewall and that firewall keeps the session alive even if a block for an IP address is put on the firewall. Yes, this sounds odd but there are a few firewalls out there that if it has a session going across it and a block for either the source or destination of this session goes up, the session will stay up but if I bring the session down and try to bring it back up it won't work. So, keeping the active responses down to a minimum by doing active policy modification seems to be a good fit but just using active responses does seem to stress out the sensor in a bad way. I agree with Detmar in that sending them out consistently isn't a good thing but if you just do a simple, kill then block, the hosts that the attacker was going after are now gone. Just my .02
-----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]--[Router]--[A
t
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
Current thread:
- Active response... some thoughts. Abe L. Getchell (Jan 20)
- RE: Active response... some thoughts. Abe L. Getchell (Jan 23)
- Re: Active response... some thoughts. Martin Roesch (Jan 26)
- <Possible follow-ups>
- RE: Active response... some thoughts. Abe L. Getchell (Jan 26)
- RE: Active response... some thoughts. Ralph Los (Jan 26)
- RE: Active response... some thoughts. Christopher Lyon (Jan 26)
- RE: Active response... some thoughts. Alan Shimel (Jan 26)
- RE: Active response... some thoughts. Kohlenberg, Toby (Jan 28)
- RE: Active response... some thoughts. Garbrecht, Frederick (Jan 28)
- Message not available
- Re: Active response... some thoughts. Stone Cold (Jan 31)
- Message not available
- RE: Active response... some thoughts. Kohlenberg, Toby (Jan 28)
- RE: Active response... some thoughts. mb_lima (Jan 28)
- Re: Active response... some thoughts. Paul Palmer (Jan 31)
- RE: Active response... some thoughts. Rob Shein (Jan 31)
- Re: Active response... some thoughts. mb_lima (Jan 31)