Table Of Contents

Product Overview

Understanding the MultiDevice Manager Network

Understanding DDoS Attacks

Understanding Spoofed Attacks

Understanding Nonspoofed Attacks

Understanding Detectors, Guards, and Zones

Using the Detector for Attack Detection

Using the Guard for Attack Mitigation

Understanding Zones and Learning Zone Traffic

Understanding the MDM Functions

Communicating with the Devices

Tracking Device-to-Zone Associations

Managing Zone Configurations

Managing Network Statistical and Status Information

Product Overview

---

This chapter provides a general overview of the Cisco DDoS MultiDevice Manager (MDM) and describes the various components that make up the MDM network. You use the MDM to remotely monitor and manage the following products:

•Cisco Traffic Anomaly Detector Module and Cisco Traffic Anomaly Detector appliance

•Cisco Anomaly Guard Module and Cisco Guard appliance

---

Note This guide refers to the Cisco Traffic Anomaly Detector Module and the Cisco Traffic Anomaly Detector appliance as Detector and the Cisco Anomaly Guard Module and the Cisco Guard appliance as Guard. When referring to both the Detector and the Guard, this guide uses the term device.

---

This chapter contains the following sections:

•Understanding the MultiDevice Manager Network

•Understanding DDoS Attacks

•Understanding Detectors, Guards, and Zones

•Understanding the MDM Functions

Understanding the MultiDevice Manager Network

The MDM software allows you to monitor and manage multiple Detector and Guard devices that protect your network against Distributed Denial of Service (DDoS) attacks. The MDM, which runs on a Linux server, has a web-based GUI that provides easy access to network and device status and statistical information. The MDM also enables you to perform the following tasks:

•Define and manage the network zones, or regions of your network that the devices protect

•Display a consolidated view of ongoing and past attacks on all zones

•Display consolidated statistical information related to all zones and devices

•Create aggregated reports

•Configure or modify zone information on one device and then synchronize the zone to copy the configuration information to the other zone devices

•Activate anomaly detection on all of the zone Detectors

•Activate zone protection (attack mitigation) on all of the zone Guards

•Activate the learning process on one, or all, of the zone devices

Figure 1-1 shows a sample MDM network where the MDM monitors and manages several devices. While there are many possible network configurations in which the Detectors and Guards can be incorporated into a network, this example shows a typical application where the Detectors are used to detect attacks on a zone and then activate one or more of the Guards to mitigate the attack. Communication between the Detector and Guard devices and between the devices and the MDM server is performed over Secure Sockets Layer (SSL) communication channels.

Figure 1-1

Sample MDM Network

Table 1-1 describes the various elements of the MDM network.

Table 1-1 Elements of the MDM Network 

Item	Description
Detector	A Detector receives a copy of the network traffic, which it analyzes for deviations in normal traffic patterns. Traffic abnormalities, or anomalies, indicate an attack on the network. When the Detector detects an attack, it can activate one or more Guards to mitigate the attack.
Guard	A Guard receives network traffic that is diverted from its normal route so it can pass through the Guard for analysis and cleaning. The Guard analyzes the traffic, looking for traffic anomalies that indicate an attack on the zone. When an anomaly is detected, the Guard begins mitigating the attack, separating and dropping malicious traffic, and injecting only clean traffic back into the network. When the Guard determines that the attack is over, traffic is no longer diverted through the Guard.
Zone	A zone represents a number of network elements, or network destinations (such as a server farm), that you want selected Detector and Guard devices to protect against DDoS attacks. You can configure a device with multiple zones.
MDM server	The MDM server ties all of the devices and zones together. The MDM maintains a database of every device that you specify and every zone that you configure on a device through the MDM. This database also shows the association between a device and the zones configured on it. The MDM displays aggregated statistical and status information based on information that it gathers from the devices.
Master device	The master device is the device through which the MDM manages a zone configuration. Every zone has one master device, which you select when you define the zone. The master device enables you to create or modify a zone configuration once on the master device and then use a process know as synchronization to copy the configuration to all of the associated zone devices.

Understanding DDoS Attacks

DDoS attacks deny legitimate users access to a specific computer or network resource. These attacks are launched by individuals who send malicious requests to targets that degrade service, disrupt network services on computer servers and network devices, and saturate network links with unnecessary traffic.

This section contains the following topics:

•Understanding Spoofed Attacks

•Understanding Nonspoofed Attacks

Understanding Spoofed Attacks

A spoofed attack is a type of DDoS attack in which the packets contain an IP address in the header that is not the actual IP address of the originating device. The source IP addresses of the spoofed packets can be random or have specific, focused addresses. Spoofed attacks saturate the target site links and the target site server resources. It is easy for a computer hacker to generate high volume spoofed attacks even from a single device.

