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

Matt W. kmx at ...309...
Mon Apr 2 02:58:56 EDT 2001


Comments inline

agetchel at ...358... wrote:

> 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.

Another quick thing this would not be a preprocessor it would be a postprocessor
since it's decisions would be based on matched rules.

>  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.

<Marketing Foo>
might want to check out www.farm9.com and our harvester application before your
build your own.  We support Snort, Realsecure, syslog, snmptraps, fw1, etc..
Display it in a web console and have a rule / sorting system so only valid
things are brought to your attention.
<End Marketing Foo>

> 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.

Good database design can mitigate this. But i get your point.

> 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.

Only if the attacker was able to find valid attacks against your network.  With
the data mining method these invalid attacks would just show up as "Invalid
Attacks, naughty boy detected" This would be one alert and not 100's.

>  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?

I would rather see a lot of work done on a back end analysis engine instead of
piece meal postprocessors that only handle one type of attack.  SPADE is a step
in the general direction of a data mining postprocessor or outside analysis
engine.

> 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.
>

Sounds like a good reason to create the backend system for snort that uses free
products.

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

:)

-matt
www.farm9.com

>
> 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: 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