Chapter 2: Mitigating Distributed Denial-of-Service Attacks

Cisco Press

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

Name of Attack

Flooding Capability

Short Description

Land

TCP SYN

Source and destination IP addresses are the same, causing the TCP response to loop.

SYN

TCP

Sends large numbers of TCP connection initiation requests to the target. The target system must consume resources to keep track of these partially opened connections.

Teardrop

TCP fragments

Sends overlapping IP fragments.

Smurf

Internet Control Message Protocol (ICMP)

Sends ICMP ping requests to a directed broadcast address. The forged source address of the request is the target of the attack. The recipients of the directed broadcast ping request respond to the request and flood the target's network.

Ping of death

ICMP

Brings down a system by sending out more than 65536 ICMP packets.

Open/close

TCP, UDP

Opens and closes connections at a high rate to any port serviced by an external service through inetd. The number of connections allowed is hard coded inside inetd (Internet super daemon, often used to run other services like FTP).

ICMP Unreachable

ICMP

The attacker sends ICMP unreachable packets from a spoofed address to a host. This causes all legitimate TCP connections on the host to be torn down to the spoofed address. This causes the TCP session to retry, and as more ICMP unreachables are sent, a denial-of-service (DoS) condition occurs.

ICMP redirect

ICMP

Causes data overload to the system being targeted.

ICMP Router Discovery Protocol (IRDP)

ICMP

Spoofing IRDP causes fake routing entries to be entered into a Windows machine. IRDP has no authentication. Upon startup, a system running MS Windows 95/98 will always send 3 ICMP Router Solicitation packets to the 224.0.0.2 multicast address. If the machine is NOT configured as a DHCP client, it ignores any Router Advertisements sent back to the host. However, if the Windows machine is configured as a DHCP client, any Router Advertisements sent to the machine will be accepted and processed.

ARP redirect

ARP

Attacks local subnets.

Looping User Datagram Protocol (UDP) ports

UDP

Spoofs two UDP services—chargen (port 19) and echo (port 7)—to send data to each other.

Fraggle

UDP

Same as Smurf, but uses UDP rather than ICMP to broadcast address for amplification.

UDP flood

UDP

Sends large numbers of UDP packets to the target system, thus tying up network resources.

TCP flood

TCP

Repeatedly establishes and abandons TCP connections, enabling a malicious host to tie up significant resources on a server.

UDP reflectors

UDP

All web servers, Domain Name System (DNS) servers, and routers are reflectors, because they will return SYN ACKs or RSTs in response to SYN or other TCP packets; query replies in response to query requests; or ICMP Time Exceeded or Host Unreachable in response to particular IP packets. By spoofing IP addresses from slaves, a massive DDoS attack can be arranged.

URL attacks

TCP

Attempts to overload an HTTP server with HTTP bombing (continuous requests for the same homepage or large web page) or by requesting the page with REFRESH to bypass any proxy server. Many of these attacks are not zombie attacks but rather human executed—by hundreds simultaneously.

Virtual Private Network (VPN) attacks

TCP

Using specially crafted Generic Routing Encapsulation (GRE) or IP in IP tunnel (IPIP) packets to attack the destination address of a VPN.

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

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

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

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

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 
 <remote-guard-address>: IP address in dotted-decimal notation (A.B.C.D)
Related:
1 2 3 Page 1
Page 1 of 3
SD-WAN buyers guide: Key questions to ask vendors (and yourself)