Snort mailing list archives
RE: Filtering alerts
From: "Richard Brackett" <rbrackett () securityvolition com>
Date: Mon, 22 Sep 2003 21:14:47 -0400
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 () arizona edu] Sent: Monday, September 22, 2003 9:07 PM To: Richard Brackett; snort-users () 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 () 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
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ 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
Current thread:
- Filtering alerts Richard Brackett (Sep 22)
- Re: Filtering alerts Geoff (Sep 22)
- <Possible follow-ups>
- RE: Filtering alerts Richard Brackett (Sep 22)
- RE: Filtering alerts Erek Adams (Sep 23)
- RE: Filtering alerts Richard Brackett (Sep 23)
- RE: Filtering alerts Erek Adams (Sep 23)
- RE: Filtering alerts Richard Brackett (Sep 23)
- RE: Filtering alerts Marc Quibell (Sep 23)