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

agetchel at ...358... agetchel at ...358...
Tue Aug 21 15:47:47 EDT 2001


Greetings!
	Agreed.  While counting TTLs isn't generally an accepted practice
for determining metrics because of dynamic routing and the TTL potentially
being decremented by more than one by routers holding onto the packet, I've
personally found it to be quite accurate on "today's Internet".
	While sending packets back to the attacker may be meaningless, it's
quite effective with the tools that they're using today.  Most of the tools
widely used by your aggressor of average skill level are pretty basic, and
hence generally follow the rules of IP... which includes the functionality
of immediately stopping a session when receiving an RST.  Until these tools
are developed to be more "robust" (doing things like ignoring RSTs and
attempting to continue communications), the current methods we use to deter
these folks are actually pretty effective.  If you have a skilled aggressor
on your hands, you probably have more to be worried about than his software
ignoring RSTs. =)  Regardless, for the plague of "dumb" (I could think of
other choice words... =) worms running around on the Internet these days,
FlexRepsonse has been proven to be _very_ effective.  It would be a bad
thing if someone were to develop one that ignored common defensive
countermeasures such as this...

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/


> -----Original Message-----
> From: Burak DAYIOGLU [mailto:dayioglu at ...287...]
> Sent: Tuesday, August 21, 2001 3:07 AM
> To: snort-devel at lists.sourceforge.net
> Subject: Re: [Snort-devel] IDS fingerprinting techniques & 
> Snort's FlexResponse...
> 
> 
> agetchel at ...358... wrote:
> > 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".
> 
> Dynamic routing may result in different TTL's counted at each 
> time especially
> when the distance increases.
> 
> Your arguments are true. Counting TTLs to measure exact 
> distance is not
> generally accepted, which is one thing I hate.
> 
> Gateway systems decrease TTL "at least by one" depending on 
> the time it takes
> to process the packet. Still, I argue that exact TTL counting 
> should work because
> the processing power of ordinary gateway equipment has 
> improved so much that it
> ALWAYS takes less than a second.
> 
> Exact TTL counting cannot be used to measure distances in the 
> Internet (because
> of the existance of dynamic routing), but it is possible for 
> an IDS to measure
> its distance to hosts on the protected domain.
> 
> If an IDS can measure its distance from a protected host, it 
> cannot be fooled
> any more by TTL games (see Ptacek and Newsham for explanation 
> of the game).
> 
> Any counter-arguments to this suggestion? Measuring distances 
> between the NIDS
> and the protected hosts is easy if one has a passive 
> fingerprint plug-in with
> a good database of fingerprints. (I have one :)
> 
> >         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
> 
> Sending RST's or ICMP errors back to the attacker is 
> meaningless. A skilled
> attacker can easily discard such packets and attempt to 
> continue processing.
> It is best to send such active-response packets to the 
> protected domain
> only to close the protected-end of the communication. 
> However, we know that
> there are many people doing the reverse thing so I find your 
> proposition
> appropriate. Dynamically changing response packet properties with some
> randomness should be an easy trick for Marty.
> 
> Thanks.
> -- 
> Burak DAYIOGLU
> Phone: +90 312 2103379   Fax: +90 312 2103333
>        http://www.dayioglu.net
> 
> _______________________________________________
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/snort-devel
> 




More information about the Snort-devel mailing list