Understanding Nonspoofed Attacks

Nonspoofed attacks (or client attacks) are mostly TCP-based with real TCP connections that can overwhelm the application level on the server rather than the network link or operating system.

Client attacks from a large number of clients (or zombies) may overwhelm the server application even without any of the individual clients creating an anomaly. The zombie programs try to imitate legitimate browsers that access the target site.

Understanding Detectors, Guards, and Zones

This section describes the basic functions of the Detector and Guard devices in the network, how you use the devices to detect and mitigate DDoS attacks, and how you define the areas of the network (zones) to be protected.

This section contains the following topics:

•Using the Detector for Attack Detection

•Using the Guard for Attack Mitigation

•Understanding Zones and Learning Zone Traffic

Using the Detector for Attack Detection

The Detector is a passive monitoring device that continuously looks for indications of a DDoS attack against a zone, such as a server, firewall interface, or router interface. The Detector works optimally with a Guard but it can also operate as a separate DDoS detection and alarm component.

The Detector analyzes copies of all inbound traffic destined for the protected zones. It compares the current traffic characteristics to a set of established behavioral thresholds (the zone policy) to detect anomalous traffic behavior. When the Detector identifies a traffic anomaly, it can activate a Guard to mitigate these attacks. Because the Detector uses a copy of the traffic for analysis purposes, it sits unobtrusively in the background of the network.

The Detector uses the following features to monitor traffic:

•An algorithm-based system that learns the zone traffic, adopts itself to the traffic characteristics, and provides the Detector with references and instructions in the form of polices and policy thresholds.

•A system that either remotely activates a Guard to protect the zones or records the traffic anomalies in the Detector syslog.

You can enable the Detector to receive a copy of the network traffic by one of the following methods:

•Port mirroring feature (such as SPAN) of a switch

•Splitting

•Configuring the switch or router in which the Detector is installed to capture the traffic that is sent to the zone and pass a copy of the traffic to the Detector

When used with a Guard, the Detector (placed logically downstream from the Guard) can activate the Guard when it detects an attack on the zone. When no attack is in progress, the Detector sees a copy of all inbound traffic destined for the protected zone. During an attack, when the Guard diverts traffic from the targeted zone for mitigation, the Detector sees only the legitimate traffic that the Guard injects back into the network.

A Detector can activate a Guard in one of the following ways:

•Using a remote Guard list—The Detector can activate the list of Guards that you define on the Detector.

•Using Border Gateway Protocol (BGP)—The Detector can send a BGP message to the adjacent router to divert the zone traffic to a Guard. This method is supported by the Cisco Traffic Anomaly Detector only and not by the Cisco Traffic Anomaly Detector Module.

•Offline—The Detector can issue a notification when an attack on the zone occurs, at which time you can manually activate zone protection on the Guard.

•Manually—You can create a dynamic filter on the Detector to activate a Guard.

For more information on the Detector, see the appropriate documentation in the "Related Documentation" section on page x.

Using the Guard for Attack Mitigation

The Guard is an active DDoS attack mitigation device that protects the zone against DDoS attacks. The Guard receives traffic that is diverted from the attacked zones and inspects the diverted traffic to identify and separate malicious flows from legitimate transactions. The Guard removes specific attack packets and forwards legitimate traffic packets to their targeted destination, helping to ensure that real users and real transactions get through.

Typically, you deploy the Guard in a distributed upstream configuration at the backbone level. When the Guard detects an attack, it diverts only the traffic of the attacked zone to itself. Any traffic destined for other zones (not under attack) continues to flow without interference. The Guard analyzes the packets and removes the DDoS components so that only clean traffic packets are allowed to continue on to the intended zone. The Guard constantly filters the traffic and adjusts the attack mitigation process as the attack evolves.

The Guard uses the following features to manage zone traffic:

•A traffic diversion process that diverts the zone traffic to the Guard for learning purposes, protects against DDoS attacks, and injects legitimate traffic back into the network.

•An algorithm-based learning process that can learn the characteristics of normal zone traffic and customize the zone protection capabilities. This process provides the Guard with traffic reference points and protection instructions in the form of zone policies and policy thresholds.

•Protection processes that can distinguish between legitimate and malicious traffic. The protection processes filter the malicious traffic so that only the legitimate traffic can pass through to the zone.

These components enable the Guard to assume its protective role when there is an attack but allows the Guard to remain unobtrusively in the background when there is no attack. When there are no suspected attacks, you do not need to activate the diversion process, and the Guard does not see the traffic.

Understanding Zones and Learning Zone Traffic

A zone can consist of one or any combination of the following network elements:

•A network server, client, or router

•A network link, a subnet, or an entire network

•An individual Internet user or a company

•An Internet Service Provider (ISP)

