Configuring Attack Detectors - Cisco SCE8000 Configuration Manual

Service control engine
Table of Contents

Advertisement

Configuring Attack Detectors

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
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 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.
Cisco SCE8000 Software Configuration Guide, Rel 3.1.6S
10-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
Monitoring Attack Filtering, page
Check the " HW-filter " field in the show interface linecard attack-filter current-attacks
command.
Check the " HW-filter " field in the attack log file.
Enabling Specific-IP Detection, page 10-8
Configuring the Default Attack Detector, page 10-10
Specific Attack Detectors, page 10-12
Sample Attack Detector Configuration, page 10-16
Chapter 10
Identifying and Preventing Distributed-Denial-Of-Service Attacks
10-20):
OL-16479-01

Advertisement

Table of Contents
loading

Table of Contents