Chapter 2: Mitigating Distributed Denial-of-Service Attacks

More chapters from new and classic Cisco Press books 

Rate your favorite Cisco Press books

The Cisco distributed denial-of-service (DDoS) mitigation solution is composed of two key components: Cisco Traffic Anomaly Detector, which is responsible for detecting a DDoS attack, and Cisco Guard, which is responsible for mitigating the attack. Customers can implement a DDoS solution with the Cisco Guard and the Cisco Traffic Anomaly Detector, or they can purchase the DDoS solution from a service provider. The solution from a service provider is often called a clean pipes solution. A clean pipes solution is implemented with a variety of products, including the Cisco Guard, Cisco Traffic Anomaly Detector, and partner products from vendors like Arbor Networks.

The Cisco Guard and the Cisco Traffic Anomaly Detector are based upon the patented Multi-Verification Process (MVP) architecture. This MVP architecture enables the Cisco Guard and Cisco Traffic Anomaly Detector to leverage the latest analysis and attack recognition techniques to detect and remove network attack traffic while scrubbing and reinjecting valid network traffic to its proper destination. Before describing the functions and configuration processes for these products, this chapter summarizes various DDoS attacks.

Understanding Types of DDoS Attacks

Table 2-1 describes several varieties of generic DDoS attacks.

Table 2-1 Generic DDoS Attacks

Source: Cisco Systems, Inc.

DDoS Mitigation Overview

To mitigate DDoS attacks, Cisco offers the Traffic Anomaly Detector and the Guard.

The Traffic Anomaly Detector learns what is a normal traffic pattern for a protected network area, or zone. After the Traffic Anomaly Detector establishes a network traffic baseline, DDoS mitigation policies are constructed and thresholds are tuned in order to configure the Traffic Anomaly Detector to react to various DDoS attack scenarios. In the event of a DDoS attack, the Traffic Anomaly Detector informs the Guard of the DDoS attack. The Guard diverts the traffic from the DDoS attack to the Guard. This DDoS attack diversion is typically implemented by updating the Border Gateway Protocol (BGP) routing table or by other mechanisms including static routes (manual IP routes) and policy-based routes (specific traffic forwarding based upon parameters including application and packet size).

The Guard’s ability to update routing tables in the event of an attack allows the Guard to automatically scrub the DDoS attack traffic, while still forwarding or tunneling valid network traffic to the destination zone. The Traffic Anomaly Detector is often deployed upstream from the servers that are being protected in the data center. Figure 2-1 shows the Traffic Anomaly Detector and Guard appliances.

Figure 2-1

Traffic Anomaly Detector and Guard Appliances

Source: Cisco Systems, Inc.

Using Cisco Traffic Anomaly Detector

The two main product options for the Cisco Traffic Anomaly Detector are the appliance and the Traffic Anomaly Detector service module on the Catalyst 6500 and Catalyst 7600 product lines. Figure 2-2 shows the Traffic Anomaly Detector service module.

Figure 2-2

Catalyst 6500/7600 Traffic Anomaly Detector Service Module

Source: Cisco Systems, Inc.

In addition to the Traffic Anomaly Detector, there are several others mechanisms to detect a DDoS attack and inform the Guard of the attack. Some of these mechanisms that detect a DDoS attack and inform the Guard include the DDoS signatures on the intrusion prevention system (IPS) appliances and modules. However, this section focuses on the Traffic Anomaly Detector because this component is frequently deployed and is a very feature-rich component for DDoS mitigation.

The Traffic Anomaly Detector is capable of monitoring gigabit speeds and operates on a copy of the network traffic. This copy of the network traffic is often obtained by using a span port of the Catalyst LAN switch to create a copy of the network traffic. The Traffic Anomaly Detector is designed to monitor the traffic destined to one of more zones. A Zone is a particular server, group of servers, subnet, network, or Internet service provider (ISP) that is being protected from a DDoS attack. The Traffic Anomaly Detector protects a zone by learning the baseline traffic destined to the zone, and then applies policy configuration and threshold tuning to protect the zone from a DDoS attack. The Traffic Anomaly Detector can be configured with command-line interface (CLI) or an easy-to-use web-based device manager (WBM). However, the Traffic Anomaly Detector WBM supports only a subset of the CLI of the Traffic Anomaly Detector.

