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

Smith, Donald Donald.Smith at ...530...
Thu Aug 23 23:09:29 EDT 2001


I DO NOT want the ids (or other responder such as Labrea) to know that much
about my network.
I think allowing for a hop count between your ids and your network might be
reasonable. But
if you ids/responder advertises that a machine has a ttl slightly less then
64 that is a clue to what
os is being run on that machine. Nope I think a static ttl - hop count is
acceptable. I also think that
 64 is too small so I am recommending 128 as the base static ttl number from
which a hop count (you decide if 
you want to lie about the hop count) is subtracted is good enough. It's
easy, cheap and fast. You don't see many solutions that give you all
three;-)
As for being alerted when someone trys a iis attack against my apache
server, YES I want to be alerted.
It is a false alert in that it will not work against my apache server but I
want to know when someone is trying 
an attack against any network element.
Now if you recommended a filtering process (as part of the database plugin
or something) that knew 10.1.1.1 was an apache server and cr2.0.1.7.alpha
wasn't going to work that would be full acceptable. Plus at the filter end
of things you can spend as many cycles as you want;-) At the realtime
response end we have to be conservative.

> -----Original Message-----
> From: agetchel at ...358... [mailto:agetchel at ...358...]
> Sent: Thursday, August 23, 2001 7:46 PM
> To: Donald.Smith at ...530...; dr at ...40...
> Cc: tlewis at ...255...; snort-devel at lists.sourceforge.net
> Subject: RE: [Snort-devel] IDS fingerprinting techniques & Snort's
> FlexRe sponse...
> 
> 
> 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