Table Of Contents
Analyzing Guard Module Mitigation
Analyzing Zone Traffic Patterns
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 provides guidelines on 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 includes the following sections:
•
Analyzing Zone Traffic Patterns
•Verifying Attack Mitigation
Analyzing Zone Traffic Patterns
Prior knowledge of normal traffic rates for the zone helps you to recognize abnormal traffic to the zone.
We highly recommend that once the current attack ends, you let the Guard module learn the zone traffic patterns if this is an on-demand zone or if the zone traffic characteristics have changed since you last issued the learning process.
Use the show rates command to display the current zone traffic rates. See the "Displaying Zone Counters" section for more information.
View the received traffic rate and consider the following guidelines:
•If the received rate is zero, this rate indicates a diversion problem. See the "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 is for the zone is a lot lower than the zone traffic rate under normal traffic conditions, see the "Verifying Traffic Blocking Criteria" section.
Diversion Problem
If the Guard module does not receive any packets, this condition may indicate a diversion problem. The Guard module does not receive the traffic that is sent to the zone.
Verify that you have configured diversion correctly. See "Configuring Traffic Diversion," for more information.
Use the following guidelines to verify the 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, it could imply that the Guard module is not blocking all attack traffic. This situation can happen with on-demand zones for which the learning process was not performed. In such cases, the on-demand 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 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 thresholds of policies, 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 on 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, 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 imply that the Guard module is blocking access to the zone from 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 too low.
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 from 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 two. 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 have identified 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 in on-demand protection and the Guard module did not learn the zone traffic patterns.
To verify attack mitigation, perform the following actions:
•View the zone current attack report. See the "Displaying the Zone Current Attack Report" section for more information.
•View the Guard module filters, counters and statistics. This actions requires in-depth knowledge of the Guard module operation and functions.
Displaying the Zone Current Attack Report
You can display the report of an ongoing attack to gain knowledge of 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 protect the zone (mitigate the attack). See the "Understanding the Report Layout" section for more information.
The report provides you with details about the attack classification. DDoS attacks are divided into two main classes:
•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 gain additional knowledge about the attack characteristics and the measures that the Guard module took to mitigate the attack. These procedures require in-depth knowledge of the Guard module operation and functions.
You can view the following information to gain knowledge about attack characteristics and the mitigation measures that the Guard module took:
•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—This list provides the rate that the Guard module measured for each counter in the past 24 hours and provides details about the attack evolvement. To display the zone rate history, use the show rates history command. See the "Displaying Zone Counters" section for more information.
•Zone counters—This list 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 "Displaying Zone Counters" 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 rates, packets, and bits units.
Table 13-1 provides the drop statistics.
Table 13-1 Drop Statistics
Drop Statistics
|
Description
|
Total dropped
|
The total amount of dropped traffic.
|
Dynamic filters
|
The amount of traffic dropped by the dynamic filters.
|
User filters
|
The amount of traffic dropped by the user filters.
|
Flex-Content filter
|
The amount of traffic dropped by the flex-content filters.
|
Rate limit
|
Specifies packets, which are defined by the user filters rate limit parameter and the zone rate-limit command, that were dropped.
|
Incoming TCP unauthenticated basic
|
The traffic that the TCP basic anti-spoofing functions could not authenticate and therefore dropped. In the attack reports, these packets are counted under the spoofed packets in the Dropped/Replied Packets table.
|
Incoming TCP unauthenticated-strong
|
The traffic that the TCP strong anti-spoofing functions could not authenticate and therefore dropped. In the attack reports, these packets are counted under the spoofed packets in the Dropped/Replied Packets table.
|
Outgoing TCP unauthenticated
|
The zone-initiated-connections traffic that the TCP anti-spoofing functions could not authenticate and therefore dropped. In the attack reports, these packets are counted under the spoofed packets in the Dropped/Replied Packets table.
|
UDP unauthenticated-basic
|
The UDP traffic that the basic anti-spoofing functions could not authenticate and therefore dropped. In the attack reports, these packets are counted under the spoofed packets in the Dropped/Replied Packets table.
|
UDP unauthenticated-strong
|
The UDP traffic that the strong anti-spoofing functions could not authenticate and therefore dropped. In the attack reports, these packets are counted under the spoofed packets in the Dropped/Replied Packets table.
|
Other protocols unauthenticated
|
Traffic, other than TCP and UDP traffic, that the Guard anti-spoofing functions could not authenticate and therefore dropped. In the attack reports, these packets are counted under the spoofed packets in the Dropped/Replied Packets table.
|
TCP fragments unauthenticated
|
TCP fragmented packets that the Guard anti-spoofing functions could not authenticate and therefore dropped. In the attack reports, these packets are counted under the spoofed packets in the Dropped/Replied Packets table.
|
UDP fragments unauthenticated
|
UDP fragmented packets that the Guard anti-spoofing functions could not authenticate and therefore dropped. In the attack reports, these packets are counted under the spoofed packets in the Dropped/Replied Packets table.
|
Other protocols fragments unauthenticated
|
Fragmented packets, other than TCP and UDP fragmented packets, that the Guard anti-spoofing functions could not authenticate and therefore dropped. In the attack reports, these packets are counted under the spoofed packets in the Dropped/Replied Packets 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 Dropped/Replied Packets table.
|
DNS spoofed replies
|
DNS packets 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 Dropped/Replied Packets 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 Dropped/Replied Packets table.
|
NON DNS packets to DNS port
|
Non-DNS traffic destined to a DNS port that the Guard protection functions dropped. In the attack reports, these packets are counted under the malformed packets in the Dropped/Replied Packets 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 mechanisms related pkts
|
The number of dropped packets due to side-operations of the Guard module TCP anti-spoofing functions. In the attack reports, these packets are counted under the malformed packets in the Dropped/Replied Packets table.
|
DNS anti-spoofing mechanisms related pkts
|
The number of packets dropped packets due to side-operations of the Guard module DNS anti-spoofing functions. In the attack reports, these packets are counted under the malformed packets in the Dropped/Replied Packets table.
|
Anti-spoofing internal errors
|
The number of packets dropped due to the Guard module anti-spoofing functions errors. In the attack reports, these packets are counted under Packets table.
|
Land attack
|
The 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 Dropped/Replied Packets table.
|
Malformed packets
|
The 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 Dropped/Replied Packets table.
|
The following example shows how to display the drop statistics:
user@GUARD-conf-zone-scannet# show drop-statistics
