[Snort-devel] IDS fingerprinting techniques & Snort's FlexResponse...

agetchel at ...358... agetchel at ...358...
Mon Aug 20 22:37:23 EDT 2001


Good evening ya'll,
	I've been doing some research into IDS fingerprinting techniques
(the methods attackers use to gain knowledge about the type of IDS you're
running and where it's placed) and have come across two concerns related to
Snort's FlexResponse code.  It's obvious that whenever you're using some
kind of active response on an IDS, you're giving information away.  This
information might range from "Hey, I'm using and IDS doing active response,
and here's a whole bunch of ICMP Host Unreachable's to prove it!" too "I'm
using an IDS doing active response using X version, of X brand, on X OS, and
here's my serial number so you know I paid for it!".  I think, knowing the
risks of utilizing active response, the Snort community should strive to
make it more difficult (isn't that what security is all about? =) for an
intruder to determine that you're using Snort and where that box is placed.
To these ends, I've noticed the following about Snort's FlexResponse code:

-The TTL of all FlexResponse packets built by Snort is hard-coded to
sixty-four.  The attacker, doing a simple traceroute into your network,
could count the number of hops it takes to get there, add this to the TTL of
the packets which are resetting his connection, and get a number close too
the magical sixty-four (unless your IDS is deep within your network, which
would probably trip him up for a bit... but more on determining placement
below).  This would tell him that there's a reasonable probability that
you're using Snort, and can thus deploy a tool like stick or snot to make
you have a bad day.
	This "fun with TTLs" also has the nasty side effect of letting the
attacker know how deep into your network your Snort box is sitting;
potentially on which specific segment.  For instance, if the attacker does a
traceroute into your network and determines that he's ten hops away from
your border router, and receives packets which are resetting his connection
that have a TTL of fifty-four (a TTL of sixty-four minus ten hops for the
packet to get to you) then he knows that the IDS is sitting on the other
side of your border router.  If he bypasses those countermeasures, and is
still getting resets from a Snort box placed deep within your network, he
can tell how far into your environment you have your second tier IDS placed.
An attacker knowing your IDS placement is "bad thing".
	Would it be a better solution to have Snort randomly generate the
TTL of the packet when using FlexResponse?  Say to a number between 64 and
255?  This would at least keep the attacker guessing about where your IDS is
placed, and potentially hide the fact that you're using Snort... unless of
course Snort is the only IDS that uses randomly generated TTLs when doing
active response, in which case it would be a signature of Snort to see
packets coming back at you with TTLs all over the place.  But at least it
might keep him guessing for a while.

-Snort always seems to send the same number of ACK-RSTs or ICMP error
messages back to the host which it is trying to shun.  While this isn't
telling the attacker where your IDS is placed, it is a good signature that
you're running Snort and can be defeated by using a tool like stick or snot.
Maybe it would be a good idea send a single reset or ICMP error message
back, thus more realistically resembling what a real IP stack would do under
normal conditions.  I'm sure there are downsides to this, like the fact that
you can get into "packet races" with the packet traveling across the wire
which tripped the response, your packet arriving at the target host second
behind the offending packet, and being dropped in the bit-bucket thus
allowing the connection to continue; hence the need for sending multiple
packets to try and win the race... I think I can I think I can! =)  Are
multiple reset packets or ICMP messages sent to ensure reliability?

		In either case, one could always opt to send resets or ICMP
errors only back to the destination host (which for an incoming attack would
be located on your network) keeping all response to intrusion on your
internal network, though I believe that reliability suffers when you don't
reset both ends or the connection... the whole "packet race" thing.
Thoughts on this one?

Thanks,
Abe

Abe L. Getchell - Security Engineer
Division of System Support Services
Kentucky Department of Education
Voice   502-564-2020 ext. 225
E-mail  agetchel at ...358...
Web     http://www.kde.state.ky.us/




More information about the Snort-devel mailing list