Configuring the Traffic Anomaly Detector

The Traffic Anomaly Detector must be bootstrapped or configured to allow web-based access to the device. The following CLI commands allow web-based access:

service wbm
permit wbm ip-addr [ip-mask]

ip-addr [ip-mask] is the IP address of the host the launches the web browser.

Launch the web browser and type the following:

https://detector-ip-addr

detector-ip-addr is the IP address of the Detector.

Enter the username and password for the administrative rights to configure the Traffic Anomaly Detector, and you will see the homepage of the Traffic Anomaly Detector WBM, as shown in Figure 2-3. The Traffic Anomaly Detector WBM features a Detector Summary, which displays the average, minimum, maximum, and current level of network traffic through the Traffic Anomaly Detector in bits per second (bps).

Figure 2-3

Traffic Anomaly Detector WBM Homepage

Zone Creation

The Traffic Anomaly Detector attempts to detect a DDoS attack against a particular zone. You can create a zone under the Zones tab by selecting Create Zone. Figure 2-4 shows an example of the Create Zone configuration panel.

You can give a zone a name and template, which contains a list of default DDoS mitigation policies templates to be constructed and tuned for the zone. Default templates are provided to create a base DDoS protection coverage. You can copy and edit these default configuration policies to provide customized configuration policies for more advanced attack protection.

Zones can be created with either a DETECTOR_zone template or a GUARD_zone template. A zone that is created with GUARD_zone template has the ability to be automatically synchronized with the Guard. DETECTOR_zone templates are designed for use when zone information does not need to be synchronized with the Guard.

Figure 2-4

Create Zone Configuration

The Traffic Anomaly Detector can inform the admin of a potential DDoS attack, or a Traffic Anomaly Detector can automatically inform or trigger the Guard to mitigate the attack. Select the automatic operation mode for the Traffic Anomaly Detector to inform the Guard to trigger or automatically protect against the known attack so that the network can be self-defending against a DDoS attack without user intervention.

---

CAUTION – A self-defending network is a very powerful concept. However, be aware that a self-defending network can automatically configure network devices, reroute and deny network traffic, and may result in false positives. A false positive is valid network traffic that was dropped, delayed, or otherwise affected due to an incorrect classification that the valid network traffic was in fact part of a network attack.

---

To configure the IP address of the remote Guard that will protect the Traffic Anomaly Detector’s zone, you must use CLI. Example 2-1 shows an example of a base Traffic Anomaly Detector configuration file that details how to configure the IP address of the remote Guard for the Traffic Anomaly Detector. Network connections between the Traffic Anomaly Detector and the remote Guard are secured with Secure Shell (SSH) or Secure Socket Layer (SSL). SSH keys must be generated and applied to both devices to complete the SSH connection. The Traffic Anomaly Detector can generate a private-public SSH key pair and distribute its public key to every Guard listed in the remote-guards list. Multiple Cisco Traffic Anomaly Detectors can report to the same Cisco Guard for a distributed architecture.

Example 2-1 CLI Configuration of the Cisco Traffic Anomaly Detector Service Module

hostname ce-detector
timezone America/Los_Angeles

history logs 7
history reports 30
no export packet-dump
boot reactivate-zones
tacacs-server timeout 0
tacacs-server key (null)
no tacacs-server first-hit
aaa authentication login local 
aaa authentication enable local 
no aaa authorization exec tacacs 
username riverhead dynamic encrypted $1$LVZopVja$8kSY10uykJaSYT325wDDk/
username cleanpipes adm1n09 encrypted 18KLWZvg0DP02
enable password level admin encrypted 18xVodWfkJfOk
enable password level config encrypted 84QiLbAV5gfOA
enable password level dynamic encrypted 161R6GsPeIPWs

