Attack Filtering and Attack Detection

Attack Filtering

The Cisco SCE platform includes extensive capabilities for identifying DDoS attacks, and protecting against them.

Attack filtering is performed using specific-IP attack detectors. A specific-IP attack detector tracks the rate of flows (total open and total suspected) in the Cisco SCE platform for each combination of IP address (or pair of IP addresses), protocol (TCP/UDP/ICMP/Other), destination port (for TCP/UDP), interface and direction. When the rates satisfy user-configured criteria, it is considered an attack, and a configured action can take place (report/block, notify subscriber, send SNMP trap).

This mechanism is enabled by default, and can be disabled and enabled for each attack type independently.

There are 32 different attack types:

1—
TCP flows from a specific IP address on the subscriber side, regardless of destination port

2—
TCP flows to a specific IP address on the subscriber side, regardless of destination port

3-4—
Same as 1 and 2, but for the opposite direction (subscriber network)

5—
TCP flows from a specific IP address on the subscriber side to a specific IP address on the network side

6—
Same as 5, but for the opposite direction (from the network side to the subscriber side)

7-12—
Same as 1-6 but with a specific destination port common to all flows of the attack (1-6 are port-less attack types, 7-12 are port-based attack types)

13-24—
Same as 1-12 but for UDP instead of TCP

25-28—
Same as 1-4 but for ICMP instead of TCP

29-32—
Same as 1-4 but for Other protocols instead of TCP

Specific Attack Filtering

When the specific IP attack filter is enabled for a certain attack type, two rates are measured per defined entity:

Rate of new flows

Rate of suspected flows (In general, suspected flows are flows for which the SCOS did not see proper establishment (TCP) or saw only a single packet (all other protocols)).

Separate rate meters are maintained both for each IP address separately (single side) and for IP address pairs (the source and destination of a given flow), so when a specific IP is attacking a specific IP, this pair of IP addresses defines a single incident (dual-sided).

Based on these two metrics, a specific-IP attack is declared if either of the following conditions is present:

The new flows rate exceeds a certain threshold

The suspected flows rate exceeds a configured threshold and the ratio of suspected flows rate to total new flow rate exceeds a configured threshold.

When the rates stop satisfying this criterion, the end of that attack is declared.

Note that specific attack filtering is configured in two steps:

Enabling specific IP filtering for the particular attack type.

Configuring an attack detector for the relevant attack type. Each attack detector specifies the thresholds that define an attack and the action to be taken when an attack is detected.

In addition to specific attack detectors, a default detector exists that can be configured with user-defined thresholds and action, or system defaults may be retained.

In addition, the user can manually override the configured attack detectors to either force or prevent attack filtering in a particular situation.

Specific IP filtering for selected attack types is enabled with the following parameters. These parameters control which of the 32 attack types are being filtered for:

Protocol—
TCP, UDP, ICMP, or Other

Attack direction—
The direction of the attack may be identified by only one IP address or by two IP addresses:

–
single side—
The attack is identified by either the source IP address or the destination address only.

The filter definition may specify the specific side, or may include any single side attack, regardless of side (both).

–
dual side
(TCP and UDP protocols only)—The attack is identified by both the source and destination IP addresses. In other words, when a specific IP attacks a specific IP, this is detected as one incident rather than as two separate incidents.

Side—Interface (Subscriber/Network) from which attack packets are sent

Attack-direction—If a single IP address is specified, the IP address is an attack-source or an attack-destination address.

The system can identify a maximum of 1000 independent, simultaneous attacks.

Once an attack is identified, the system can be instructed to perform any of the following actions:

Report—
By default, the attack beginning and end are always reported.

Block—
The system will block all attack traffic for the duration of the attack. (The traffic is from or to the attack IP address, depending on whether the IP address is an attack-source or attack-destination)

Notify—
Subscriber notification. When the IP address identified is mapped to a particular subscriber context, the system can be configured to notify the subscriber of the fact that he is under an attack (or a machine in his network is generating such an attack), using HTTP Redirect.

Alarm—
The system will generate an SNMP trap each time an attack starts and stops.

Attack detection and handling are user-configurable. The remainder of this chapter explains how to configure and monitor attack detection.

Attack Detection Thresholds

There are three thresholds that are used to define an attack. These thresholds are based on meters that are maintained by the Cisco SCE platform for each IP address or pair of addresses, protocol, interface and attack-direction.

open flow rate—
A flow for which some traffic was seen. Any packet seen for a new flow is enough to declare this flow an open flow.

