The detection_filter Keyword
You can use the
detection_filter
keyword to prevent a rule from
generating events unless a specified number of packets trigger the rule within
a specified time. This can stop the rule from prematurely generating events.
For example, two or three failed login attempts within a few seconds could be
expected behavior, but a large number of attempts within the same time could
indicate a brute force attack.
The
detection_filter
keyword requires arguments that define
whether the system tracks the source or destination IP address, the number of
times the detection criteria must be met before triggering an event, and how
long to continue the count.
Use the following syntax to delay the triggering of events:
track by_src/by_dst, count count, seconds number_of_seconds
The
track
argument specifies whether to use the packet’s
source or destination IP address when counting the number of packets that meet
the rule’s detection criteria. Select from the argument values described in the
following table to specify how the system tracks event instances.
Argument |
Description |
---|---|
by_src |
Detection criteria count by source IP address. |
by_dst |
Detection criteria count by destination IP address. |
The
count
argument specifies the number of packets that
must trigger the rule for the specified IP address within the specified time
before the rule generates an event.
The
seconds
argument specifies the number of seconds within
which the specified number of packets must trigger the rule before the rule
generates an event.
Consider the case of a rule that searches packets for the
content
foo
and uses the
detection_filter
keyword with the following arguments:
track by_src, count 10, seconds 20
In the example, the rule will not generate an event until it has
detected
foo
in 10 packets within 20 seconds from a given source
IP address. If the system detects only 7 packets containing
foo
within the first 20 seconds, no event is generated.
However, if
foo
occurs 40 times in the first 20 seconds, the rule
generates 30 events and the count begins again when 20 seconds have elapsed.
Comparing the threshold and detection_filter Keywords
The
detection_filter
keyword replaces the deprecated
threshold
keyword. The
threshold
keyword is still supported for backward
compatibility and operates the same as thresholds that you set within an
intrusion policy.
The
detection_filter
keyword is a detection feature that is
applied before a packet triggers a rule. The rule does not generate an event
for triggering packets detected before the specified packet count and, in an
inline deployment, does not drop those packets if the rule is set to drop
packets. Conversely, the rule does generate events for packets that trigger the
rule and occur after the specified packet count and, in an inline deployment,
drops those packets if the rule is set to drop packets.
Thresholding is an event notification feature that does not result in a detection action. It is applied after a packet triggers an event. In an inline deployment, a rule that is set to drop packets drops all packets that trigger the rule, independent of the rule threshold.
Note that you can use the
detection_filter
keyword in any combination with the
intrusion event thresholding, intrusion event suppression, and rate-based
attack prevention features in an intrusion policy. Note also that policy
validation fails if you enable an imported local rule that uses the deprecated
threshold
keyword in combination with the intrusion
event thresholding feature in an intrusion policy.