snmp community public

snmp trap-dest 172.28.198.22 public debugging
interface eth0
 ip address 172.28.198.35 255.255.255.0
 mtu 1500
 no shutdown
exit
interface giga0
 mtu 1500
 no shutdown
exit
interface giga1
 mtu 1500
 no shutdown
exit

default-gateway 172.28.198.1
service ntp
service wbm
service internode-comm
service snmp-trap


permit wbm 17.28.198.100
permit ssh 17.28.198.100
permit internode-comm 172.28.198.34

ntp server 171.68.10.150

logging host 172.28.198.22
logging trap informational
logging facility local7


zone Zone_20_41_2 GUARD_DEFAULT interactive

 no learning-params periodic-action
 learning-params threshold-selection max-thresholds
 learning-params threshold-tuned
 learning-params sync accept
 learning-params sync remote-activate
 no packet-dump auto-capture
 packet-dump disk-space 2048
 ip address 20.41.2.0 255.255.255.0

 remote-guard ssl 172.28.198.34
 protect-ip-state entire-zone
 no bypass-filter *
 no flex-content-filter *

 

admin@ce-detector-conf#conf t
admin@ce-detector-conf#remote-guard 
 ssh         : Secure shell
 ssl         : Secure socket layer

admin@ce-detector-conf#remote-guard ssl 
 : IP address in dotted-decimal notation (A.B.C.D)

Traffic Anomaly Detector Zone Filters

Zone filters enable mirrored network traffic to be managed by the Detector. Zone filters enable the Traffic Anomaly Detector to drop traffic prior to inspection by the Traffic Anomaly Detector. Zone filters also enable the Traffic Anomaly Detector to analyze network traffic for spikes or anomalies and notify the Guard of these network traffic abnormalities. There are four types of filters:

•  User—User filters are assigned to a Zone that is created with the GUARD_zone template. User filters are used to provide a first layer of defense against the attack until the Guard has analyzed the attack and until the Guard can create custom, dynamic filters for the network attack.

•  Bypass—Bypass filters restrict certain network traffic flows from being directed to the Detector.

•  Flex—Flex filters support the ability to count a specific traffic flow.

•  Dynamic—The Detector creates dynamic filters as the result of an analysis of a traffic flow. The dynamic filter is the mechanism to activate a remote Guard to protect a zone, or an IP address in a zone, in the event of a detected DDoS attack for a specific IP traffic flow. Dynamic filters are temporary and are expected to expire at the end of a DDoS attack.

You can configure user, bypass, and flex filters with the Traffic Anomaly Detector WBM. You can create these filters by selecting the Configuration tab for a specific Zone.

Policy Template

A policy template is a collection of information that is leveraged during the learning phase of the zone. The policy template provides the basis for creating the zone’s detection policies after the normal traffic baseline is established during the learning phase. To configure a policy template for a zone, go to Configuration > Policy template as shown in Figure 2-5.

Figure 2-5

Policy Template Configuration

You can select and edit the policy templates. The primary parameters or options for each policy template are

•  State—State allows the user to enable or disable/turn-off a policy template. It is strongly cautioned that disabling/turning-off a default policy template can compromise the DDoS protection of a zone because there may be no policies to protect the network traffic that would have been specified in the policy template.

•  Minimum threshold—Minimum threshold refers to packets-per-second (pps) or total number of network connections. The Guard will not create a dynamic filter to mitigate an attack until the traffic flow exceeds the minimum threshold.

•  Maximum services—Maximum services refers to the number of port numbers or service ports that are protected by the Guard for that policy template. Additional memory on the Traffic Anomaly Detector is required for each additional service in the policy templates for each Zone.

Learning Phase

