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.

Figure 2-13. Display of Policy for a Zone on the Guard

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