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.

Figure 2-4. Create Zone Configuration

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.

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) 

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.

Figure 2-7. Zone Detection

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-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