IDS mailing list archives
RE: Active response... some thoughts.
From: "Abe L. Getchell" <abegetchell () qx net>
Date: Fri, 24 Jan 2003 01:17:04 -0500
...and this would solve the problem, sort of. For all practical purposes you're entering a "packet race" when you use this technique. You're trying to get the resets to either endpoint of the connection before the real packet gets there, thus making sure sequence numbers are correct so the machines at both ends don't know anything funny is going on and reject the subsequent "real" packets like you're trying to make them do. When you only send resets to one end of the connection you're technically cutting your chances of this succeeding in half, the way I see it (which very well may be wrong). The more resets you send out on the wire as fast as you can, the better the chance of one of those getting there before the real packet does and closing the connection before any damage can be done. This is why Marty spent a considerable amount of time manipulating the FelxResp code in Snort a year or so ago to setup precaching of IP and UDP/TCP headers used in the response packets... the less time you spend generating these headers on the fly, the more of them you can send out at a higher rate of speed. FWIW, we found that during the original Code Red outbreak, we saw a 90% success rate when using FlexResp to snipe sessions from infected hosts. This, of course, means that 10% of all of those forged reset packets didn't make it to either end of the connection in time... this was before the days in Snort where the precaching I mentioned above was implemented. I haven't been lucky (?) enough to be in a situation again where I've needed to test this ability in a high-volume production environment. Thanks, Abe -- Abe L. Getchell Security Engineer abegetchell () qx net
-----Original Message----- From: Ron Gula [mailto:ronald.gula () verizon net] Sent: Monday, January 20, 2003 11: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 intrusiondetectionsystems 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 portand networkunreachable's, etc). While discussing the benefits and drawbacks we both feel come along with this technology, I mentioned aspecific issueI had with a sensor directly responding to detects, and hesaid it wassomething that he had never thought of before. After pokingaround fora while in the list archives, I can't find anywhere where it's mentioned, even when discussing this particular topic. Ifind it hardto 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 toknow whatthe community here thinks about this... Basically, it's possible for an attacker tocalculate where anIDS 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 inresponse toan attack. For example, let's say we have the followingnetwork setup:[Server]--[Router]--[Router]--[IDS]--[Firewall]--[Router]--[Router]--[Attacker] The attacker is trying to break into the server andthe sensorhas a signature that resets the connection when it sees theexploit he'strying 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 resetsthe TTL in theIP header is 252 compared to 250 for normal responses.Knowing now thatan 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.0from 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 headerfor the TCPreset and ICMP unreachable messages that the IDS uses for active response. Knowing from this code that the TTL is staticallyset to 255and hence, that's what it was when the reset left the NIC ofthe IDS, hecan then easily trace the path backwards through each hop (assuming there's no asymmetric routing happening) and determine onwhat segmentthe sensor resides by using simple addition! This information is invaluable to the attacker for future attacks against thenetwork, andhe now knows where he should focus his attack if he wants todisable thesensor itself. I posted a message about this on the Snortdevelopers list quitesome time ago, which got a good discussion going, but wecouldn't comeup with a good solution to this problem. I believe the bestidea thatwe can up with was to randomize the TTL, though if anattacker would seea 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, isof course, abad thing. Another good idea was to let the user specify (in a configuration file somewhere for those that don't build fromsource) aTTL that they wanted to use... obviously you'd want to use some off-the-wall number like 213 or so. The attacker wouldn'tknow what hopto count back too because he wouldn't know what the TTL wasoriginallyset too. Please note that I'm only using Snort as an examplehere becauseit'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 activeresponse...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)