threshold can be included as part of a rule, or you can use standalone
thresholds that reference the generator and SID they are applied to. There is
no functional difference between adding a threshold to a rule, or using a
standalone threshold applied to the same rule. There is a logical difference.
Some rules may only make sense with a threshold. These should incorporate the
threshold into the rule. For instance, a rule for detecting a too many login
password attempts may require more than 5 attempts. This can be done using the
`limit' type of threshold. It makes sense that the threshold feature is an
integral part of this rule.
type limit alerts on the 1st m events during the time interval, then
ignores events for the rest of the time interval. Type threshold
alerts every m times we see this event during the time interval. Type
both alerts once per time interval after seeing m occurrences of the
event, then ignores any additional events during the time interval.
rate is tracked either by source IP address, or destination IP address. This
means count is maintained for each unique source IP addresses, or for each
unique destination IP addresses. Ports or anything else are not tracked.
number of rule matching in s seconds that will cause event_filter
limit to be exceeded. c must be nonzero value.
time period over which count is accrued. s must be nonzero
value.
This rule logs the first event of this SID every 60 seconds.
This rule logs every 10th event on this SID during a 60 second interval. So if
less than 10 events occur in 60 seconds, nothing gets logged. Once an event is
logged, a new time period starts for type=threshold.
This rule logs at most one event every 60 seconds if at least 10 events on this
SID are fired.
3.8.0.0.1 Format
Option
Description
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
type limit|threshold|both
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
track by_src|by_dst
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
count c
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
seconds s
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
3.8.0.1 Examples