The rate is measured in new flows per second.

suspected flow rate—
A suspected flow is one that was opened, but did not become an established flow.

The rate is measured in new flows per second.

suspected flow ratio—
The ratio of the suspected flow rate to the open flow rate.

As explained above, a specific-IP attack is declared if either of the following conditions is present:

The open flows rate exceeds the threshold

The suspected flows rate exceeds the threshold and the suspected flows ratio exceeds the threshold.

The values for each attack type will have a separate configured default value.

In general, for a given protocol, the suspected flows rate threshold should be lower for a port-based detection than for a port-less detection. This is because flows with a given IP address and a common destination port are metered twice:

By themselves—To detect a port-based attack

Together with flows with the same IP address and different destination ports—to detect a port-less attack

If a port-based attack occurs, and the rate of flows is above both thresholds (port-based thresholds and the port-less thresholds), it is desirable for the port-based attack to be detected before the port-less attack. Similarly, this threshold should be lower for dual-IP detections then for single-IP detections.

The user may define values for these thresholds that override the preset defaults. It is also possible to configure specific thresholds for certain IP addresses and ports (using access lists and port lists). This enables the user to set different detection criteria for different types of network entities, such as a server farm, DNS server, or large enterprise customer.

Attack Handling

Attack handling can be configured as follows

Configuring the action:

– Report—Attack packets are processed as usual, and the occurrence of the attack is reported.

– Block—Attack packets are dropped by the Cisco SCE platform, and therefore do not reach their destination.

Regardless of which action is configured, two reports are generated for every attack: one when the start of an attack is detected, and one when the end of an attack is detected.

Configuring subscriber-notification (notify):

– Enabled—If the subscriber IP address is detected to be attacked or attacking, the subscriber is notified about the attack.

– Disabled—The subscriber is not notified about the attack.

Configuring sending an SNMP trap (alarm):

Enabled—An SNMP trap is sent when attack begins and ends.

The SNMP trap contains the following information fields:

– A specific IP address or

–
Protocol
(TCP, UDP, ICMP or Other)

–
Interface
(User/Network) behind which the detected IP address is found. This is referred to below as the attack ‘side’

–
Attack direction
(whether the IP address is the attack source or the attack destination).

–
Action taken
(report, block) indicating what was the action taken by the Cisco SCE platform in response to the detection

–
Amount of attack flows blocked/ reported
providing the total number of flows detected during the attack [‘attack- stop’ traps only]

Disabled—No SNMP trap is sent

Subscriber Notification

When an attack is identified, if the IP address is detected on the subscriber side and is mapped to a subscriber, the system notifies the application about the attack. This enables the application to notify the subscriber about the attack on-line by redirecting HTTP requests of this subscriber to a server that will notify it of the attack.

In addition, when blocking TCP traffic, the system can be configured not to block a specified port to make this redirection possible. This port is then considered to be un-blockable.

Note that subscriber-notification can only function if supported by the Service Control Application currently loaded to the Cisco SCE platform, and the application is configured to activate this capability. To verify whether the application you are using supports attack subscriber notification, and for details about enabling attack subscriber notification in the application, please refer to the documentation of the relevant Service Control Application.

Hardware Filtering

The Cisco SCE platform has two ways of handling an attack: by software or by hardware. Normally, attacks are handled by software. This enables the Cisco SCE platform to accurately measure the attack flows and to instantly detect that an attack has ended.

However, very strong attacks cannot be handled successfully by the software. If the software cannot adequately handle an attack, the resulting high CPU load will harm the service provided by the Cisco SCE platform (normal traffic classification and control). An attack that threatens to overwhelm the software will, therefore, be automatically filtered by the hardware.

When the hardware is used to filter the attack, the software has no knowledge of the attack packets, and therefore the following side effects occur:

The number of attack flows is greatly under-estimated by the software. This means that the total amount of flows in the attack reported by the CLI (show interface linecard attack-filter current-attacks) is considerably lower than the actual amount.

Similarly, the reported attack flow rate (also reported by the CLI) is also considerably lower than the actual rate. Usually a rate of 0 is measured by the software.

There is considerable delay in detecting the end of the attack. The delay in detecting the end of attack is limited by two upper bounds.

– The first upper bound depends on the configured action, as follows:

– Report—A delay of no more than 8 minutes

– Block—A delay of no more than 64 minutes

– A second upper bound for the delay is one minute more than actual duration of the attack (for example, maximum delay for detecting the end of an attack lasting three minutes is four minutes).

