Chapter 2: Mitigating Distributed Denial-of-Service Attacks

Cisco Press

1 2 3 Page 2
Page 2 of 3

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

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

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

Figure 2-7

Zone Detection

Figure 2.9

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

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

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

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

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

Figure 2-13

Display of Policy for a Zone on the Guard

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

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.

Related:
1 2 3 Page 2
Page 2 of 3
SD-WAN buyers guide: Key questions to ask vendors (and yourself)