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

Smith, Donald Donald.Smith at ...530...
Tue Aug 21 16:39:34 EDT 2001


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Liston's the author and was planning on a new release soon.

Contact him for the NEW version.
tliston at ...621...

The old version is probably still here.
http://www.threenorth.com/LaBrea

And yes a list of valid webservers is given so that LaBrea can ignore
those port 80 -> valid web server packets.

TTL = 63 + (int) ( 192 * rand()/(RAND_MAX+1.0) ) 

will give you a psuedo random number between 64 and 255.

Of course don't to forget to seed your random number generator ( ONLY
1
time) before using this.

Having shown you to do a "random" ttl realize random number
generation is expensive and WILL slow down any 
application that uses it. 

Donald.Smith at ...530... IP Engineering Security
303-226-9939/0688 Office/Fax
720-320-1537 cell

> -----Original Message-----
> From: agetchel at ...358... [mailto:agetchel at ...358...]
> Sent: Tuesday, August 21, 2001 2:24 PM
> To: Donald.Smith at ...530...; tliston at ...621...
> Cc: snort-devel at lists.sourceforge.net
> Subject: RE: [Snort-devel] IDS fingerprinting techniques & Snort's
> FlexRe sponse...
> 
> 
> Greetings!
> 	I'll work on some code to try and do this efficiently in
> FlexResponse tonight, unless of course someone doesn't beat 
> me to the punch.

> Anywho, just out of curiosity (and kind of off-topic for this 
> list), how
> does one identify a SYN coming in on port 80 that shouldn't 
> be there?  Would
> it be positioned much like an IDS, check a list of valid web 
> servers that
> has been predefined, and send a SYN-ACK out to anything that it
> sees a packet destined for that doesn't exist?  I did a search for
> this tool on-line, and didn't come up with anything.  If you have
> any 
> pointers to
> where I can read more about it, I would love to see 'em.  Oh, 
> and you don't
> want to know what kind of companies reside on "LaBrea" street in
> some cities... =)
> 
> 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: Smith, Donald [mailto:Donald.Smith at ...530...]
> > Sent: Tuesday, August 21, 2001 12:09 PM
> > To: 'Burak DAYIOGLU'; snort-devel at lists.sourceforge.net
> > Cc: 'tliston at ...621...'
> > Subject: RE: [Snort-devel] IDS fingerprinting techniques &
> > Snort's FlexRe sponse...
> > 
> > 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Something like 
> > TTL = 63 + (int) ( 192 * rand()/(RAND_MAX+1.0) ) 
> > 
> > will give you a psuedo random number between 64 and 255.
> > Of course don't to forget to seed your random number generator (1
> > time) before using this.
> > 
> > 
> > As for not bothering to send rst or icmp these methods do work
> > for many of the tools that
> > are currently being used to scan our networks. 
> > 
> > LaBrea by Tom Liston [tliston at ...621...] is currently 
> being used to
> > SLOW down the infection rate of the code red worm.
> > It sends syn/ack for every syn it sees that it shouldn't be
> > seeing.  
> > 
> > Until all hackers use prefected tools active defense works.
> > 
> > 
> > Donald.Smith at ...530... IP Engineering Security
> > 303-226-9939/0688 Office/Fax
> > 720-320-1537 cell
> > 
> > > -----Original Message-----
> > > From: Burak DAYIOGLU [mailto:dayioglu at ...287...]
> > > Sent: Tuesday, August 21, 2001 1: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
> > > 
> > 
> > -----BEGIN PGP SIGNATURE-----
> > Version: PGP Personal Privacy 6.5.8
> > 
> > iQA/AwUBO4KKmkPxB2evAO3MEQKU7gCdFDzXlmBfh/z4kcVC8NF5uAGRax8AnR4V
> > bemDNDR6/ozXRwnfnVBiFR09
> > =08D6
> > -----END PGP SIGNATURE-----
> > 
> > _______________________________________________
> > Snort-devel mailing list
> > Snort-devel at lists.sourceforge.net
> > http://lists.sourceforge.net/lists/listinfo/snort-devel
> > 
> 

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.8

iQA/AwUBO4LJ7kPxB2evAO3MEQK6LACgw5rM6MtQFETzLq/zTgzliPtCGXsAoIaE
QX781zL/DJbpvJ7X2cZ3LTOh
=+y5T
-----END PGP SIGNATURE-----




More information about the Snort-devel mailing list