The following examples illustrate the interaction of these two upper bounds:

– For an attack lasting two minutes, the maximum delay in detecting the end will be three minutes, regardless of configured action

– For an attack lasting two hours whose configured action is 'report', the maximum delay in detecting the end will be eight minutes

– For an attack lasting two hours whose configured action is 'block', the maximum delay in detecting the end will be 64 minutes

Hardware attack filtering is an automatic process and is not user-configurable. However, due to the effects of hardware attack filtering on attack reporting, it is important to be aware of when hardware processing has been activated, and so monitoring of hardware filtering is essential. There are two ways to do this (see “Monitoring Attack Filtering” section):

Check the "
HW-filter
" field in the
show interface linecard attack-filter current-attacks
command.

Configuring Attack Detectors

The Cisco attack detection mechanism is controlled by defining and configuring special entities called Attack Detectors.

There is one attack detector called ‘default’, which is always enabled, and 99 attack detectors (numbered 1-99), which are disabled by default. Each detector (both the default and detectors 1-99) can be configured with a separate action and threshold values for all 32 possible attack types.

When detectors 1-99 are disabled, the default attack detector configuration determines the thresholds used for detecting an attack, and the action taken by the Cisco SCE platform when an attack is detected. For each attack type, a different set of thresholds and action can be set. In addition, subscriber-notification and SNMP traps (alarm) can be enabled or disabled in the same granularity.

The default attack detector should be configured with values that reflect the desired Cisco SCE platform behavior for the majority of the traffic flows flowing through it. However, it is not feasible to use the same set of values for all the traffic that traverses through the Cisco SCE platform, since there might be some network entities for which the characteristics of their normal traffic should be considered as an attack when coming from most other network elements. Here are two common examples:

A DNS server is expected to be the target of many short DNS queries. These queries are typically UDP flows, each flow consisting of two packets: The request and the response. Normally, the Cisco SCE platform considers all UDP flows that are opened to the DNS server as DDoS-suspected flows, since these flows include less than 3 packets. A DNS server might serve hundreds of DNS requests per second at peak times, and so the system should be configured with a suitable threshold for DDoS-suspected flows for protocol = UDP and direction = attack-destination. A threshold value of 1000 flows/second would probably be suitable for the DNS server. However, this threshold would be unsuitable for almost all other network elements, since, for them, being the destination of such large rate of UDP flows would be considered an attack. Therefore setting a threshold of 1000 for all traffic is not a good solution.

The subscriber side of the Cisco SCE platform might contain many residential subscribers, each having several computers connected through an Internet connection, and each computer having a different IP address. In addition, there might be a few business subscribers, each using a NAT that hides hundreds of computers behind a single IP address. Clearly, the traffic seen for an IP address of a business subscriber contains significantly more flows than the traffic of an IP address belonging to a residential subscriber. The same threshold cannot be adequate in both cases.

To let the Cisco SCE platform treat such special cases differently, the user can configure non-default attack detectors in the range of 1-99. Like the default attack detector, non-default attack detectors can be configured with different sets of values of action and thresholds for every attack type. However, to be effective, a non-default attack detector must be enabled and must be assigned an ACL (access control list). The action and thresholds configured for such attack detector are effective only for IP addresses permitted by the ACL. Non-default attack-detectors can be assigned a label for describing their purpose, such as ‘DNS servers’ or ‘Server farm’.

Non-default attack detectors are effective only for attack types that have been specifically configured. This eliminates the need to duplicate the default attack detector configuration into the configuration non-default attack detectors, and is best illustrated with an example: Suppose an HTTP server on the subscriber side of the Cisco SCE platform is getting many requests, which requires the use of a non-default attack detector for configuring high threshold values for incoming TCP flow rates. Assume attack detector number 4 is used for this purpose; hence it is enabled, and assigned an ACL which permits the IP address of the HTTP server. Also suppose that it is desirable to protect subscribers from UDP attacks, hence the default attack detector is configured to block UDP attacks coming from the network (The default configuration is only to report attacks, not block them). If the HTTP server is attacked by a UDP attack from the network, the configuration of the default attack detector will hold for this HTTP server as well, since attack detector number 4 was not configured for UDP attacks.

For each of the non-default attack detectors, for each of the 32 attack types, there are four configurable settings:

Threshold

Action

Subscriber-notification

Alarm

Each of these four settings can be either configured (with a value or set of values) or not configured. The default state is for all them is not configured.

