Table Of Contents
Analyzing Guard Module Mitigation
Analyzing Zone Traffic Patterns
Recognizing a Traffic Diversion Problem
Blocking Flows to the Zone Based on Flow Characteristics
Verifying Traffic Blocking Criteria
Verifying Attack Mitigation
Displaying the Zone Current Attack Report
Displaying the Guard Module Advanced Statistics
Displaying Dropped Traffic Statistics
Analyzing Guard Module Mitigation
This chapter describes how to analyze the Cisco Anomaly Guard Module (Guard module) mitigation and the zone traffic, and it shows how to identify configuration problems. It provides a brief explanation of how to identify the type of attack.
This chapter contains the following sections:
•Analyzing Zone Traffic Patterns
•Verifying Attack Mitigation
Analyzing Zone Traffic Patterns
We recommend that once the current attack ends, you allow the Guard module to learn the zone traffic patterns if the zone is an on-demand zone configuration using default parameters or if the zone traffic characteristics have changed since the last time the Guard module learned the zone traffic.
Use the show rates command to display the current zone traffic rates. See the "Using Counters to Analyze Traffic" section for more information.
View the received traffic rate and follow these guidelines:
•If the received rate is zero, this rate indicates a diversion problem. See the "Recognizing a Traffic Diversion Problem" section for more information.
•If the received rate is greater than the legitimate rate, this rate indicates that the Guard module mitigation is functioning, and the following problems might exist:
–If the legitimate traffic rate for the zone is a lot higher than the zone traffic rate under normal traffic conditions, see the "Blocking Flows to the Zone Based on Flow Characteristics" section.
–If the legitimate traffic for the zone is a lot lower than the zone traffic rate under normal traffic conditions, see the "Verifying Traffic Blocking Criteria" section.
This section contains the following topics:
•Recognizing a Traffic Diversion Problem
•Blocking Flows to the Zone Based on Flow Characteristics
•Verifying Traffic Blocking Criteria
Recognizing a Traffic Diversion Problem
If the Guard module does not receive any packets, this condition may indicate a traffic diversion problem where the Guard module does not receive the traffic that is sent to the zone.
Verify that you have configured traffic diversion correctly. See Chapter 5 "Configuring Traffic Diversion," for more information.
Follow these guidelines to verify the traffic diversion configuration:
•Verify that you have configured the correct diversion routes. See the "Displaying the Diversion Routes" section for more information.
•Verify that the hijacking VLAN is not blocked. Ping the hijacking interface from the supervisor engine.
Blocking Flows to the Zone Based on Flow Characteristics
If the legitimate traffic rate for the zone is a lot higher than the zone traffic rate under normal traffic conditions, the Guard module might not be blocking all attack traffic. A high rate of legitimate traffic can occur if you did not allow the Guard module to learn the traffic patterns of a zone, such as when you use an on-demand zone configuration for zone protection (see the "Activating On-Demand Protection" section). If the Guard module does not know the zone traffic patterns, the policy thresholds may be too high for the specific zone.
To prevent the Guard module from forwarding unwanted flows to the zone, we recommend that you perform the following tasks:
•Lower the threshold of policies that measure traffic according to source IP addresses.
•View the legitimate traffic rate. If the legitimate traffic rate still seems too high, this condition could indicate a sophisticated, large-scale, zombie or client attack. Such attacks consist of many flows that do not differ in rate or in the number of connections from a regular flow. You can configure a flex-content filter to block such anomaly traffic flows. See the "Configuring Flex-Content Filters" section for more information.
To lower the policy thresholds, perform the following steps:
Step 1 Display the current policy thresholds by entering the following command in zone configuration mode:
See the "Displaying Policies" section for more information about the policies.
Step 2 Examine the zone global traffic by entering the following command in zone configuration mode:
show policies */*/*/*/global statistics
The Guard module displays the traffic flows with the highest rates that are forwarded to the zone, as measured by the protection policies. Determine whether or not the type of services and the volume represent the zone traffic. See the "Displaying Policy Statistics" section for more information about policy statistics.
Step 3 Examine the traffic of single users that are represented by a source IP address and determine which policies have a high threshold that should be decreased by entering the following command in zone configuration mode:
show policies */*/*/*/src_ip statistics
The Guard module displays the traffic flows with the highest rates forwarded to the zone, as measured by the protection policies. See the "Displaying Policy Statistics" section for more information about policy statistics.
Step 4 If the traffic volume does not represent the zone traffic, decrease the threshold of the source IP address policies by entering the following command in zone configuration mode:
policy */*/*/*/src_ip thresh-mult threshold-multiply-factor
The threshold-multiply-factor argument specifies the number by which to multiply the policy threshold. Enter a number less than 1 to decrease the policy threshold. For example, enter 0.5 to decrease the threshold by half. See the "Multiplying a Threshold by a Factor" section for more information.
Verifying Traffic Blocking Criteria
If the legitimate traffic rate seems too low, it could indicate that the Guard module is blocking access to the zone by legitimate clients. This condition could occur if the learning process was performed some time ago and the policy thresholds no longer fit the zone traffic pattern. The result is that the policy thresholds are not tuned properly and are set too low for current normal traffic patterns.
To verify and change the Guard module blocking criteria, perform the following steps:
Step 1 If you suspect that the Guard module is blocking access to the zone by legitimate clients, verify that dynamic filters are not blocking access from these clients by entering the following command in zone configuration mode:
show dynamic-filters [details]
The dynamic filters provide details on the policy that caused the production of the dynamic filters. See the "Displaying Dynamic Filters" section for more information.
Step 2 Identify the policies that caused the production of the dynamic filters and display the statistics of these policies. For example, examine the traffic of single users, represented by a source IP address. Determine which policies have a low threshold that should be increased by entering the following command in zone configuration mode:
show policies */*/*/*/src_ip statistics
The Guard module displays the traffic flows with the highest rates forwarded to the zone, as measured by the zone policies. See the "Displaying Policy Statistics" section for further information about policy statistics.
Step 3 If the traffic volume does not represent the zone traffic, increase the threshold by entering the following command in zone configuration mode:
policy */*/*/*/src_ip thresh-mult threshold-multiply-factor
The threshold-multiply-factor argument specifies the number by which to multiply the policy threshold. Enter a number greater than 1 to increase the policy threshold. For example, enter 2 to increase the threshold by 2. See the "Multiplying a Threshold by a Factor" section for more information.
Step 4 Display the list of dynamic filters. (See Step 1.) If the list of dynamic filters includes dynamic filters for IP addresses of legitimate clients with an action of drop, remove those dynamic filters by entering the following command in zone configuration mode:
no dynamic-filter filter-id
See the "Configuring Dynamic Filters" section for more information about dynamic filters.
Step 5 If the Guard module continues to produce drop-action dynamic filters from specific policies, deactivate these policies by entering the following command in policy configuration mode:
See the "Changing the Policy State" section for more information.
Tip If several policies that are part of the same policy branch produce drop-action dynamic filters, you can deactivate the policy branch by changing the policy state at the higher-level policy sections (such as policy template or service sections).
Step 6 Configure known client IP addresses that are crucial to proper zone functioning to bypass the Guard module protection functions so that the Guard module forwards these traffic flows directly to the zone. Create a bypass filter with the IP address of these clients by entering the following command in zone configuration mode:
bypass-filter row-num ip-address protocol dest-port fragments-flag
See the "Configuring Bypass Filters" section for more information.
Verifying Attack Mitigation
After you identify an attack on the zone, you can verify that the Guard module is mitigating the attack. This action is especially important if you are not familiar with the zone traffic patterns or if the zone is using an on-demand protection configuration ("Activating On-Demand Protection" section) and the Guard module did not learn the zone traffic patterns.
To verify attack mitigation, perform the following actions:
•Display the zone current attack report to analyze the attack statistical information. See the "Displaying the Zone Current Attack Report" section for more information.
•View the Guard module filters, counters, and statistics.
This section contains the following topics:
•Displaying the Zone Current Attack Report
•Displaying the Guard Module Advanced Statistics
•Displaying Dropped Traffic Statistics
Displaying the Zone Current Attack Report
You can display the report of an ongoing attack to learn more about the attack characteristics and the measures that the Guard module took to mitigate the attack by entering the show reports current command. See the "Displaying Attack Reports" section for more information.
The report provides you with details about the attack. The information includes when the attack started, a general analysis of the zone traffic flow, an analysis of the packets that were dropped and replied, details of the traffic anomalies that the Guard module detected in the zone traffic, and the steps the Guard module took to mitigate the attack. See the "Understanding the Report Layout" section for more information.
The report provides you with details about the two main classes of DDoS attack classifications as follows:
•Bandwidth depletion—Attacks designed to flood the zone with unwanted traffic that prevents legitimate traffic from reaching the zone. These attacks include spoofed attacks and malformed packets.
•Resource depletion—Attacks that are designed to tie up the resources of the zone.
See the "Mitigated Attacks" section for more information about the types of mitigated attack.
Displaying the Guard Module Advanced Statistics
You can view the Guard module filters, counters, and diagnostics to learn about the attack characteristics and the measures that the Guard module is taking to mitigate the attack. The Guard module advanced statistics includes the following information:
•Dynamic filters—Provide details about how the Guard module is handling the attack. To view the dynamic filters, use the show dynamic-filters command. See the "Displaying Dynamic Filters" section for more information.
•User filters—Define how to handle traffic flows that are suspected as DDoS attacks. The zone configuration includes a default set of user filters. You can add or delete user filters. To display the user filters, use the show command or the show running-config command. The Guard module displays the current traffic rate, measured for each user filter. See the "Displaying User Filters" section for more information.
•Statistics on dropped packets—Provide a list that details the distribution of dropped packets for the ongoing attack. To display the statistics about dropped packets, use the show drop-statistics command. See the "Displaying Dropped Traffic Statistics" section for more information.
•Zone rate history—Provides the rate that the Guard module measured for each counter in the past 24 hours and the details about the attack evolvement. To display the zone rate history, use the show rates history command. See the "Using Counters to Analyze Traffic" section for more information.
•Zone counters—Provides the number of packets that the Guard module measured for each counter and enables you to analyze the way the Guard module has handled the zone traffic since the attack was initiated. See the "Using Counters to Analyze Traffic" section for more information.
Displaying Dropped Traffic Statistics
You can view the distribution of dropped packets for an ongoing attack by entering the following command in configuration mode:
show drop-statistics
The Guard module displays the packets dropped by its protection functions by rate, packet, and bit units.
Table 15-1 provides the drop statistics.
Table 15-1 Drop Statistics
Drop Statistics
|
Description
|
Total dropped
|
Total amount of dropped traffic.
|
Dynamic filters
|
Amount of traffic dropped by the dynamic filters.
|
User filters
|
Amount of traffic dropped by the user filters.
|
Flex-Content filters
|
Amount of traffic dropped by the flex-content filters.
|
Rate limit
|
Packets that are defined by the rate limit parameter of the user filters and the zone rate-limit command that were dropped.
|
Incoming TCP unauthenticated basic
|
Traffic that the TCP basic anti-spoofing functions could not authenticate and dropped. In the attack reports, these packets are counted under the spoofed packets in the Malicious Packets Statistics table.
|
Incoming TCP unauthenticated-strong
|
Traffic that the TCP strong anti-spoofing functions could not authenticate and dropped. In the attack reports, these packets are counted under the spoofed packets in the Malicious Packets Statistics table.
|
Outgoing TCP unauthenticated
|
Zone-initiated-connections traffic that the TCP anti-spoofing functions could not authenticate and dropped. In the attack reports, these packets are counted under the spoofed packets in the Malicious Packets Statistics table.
|
UDP unauthenticated-basic
|
UDP traffic that the basic anti-spoofing functions could not authenticate and dropped. In the attack reports, these packets are counted under the spoofed packets in the Malicious Packets Statistics table.
|
UDP unauthenticated-strong
|
UDP traffic that the strong anti-spoofing functions could not authenticate and dropped. In the attack reports, these packets are counted under the spoofed packets in the Malicious Packets Statistics table.
|
Other protocols unauthenticated
|
Non-TCP and non-UDP traffic that the Guard anti-spoofing functions could not authenticate and dropped. In the attack reports, these packets are counted under the spoofed packets in the Malicious Packets Statistics table.
|
TCP fragments unauthenticated
|
TCP fragmented packets that the Guard anti-spoofing functions could not authenticate and dropped. In the attack reports, these packets are counted under the spoofed packets in the Malicious Packets Statistics table.
|
UDP fragments unauthenticated
|
UDP fragmented packets that the Guard anti-spoofing functions could not authenticate and dropped. In the attack reports, these packets are counted under the spoofed packets in the Malicious Packets Statistics table.
|
Other protocols fragments unauthenticated
|
Non-TCP and non-UDP fragmented packets that the Guard anti-spoofing functions could not authenticate and dropped. In the attack reports, these packets are counted under the spoofed packets in the Malicious Packets Statistics table.
|
DNS malformed replies
|
Malformed DNS replies that the Guard protection functions dropped. In the attack reports, these packets are counted under the malformed packets in the Malicious Packets Statistics table.
|
DNS spoofed replies
|
DNS packets that are coming in response to zone-initiated connections that the Guard anti-spoofing functions dropped. In the attack reports, these packets are counted under the spoofed packets in the Malicious Packets Statistics table.
|
DNS short queries
|
Short (malformed) DNS queries that the Guard protection functions dropped. In the attack reports, these packets are counted under the malformed packets in the Malicious Packets Statistics table.
|
Non DNS packets to/from DNS port
|
Non-DNS traffic destined to a DNS port or from a DNS port that the Guard protection functions dropped. In the attack reports, these packets are counted under the malformed packets in the Malicious Packets Statistics table.
|
Bad packets to proxy addresses
|
Malformed traffic destined to the Guard module proxy IP address that the Guard protection functions dropped.
|
TCP anti-spoofing features related pkts
|
Number of dropped packets due to side operations that the Guard module TCP anti-spoofing functions performed. In the attack reports, these packets are counted under the malformed packets in the Malicious Packets Statistics table.
|
DNS anti-spoofing features related pkts
|
Number of dropped packets due to side operations that the Guard module DNS anti-spoofing functions performed. In the attack reports, these packets are counted under the malformed packets in the Malicious Packets Statistics table.
|
Anti-spoofing internal errors
|
Number of packets dropped due to the Guard module anti-spoofing function errors. In the attack reports, these packets are counted under the Packets table.
|
SIP anti-spoofing features related pkts
|
Number of SIP1 over UDP packets that the Guard module dropped due to side operations. In the attack reports, these packets are counted under the spoofed packets in the Malicious Packets Statistics table.
|
SIP malformed packets
|
SIP over UDP packets that the Guard protection functions dropped because they were malformed. In the attack reports, these packets are counted under the malformed packets in the Malicious Packets Statistics table.
|
Land attack
|
Number of packets dropped because they had identical source and destination IP addresses. In the attack reports, these packets are counted under the malformed packets in the Malicious Packets Statistics table.
|
Malformed packets
|
Number of packets dropped due to a malformed header in which the port, protocol, or IP field in the header equals zero (0). In the attack reports, these packets are counted under the malformed packets in the Malicious Packets Statistics table.
|
The following example shows how to display the drop statistics:
user@GUARD-conf-zone-scannet# show drop-statistics