Table Of Contents
Zone Statistics and Diagnostics
Zone Counters
Analyzing Traffic
Analyzing Problems
Zone Event Log
Zone Protection Summary Report
Protection Graph
Total Attack Statistics
Per Attack Summary
Zone Attack Reports
General Details
Attack Statistics
Dropped/Bounced Packets
Detected Anomalies
Detected Anomalies Details
Mitigated Attacks
Mitigated Attack Details
HTTP Detected Zombies
HTTP Zombies
Viewing Policy Statistics
Drop Statistics
Zone Statistics and Diagnostics
This chapter describes how to perform tasks used for monitoring zones and displaying various zone statistics and diagnostics on the Cisco Anomaly Guard Module using Web-Based Management (WBM).
This chapter includes the following sections:
•
Zone Counters
•Zone Event Log
•Zone Protection Summary Report
•Zone Attack Reports
•HTTP Zombies
•Viewing Policy Statistics
•Drop Statistics
Zone Counters
The zone counters (Figure 8-1) enable you to analyze the zone traffic in order to verify the zone status and to determine whether the zone protection is functioning properly. You can view the zone counters for a configurable period of time as a graph to see how zone protection is evolving. The information relates to the current zone.
To view the zone counters, choose the relevant zone and choose Diagnostics > Counters from the zone main menu.
The following counters appear:
•Legitimate—Legitimate traffic forwarded by the Guard module to the zone.
•Malicious—Malicious traffic destined to the zone. Malicious traffic is the sum of dropped packets and spoofed packets (which also include zombie packets).
•Received—Total packets received and handled by the Guard module. Received packets are the sum of legitimate traffic and malicious traffic.
•Dropped—Packets that were identified by the Guard module as part of an attack, and therefore dropped.
•Replied—Packets to which replies were sent to the initiating client as part of the anti-spoofing or anti-zombie mechanisms in order to verify whether they are part of authentic traffic or part of an attack.
•Spoofed—Packets that were identified by the Guard module as spoofed packets and therefore not forwarded to the zone. Spoofed packets are replied (bounced) packets (see Replied counter above for further details) for which no replies were received. Zombie packets are also included in the spoofed packets counter.
Figure 8-1 Zone Counters
The following information is available for each of the counters:
•Shown in Graph—Specifies whether the counter is displayed in the graph.
•Packets—Total number of packets destined to the zone since last activation.
•Bits—Total number of bits destined to the zone since last reload.
•pps—Current traffic rate destined to the zone, measured in packets per second.
•bps—Current traffic rate destined to the zone, measured in bits per second.
By default, Legitimate and Malicious traffic counters are displayed for a period of the last two hours and are measured in bits per second (bps).
To change the graph settings, perform the following steps:
Step 1 Check the boxes of the counters to display in the graph.
Step 2 Select a time period for the graph from the drop-down list.
Step 3 Select a type from the drop-down list to specify the traffic rate units.
Step 4 Click Update Graph to update the graph with the new settings.
A legend identifying the counters appears below the graph and the minimum, maximum and average rates for each counter are displayed for the time period and rate units selected.
Analyzing Traffic
It is important to analyze the traffic flow in order to determine whether traffic is flowing properly to the zone. The following section provides information to help you analyze the traffic flow, indicating possible problems and their solutions:
•If the number of received and legitimate (forwarded to the zone) packets is greater than zero, this indicates that the Guard module diversion mechanism is functioning properly.
•If the number of received packets is greater than the number of legitimate packets, and the number of malicious packets is greater than zero, this indicates that protection is functioning properly. This is not an absolute indicator and you can also look at the Dynamic filters.
•If the number of received packets is greater than the number of legitimate packets and Dynamic filters are produced, this indicates that the Guard module has identified an attack.
Based on your work experience and knowledge of the network traffic, pay attention to the following:
•If there are dropped packets, you should verify whether a trusted IP source is blocked by a Dynamic filter. You might wish to have that source IP bypass the Guard module filters. See the "Configuring Bypass Filters" section for further details.
•If a policy has produced filters that drop too many IP flows, you should verify whether filters are blocking flows from source IP addresses that seem legitimate but are sending traffic at rates above the thresholds. In such a situation, you might wish to increase the policy's threshold or prevent its further production by deactivating it. See the "Zone Policies" section for further details.
•If the current rate (pps and bps) of received packets= 0, or the number of legitimate packets remains constant over a long period of time, see the "Analyzing Problems" section.
Analyzing Problems
If the received counters (packets or bits) or legitimate counters (packets or bits) equal 0, this could indicate a problem. The problem could be due to either one, or both, of the following:
•The Guard module does not receive the packets destined to the zone (received counters = 0)—This indicates a diversion problem or a network configuration problem. Refer to the Cisco Anomaly Guard Module Configuration Guide for further details.
•The Guard module receives the zone diverted traffic packets but blocks them from being forwarded to the zone (received counters > 0 and legitimate current rate (pps or bps) = 0 over a period of time)—This may indicate legitimate traffic was falsely identified as malicious traffic and is being dropped.
The example shown in Figure 8-2 describes a situation in which almost all the traffic destined to the zone is dropped. You should scan the Dynamic filters the Guard module produced for a drop-action filter and consider the following suggestions:
•Erase the drop-action Dynamic filter.
•Deactivate the protection policy that produced the drop-action Dynamic filter so that no policies of the kind that produced the drop-action Dynamic filter can be reproduced. If you do not take this action, the drop-action filter will reappear.
Figure 8-2 Problem analysis: Rcv >0, Legitimate = 0
Caution Deactivating the protection policy that produced the Dynamic filter compromises the zone protection.
This kind of problem can occur in the following situations:
•The protected zone receives no traffic.
•The Guard module identifies all the traffic destined to the zone as malicious.
Tips These situations are more likely to occur in a laboratory setup and are less likely to occur in real-life networks.
Zone Event Log
The zone event log (Figure 8-3) provides useful monitoring and troubleshooting information.
To view the zone event log, choose Diagnostics > Event log from the zone main menu.
Figure 8-3 Zone Event Log
Table 8-1 describes the different severity levels.
Table 8-1 Event Log Severity Levels
Event Level
|
Description
|
Emergencies
|
System is unusable
|
Alerts
|
Immediate action required
|
Critical
|
Critical condition
|
Errors
|
Error condition
|
Warnings
|
Warning condition
|
Notifications
|
Normal but significant condition
|
Informational
|
Informational messages
|
Debugging
|
Debugging messages
|
To filter the events according to their severity level, check the boxes for the requested severity levels and click Filter Events.
Only those events with the requested severity levels appear.
Zone Protection Summary Report
The Guard module provides a protection summary report for each zone to help form a clearer picture of the detected attacks on the zone. It summarizes the DDoS attacks on the zone during a user-defined period of time. The Guard module records the relevant details during attacks and organizes the data into different categories. The report gives details of the total number and intensity of the attacks, and a short summary for each of the attacks. The data is also presented graphically.
To view the zone protection summary report choose Diagnostics > Attack Reports from the zone main menu.
The zone protection summary report appears. It includes data fields and tables that are grouped in three sections:
•Protection Graph
•Total Attack Statistics
•Per Attack Summary
By default, the report is displayed for a period of the last month.
To change the time period of a protection summary report, perform the following steps:
Step 1 In the report, enter the Period from and to dates. You can enter the dates manually or click on the calendar icon (at the right of each field) and select a date.
Step 2 Click Get Reports.
Protection Graph
The protection graph provides a graphical summary of the attacks during the user-defined period of time.
Figure 8-4 Zone Protection Summary Report—Protection Graph
The X-axis displays the time over which the attack occurred. The Y-axis displays the average attack rate in packets per second (pps). Each attack is represented by a bar. If you hold your mouse over any of the attack bars for a few seconds, the average attack rate is displayed.
Note Click on the attack bar to access the attack report (see the"Zone Attack Reports" section).
Total Attack Statistics
The total attack statistics table (Figure 8-5) provides information on the number of attacks on the zone and the aggregated attack details during the period of time you defined.
Figure 8-5 Zone Protection Summary Report—Total Attack Statistics
Table 8-2 describes the fields in the report.
Table 8-2 Field Descriptions for Total Attack Statistics Report
Field
|
Description
|
Attacks Mitigated
|
The number of attacks mitigated.
|
Attacks Duration
|
The aggregated duration of the mitigated attacks.
|
Max. Traffic Rate
|
The maximum rate of malicious traffic destined to the zone.
|
Total Rx
|
The total amount of traffic destined to the zone.
|
Total Blocked
|
The total amount of traffic destined to the zone, that was dropped by the Guard module.
|
Legitimate vs. Malicious Traffic
|
A pie chart that displays the percentage of malicious traffic (displayed in red), and legitimate traffic (displayed in blue) in the total zone traffic.
|
Per Attack Summary
The Per Attack Summary provides a table with a list of the DDoS attacks on the zone during the time period you defined.
Figure 8-6 Zone Protection Summary Report—Per Attack Summary
Table 8-3 describes the fields in the columns of the table.
Table 8-3 Field Descriptions for Summary Report
Field
|
Description
|
#
|
The identification number (ID) of the mitigated attack.
|
Start time
|
The date and time of the mitigated attack.
|
Duration
|
The duration of the mitigated attack in hours, minutes, and seconds.
|
Type
|
The type of mitigated attack. Possible values are:
•Client Attack—All non-spoofed traffic anomalies.
•Malformed Packets—All traffic anomalies identified as consisting of maliciously malformed packets.
•Spoofed—Traffic anomalies identified as a DDoS attack coming from a spoofed source.
•User Defined—All anomalies handled by the user filters. These can either function by default or be user configured.
•Zombie—Traffic anomalies identified as having been originated by zombies.
•Hybrid—An attack made up of several attacks with different characteristics.
•Traffic Anomaly—An anomaly that was only detected for a short period of time and therefore did not require mitigation.
|
Peak (pps)
|
The maximum attack rate measured in packets per second.
|
Received Pkts
|
The total number of packets destined to the zone that was handled by the Guard module during the attack.
|
Legitimate vs. Malicious Traffic
|
A pie chart that displays the percentage of malicious traffic (displayed in red), and legitimate traffic (displayed in blue) in the total traffic during the attack.
|
Note Click in any of the fields to access the attack report (see "Zone Attack Reports" section).
Zone Attack Reports
The Guard module provides an attack report for every zone to help form a clearer picture. The attack report gives details of the attack, starting with the production of the first Dynamic filter, and ending with protection termination (either by a user decision or by the action of a timeout parameter).
The Guard module records the relevant details during an attack and organizes the data into categories. Attack reports are available for both past attacks and the current attack.
To view a zone attack report, perform these steps:
Step 1 Select the relevant zone.
Step 2 Select Diagnostics > Attack Reports from the zone main menu.
Step 3 To view details of the attack:
•Click on the attack bar in the "Protection Graph"
OR
•Click on any of the fields for the attack in the "Per Attack Summary" table.
Note When an attack is in progress, a Report button is displayed on the home page for the zone under attack.
To view the current attack report:
•Click Report on the zone home page
OR
•Select Diagnostics > Attack Reports from the zone main menu and click on any of the fields for the attack in progress in the "Per Attack Summary" table.
The attack report includes data fields and tables, grouped together in sections:
•General Details
•Attack Statistics
•Dropped/Bounced Packets
•Detected Anomalies
•Mitigated Attacks
•HTTP Detected Zombies
General Details
The first section of the report (Figure 8-7) provides information related to the timing of the attack. It includes information on when the attack started, when it ended, and how long it lasted.
To view more details of the report, click i or Show details for all events.
Figure 8-7 Attack Report—General Details
All counters are integers except for rate. You can select the statistics units from the drop-down list.
To change the statistic units, choose the units from the drop-down list and click Set units.
Attack Statistics
The attack statistics table (Figure 8-8) provides information on the following packet types:
•Received—Traffic received by the Guard module destined to the zone.
•Forwarded—The clean and legitimate traffic forwarded to the zone.
•Replied—Traffic sent to the client as part of the Guard module anti spoofing and anti-zombie modules.
•Dropped—The total number of packets destined to the zone and dropped by the Guard module.
Figure 8-8 Attack Report—Attack Statistics
Table 8-5 describes the information for each packet type:
Table 8-5 Attack Statistics
Field
|
Description
|
Total
|
The total number of packets in the category.
|
Max Rate
|
The maximum packet rate that was measured.
|
Average Rate
|
The average packet rate.
|
%
|
The number of packets as a percentage of the received packets.
|
The traffic rate is displayed in the units that were selected from the drop-down list in the "General Details" section.
Dropped/Bounced Packets
The Dropped/Bounced table (Figure 8-9) provides statistics for packets that were identified as malicious traffic and were dropped or replied (bounced). The packets are classified according to the mechanism that identified them.
Figure 8-9 Attack Report—Dropped/Bounced Packets
The following filters are displayed in the rows of the table:
•Rate Limiter—Packets dropped by the rate limiter of the zone or by filters for which a rate limit was configured. The rate limiter limits the traffic rate to the zone. See the section on "Managing Zones" section for further details.
•Flex filter—Packets dropped by the Flex filter. The Flex filter is used to count or drop a specific packet flow. See the section on"Configuring the Flex Filter" section for further details.
•User filter—Packets dropped by the User filters. The User filter is used to direct a specific traffic flow to the desired Guard module protection modules. See the section on "Configuring User Filters" section for further details.
•Dynamic filter—Packets dropped by the Dynamic filters. Dynamic filters are created by the Guard module as the result of the analysis of traffic flow. See the section on "Dynamic Filters" section for further details.
•Spoofed—Packets that were identified by the Guard module as spoofed packets or packets originated by zombies and therefore not forwarded to the zone. Spoofed packets are packets to which no replies were received.
•Malformed—Packets, destined to the zone and dropped because they were analyzed as malformed.
Table 8-6 describes the information that is available for each packet.
Table 8-6 Field Descriptions for Dropped/Bounced Packets
Field
|
Description
|
Total
|
The total number of dropped/bounced packets.
|
Max Rate
|
The maximum packet rate measured.
|
Average Rate
|
The average packet rate.
|
%
|
The number of packets as a percentage of the total dropped/bounced packets.
|
The traffic rate is displayed in the units that were selected from the drop-down list in the "General Details" section.
Detected Anomalies
The Detected Anomalies table (Figure 8-10) provides details of the anomalies the Guard module detected in the zone traffic. A flow is classified as being an anomaly when it requires the production of a Dynamic filter. These anomalies can occur infrequently or can turn into systematic DDoS attacks. The Guard module clusters anomalies with the same type and flow parameters (such as source IP address, destination port) under one anomaly type.
Figure 8-10 Attack Report—Detected Anomalies
The following information is provided for each anomaly:
Table 8-7 Field Descriptions for Detected Anomalies
Field
|
Description
|
#
|
The identification number (ID) of the detected anomaly.
|
Start time
|
The date and time the anomaly was detected.
|
Duration
|
The duration of the anomaly in hours, minutes, and seconds
|
Type
|
The type of the detected anomaly. Possible values are:
•Tcp_connections—A detected flow with unusual number of TCP concurrent connections, with or without data.
•HTTP—An unusual HTTP traffic flow.
•Tcp incoming—A detected flow attacking a TCP service when the zone is a server.
•Tcp outgoing—A detected attack flow in which the client appears to be the zone, such as SYN-ACK attacks on connections initiated by the zone when the zone is the client.
•Unauthenticated tcp—A detected flow that the Guard module anti-spoofing mechanisms have not succeeded in authenticating. For example, ACK flood, FIN flood or any other flood of unauthenticated packets.
•DNS (Udp)—An attacking DNS-UDP protocol flow.
•DNS (Tcp)—An attacking DNS-TCP protocol flow.
•Udp—An attacking UDP protocol flow.
•Non tcp/udp protocols—A non TCP/UDP attacking protocol flow.
•Fragments—A detected flow with an unusual amount of fragmented traffic.
•TCP ratio—A detected flow with an unusual ratio between different types of TCP packets (for example, SYN packets versus FIN/RST packets).
•IP scan—A detected flow initiated from a source IP address that tried to access many zone destination IP addresses.
•port scan—A detected flow initiated from a source IP address that tried to access many zone ports.
•user detected—An anomaly flow detected by user definitions.
|
Triggering rate
|
The anomaly traffic rate that violated a policy threshold.
|
% Threshold
|
The percentage by which the triggering rate is above the policy threshold.
|
Anomaly Flow
|
The anomaly traffic flow. The parameters of the common flow characteristics are displayed. The information includes parameters such as the anomaly protocol number, the destination IP address of the traffic flow and the flow packet type. If the anomaly flow is on a specific port, it is displayed as: dst=ip address:port
|
Details
|
Indicates whether additional information can be viewed for this filter. Click i for additional information.
|
A value of * for any of the parameters indicates one of the following:
•The value is undetermined.
•More than one value was measured for the anomaly's parameter.
A value of # for any of the parameters indicates the number of values measured for that anomaly's parameter.
Detected Anomalies Details
The detected anomalies details table provides additional information on the Dynamic filters that constitute the detected anomaly.To display the detected anomalies details table click i in the details column for the filter in the detected anomalies table.
The following information is provided:
Table 8-8 Field Descriptions for Detected Anomalies Details
Field
|
Description
|
Start time
|
The date and time the anomaly was detected.
|
End time
|
The expiration date and time of the Dynamic filter.
|
Rate (pps)
|
The rate measured in packets per second.
•Thresh—Indicates the policy threshold that was violated by the detected anomaly.
•Triggered—Indicates the anomaly traffic rate that violated a policy threshold.
|
Count
|
The number of packets that were handled by the Dynamic filter.
|
Detected flow
|
Provides the following information on the detected attack flow that caused the production of the Dynamic filter:
•Prot.—The protocol number.
•Src IP—The source IP.
•Src Port—The source port.
•Dst IP—The destination IP.
•Dst Port—The destination port.
•frag.—Indicates the fragmentation characteristics of the detected traffic flow.
•Type—The detected anomaly type. Refer to the
Cisco Anomaly Guard Module Configuration Guide for further details.
|
Action flow
|
Provides information on the action flow that was addressed by the Dynamic filter. The action flow can have a wider range than the detected flow. For example, the detected flow could indicate a specific source port for a specific source IP whereas the action flow could indicate all source ports for the specific source IP. The columns represent the dynamic filter traffic data.
•Prot.—The protocol number.
•Src IP—The source IP.
•Src Port—The source port.
•Dst IP—The destination IP.
•Dst Port—The destination port.
•frag.—Indicates the fragmentation characteristics of the action flow.
|
Mitigated Attacks
The Mitigated Attacks table (Figure 8-11) gives details of the actions the Guard module took against the traffic anomalies, described in the Detected Anomalies table, that proved to be a hazard for the zone. These actions can be anti-spoofing or anti-zombie mechanisms, user filters with a drop action, rate limit, and so forth. The Guard module groups mitigation actions with same types and flow parameters, and displays them together.
Figure 8-11 Attack Report—Mitigated Attacks
Table 8-9 Field Descriptions for Mitigated Attacks Table
Field
|
Description
|
#
|
The identification number (ID) of the mitigated attack.
|
Start time
|
The date and time of the mitigated attack.
|
Duration
|
The duration of the mitigated attack in hours, minutes, and seconds.
|
Attack Type
|
The type of the mitigated attack. Possible values are:
•Spoofed—Includes all traffic anomalies identified as a DDoS attack from a spoofed IP source.
•Client Attack— Includes all traffic anomalies identified as a DDoS attack from an unauthenticated source IP address.
•User Defined—Includes DDoS attacks identified by user defined filters and includes all packets dropped due to user definitions, such as anomalies handled by the User filters. See the "Configuring User Filters" section for further details.
•Zombie—Includes all traffic anomalies identified as a DDoS attack originated by zombies
•Malformed Packets—Includes all traffic anomalies identified as a DDoS attack consisting of maliciously malformed packets.
The protection module (basic or strong) is shown in brackets.
For a comprehensive overview of the sub-types of each attack type, refer to the Cisco Anomaly Guard Module Configuration Guide.
|
Triggering rate
|
The traffic rate of the mitigated attack. The triggering rate applies only for client attacks or user defined attacks. It does not apply for spoofed or malformed attacks.
|
% Threshold
|
The mitigated attack rate as a percentage of the policy threshold.
|
Anomaly Flow
|
The traffic flow of the anomaly that was mitigated. The parameters of the common flow characteristics are displayed. The information includes parameters such as the anomaly protocol number, the destination IP address of the traffic flow and the flow packet types.
|
Action flow
|
The traffic characteristics of the flow after the attack mitigation. The parameters of the common flow characteristics are displayed.
|
Dropped
|
The counter for traffic that was dropped during the attack mitigation.
|
Details
|
Indicates whether additional information can be viewed for this filter. Click i for additional information.
|
A value of * for any of the action flow or anomaly flow parameters indicates one of the following:
•The value is undetermined.
•More than one value was measured for the anomaly's parameter.
A value of # for any of the action flow or anomaly flow parameters indicates the number of values measured for that mitigated attack parameter.
Mitigated Attack Details
The mitigated attack details table provides additional information on the mechanisms that were used to mitigate the attack.
To display the mitigated attack details table click i in the details column for the filter in the mitigated attack table.
The following information is provided:
Table 8-10 Field Descriptions for Detailed Mitigated Attack Table
Field
|
Description
|
Start time
|
The date and time of the mitigated attack
|
End time
|
The expiration date and time of the Dynamic filter that was activated
|
Rate (pps)
|
The rate measured in packets per second.
•Thresh—Indicates the policy threshold that was violated by the mitigated attack
•Triggered—Indicates the anomaly traffic rate that violated a policy threshold
|
Count
|
The number of packets that were handled by the Dynamic filter
|
Detected flow
|
Provides the following information on the detected flow that was mitigated:
•Prot.—The protocol number.
•Src IP—The source IP address.
•Src Port—The source port.
•Dst IP—The destination IP address.
•Dst Port—The destination port.
•frag.—Indicates the fragmentation characteristics of the detected traffic flow.
•Type—The detected anomaly type. Refer to the Cisco Anomaly Guard Module Configuration Guide for further details.
|
Action flow
|
Provides information on the action flow that was addressed by the mitigation mechanism. The action flow can have a wider range than the detected flow. For example, the detected flow could indicate a specific destination port for a specific destination IP address, whereas the action flow could indicate all destination ports for the specific destination IP address. The columns represent the Dynamic filter traffic data.
•Prot.—The protocol number
•Src IP—The source IP address
•Src Port—The source port
•Dst IP—The destination IP address
•Dst Port—The destination port
•frag.—Indicates the fragmentation characteristics of the action flow
|
HTTP Detected Zombies
Indication that an HTTP zombie attack has been detected appears in the "General Details" section (see Figure 8-12).
Figure 8-12 HTTP Detected Zombies
To view the list of detected HTTP zombies, click i or Show HTTP detected zombies. See the "HTTP Zombies" section for further details.
HTTP Zombies
The HTTP Zombies list (Figure 8-13) enables you to analyze the zone traffic and view the list of zombies that initiated the attack. You can then take action against the zombies. To view the list of HTTP Zombies, choose Diagnostics > HTTP Zombies from the zone main menu.
Figure 8-13 HTTP Zombies list
Table 8-11 Field Descriptions for HTTP Zombies
Field
|
Description
|
IP
|
The zombie IP address
|
Start Time
|
The date and time the zombie connection was first identified
|
Duration
|
The duration of the zombie attack
|
"get" Requests
|
The number of HTTP "get" requests sent by the zombie
|
Viewing Policy Statistics
The policy statistics table (Figure 8-14) enables you to view the rate of the traffic flowing through each policy for a specific zone. This helps you to determine whether only legitimate traffic is passed to the zone and to manually tune thresholds.
To view the policy statistics table, choose Diagnostics > Policy Statistics from the zone main menu.
Figure 8-14
Policy Statistics Table
The policy statistics table displays the information in three sections. The information in each section is sorted by value, with the highest values appearing at the top:
•Rate—The rate of traffic flowing through the policy.
•Ratio—The ratio between the number of SYN flagged packets and the number of FIN/RST flagged packets. This information is available only for syn_by_fin policies.
•Connections—The number of concurrent connections or source IP addresses. This information is available for tcp_connections policies and the following packet types:
–in_nodata_conns for the Analysis protection module
–in_conns for the Strong protection module
For easier management, you can set screen filters to display only a partial list of the statistics available. To set a screen filter, click Set Screen Filter, choose the values of the parameters from the drop-down lists in the Policy Filter and click OK.
A partial list of the policies, meeting the criteria that you specified, appears. Details of the selected path and the maximum keys per policy appear in the Screen Filter frame.
Note If you change one of the parameters, all the parameters that are listed below it, are automatically cleared and you must enter new values.
Table 8-12 describes the policy statistics fields.
Table 8-12 Policy Statistics
Field
|
Description
|
Policy template
|
The policy template that was used to construct the policy.
|
Service
|
The services to which the policy relates.
|
Level
|
The protection module used to process the traffic flow. Possible values are Analysis, Basic, and Strong.
|
Type
|
The packet type. Possible values are:
•auth_pkts—Packets that underwent either TCP handshake or UDP authentication.
•auth_tcp_pkts—Packets that underwent TCP handshake.
•auth_udp_pkts—Packets that underwent UDP authentication.
•in_nodata_conns—Zone incoming connections that have no data transfer on the connection (packets without a data payload).
•in_conns—Zone incoming connections.
•in_pkts—Zone incoming DNS query packets.
•in_unauth_pkts—Zone incoming unauthenticated DNS queries.
•num_sources—Number of TCP source IP addresses, destined to the zone, that have been authenticated by the Guard module anti-spoofing mechanisms.
•out_pkts—Zone incoming DNS reply packets.
•reqs—Request packets with data payload.
•syns—Synchronization packets—TCP SYN flagged packets.
•syn_by_fin—SYN and FIN flagged packets. Verifies the ratio between the number of SYN flagged packets and the number of FIN flagged packets.
•unauth_pkts—Packets that did not undergo TCP handshake.
•pkts—All packet types that do not fall under any other category in the same protection level.
|
Policy
|
The policy.
|
Key
|
The key (traffic characteristics) that was used to aggregate the policies. Possible values are:
•dst_ip—Traffic destined to a zone IP address.
•dst_ip_ratio—The ratio of SYN and FIN flagged packets destined to a specific IP address.
•dst_port_ratio—The ratio of SYN and FIN flagged packets destined to a specific port.
•global—A summation of all traffic flow as defined by the other policy sections.
•src_ip—Traffic destined to the zone aggregated according to source IP address.
•src_net—Traffic destined to the zone aggregated according to source subnet IP address.
•dst_port—Traffic destined to a specific zone port.
•protocol—Traffic destined to the zone aggregated according to protocol.
•src_ip_many_dst_ips—This is the key used for IP scanning. Traffic from a single IP address destined to many zone IP addresses.
•src_ip_many_port—This is the key used for port scanning. Traffic from one IP address destined to many zone ports.
|
Value
|
The rate, ratio, or number of connections depending on the section of the table. The information in each section is sorted by value, with the highest value appearing first.
|
Drop Statistics
The drop statistics table (Figure 8-15) enables you to view the distribution of dropped packets for an ongoing attack by rate and counter.
To view the drop statistics table, choose Diagnostics > Drop Statistics from the Zone main menu.
You can select the statistics units from the drop-down list.
To change the statistic units, choose the units from the drop-down list and click Set units.
Figure 8-15
Drop Statistics Table
The dropped packets appear in two tables according to type:
Table 8-13 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 module 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 module 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 module 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 module 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 module 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 module 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 module 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 module 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 module 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 the attack reports, these packets are counted under the malformed packets in the Dropped/ Replied Packets table.
|
Table 8-14 Spoofed Statistics
Type
|
Description
|
Total spoofed
|
The total amount of spoofed traffic.
|
Spoofed incoming TCP basic
|
The traffic that the TCP basic anti-spoofing mechanisms tried to authenticate, but failed. In the attack reports, these packets are counted under the spoofed packets in the Dropped/ Replied Packets table
|
Spoofed incoming TCP strong
|
The traffic that the TCP strong anti-spoofing mechanisms tried to authenticate, but failed. In the attack reports, these packets are counted under the spoofed packets in the Dropped/ Replied Packets table.
|
Spoofed outgoing TCP basic
|
The zone-initiated-connections traffic that the TCP basic anti-spoofing mechanisms tried to authenticate, but failed. In the attack reports, these packets are counted under the spoofed packets in the Dropped/ Replied Packets table.
|
Spoofed outgoing TCP strong
|
The zone-initiated-connections traffic that the TCP strong anti-spoofing mechanisms tried to authenticate, but failed. In the attack reports, these packets are counted under the spoofed packets in the Dropped/ Replied Packets table
|
Spoofed incoming DNS
|
The traffic that incoming DNS (queries) anti-spoofing mechanisms tried to authenticate, but failed. In the attack reports, these packets are counted under the spoofed packets in the Dropped/ Replied Packets table
|
Spoofed outgoing DNS basic
|
The traffic that outgoing DNS (replies) basic anti-spoofing mechanisms tried to authenticate, but failed. In the attack reports, these packets are counted under the spoofed packets in the Dropped/ Replied Packets table
|
Spoofed outgoing DNS strong
|
The traffic that outgoing DNS (replies) strong anti-spoofing mechanisms tried to authenticate, but failed. In the attack reports, these packets are counted under the spoofed packets in the Dropped/ Replied Packets table
|
Spoofed zombie
|
The traffic that the zombie anti-spoofing mechanisms tried to authenticate, but failed. In the attack reports, these packets are counted under the spoofed packets in the Dropped/ Replied Packets table.
|
