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

agetchel at ...358... agetchel at ...358...
Thu Aug 23 21:45:46 EDT 2001


Good evening!
	What you run into here is the classic problem of the sensor not
having enough information about the network it's protecting to accurately
handle network based intrusions.  For instance, your IDS shouldn't alert you
on an IIS buffer overflow when it's being sent to an OpenBSD web server
running Apache, or alert you when someone runs a Linux ftpd DoS attack
against a Windows 2000 box running IIS 5.0's FTP service.  Hence, you
shouldn't have an IDS sending a reset when it doesn't know what TTL it
should be using to accurately emulate the TTL of the target of the attack.
	I suppose an option could be included in the Snort configuration
file where, when setting the $HOME_NET variable, to tell Snort how many
metric hops the server it's running on is away from each network you
specify.  This would allow the sensor to decrement the TTL by the correct
amount to emulate a reset from each network it's monitoring.  However, you
still have the same problem you mentioned below.  What's the starting TTL?
This I don't have an answer for, without somehow configuring Snort to have
an intimate knowledge of your network...
	What if Snort implemented some sort of "packet cache"?  This could
be configured in the Snort configuration file by setting the number of
megabytes of RAM to dedicate to the cache.  Snort would save a copy of every
packet that came in off the wire (whether it matches a signature or not) in
this cache to refer too when determining how to handle certain detections.
On high volume networks you'd have to set the amount of memory for the cache
to utilize pretty high, but chances are if you're monitoring a network
pushing a lot of data you've already invested a lot of money in sensor
hardware and have plenty of RAM to spare.  Related to this specific problem,
Snort could simply look at the TTL of a packet which it grabbed off of the
wire during any part of the session previously (the TCP three way handshake
for example), coming from the target host, and use that TTL when sending the
reset back to terminate the connection.
	On another note, wouldn't it be cool for Snort to have the ability
to look at the conversation (from the packet cache) which occurred before
the actual detect took place and make decisions on how it will handle the
detect based upon that information as well as the single packet which caused
the alert to be generated?  Or even have the ability, when an alert is
triggered, to have the sensor capture data for another X number of
milliseconds and see what the server's response was and take action based
upon that?  Of course this would cause packets to go by unchecked and would
really only be feasible in a multi-threaded Snort, unless you didn't read
data directly from the wire, but from this packet cache in the first place
and have Snort play catch-up when it's done processing the alert it's
working on.
	Yadda yadda yadda, at this point I'm just brainstorming... I'm not
sure if any of this is realistic to implement in an IDS, but it sure would
be cool.  Eh? =)

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: Thursday, August 23, 2001 5:37 PM
> To: 'agetchel at ...358...'; dr at ...40...
> Cc: tlewis at ...255...; snort-devel at lists.sourceforge.net
> Subject: RE: [Snort-devel] IDS fingerprinting techniques & Snort's
> FlexRe sponse...
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> So what you really need is the "correct" ttl that the host would have
> responded with
> if the host had responded right?
> But depending on the target's os that will start with 255, 128 or 64
> (maybe some other values but those are the common ones).
> So fool them into thinking the whole network by using 128 instead of
> 64;-)
> Does a reset comming from 128 become a sig for snort? Maybe but it is
> also the sig for several other common os.
> It's simple, easy and unless your attacker has already mapped your
> network then he/she won't know it came from your ids.
> 
> To make things just a little more difficult put it in the configure
> file to ask if they want 64, 128, 255 or some other number to be used
> as the ttl in flexresp. That way if my internal network is 3 hops
> away from my ids I could choose 125 as a starting ttl!
> Further if different people used different numbers it would be less
> of a signature.
> 
> 
> 
>  
> 
> 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: Thursday, August 23, 2001 3:12 PM
> > To: dr at ...40...
> > Cc: tlewis at ...255...; snort-devel at lists.sourceforge.net
> > Subject: RE: [Snort-devel] IDS fingerprinting techniques & Snort's
> > FlexRe sponse...
> > 
> > 
> > 	LOL!  Ok, let me try and hit every box on the Internet 
> > and see who's
> > seventeen hops away from me... that should narrow it down. =) 
> >  Seriously
> > though, I know there's a big difference between knowing where 
> > the IDS is
> > placed and what software it's running, as I did address them 
> > as separate
> > issues in my original e-mail to the list.  The problem is, with
> > Snort setting the TTL of flexresp packets too sixty-four every time
> > it sends one
> > out, it gives an intruder information about back about where 
> > the IDS is
> > located (remember, he's targeting one specific network and 
> > probably has it
> > mapped out pretty well) and what software it's running.  With
> > flexresp packets always having a TTL of sixty-four, it becomes a 
> > signature of Snort!
> > 
> > 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: Dragos Ruiu [mailto:dr at ...40...]
> > > Sent: Thursday, August 23, 2001 9:13 AM
> > > To: agetchel at ...358...
> > > Cc: tlewis at ...255...; snort-devel at lists.sourceforge.net
> > > Subject: Re: [Snort-devel] IDS fingerprinting techniques &
> > > Snort's FlexRe sponse...
> > > 
> > > 
> > > On Wed, 22 Aug 2001 23:06:15 -0400
> > > agetchel at ...358... wrote:
> > > > 	You don't think it's a big deal if an intruder knows 
> > > where your IDS
> > > > is placed and what software it's running?  Just because a 
> > > technique hasn't
> > > > been used to break into a network, doesn't mean it's 
> > > theoretical.  I've
> > > > _done_ this in a lab environment to make sure I wasn't 
> > > talking out of my
> > > > @$$. =)
> > > 
> > > There is a big difference between knowing where the IDS is 
> > > and what OS/sw
> > > it is running on and knowing the time-to-live of packets to it.
> > > 
> > > I'm probably TTL=17 away from you... find me...  :-)
> > > 
> > > cheers,
> > > --dr
> > > 
> > 
> > _______________________________________________
> > 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/AwUBO4V6TkPxB2evAO3MEQKxiACg7d+egrWDO6bVCZxTTE3QjoLiv/EAoN4q
> bnNLYcPQn/zj2bFli7uau0N3
> =ONoU
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> 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