Configuring Rate-Based Attack Prevention

Note

This section applies to Snort 2 preprocessors. For information on Snort 3 inspectors, see https://www.cisco.com/go/snort3-inspectors.

You can configure rate-based attack prevention at the policy level to stop SYN flood attacks. You can also stop excessive connections from a specific source or to a specific destination.

Procedure


Step 1

Choose Policies > Access Control, then click Network Analysis Policy or Policies > Access Control > Intrusion, then click Network Analysis Policies.

Note

If your custom user role limits access to the first path listed here, use the second path to access the policy.

Step 2

Click Snort 2 Version next to the policy you want to edit.

Step 3

Click Edit (edit icon) next to the policy you want to edit.

If View (View button) appears instead, the configuration belongs to an ancestor domain, or you do not have permission to modify the configuration.

Step 4

Click Settings.

Step 5

If Rate-Based Attack Prevention under Specific Threat Detection is disabled, click Enabled.

Step 6

Click Edit (edit icon) next to Rate-Based Attack Prevention.

Step 7

You have two choices:

  • To prevent incomplete connections intended to flood a host, click Add under SYN Attack Prevention.
  • To prevent excessive numbers of connections, click Add under Control Simultaneous Connections.

Step 8

Specify how you want to track traffic:

  • To track all traffic from a specific source or range of sources, choose Source from the Track By drop-down list, and enter a single IP address or address block in the Network field.
  • To track all traffic to a specific destination or range of destinations, choose Destination from the Track By drop-down list, and enter an IP address or address block in the Network field.
    Note
    • Do not enter the IP address 0.0.0.0/0 in the Network field to monitor all subnets or IPs. The system does not support this IP address (which is usually used to identify all subnets or IPs) for Rate Based Attack Prevention.

    • The system tracks traffic separately for each IP address included in the Network field. Traffic from an IP address that exceeds the configured rate results in generated events only for that IP address. As an example, you might set a source CIDR block of 10.1.0.0/16 for the network setting and configure the system to generate events when there are ten simultaneous connections open. If eight connections are open from 10.1.4.21 and six from 10.1.5.10, the system does not generate events, because neither source has the triggering number of connections open. However, if eleven simultaneous connections are open from 10.1.4.21, the system generates events only for the connections from 10.1.4.21.

Step 9

Specify the triggering rate for the rate tracking setting:

  • For SYN attack configuration, enter the number of SYN packets per number of seconds in the Rate fields.

  • For simultaneous connection configuration, enter the number of connections in the Count field.

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. It triggers alert, if users send too many connection attempts within prescribed time intervals. Hence it is recommended to rate limit the rule. For help determining the correct rate, contact Support.

Step 10

To drop packets matching the rate-based attack prevention settings, check the Drop check box.

Step 11

In the Timeout field, enter the time period after which to stop generating events (and if applicable, dropping) for traffic with the matching pattern of SYNs or simultaneous connections.

Caution
Setting a high timeout value may entirely block connection to a host in an inline deployment.

Step 12

Click OK.

Step 13

To save changes you made in this policy since the last policy commit, click Policy Information, then click Commit Changes.

If you leave the policy without committing changes, changes since the last commit are discarded if you edit a different policy.


What to do next

  • Deploy configuration changes.