For each attack type, the set of enabled attack detectors, together with the default attack detector, forms a database used to determine the threshold and action to take when an attack is detected. When the platform detects a possible attack, it uses the following algorithm to determine the thresholds for attack detection.

Enabled attack detectors are scanned from low to high numbers.

If the IP address is permitted by the ACL specified by the attack detector, and a threshold is configured for this attack type, then the threshold values specified by this attack detector are used. If not, the scan continues to the next attack detector.

If no attack detector matches the IP address/protocol combination, then the values of the default attack detector are used.

The same logic is applied when determining the values to use for the remaining settings: action, subscriber-notification and alarm. The value that is used is the one specified by the lowest-numbered enabled attack detector that has a configured value for the attack type. If none exists, the configuration of the default attack detector is used.

By default, specific-IP detection is enabled for all attack types. You can configure specific IP detection to be enabled or disabled for a specific, defined situation only, depending on the following options:

For a selected protocol only.

For TCP and UDP protocols, for only port-based or only port-less detections.

For a selected attack direction, either for all protocols or for a selected protocol.

Options

The following options are available:

protocol—
The specific protocol for which specific IP detection is to be enabled or disabled.

Enables or disables sending an SNMP trap by default for the defined attack type.

The attack type must be defined the same as in Step 1.

How to Reinstate the System Defaults for a Selected Set of Attack Types

Use the following command to delete user-defined default values for action, thresholds, subscriber notification, and sending an SNMP trap for a selected set of attack types, and reinstate the system defaults.

Options

A specific attack detector may be configured for each possible combination of protocol, attack direction, and side. The Cisco SCE platform supports a maximum of 100 attack detectors. Each attack detector is identified by a number (1-100). Each detector can be either disabled (default) or enabled. An enabled attack detector must be configured with the following parameters:

– For dual-ip detections, the destination IP address is used for matching with the ACL.

– Use the "none" keyword to indicate that all IP addresses are permitted by this attack-detector.

This option is useful when using the command to define a port list, and the desired configuration should be set for all IP addresses.

comment—
For documentation purposes.

In addition, an enabled attack detector may contain the following settings:

TCP-port-list/UDP-port-list—
Destination port list for the specified protocol. TCP and UDP protocols may be configured for specified ports only. This is the list of specified destination ports per protocol.

Up to 15 different TCP port numbers and 15 different UDP port numbers can be specified.

Configuring a TCP/UDP port list for a given attack detector affects only attack types that have the same protocol (TCP/UDP) and are port-based (i.e. detect a specific destination port). Settings for other attack types are not affected by the configured port list(s).

The following settings are configurable for each attack type in each attack detector. Each setting can either be in a 'not configured' state (which is the default), or be configured with a specific value.

action—
Action:

–
report
(default)—Report beginning and end of the attack by writing to the attack-log.

–
block—
Block all further flows that are part of this attack, the Cisco SCE platform drops the packets.

How to Delete User-Defined Values

Use the following command to remove settings of action, thresholds, subscriber notification, and sending an SNMP trap for a specific attack detector and selected set of attack types.

Removing these settings for a given attack type restores them to the default 'not configured' state, which means that the attack detector does not take part in determining the response for attacks of this attack type.

How to Disable a Specific Attack Detector

Use the following command to disable a specific attack detector, configuring it to use the default action, threshold values and subscriber notification for all protocols, attack directions and sides.

From the SCE(config if)# prompt, type:

Command

Purpose

default attack-detector
number

Disables the specified attack detector.

How to Disable All Non-default Attack Detectors

Use the following command to disable all non-default attack detectors, configuring them to use the default values.

From the SCE(config if)# prompt, type:

Command

Purpose

default attack-detector all-numbered

Disables all non-default attack detectors.

How to Disable All Attack Detectors

Use the following command to disable all attack detectors, configuring them to use the default values.

From the SCE(config if)# prompt, type:

Command

Purpose

default attack-detector all

Disables all attack detectors.

Sample Attack Detector Configuration

The following configuration changes the default user threshold values used for detecting ICMP attacks, and configures an attack-detector with high thresholds for UDP attacks, preventing false detections of two DNS servers (10.1.1.10 and 10.1.1.13) as being attacked.

Subscriber Notifications

Subscriber notification is a capability used- for notifying a subscriber in real-time about current attacks involving IP addresses mapped to that subscriber. Subscriber notification is configured on a per-attack-detector level, as explained above, and must also be enabled and configured by the application loaded to the Cisco SCE platform, as explained in the Cisco Service Control Application for Broadband User Guide
.