When you create a zone, you configure it with the network addresses and the traffic policies that the Detectors use for anomaly detection and the Guards use for attack mitigation, or zone protection. The Detectors and Guards can manage different zones simultaneously if their network address ranges do not overlap.

When you create a zone, you base the zone configuration on one of several predefined zone templates. Each zone template contains a set of default policies that the device applies to the zone traffic. Each policy is preconfigured with a default traffic threshold value that provides a reference point for determining when the zone is under attack. The device considers all traffic that does not exceed the policy threshold as normal traffic. When the traffic exceeds the policy threshold, the device considers the traffic to be an attack on the zone and responds according to the action associated with the policy.

To adjust the anomaly detection and zone protection capabilities of a device, the devices can learn the zone traffic and make modifications to the zone policies that are based on the characteristics of the zone traffic. This process, known as the learning process, consists of the following two phases:

•Policy construction phase—The device creates new policies based on the services that the device detects in the zone traffic.

•Threshold tuning phase—The device modifies the thresholds of the policies based on normal traffic volume.

Understanding the MDM Functions

This section describes how you can use the MDM to monitor and manage the devices on your network and the zones configured on the devices.

This section contains the following topics:

•Communicating with the Devices

•Tracking Device-to-Zone Associations

•Managing Zone Configurations

•Managing Network Statistical and Status Information

Communicating with the Devices

The MDM monitors and manages the devices that you specify on the MDM device list. Communication between the MDM and a device is enabled by a Remote Agent (RA) that resides on the device. The device software image contains an RA stub, which the MDM keeps updated with the latest RA version so that you do not need to manually update the RA on each device.

To ensure network security, the MDM communicates with a device over a secure SSL communication channel. When the MDM initiates a connection with a device, the MDM server and the device perform an SSL handshake, exchanging the keys and certificates required to authenticate themselves.

---

Note The MDM does not support network address translation (NAT) or proxy services between it and the remote agent located on each device that you specify on the MDM device list.

---

Tracking Device-to-Zone Associations

The MDM maintains a local database of the devices that you specify on the MDM device list and the zones that you configure on the devices using the MDM. The database also tracks the association between a zone name and the devices that you associate with the zone. Only the zone name is stored in the MDM database. The zone configuration information is stored in each of the zone devices.

You can enable the MDM to search the network for discrepancies between the device and zone information in its database and the information that it detects in the network. When the MDM detects a discrepancy, it displays a conflict error condition. A conflict can occur for several reasons, including:

•You add a device to the MDM device list that already contains a zone configuration.

•The MDM detects a zone on a device that the database does not associate with the device.

•The database has a zone that is associated with a device, but the MDM cannot find the zone on the device.

Managing Zone Configurations

The MDM performs all zone configuration operations through the zone master device. When you select a zone configuration to view, the MDM displays the configuration that resides on the zone master device. The only time that the MDM interacts directly with each of the zone devices for a zone configuration operation is during the first step of the zone creation process when you define the high level zone configuration parameters, such as the zone name, IP address, and the devices that will provide DDoS protection. When you complete this step, the MDM pushes the configuration information to each of the devices that you associate with the zone. From that point on, you perform all modifications to the copy of the zone configuration that resides on the master device. To update the other zone devices with the configuration changes that reside on the master device, you use the synchronization process in which the master device copies the configuration information to the other zone devices. You can initiate synchronization manually when needed, or you can configure the MDM to perform the process automatically at specific times. For example, the MDM can automatically initiate synchronization of a zone every time that a change is made to the zone configuration.

---

Note The MDM does not track changes that you make to a zone configuration using the device CLI or Web-Based Manager (WBM). For example, if you modify the zone configuration on a device (other than the zone master device) using the device CLI, the MDM does not know that a change has been made. The next time that the zone is synchronized, the master device zone configuration will overwrite the changes that you made to the configuration on the other device.

Managing Network Statistical and Status Information

The MDM uses a process called consolidation to collect and manage the information that it pulls from the network devices. This information is a collection of statistical information, such as traffic counter rates and status information that relate to the different zones and devices. From the information collected from the devices, the MDM creates aggregated reports that provide you with the operational details on a global level as well as a zone-specific level. With the various MDM menu options, you can view the following information:

•Zones currently under attack

•Attack details, such as the traffic rates associated with the malicious traffic versus the legitimate traffic

•Number of active dynamic filters that the devices produced in response to a zone attack

•Operational state of the zones (for example, zone protection is activated or the zone is learning the traffic)

•Communication state of the zone devices (for example, the MDM has established a session with a device or a device is being initialized)

•Conflict error conditions that indicate that discrepancies exist between the zone and device information in the database and what the MDM has detected in the network

•Synchronization errors that indicate that the devices of a zone do not all contain the configuration information contained on the master device