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

Smith, Donald Donald.Smith at ...530...
Wed Aug 22 06:43:05 EDT 2001

```It sounds really good. You only have to compute 1 random number every 255/n
or so packets.
However if I saw the ttl on a reset follow this tread 20,21,22,...255 or
20,22,24,...254 etc
I would know something was up;-)

Besides when we are responding most of the time we get to respond for a
whole net one at a time.
As someone scans my net for port 53 it would make sense to have the ttl be
constant for all of the resets in that network.
Assuming I don't have a lot of routers splitting up my single class b
So if the ttl was randomized 1 time per netblock scan that would seem to be
enough and probably not too expensive.
Better yet I don't need a real random number just something that requires
WORK to figure out.
128? And only compute it once for each netblock scan.

> -----Original Message-----
> From: Dragos Ruiu [mailto:dr at ...40...]
> Sent: Tuesday, August 21, 2001 8:01 PM
> To: agetchel at ...358...
> Cc: Donald.Smith at ...530...; tliston at ...621...;
> snort-devel at lists.sourceforge.net
> Subject: Re: [Snort-devel] IDS fingerprinting techniques & Snort's
> FlexRe sponse...
>
>
>
> Solution and best of both worlds:
>
> Hypothetical problem:
>
> massive information hemmorhage through ttl of snort flexresp rst's....
>
> Overly resource intensive solution: randomize them.
>
> Better solution: cycle through a linear count of 20+x<->n+x
> for each successive
> distance to ids location,
>  without cpu intensity of gettign real entropy.  Preselect
> small random delta (x)
>  to boundaries (20,n - where n is random too) of cycle range
> once at startup.
>
> cheers,
> --dr
>
>
> On Tue, 21 Aug 2001 17:17:18 -0400
> agetchel at ...358... wrote:
>
> > Greetings!
> > 	Of course slowing down packet generation is a bad
> thing, especially
> > when trying to win packet races.  I'm concerned that this
> change would
> > effect the reliability of Snort's FlexResponse, but will of
> course do
> > vigorous testing after I make the change tonight.  Thanks
> for the code
> > snippit.
> >
> > 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 4:40 PM
> > > To: 'agetchel at ...358...'; Smith, Donald ;
> tliston at ...621...
> > > Cc: snort-devel at lists.sourceforge.net; 'tliston at ...621...'
> > > Subject: RE: [Snort-devel] IDS fingerprinting techniques & Snort's
> > > FlexRe sponse...
> > >
> > >
> > > -----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
> > > > > > 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
> > > > > > 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
> > > > > > 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-----
> > >
> >
> > _______________________________________________
> > Snort-devel mailing list
> > Snort-devel at lists.sourceforge.net
> > http://lists.sourceforge.net/lists/listinfo/snort-devel
> >
>

```