Rate-based attack prevention identifies abnormal traffic
patterns and attempts to minimize the impact of that traffic on legitimate
requests. Rate-based attacks usually have one of the following characteristics:
Any traffic containing excessive incomplete connections to hosts on the network, indicating a SYN flood attack
Any traffic containing excessive complete connections to hosts on the network, indicating a TCP/IP connection flood attack
Excessive rule matches in traffic going to a particular destination IP address or addresses or coming from a particular source IP address or addresses
Excessive matches for a particular rule across all traffic
In a network analysis policy, you can either configure SYN flood
or TCP/IP connection flood detection for the entire policy; in an intrusion
policy, you can set rate-based filters for individual intrusion or preprocessor
rules. Note that you cannot manually add a rate-based filter to GID 135 rules
or modify their rule state. Rules with GID 135 use the client as the source
value and the server as the destination value.
Devices load-balance inspection across internal resources. When you configure rate-based attack prevention, you configure the triggering rate per resource, not per device. If rate-based attack prevention is not working as expected, you may need to lower the triggering rate. For help determining the correct rate, contact Support.
SYN Attack Prevention option also activates rule
135:1. Manually activating this rule has no effect. The rule state is always
displayed as Disabled, and never changes. The rule generates events when this
option is enabled and a defined rate condition is exceeded.
Enabling the Control Simultaneous Connections option also activates rules 135:2 and 135:3. Manually activating these rule has no effect. The rule state is always displayed as Disabled, and never changes. Rule 135:2 rule generates events when a defined rate condition is exceeded. Rule 135:3 generates events when a session closes or times out.
Each rate-based filter contains several components:
For policy-wide or rule-based source or destination settings, the network address designation
The rule matching rate, which you configure as a count of rule matches within a specific number of seconds
A new action to be taken when the rate is exceeded
When you set a rate-based setting for the entire policy, the
system generates events when it detects a rate-based attack, and can drop the
traffic in an inline deployment. When setting rate-based actions for individual
rules, you have three available actions: Generate Events, Drop and Generate
Events, and Disable.
The duration of the action, which you configure as a timeout value
Note that when started, the new action occurs until the timeout
is reached, even if the rate falls below the configured rate during that time
period. When the timeout period expires, if the rate has fallen below the
threshold, the action for the rule reverts to the action initially configured
for the rule. For policy-wide settings, the action reverts to the action of
each rule the traffic matches or stops if it does not match any rules.
You can configure rate-based attack prevention in an inline
deployment to block attacks, either temporarily or permanently. Without
rate-based configuration, rules set to Generate Events create events, but the
system does not drop packets for those rules. However, if the attack traffic
matches rules that have rate-based criteria configured, the rate action may
cause packet dropping to occur for the period of time that the rate action is
active, even if those rules are not initially set to Drop and Generate Events.
Rate-based actions cannot enable disabled rules or drop traffic that matches disabled rules. However, if you set a rate-based filter at the policy level, you can generate events on or generate events on and drop traffic that contains an excessive number of SYN packets or SYN/ACK interactions within a designated time period.
You can define multiple rate-based filters on the same rule. The
first filter listed in the intrusion policy has the highest priority. Note that
when two rate-based filter actions conflict, the system implements the action
of the first rate-based filter. Similarly, policy-wide rate-based filters
override rate-based filters set on individual rules if the filters conflict.