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

agetchel at ...358... agetchel at ...358...
Fri Aug 24 00:23:30 EDT 2001


Good evening!
	NIDS which I've deployed myself and seen deployed by others have
been setup to watch geographically distributed mission critical systems,
with mass amounts of data going too and from them, and provide near
real-time alerting mechanisms.  They have better things to do than let me
know someone launched an IIS Unicode attack against my Solaris/Apache web
server. =)  I tend to get this type of (what I consider non-critical) data
from simple log auditing or HIDS; I don't need to know _right now_ that
someone tried an attack that won't work, but it's good to have given the
need to correlate data some time down the road.  FWIW, I'm not proposing
anything, I'm just trying to get a general feel about what features in Snort
folks on this list would like to see included.  The ability (and I stress
_ability_ - you could turn it off if you don't want to use it, as with
almost anything else in Snort) to be able to give your IDS intimate
knowledge about your network so it will only alert you to what could truly
be exploitable _could_ be a good thing.  I suppose this could really be
accomplished now by writing a _very_ specialized set of signatures noting
specific IP addresses and what to alert on going to them... but _man_ would
this take a massive amount of work.  Anybody have any idea how this could
more easily be accomplished?
	A static TTL of 128 minus a hop count specified in the snort config
file would work for me.  Anyone else out there care to comment before I get
started on the coding?

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 11:09 PM
> To: 'agetchel at ...358...'; Smith, Donald ; dr at ...40...
> Cc: tlewis at ...255...; snort-devel at lists.sourceforge.net
> Subject: RE: [Snort-devel] IDS fingerprinting techniques & Snort's
> FlexRe sponse...
> 
> 
> 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