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
Viewing the Zone Current Attack Report
Viewing the Guard Module Advanced Statistics
Viewing Dropped Traffic Statistics
Analyzing Guard Module Mitigation
This chapter provides guidelines on how to analyze the Guard module mitigation and the zone traffic, and how to identify configuration problems. It provides a brief explanation on 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 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 "Analyzing the Zone Traffic" section for further details.
View the received traffic rate:
•If the received rate is zero, this indicates a diversion problem. See the "Diversion Problem" section for further details.
•If the received rate is greater than the legitimate rate, this indicates that the Guard module mitigation is functioning:
–If the legitimate traffic rate is too high for the zone traffic as you know it, see the "Blocking Flows to the Zone Based on Flow Characteristics" section.
–If the legitimate traffic is too low for the zone traffic as you know it, see the "Verifying Traffic Blocking Criteria" section.
Diversion Problem
If the Guard module does not receive any packets, this may indicate a diversion problem. The Guard module does not receive the traffic that is sent to the zone.
Verify that you configured diversion correctly. See "Configuring Zone Traffic Diversion" for further details.
Use the following guidelines:
•Verify that you have configured the correct diversion routes. See the "Displaying the Diversion routes" section for further details.
•Verify that the hijacking VLAN is not blocked. Ping the hijacking interface from the supervisor.
Blocking Flows to the Zone Based on Flow Characteristics
If the legitimate traffic rate seems too high according to the zone traffic characteristics as you know them, it could imply that the Guard module is not blocking all the attack traffic. This could 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.
We recommend that you perform the following actions:
•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 could indicate a sophisticated, large scale, zombie or client attack. Such attacks consist of many flows that do not differ in rate or the number of connections from a regular flow. You can configure a Flex filter to block such anomaly traffic flows. See the "Configuring the Flex Filter" section for further details.
To lower the thresholds of policies, perform the following steps:
Step 1 View the current policy thresholds. Enter the following command in the relevant zone configuration mode:
See the "Viewing Policies" section for further details on the policies.
Step 2 Examine the zone global traffic. Enter the following command:
show policies statistics */*/*/*/global
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 the type of services and volume represent the zone traffic. See the "Viewing Policy Statistics" section for further information on policy statistics.
Step 3 Examine the traffic of single users, represented by a source IP address. Determine which policies have a high threshold that should be decreased. Enter the following command:
show policies statistics */*/*/*/src_ip
The Guard module displays the traffic flows with the highest rates forwarded to the zone, as measured by the protection policies. See the "Viewing Policy Statistics" section for further information on policy statistics.
Step 4 If the traffic volume does not represent the zone traffic, decrease the threshold of the source IP address policies. Enter the following command:
policy */*/*/*/src_ip thresh-mult threshold-multiply-factor
The threshold-multiply-factor argument 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 further details.
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 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 Guard module Dynamic filters are not blocking access from these clients. Enter the following command:
show dynamic-filters [details]
See the "Viewing Dynamic Filters" section for further details on Dynamic filters. The Dynamic filters provide details on the policy that caused the production of the Dynamic filters.
Step 2 View 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. Enter the following command:
show policies statistics */*/*/*/src_ip
The Guard module displays the traffic flows with the highest rates forwarded to the zone, as measured by the protection policies. See the "Viewing Policy Statistics" section for further information on policy statistics.
Step 3 If the traffic volume does not represent the zone traffic, increase the threshold. Enter the following command in the relevant zone configuration mode:
policy */*/*/*/src_ip thresh-mult threshold-multiply-factor
The threshold-multiply-factor argument 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 further details.
Step 4 View 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. Enter the following command:
no dynamic-filter filter-id
See the "Configuring Dynamic Filters" section for further details on Dynamic filters.
Step 5 If the Guard module continues to produce drop-action Dynamic filters from specific policies, deactivate these policies. Enter the following command:
See the "Changing the Policy State" section for further details.
Tip If several policies that are part of the same policy branch, produce drop-action Dynamic filters, you can deactivate the policy branch.
Step 6 Configure known client IP addresses that are crucial to proper zone functioning to bypass the Guard module protection mechanisms. Add the IP address of these clients to the Bypass filter. The Guard module forwards these traffic flows directly to the zone. Enter the following command:
bypass-filter row-num ip-address protocol dest-port fragments-flag
See the "Configuring Bypass Filters" section for further details.
Verifying Attack Mitigation
After you have identified an attack on the zone, you can verify that the Guard module is mitigating the attack. This is especially important if you are not familiar with the zone traffic patterns or the zone is in on-demand protection and the Guard module did not learn the zone traffic patterns.
You can perform the following:
•View the zone current attack report. See the "Viewing the Zone Current Attack Report" section for further details.
•View the Guard module filters, counters and statistics. This requires in-depth knowledge of the Guard module operation and mechanisms.
Viewing the Zone Current Attack Report
You can view the report of an ongoing attack to gain knowledge on the attack characteristics and the measures the Guard module took to mitigate the attack.
Use the show reports current command to view the attack report of an ongoing attack. See the "Viewing Attack Reports" section for further details.
The report provides you with details on 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 the Guard module detected in the zone traffic and the steps the Guard module took to protect the zone (mitigate the attack). See the "Report Layout" section for further details.
The report provides you with details on 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 further details on the types of mitigated attack.
Viewing the Guard Module Advanced Statistics
You can view the Guard module filters, counters and diagnostics to gain further knowledge on the attack characteristics and the measures the Guard module took to mitigate the attack. These procedures require in-depth knowledge of the Guard module operation and mechanisms.
You can view:
•Dynamic filters—These filters provide the details on how the Guard module is handling the attack. To view the Dynamic filters, use the show dynamic-filters command. See the "Viewing Dynamic Filters" section for further details.
•User filters—These filters define how to handle traffic flows suspected as DDoS attacks. The zone configuration includes a default set of User filters. You can add or delete User filters. To view 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 "Viewing the User Filters" section for further details.
•Statistics on dropped packets—These statistics provide a list with the distribution of dropped packets for the ongoing attack. To view the statistics on dropped packets, use the show drop-statistics command. See the "Viewing Dropped Traffic Statistics" section for further details.
•Zone rate history—This list provides the rate that the Guard module measured for each counter in the past 24 hours thus providing details on the attack evolvement. To view the zone rate history, use the show rates history command. See the "Viewing Zone Counters" section for further details.
•Zone counters—This list provides the number of packets that the Guard module measured for each counter thus enabling you to analyze the way the Guard module has handled the zone traffic since the attack was initiated. See the "Viewing Zone Counters" section for further details.
Viewing Dropped Traffic Statistics
You can view the distribution of dropped packets for an ongoing attack. The Guard module displays the packets dropped by its protection mechanisms by rates, packets and bits units.
Enter the following command:
show drop-statistics
Table 12-1 provides the drop statistics.
Table 12-1 Drop Statistics
Type
|
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 filter
|
The amount of traffic dropped by the Flex filter.
|
Rate limit
|
Specifies packets that were dropped by the zone Rate Limiting protection module. These packets are defined by User filters rate limit parameter and the zone rate-limit command.
|
Incoming TCP unauthenticated basic
|
The traffic that the TCP basic anti-spoofing mechanisms dropped because they could not be authenticated. 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 mechanisms dropped because they could not be authenticated. 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 mechanisms dropped because they could not be authenticated. 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 mechanisms dropped because they could not be authenticated. 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 mechanisms dropped because they could not be authenticated. 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 mechanisms dropped because they could not be authenticated. 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 mechanisms dropped because they could not be authenticated. 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 mechanisms dropped because they could not be authenticated. 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 mechanisms dropped because they could not be authenticated. 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 mechanisms 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 mechanisms 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 mechanisms 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 mechanisms 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 mechanisms dropped.
|
TCP anti-spoofing mechanisms related pkts
|
The number of dropped packets due to side-operations of the Guard module TCP anti-spoofing mechanisms. 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 mechanisms. 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 mechanisms 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.
|
For example:
admin@GUARD-conf-zone-scannet# show drop-statistics
