Table of Contents
Advertisement
Attack Filtering and Attack Detection
Hardware Filtering
The SCE platform has two ways of handling an attack: by software or by hardware. Normally, attacks
are handled by software. This enables the 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 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:
•
•
•
•
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
•
•
Cisco SCE 2000 and SCE 1000 Software Configuration Guide
11-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.
Chapter 11
Identifying and Preventing Distributed-Denial-Of-Service Attacks
11-21):
OL-7827-12
Advertisement
Table of Contents
