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

Smith, Donald Donald.Smith at ...530...
Wed Aug 22 19:27:37 EDT 2001


It was actually I who said it was compute intensive. When responding to a
packet with the hopes
of silencing both the scanner and scannie every millisecond counts. I later
posted a simple code idea that would
allow non-random ttls that appeared the same for every host in a domain.
This would be more ideal. Have the whole domain appear to respond with the
same ttl. I realize many people don't believe in responding at all. I could
make an argument for
that too but prefer to respond in a legal manner. 

Most normal packets don't have a ttl that will "time out" right at the 
door step of the scannie. In fact only things like traceroute do that. The
rest of the ip world comes with a ttl starting at
64,128 or 255 (well mostly;-)


> -----Original Message-----
> From: tlewis at ...255... [mailto:tlewis at ...255...]
> Sent: Wednesday, August 22, 2001 4:23 PM
> To: agetchel at ...358...
> Cc: snort-devel at lists.sourceforge.net
> Subject: Re: [Snort-devel] IDS fingerprinting techniques & Snort's
> FlexRe sponse...
> 
> 
> Dragos, producing pseudo-random numbers, especially for such a small
> domain, is not nearly the herculean task which you make it out to be.
> If you are really worried about the problem, though, even random ttl's
> might not be good enough, as this still does not replicate the normal
> behaviour, and this it still can leak info.
> 
> Personally, I think that the answer is to drop packets rather 
> than trying
> to fool the attacker into stopping.  If you had a flexible 
> rule system,
> then you could drop packets whose ttl is >= the ttl required for it
> to get to the destination.  That way, traceroutes would go right up to
> the target of the attack and then die, with the attacker 
> having no clue
> which box in the middle is doing the filtering.
> 
> Unless you're willing to put a lot of effort into closing all of these
> doors, it will remain easy to identify the IDS system, and 
> the marginal
> return for this work will remain close to zero.  For that reason, I
> think that time is better spent on the more serious problems at hand
> that have a lower investment-payoff threshold.
What doors? Sorry I don't get this part. As for payoff counic, snort
flesresp, and now labrea can all be used
to affect worms. They may not affect live hackers with an understanding of
the entire ip stack but they are hard to 
fool with any automated tool.
 
> --
> Todd Lewis
> tlewis at ...255...
> 
> On Wed, 22 Aug 2001, Dragos Ruiu wrote:
> 
> > 
> > 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
> >  response.  Solve problem of adding uncertainty about 
> 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 
> 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-----
> > > > 
> > > 
> > > _______________________________________________
> > > Snort-devel mailing list
> > > Snort-devel at lists.sourceforge.net
> > > http://lists.sourceforge.net/lists/listinfo/snort-devel
> > > 
> > 
> > _______________________________________________
> > Snort-devel mailing list
> > Snort-devel at lists.sourceforge.net
> > http://lists.sourceforge.net/lists/listinfo/snort-devel
> > 
> 
> 
> _______________________________________________
> 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