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.

detection_filter Track Arguments

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.