[Snort-devel] Defeating the anti-IDS tools...

agetchel at ...358... agetchel at ...358...
Mon Apr 2 00:42:21 EDT 2001

Hi Matt,
	I agree with everything you're saying, except for your statement
that a preprocessor isn't the right way to go in this situation.  Engineers
do need to tune their rulesets to their environments.  We've cut the number
of rules on our IDS sensors down to about four hundred; not only does this
help performance of the box _tremendously_, but it also cuts down on false
positives which are generated that mean nothing to us.  Engineers also need
to use data mining tools to effectively generate statistics, identify attack
trends, as well as keep a history of intrusion attempts.  We currently do
this for all of our security devices.
	Imagine this situation though...  We are currently developing a
system which will allows us to view alerts from all of our security devices
in real-time from a simple console application.  It would be very
advantageous to be able to have an alert logged in a different log file
(which would be monitored by the console) that would tell us that Snort has
detected over three hundred alerts in the period of five seconds.  This
means we could immediately sit down and start going through logs to see what
exactly is going on.  I suppose this could be accomplished by logging all
the information to a database, then having a query run every minute which
would search through it for a large amount of entries in a relatively short
amount of time.  However, as anyone who has ever worn the DBA hat knows,
running queries very frequently on large amounts of data is not a good thing
to do.  Not only does it put the database server under heavy load, but you
can also run into situations where the dataset gets very large and one query
will start running before the previous query has stopped.  This is a bad,
bad thing.
	Even with a tuned ruleset, and a properly placed IDS, it is still
possible to generate a large number of false positives using a tool like
snot or stick.  What harm would it do to log this information and give Snort
engineers the tool (the preprocessor) to identify snot and stick attacks
without the use of data mining tools?  Saying that IDS engineers should be
doing this, and should be doing that, is great.  But, some engineers don't
have access to these tools, don't have knowledge to use them, or don't have
the money to buy them, and this would be a simple way to give them the same
kind of basic functionality.

	Besides, then the programmers could boast that Snort can detect snot
and stick attacks. <laugh>


Abe L. Getchell - Security Engineer
Division of System Support Services
Kentucky Department of Education
Voice   502-564-2020x225
E-mail  agetchel at ...358...
Web     http://www.kde.state.ky.us/

> -----Original Message-----
> From: Matt W. [mailto:kmx at ...309...]
> Sent: Sunday, April 01, 2001 11:00 PM
> To: agetchel at ...358...
> Cc: ktimm at ...364...; snort-devel at lists.sourceforge.net
> Subject: Re: [Snort-devel] Defeating the anti-IDS tools...
> Personally I think a preprocessor is going in the wrong 
> direction.  This is not
> something that should be handled by snort.  This should be 
> handled by outside
> processing.  If you tune your IDS correctly and place it in 
> your network
> correctly these attacks will never happen.
> In my opinion the real problem is snort doesn't have a way to 
> know what traffic
> is valid for your network.  So administrators have to tune 
> the device and many
> people are too lazy or not experienced enough to do this.  So 
> they use the
> default vision.conf rules and call it a day.  They then 
> wonder why they are
> getting an arse load of false positives.  This is because 90% 
> of the rules in
> vision.conf probably don't apply to their network.
> So here is a quick suggestion. Along with the scoring system 
> people are
> developing we can create a flag that says "This rule applies 
> to my network
> YES/NO"  Then it's really easy to filter all the traffic if 
> you are logging to a
> database.  This will detect things like snot and other 
> traffic generation
> attacks and it will filter out lots of the crap.
> Data mining is the key to detecting these things easily, not 
> preprocessors.
> -matt
> agetchel at ...358... wrote:
> > Hi Kevin,
> >         Personally, I don't think that using a diversion 
> alerting system
> > such as this will cause engineers to brush off alerts 
> created by this
> > preprocessor, but rather get them to look deeper into the 
> alerts which were
> > logged during this time period.  If the reason they aren't 
> looking at these
> > is an under-staffing issue, or similar, than that's a whole 
> separate problem
> > and obviously can't be handled programmatically.  Let's 
> design the software
> > for the perfect world, so if the organization using the 
> product has the
> > capability to take advantage of it, they can do so.  
> There's no reason to
> > not include a feature because _some_ shops don't have the 
> capacity to use
> > it.  I think everyone who uses Snort would agree with you 
> (as do I) that
> > this is not the perfect solution to this problem, and 
> realizes that there
> > may be network and IDS design issues, but at least it would 
> give us a
> > _basic_ tool to effectively detect these _types_ of attacks.
> >         Stateful inspection is something that has to come 
> to Snort, as well
> > as other IDS's, if they want to remain legitimate players 
> in the IDS market.
> > Especially in the face of an ever increasing level of 
> advanced intrusion
> > techniques.  This, however, from my limited familiarity of the Snort
> > code-base, would entail an almost complete rewrite of the 
> source.  Not
> > something I think the coders are willing to jump on so quickly. =)
> >         This would be an interesting subject to discuss in 
> further in depth
> > face-to-face.  Is anyone here going to be at the SANS conference in
> > Baltimore during the middle of May?  Maybe we could do a 
> BOF session?
> >
> > Thanks,
> > Abe
> >
> > Abe L. Getchell - Security Engineer
> > Division of System Support Services
> > Kentucky Department of Education
> > Voice   502-564-2020x225
> > E-mail  agetchel at ...358...
> > Web     http://www.kde.state.ky.us/
> >
> > > -----Original Message-----
> > > From: Kevin Timm [mailto:ktimm at ...364...]
> > > Sent: Sunday, April 01, 2001 6:46 PM
> > > To: agetchel at ...358...
> > > Cc: snort-devel at lists.sourceforge.net
> > > Subject: RE: [Snort-devel] Defeating the anti-IDS tools...
> > >
> > >
> > > If used in that manner I think it is a good idea, however 
> I think just
> > > tagging the diversionary tag doesn't do anything to really
> > > deal with the
> > > human issues. The human issues are that it is going to
> > > overload the analyst
> > > center. Will they be able to sift thru the information in a
> > > timely manner to
> > > mitigate the risk of the attack. Will they start to ignore
> > > diverssonary
> > > attacks because of the great amount of effort involved in
> > > analyzing the
> > > data. For these reasons it is better to fix the real problem.
> > > In a perfect
> > > world an IDS could detect attacks and then take response
> > > through resetting
> > > connections, changing access policies, routing offenders to
> > > black holes and
> > > what not. IDS is not approached a perfect world though so
> > > most automated
> > > response techniques are not used unless the chance of flase
> > > positives is
> > > extremly low. These diversionary attacks defeat any chance of
> > > effective
> > > automated response. To fix this some options are
> > > 1., Correct use of filtering on routers (the chance of this
> > > happening is
> > > small unless you have an initiative similiar to spam in that some
> > > organization contantly checks routers for improper 
> filtering and then
> > > creates a sort of real time black list.)
> > > 2., Statefull inspection on an IDS.
> > > I think the best way would be for a bunch of really smart IDS
> > > people to get
> > > together and make a list of every possible option, then
> > > decide which are the
> > > most effective to implement.
> >
> > _______________________________________________
> > 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