A zone must enter a learning phase in order to establish a baseline of normal network traffic and to provide a mechanism to construct the zone’s active policies from the base policy template. The learning phase consists of two processes:

• Policy construction

• Threshold tuning

In the policy construction phase, zone policies are created from the base template. It is recommended that the policy construction phase run for at least two hours to ensure a proper baseline.

The second phase is the threshold-tuning phase. During this tuning phase, the Traffic Anomaly Detector creates a minimum threshold value for the relevant zone policies. This threshold value is used to indicate the minimum level of network traffic for specific network flows that would indicate a potential DDoS attack on the zone. It is recommended that the threshold-tuning phase run for at least 24 hours to improve the computation of the minimum threshold values for each service that will constitute a possible DDoS attack. Zones that were created with the GUARD_zone template cannot initiate the policy construction phase from the Traffic Anomaly Detector. You can initiate the policy construction and the phases for zones created with the DETECTER_zone template through the Traffic Anomaly Detector WBM, as shown in Figure 2-6.

Figure 2-6

Initiating the Learning Phase

Detecting and Reporting Traffic Anomalies

After you have completed the learning phase, constructed zone policies, and tuned the threshold values, you can enable the zone to detect a traffic anomaly or potential DDoS attack. Figure 2-7 shows an example of the Detection tab in the Traffic Anomaly Detector WBM. Figure 2-7 also displays the location to view any generated dynamic filters. Dynamic filters are created by the Traffic Anomaly Detector during the detection of a potential DDoS attack. These dynamic filters created by the Traffic Anomaly Detector are used to create a syslog or are used as a trigger to activate the remote Guard to scrub the network traffic.

The Traffic Anomaly Detector WBM also offers extensive diagnostic information, including counters and attack reports. Figure 2-8 shows an example of an attack report, which indicates what attacks were detected and when they were detected. Attack reports can also be exported in text and XML format.

Figure 2-7

Zone Detection

Figure 2-8

Attack Reports

Figure 2-9 shows an example of the diagnostic event log with details on Traffic Anomaly Detector activity, warnings, and pending dynamic filters.

Figure 2-9

Event Logs

Configuring Cisco Guard

The Cisco Guard is the component of the DDoS mitigation solution that receives the network attack traffic for a zone from the Traffic Anomaly Detector. The Guard scrubs or removes the attack traffic and forwards or reinjects the good (nonattack) traffic back to the destination zone. The Guard is often deployed upstream at the ISP/backbone layer and can protect large network segments. A single Guard can protect more than one zone simultaneously as long as there are no overlapping IP addresses in multiple zones. A native self-protection mechanism is also contained in the Guard to protect the Guard itself from becoming the target of a DDoS attack.

The Guard is available as both an appliance and a Catalyst 6500/7600 service module. A picture of the Anomaly Guard service module is shown in Figure 2-10. The Anomaly Guard service module, unlike the appliance, contains no onboard interfaces. A single Catalyst chassis can house both the Anomaly Guard and Traffic Anomaly Detector service module.

Figure 2-10

Catalyst 6500/7600 Anomaly Guard Service Module

Source: Cisco Systems, Inc.

Like the Traffic Anomaly Detector, the Guard also features an easy-to-use WBM. The Guard’s WBM is similar in philosophy to that of the Traffic Anomaly Detector’s WBM in that the Guard WBM supports only a subset of the CLI that is implemented on the Guard. The Guard WBM features focus around the areas of zone configuration, status, and reports. Other Guard features, including zone traffic diversion, must be configured with the CLI since they are not supported in the Guard WBM.

Configuring and using the Guard includes the following:

• Bootstrapping

• Zones creation and synchronization

• Zone filters

• Zone traffic diversion

• Learning Phase

• — Policy construction

  — Threshold tuning

• Activating zone protection

• Attack reports

Bootstrapping