In the current solutions, the Cisco SCE Platform notifies the subscriber about the attack by redirecting HTTP flows originating from the subscriber to the service provider’s server, that should notify the subscriber that he is under attack. This raises a question regarding TCP attacks originating from the subscriber that are configured with block action. Such attacks cannot normally be notified to the subscriber using HTTP redirection, since all HTTP flows originating from the subscriber are TCP flows, and they are therefore blocked along with all other attack flows. To enable effective use of HTTP redirect, there is a CLI command that prevents blocking of TCP flows originating from the subscriber to a specified TCP port, even when the above scenario occurs.

Configuring the Subscriber Notification Port

You can define a port to be used as the subscriber notification port. The attack filter will never block TCP traffic from the subscriber side of the Cisco SCE platform to this port, leaving it always available for subscriber notification.

Options

The following option is available:

portnumber—
The number of the port to be used as the subscriber notification port

From the SCE(config if)# prompt, type:

Commands

Purpose

attack-filter subscriber-notification ports
portnumber

Defines a port to be used as the subscriber notification port.

How to Remove the Subscriber Notification Port

Commands

Purpose

no attack-filter subscriber-notification ports

Removes the subscriber notification port.

Preventing and Forcing Attack Detection

After configuring the attack detectors, the Cisco SCE platform automatically detects attacks and handles them according to the configuration. However, there are scenarios in which a manual intervention is desired, either for debug purposes, or because it is not trivial to reconfigure the Cisco SCE platform attack-detectors properly. For example:

The Cisco SCE platform has detected an attack, but the user knows this to be a false alarm. The proper action that should be taken by the user is to configure the system with higher thresholds (for the whole IP range, or maybe for specific IP addresses or ports). However, this might take time, and, if attack handling is specified as ‘Block’, the user may wish to stop the block action for this specific attack quickly, leaving the configuration changes for a future time when there is time to plan the needed changes properly.

Use the
dont-filter
command described below for this type of case.

An ISP is informed that one of his subscribers is being attacked by a UDP attack from the network side. The ISP wants to protect the subscriber from this attack by blocking all UDP traffic to the subscriber, but unfortunately the Cisco SCE platform did not recognize the attack. (Alternatively, it could be that the attack was recognized, but the configured action was ‘report’ and not ‘block’).

Use the
force-filter
command described below for this type of case.

The user can use the CLI attack filtering commands to do the following:

Configure a
dont-filter
command to prevent or stop filtering of an attack related to a specified IP address

Configure a
force-filter
command to force filtering (with a specific action) of an attack related to a specified IP address

Use the following commands to either force or prevent attack filtering:

[no] attack-filter dont-filter

[no] attack-filter force-filter

Options

In addition to the attack detector options described above, the following options are available:

ip-address—
The IP address for which to prevent attack filtering.

If
attack -direction
is dual-sided, an IP address must be configured for both the source (
source-ip-address
) and the destination (
dest-ip-address
) sides.

Preventing Attack Filtering

Attack filtering can be prevented for a specified IP address and attack type by executing a dont-filter CLI command. If filtering is already in process, it will be stopped. When attack filtering has been stopped, it remains stopped until explicitly restored by another CLI command (either
force
-filter or
no dont-filter)
.

Viewing the Attack Log

The Attack Log

The attack-log contains a message for each specific-IP detection of attack beginning and attack end. Messages are in CSV format.

The message for detecting attack beginning contains the following data:

IP address (Pair of addresses, if detected)

Protocol Port number (If detected)

Attack-direction (Attack-source or Attack-destination)

Interface of IP address (subscriber or network)

Open-flows-rate, suspected-flows-rate and suspected-flows-ratio at the time of attack detection

Threshold values for the detection

Action taken

The message for detecting attack end contains the following data:

IP address (Pair of addresses, if detected)

Protocol Port number (If detected)

Attack-direction (Attack-source or Attack-destination)

Interface of IP address

Number of attack flows reported/blocked

Action taken

As with other log files, there are two attack log files. Attack events are written to one of these files until it reaches maximum capacity, at which point the events logged in that file are then temporarily archived. New attack events are then automatically logged to the alternate log file. When the second log file reaches maximum capacity, the system then reverts to logging events to the first log file, thus overwriting the temporarily archived information stored in that file.

The following SNMP trap indicates that the attack log is full and a new log file has been opened

ST_LINE_ATTACK_LOG_IS_FULL

Note When the attack log is large, it is not recommended to display it. Copy a large log to a file to view it.