Table Of Contents
Analyzing Guard 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 Advanced Statistics
Viewing Dropped Traffic Statistics
Analyzing Guard Mitigation
This chapter provides guidelines on how to analyze the Guard mitigation and the zone traffic, and how to identify configuration problems. It provides a brief explanation on how to identify the type of attack. The 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 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 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 does not receive any packets, this may indicate a diversion problem. The Guard does not receive the traffic that is sent to the zone.
See "Diversion Configuration" and "Diversion Troubleshooting" for further details.
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 is not blocking all the attack traffic. This could happen with on-demand zones for which learning was not performed. In such cases, the on-demand policy thresholds might be too high for the specific zone.
We recommend that you perform the following:
•Lower the threshold of policies that measure traffic according to source IP addresses.
•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 at the relevant zone prompt:
See the "Viewing Policies" section for further details on Dynamic filters.
Step 2 Examine the zone traffic. Enter the following command:
show policies statistics */*/*/*/global
The Guard 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 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. Enter the following command:
policy */*/*/*/src_ip thresh-mult threshold-multiply-factor
The argument threshold-multiply-factor is a factor less than 1, by which 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 is blocking access to the zone from legitimate clients. This could occur if learning 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 blocking criteria, perform the following steps:
Step 1 If you suspect that the Guard is blocking access to the zone from legitimate clients, verify that Guard 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 Dyanmic 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 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 at the relevant zone prompt:
policy */*/*/*/src_ip thresh-mult threshold-multiply-factor
The argument threshold-multiply-factor is a number greater than 1 by which to increase the policy threshold. 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 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 protection mechanisms. Add the IP address of these clients to the Guard Bypass filter. See the "Configuring Bypass Filters" section for further information on Bypass filters. The Guard 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 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 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 filters, counters and statistics. This requires in-depth knowledge of the Guard 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 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 detected in the zone's traffic and the steps the Guard 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 Advanced Statistics
You can view the Guard filters, counters and diagnostics to gain further knowledge on the attack characteristics and the measures the Guard took to mitigate the attack. These procedures require in-depth knowledge of the Guard operation and mechanisms.
You can view:
•Dynamic filters—These filters provide the details on how the Guard 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 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 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 measured for each counter thus enabling you to analyze the way the Guard 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 displays the packets dropped by its protection mechanisms by rates, packets and bits units.
Enter the following command:
show drop-statistics
Table 11-1 provides the drop statistics.
Table 11-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
|
The amount of traffic dropped by the rate limiter.
|
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 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 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 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 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 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