The process to bootstrap and initialize the Guard is similar to the process described previously for the Traffic Anomaly Detector in the Configuring the Traffic Anomaly Detector section. The Guard must have an interface configured, and the WBM service should be started and permitted with the Guard CLI in order to be managed by the Guard WBM.

Zone Creation and Synchronization

The zone that is to be protected must be either configured on the Guard or synchronized from the Traffic Anomaly Detector. Zones that are configured on the Guard can be configured in a manner similar to that described previously in the Zone Creation section for the Traffic Anomaly Detector. However, many users will instead want to synchronize the zones that were already created on the Traffic Anomaly Detector using the GUARD_zone template. This process to synchronize the zones from the Traffic Anomaly Detector must be performed with Guard CLI because the zone synchronization feature is not supported in the Guard WBM.

Cisco Guard Zone Filters

The Guard features user, bypass, flex, and dynamic filters. These filter types were described previously in this chapter in the section “Traffic Anomaly Detector Zone Filters.” In the event of a suspected DDoS attack, the Guard generates dynamic filters. These dynamic filters are temporary and expire after the end of the DDoS attack. These dynamic filters instruct the Traffic Anomaly Detector on what action to perform on the suspected network attack traffic.

The Guard can also create a default set of user filters to provide a base of protection until additional dynamic filters are created after the analysis of network attack traffic. The user filters are displayed in Figure 2-11, which illustrates the user filters for a specific zone on the Guard.

Figure 2-11

Guard User Filter

User filters can also be created manually on the Guard for a user to customize how the Guard should process a specific network traffic flow. Figure 2-12 provides an example of the options available when configuring a User Filter. The options for the User Filter include the following:

•  Source IP—Includes any wildcard (*)

•  Source Subnet—Select from drop-down

•  Protocol—Includes any wildcard (*)

•  Dst Port—Refers to the Destination Port (*)

•  Fragments—Includes With, Without, or *

•  Rate—Limits traffic to specified rate

•  Burst—Refers to the Burst traffic limit

•  Action—Includes parameters to permit traffic flow to avoid Guard antispoofing and antizombie protection, authenticate, and drop traffic

Figure 2-12

User Filter Creation

Zone Traffic Diversion

Zone traffic diversion is composed of two phases:

• Divert potential DDoS traffic destined to the zone.

• Inject the scrubbed or good network traffic back from the Guard to the zone.

In the first phase, BGP routing updates are one of the most common mechanisms used to divert attack traffic from the router to the Guard for scrubbing. The Guard achieves this traffic diversion by sending a BGP update to the router to indicate that the next-hop for the zone is the Guard itself. This BGP announcement from the Guard contains a more specific prefix to ensure that the Guard is the best path for the next-hop to the zone. This BGP announcement from the Guard is often sent with a no export and no community string option to ensure that this BGP announcement is not propagated to other routes within the network.

For the second phase of traffic diversion, several traffic forwarding mechanisms, including next-hop router discovery, policy-based routing, VPN routing and forwarding (VRF), VLANs and GRE/IPIP tunnels, can be used to inject the scrubbed traffic back to the destination zone. Both the process to divert the network attack traffic to the Guard and reinject the scrubbed traffic back to the zone must be configured with CLI as they are not supported by the Guard WBM. Zone traffic diversion must be configured with CLI prior to initiating the learning phase for policy creation and threshold tuning.

Learning Phase

The Guard undergoes a learning phase similar to the learning phase described previously for the Traffic Anomaly Detector. The learning phase is composed of a policy construction phase and a threshold-tuning phase. Figure 2-13 displays the policies for the dns_tcp and dns_udp services for a specific zone on the Guard WBM. Both the Traffic Anomaly Detector and the Guard WBM feature the ability to cross-launch the policy display in the Guard and Traffic Anomaly Detector WBM for additional comparison purposes.

Activating Zone Protection

