[Snort-users] Filtering alerts

Richard Brackett rbrackett at ...10146...
Mon Sep 22 18:15:10 EDT 2003


Yes, I saw that. That's why I upgraded to 2.0.2. :-) 


It doesn't help me with "noise" though. For example, I don't care about
the various IIS related signatures that fire against my Citrix servers.
They aren't vulnerable to those attacks. I don't want to turn the rule
off though, because I have IIS servers and I never know when some yutz
is going to put a new one up without patches.

-----Original Message-----
From: Geoff [mailto:gpoer at ...10148...] 
Sent: Monday, September 22, 2003 9:07 PM
To: Richard Brackett; snort-users at lists.sourceforge.net
Subject: Re: [Snort-users] Filtering alerts

The new feature in 2.0.2 to threshold and supress should help you.
Sourcefire pointed me at the documentation in the sourcecode. Below is
what they 
gave me. I think it will help you.

Geoff

THRESHOLDING AND EVENT SUPPRESSION IN SNORT

A rule thresholding feature has been added to SNORT.  This feature is
used to
reduce the number of logged alerts for noisy rules.  This can be tuned
to
significantly reduce false alarms, and it can also be used to write a
newer breed
of rules. Thresholding commands limit the number of times a particular
event is
logged during a specified time interval. Event suppression stops
specified
events from firing without removing the rule from the rule base.

There are 3 types of thresholding:

	1) Limit
            Alert on the 1st M events during the time interval, than
ignore events.
	2) Threshold
	   Alert every M times we see this event during the time
interval.
	3) Both
	   Alert once per time interval after seeing M occurrences of
the event,
	   than ignore any additional events during the time interval.

	All tracking is by Src or by Dst IP, we do not track ports or
anything else.


Thresholding commands can be included as part of a rule, or you can use
standalone threshold commands
that reference the generator and sid they are applied to.

Suppression commands are standalone commands that reference generator
id's and sid's and an IP address
via a  CIDR block. This allows a rule to be completely supressed, or
suppressed when the causitive
traffic is going to or comming from a specific IP or group of IP
addresses.

Events in SNORT are generated in the ususal way, thresholding and event
suppresion are handled as
part of the output system.

You may apply only one threshold to any given sid, but you may apply
multiple suppresion commands to
a sid.  You may also combine one threshold command and several
suppression commands to the same sid.
If you try to apply more than one threshold command to a sid, SNORT will
terminate while reading the
configuration information.


THRESHOLDING CONFIGURATION COMMAND:
-----------------------------------

config threshold: memcap 3000000
	
The memcap paramter is specified in bytes.
	

THRESHOLD RULE OPTION:
----------------------

This format supports 4 threshold options - all are required.

type		limit, threshold, both
track		by_src , by_dst
count		n : number events used by the thresholding
seconds		m : time period over which count is accrued.

THRESHOLD RULE OPTION PARAMETERS:
---------------------------------
threshold: type limit|threshold|both, track by_src|by_dst, count n ,
seconds m ; sid: sid-id;

EXAMPLE RULES:
--------------

#
#  This rule logs the 1st event of this sid every 60 seconds
#
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
(msg:"WEB-MISC robots.txt access"; flow:to_server, established;
uricontent:"/robots.txt"; nocase; reference:nessus,10302;
classtype:web-application-activity;
threshold: type limit, track by_src, count 1 , seconds 60 ; sid:1852;
rev:1;)

#
#  This rule logs every 10th event on this sid during a 60 second
interval
#  so, if less than 10 occur in 60 seconds, nothing gets logged.
#  once an event is logged a new time period starts for type=threshold.
#
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
(msg:"WEB-MISC robots.txt access"; flow:to_server, established;
uricontent:"/robots.txt"; nocase; reference:nessus,10302;
classtype:web-application-activity;

threshold: type threshold, track by_dst, count 10 , seconds 60 ;
sid:1852;
rev:1;)

#
# This rule logs at most one event every 60 seconds if at least
# 10 events on this sid are fired.
#
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
(msg:"WEB-MISC robots.txt access"; flow:to_server, established;
uricontent:"/robots.txt"; nocase; reference:nessus,10302;
classtype:web-application-activity;
threshold: type both , track by_dst, count 10 , seconds 60 ; sid:1852;
rev:1;)


STANDALONE THRESHOLD COMMAND:
-----------------------------

This format supports 6 threshold options - all are required.

gen_id  gen-id
sig_id  sig-id
type    limit, threshold, both
track   by_src, by_dst
count   n
seconds m

THRESHOLD COMMAND FORMAT:
-------------------------

threshold gen_id gen-id, sig_id sig-id, type limit|threshold|both, track
by_src|by_dst, count n , seconds m


THRESHOLD EXAMPLES:
------------------
#
# Limit to logging 1 event per 60 seconds
#
threshold gen_id 1, sig_id 1851, type limit, track by_src, count 1,
seconds 60
#
# Limit to logging every 3rd event
#
threshold gen_id 1, sig_id 1852, type threshold, track by_src, count 3,
seconds 60
#

# Limit to logging just 1 event per 60 seconds, but only if we exceed 30
events in 60 seconds
#
threshold gen_id 1, sig_id 1853, type both, track by_src,  count 30,
seconds 60

SUPPRESS COMMAND:
-----------------

The suppress command supports either 2 or 4 options

gen_id     gen-id            # always required
sig_id     sig-id            # always required
track      by_src | by_dst   # optional - 4 option version
ip         IP[/MASK-BITS]    # optional - 4 option version

suppress gen_id gen-id, sid_id sid-id, track by_src|by_dst, ip
IP/MASK-BITS
SUPPRESS EAMPLES:
-----------------
#
#  Suppress this event completely
#
suppress gen_id 1, sig_id 1852
#
#  Suppress this event from this IP
#
suppress gen_id 1, sig_id 1852, track by_src, ip 10.1.1.54
#
#  Suppress this event to this CIDR block
#
suppress gen_id 1, sig_id 1852, track by_dst, ip 10.1.1.0/24


Richard Brackett wrote:
> Rather than disabling noisy rules (false positives) I've been using
pass
> rules to stop alerts to hosts that either aren't vulnerable to the
> attack or the data is a false positive (I get a lot of those with the
> Gnutella rule and HTTP/SMTP sessions). Is there another, better
> methodology to use rather than pass? My Syngress Snort 2.0 book says
you
> shouldn't need to write many pass rules, but how the heck do you keep
> the false positives and noise to an acceptable level? Do I have to go
> buy a management system?
> 
> I'm using Snort 2.0.2 ACID and mysql on a SuSE 8.2 box.
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Snort-users mailing list
> Snort-users at 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





More information about the Snort-users mailing list