Re: Feature request: thresholds need another counter?

[Paul Schmehl <pauls () utdallas edu>]

--On Thursday, March 18, 2004 10:59:19 AM -0600 Frank Knobbe 
<frank () knobbe us> wrote:
> Also, if you use thresholding to squelch out noisy signatures, you
> (obviously) won't detect the careful and less noisy attack that might
> trigger the same signature. If you squelch an alert, a single, slightly
> different crafted packet, could compromise the system and you wouldn't
> even know about it.
Thresholding has more than one purpose.  One is to squelch noisy alerts, of 
course, but another is to prevent you from being overwhelmed by alerts.

For example, it's entire possible to set a threshold rules that says, if 
you get one alert in 60 seconds, send the alert, but don't send a second 
one.

This would detect *all* traffic, but still not overwhelm you.

E.g. threshold: type both, track by_src, count 1, seconds 60;

This would send you one alert each minute no matter how many packets the 
host was sending.

While I agree with what you're saying about missing alerts, in the 
practical application of the theory, the noise will overwhelm the stealthy 
alerts anyway.  For stealthy stuff, you have to find something unique to 
trigger on.  The example I gave was detecting Nachi.  If an attacker wanted 
to use Windows pings to do slow scanning of the network, all it would take 
is one Nachi infection to completely mask that stealthy scan.
> Something I thought of was to create a module that takes a certain
> number of alerts and tries to identify a group as belonging to one
> cause. The best example is Nimda which triggers a series of signatures.
> The module could identify those alerts are a Nimda attack and instead of
> showing 10 IIS related alerts just show one Nimda attack alert.
>
> I'm trying to solve this on our custom backend by combing the database
> and rewriting entries there. I'm not sure if this could be solved as a
> preprocessor. I think the caching requirements to cache a large enough
> number of alerts are probably too high to do that in within Snort
> itself.
I definitely agree with you here.  This is a job best done by a backend 
processor culling from a database.

> Would be nice though, having a spp_attack or so that reduces the amount
> of alerts by identifying the program/virus/attack behind a series of
> sigs.
Perhaps the ideal solution is to allow thresholding for *reporting* 
purposes, but log everything to the db?  But again, that should be backend 
stuff, not something that requires snort to cache more and more 
information.  Snort should be able to just shove raw data down the db's 
throat, and something on the backend should be making sense of it all.

Paul Schmehl (pauls () utdallas edu)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users