A zone must be placed into protect mode after the zone configuration, policy construction, threshold tuning, and traffic diversion configuration has been completed. A zone can be automatically placed into protect mode by a trigger from the Traffic Anomaly Detector during a DDoS attack. The trigger from the Traffic Anomaly Detector can indicate whether the entire zone should be placed into protect mode or if a specific IP address in a zone should be placed into protect mode by the creation of a subzone. You can also manually place a zone in protect mode through the Protection tab in the Guard WBM, as shown in Figure 2-14.

Figure 2-13

Display of Policy for a Zone on the Guard

Figure 2-14

Placing a Zone in Protect Mode

Generating Attack Reports

You can generate an extensive list of attack reports from the Guard WMB. These attack reports include metrics on the number of mitigated attacks and a per-attack summary with a breakdown of legitimate versus malicious network traffic. Figure 2-15 displays the beginning of an attack report with total attack statistics.

Figure 2-15

Total Attack Statistics

Like the Traffic Anomaly Detector, these attack reports on the Guard are also exportable in both text and XML format.

Summary

DDoS attacks are an attempt to prevent valid users from using network resources by flooding the network. This flooding of the network is often performed by hundreds or thousands of compromised zombie computers. Cisco DDoS mitigation is composed of two key components: the Traffic Anomaly Detector and the Guard. Both the Traffic Anomaly Detector and the Guard have a subset of their CLI that is managed by a Traffic Anomaly Detector WBM and a Guard WBM.

The Traffic Anomaly Detector and Guard combine to form a comprehensive solution that protects a zone. A zone can be an IP address, subnet, network, or ISP. The Traffic Anomaly Detector and Guard participate in a learning phase that creates a baseline of valid network traffic for each zone. This learning phase is composed of a policy creation phase to create policies to protect the zone and a threshold-tuning phase. The threshold-tuning phase creates minimum threshold values for each configured protocol that are based on the sample network traffic observed during the learning phase. Once network traffic for a specific application exceeds the tuned threshold, the Guard can create a dynamic filter or leverage a user filter to attempt to protect the zone against the DDoS attack. The specific DDoS attack traffic for that zone is diverted to the Guard, often with a BGP routing update mechanism. This DDoS traffic is then scrubbed by the Guard and reinjected back to the zone, often with a tunneling or VLAN mechanism. Both the Traffic Anomaly Detector and the Guard WBM features a rich-set of status and attack reports to visualize the DDoS attack and mitigation process for the protected zone.

References

Cisco Systems, Inc. DDoS Attack Prevention. https://www.cisco.com/en/US/netsol/ns480/networking_solutions_sub_solution_home.html

Cisco Systems, Inc. Cisco Traffic Anomaly Detector User Guide. https://cisco.com/application/pdf/en/us/guest/products/ps5887/c2001/ccmigration_09186a00803bd0d8.pdf

Cisco Systems, Inc. Cisco Traffic Anomaly Detector Web-Based Management User Guide. https://cisco.com/application/pdf/en/us/guest/products/ps5887/c2001/ccmigration_09186a00802d7255.pdf

Cisco Systems, Inc. Cisco Traffic Anomaly Detector Web-Based Management User Guide (Software Version 5.0). https://www.cisco.com/en/US/products/hw/modules/ps2706/products_module_configuration_guide_chapter09186a00804bef24.html

Cisco Systems, Inc. Cisco Guard Configuration Guide (Software Version 3.1(0)). https://www.cisco.com/en/US/products/ps5888/products_configuration_guide_book09186a00803bed03.html

Cisco Systems, Inc. Cisco Guard Web-Based Management User Guide (Software Version 3.1(0)). https://www.cisco.com/en/US/products/ps5888/products_configuration_guide_book09186a00802d1baf.html

Cisco Systems, Inc. Cisco Anomaly Guard Module Web-Based Management Configuration Guide, Glossary. https://www.cisco.com/en/US/products/hw/modules/ps2706/products_module_configuration_guide_chapter09186a00803f3ee7.html

Copyright © 2007 Pearson Education. All rights reserved.