Subscriber Notification - Cisco SCE 8000 10GBE Software Configuration Manual

Attack Filtering and Attack Detection

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:
•
•
•
•
Cisco SCE 8000 10GBE Software Configuration Guide
12-6
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
Chapter 12 Identifying and Preventing Distributed Denial-of-Service Attacks
OL-30621-02