9.5 Thresholding and Suppression

Threshold and suppression rules were first introduced in Snort Version 2.0.0. They allow an administrator to control how many alerts are generated from (or to) a given host or for a particular signature. Unfortunately, they were very thinly documented and (while it might get me in a bit of trouble with the folks at Sourcefire) were a little buggy. Snort 2.1.x not only fixes the problems, it also introduces global thresholds. Global thresholds let you control alert volume for all rules. Threshold and suppression commands are, by convention, placed in the threshold.conf file in the same directory as the rule sets. While this is not required, it is a good idea to keep them in one place. Threshold and suppression rules can track by source or destination IP address. Sometimes a signature alerts on an inbound attack packet or an outbound response to an attack. It should be noted that suppression rules are applied before thresholding rules.

9.5.1 Simple Thresholds

Threshold rules come in three flavors (excerpt from the README.thresholding file):

Limit

Alert on the first M events during the time interval, then ignore events for the rest of the time interval.

Threshold

Alert every M times this event is seen during the time interval.

Both

Alert once per time interval after seeing M occurrences of the event, then ignore any additional events during the time interval.

Threshold rules can be incorporated into the rule definitions themselves or built as standalone rules. The administrative ease of keeping the threshold rules in one place argues against incorporating them into the rules directly. When scattered among the rule sets, threshold rules can be hard to find. There are, however, some instances when it makes sense to incorporate the threshold components to a rule.

Here's an excerpt from the README.thresholding file:

There is no functional difference between adding a threshold to a rule, or using a separate threshold command applied to the same rule. There is a logical difference. Some rules may only make sense with a threshold. These should incorporate the threshold command into the rule.

For instance, when security policies are set to lock out an account after four bad password guesses, alerting on the fifth bad guess is appropriate. Such a threshold can be incorporated into the rule itself.

When incorporating thresholds into rules, the following format is used:

threshold: type [limit|threshold|both], track [by_src|by_dst], count n , seconds m ;

Here are some thresholding examples:

Limit type

Logs the first event to a particular destination IP address of this signature every 60 seconds:

    alert tcp $LOCAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-IIS unicode 

directory traversal attempt"; flow:to_server,established; content:"/..%c0%af../"; 

nocase; classtype:web-application-attack; reference:cve,CVE-2000-0884; threshold: 

type limit, track_by_dst, count 1, seconds 60; sid:981; rev:6;)

Threshold type

Logs every twentieth event on this signature during a 60-second interval—so if less than 20 occur in 60 seconds, nothing gets logged. Once an event is logged, a new time period starts for type=threshold. This might be used to watch for the 403: Forbidden web responses where the administrator is concerned when the incidence of this event becomes too high:

    alert tcp $HTTP_SERVERS $HTTP_PORTS -> $EXTERNAL_NET any (msg:"ATTACK-

RESPONSES 403 Forbidden"; flow:from_server,established; content:"HTTP/1.1 403";

depth:12; classtype:attempted-recon; threshold: type threshold, track by_dst, 

count 20, seconds 60; sid:1201; rev:7;)

Both type

Logs at most one event every 120 seconds if at least 4 events on this sid are fired. This is the example given previously, in which an account locks after four bad guesses. Only one alert would be generated for a locked account every two minutes:

    alert tcp $SQL_SERVERS 1433 -> $EXTERNAL_NET any (msg:"MS-SQL sa login 

failed"; content: "Login failed for user |27|sa|27|"; flow:from_

server,established; classtype:unsuccessful-user; threshold: type both, track by_

dst, count 5, seconds 60; sid:688; rev:4;)

Standalone thresholds are written with the following syntax:

threshold gen_id gen-id, sig_id sig-id, type [limit|threshold|both], track [by_

src|by_dst], count n , seconds m

The main difference between standalone thresholds and those incorporated into rules is the inclusion of the gen_id and the sig_id parameters. These are needed in the standalone threshold rules to specify the rule and generators to which the threshold applies. As discussed in Chapter 7, gen_id refers to the Snort generator involved and sig_id is the unique identifier for the rule the threshold is being applied to. Only one threshold can be applied per unique sig_id. Most often, the gen_id is set to 1 (the Snort Rules Engine).

Here's how you would limit to logging 1 event per 120 seconds for the signature with the sig_id of 1,759 (MS-SQL xp_cmdshell program execution):

threshold gen_id 1, sig_id 1759, type limit, track by_src, count 1, seconds 120

And limit to logging every fifth event in 120 seconds for the same signature:

threshold gen_id 1, sig_id 1759, type threshold, track by_src, count 5, seconds 120

And limit to logging just 1 event per 60 seconds, but only if we exceed 50 events in 60 seconds:

threshold gen_id 1, sig_id 1759, type both, track by_src,  count 50, seconds 60

9.5.2 Global Thresholds

Global threshold commands are the same as standalone thresholds, except the sig_id is parameter is set to 0 to indicate "all rules."

Here's how you would limit to logging 1 event per 120 seconds per IP triggering any rule generated by the Snort rules engine tracking by source address:

threshold gen_id 1, sig_id 0, type limit, track by_src, count 1, seconds 120

And here's how you'd limit to logging 1 event per 120 seconds per IP triggering any rule for any Snort event generator component tracking by destination address:

threshold gen_id 0, sig_id 0, type limit, track by_dst, count 1, seconds 120

..."

9.5.3 Suppression Rules

Suppression rules are similar in syntax to standalone threshold rules. Suppression rules can suppress alerts by signature, by source or destination address, or by an entire CIDR network block. This flexibility has considerable power. Care must be taken to only suppress the correct alerts or addresses. An administrator could inadvertently suppress legitimate alerts.

Suppression rules are written with the following syntax:

suppress gen_id gen-id, sid_id sid-id, track [by_src|by_dst], ip IP/MASK-BITS

Suppress this event completely:

suppress gen_id 1, sig_id 114

Suppress this event from this source IP address:

suppress gen_id 1, sig_id 114, track by_src, ip 10.2.1.154

Suppress this event to this destination CIDR block:

suppress gen_id 1, sig_id 114, track by_dst, ip 10.2.1.0/24