Table Of Contents
Attack Reports
Report Layout
General Details
Attack Statistics
Dropped/ Replied Packets
Detected Anomalies
Mitigated Attacks
Spoofed
Zombie
Client Attack
User Defined
Malformed Packets
Zombies
Report Parameters
Viewing Attack Reports
Exporting Attack Reports
Attack Reports
This chapter describes the attack reports that the Guard module produces and includes the following sections:
•
Report Layout
•
Report Parameters
•
Viewing Attack Reports
•
Exporting Attack Reports
Report Layout
The Guard provides an attack report for each zone to help form a clearer picture of the attack. An attack begins when the Guard produces the first Dynamic filter and ends when no Dynamic filter is in use and no new Dynamic filters are added. Reports include details of the attacks organized into sections. Each section describes different aspects of the traffic flow during an attack. You can view reports for past attacks and ongoing attacks and can export reports to an FTP server.
Reports include the following sections:
•
General Details
•
Attack Statistics
•
Dropped/ Replied Packets
•
Detected Anomalies
•
Mitigated Attacks
•
Zombies—This section is only available when you issue the show reports details and show zombies commands
General Details
The general details section of the attack report includes general information about an attack. Table 10-1 describes the fields in this section of the report.
Table 10-1 Field Descriptions in General Details Section of Attack Report
Field
|
Description
|
Report ID
|
The identification number of the report.
|
Attack Start
|
Displays the date and time that the attack started.
|
Attack End
|
Displays the date and time that the attack ended. Attack in progress indicates that there an ongoing attack.
|
Attack Duration
|
Displays the duration of the attack.
|
Attack Statistics
The attack statistics section provides a general analysis of the zone traffic flow for various packets. Table 10-2 describes for the packet types.
Table 10-2 Packet Types
Type
|
Description
|
Received
|
Specifies the total amount of the diverted traffic
|
Forwarded
|
Specifies the legitimate traffic that the Guard module forwarded on to the zone
|
Replied
|
Specifies the traffic that the Guard module anti-spoofing and anti-zombie mechanisms sent back to the source in a verification attempt
|
Dropped
|
Specifies the traffic that the Guard module dropped
|
Dropped/ Replied Packets
The dropped/replied packets section of the attack report analyzes the packets that the Guard module dropped and sent back to the source in a verification attempt (replied). The report classifies the packets by their type (spoofed or malformed) and by their handling mechanism (filter types, or the Rate Limiting protection module).
Table 10-3 describes the different kinds of dropped and replied packets
Table 10-3 Types of Dropped/Replied Packets
Type
|
Description
|
Rate Limiter
|
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.
|
Flex Filter
|
Specifies packets that were dropped by the Flex filter.
|
User Filters
|
Specifies packets that were dropped by the User filters.
|
Dynamic Filters
|
Specifies packets that were dropped by the Dynamic filters.
|
Spoofed
|
Specifies packets that were 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 replied (bounced) packets to which no replies were received.
|
Malformed
|
Specifies packets that were analyzed as malformed as a result of their malformed structure or due to the Guard module anti-spoofing mechanisms.
|
Detected Anomalies
The detected anomalies section of the attack report provides details of the traffic anomalies that 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 clusters anomalies with the same type and flow parameters (such as source IP address and destination port) under one anomaly type.
Table 10-4 describes the different types of detected anomalies.
Table 10-4 Types of Detected Anomalies
Type
|
Description
|
tcp_connections
|
A detected flow with an 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 flow consisting of SYN-ACK flood or other packet attacks on connections initiated by the zone when the zone is the client.
|
unauthenticated_tcp
|
A detected flow that the Guard 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.
|
other_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
|
An anomaly flow detected by user definitions.
|
Mitigated Attacks
The mitigated attacks section of the attack report details the steps the Guard module took to protect the zone (mitigated attacks). The report provides details of the timing of the mitigation and the type of mitigated attack. The Guard module defines the mitigation type according to the mechanisms utilized. These indicate the attack type and sub-type.
For example, if the Guard module utilized a basic anti spoofing mechanism against the attacking flow of syn packets, the mitigated attack would appear as spoofed/tcp_syn_basic. Spoofed indicates the attack type and tcp_syn_basic indicates the sub-type.
There are five types of mitigated attacks:
•
Spoofed
•
Zombie
•
Client Attack
•
User Defined
•
Malformed Packets
Spoofed
Spoofed attacks includes all traffic anomalies identified as a DDoS attack coming from a spoofed source. Table 10-5 describes the different types of spoofed attacks.
Table 10-5 Types of Spoofed Attacks
Attack Type
|
Description
|
spoofed/tcp_syn (basic)
|
A flood of SYN packets that the basic anti-spoofing mechanisms haven't succeeded in authenticating
|
spoofed/tcp_syn (strong)
|
A flood of SYN packets that the strong anti-spoofing mechanisms haven't succeeded in authenticating
|
spoofed/tcp_syn_ack (basic)
|
A flood of syn_ack packets that the basic anti-spoofing mechanisms haven't succeeded in authenticating
|
spoofed/tcp_syn_ack (strong)
|
A flood of syn_ack packets that the strong anti-spoofing mechanisms haven't succeeded in authenticating
|
spoofed/tcp_incoming (basic)
|
A flood of traffic that the basic anti-spoofing mechanisms haven't succeeded in authenticating
|
spoofed/ tcp_incoming (strong)
|
A flood of traffic that the strong anti-spoofing mechanisms haven't succeeded in authenticating
|
spoofed/tcp_outgoing (strong)
|
A flood of traffic coming in response to zone initiated connections that the strong anti-spoofing mechanisms haven't succeeded in authenticating
|
spoofed/udp (basic)
|
A flood of UDP traffic that the basic anti-spoofing mechanisms haven't succeeded in authenticating
|
spoofed/udp (strong)
|
A flood of UDP traffic that the strong anti-spoofing mechanisms haven't succeeded in authenticating
|
spoofed/other_protocols
|
A flood of other than TCP and UDP traffic that the Guard module anti-spoofing mechanisms haven't succeeded in authenticating
|
spoofed/tcp_fragments
|
A flood of TCP fragmented packets that the Guard module anti-spoofing mechanisms haven't succeeded in authenticating
|
spoofed/udp_fragments
|
A flood of UDP fragmented, packets that the Guard module anti-spoofing mechanisms haven't succeeded in authenticating
|
spoofed /other_protocols_fragments
|
A flood of other than TCP and UDP fragmented packets that the Guard module anti-spoofing mechanisms haven't succeeded in authenticating
|
spoofed/dns_queries (strong)
|
A flood of DNS queries packets that the strong anti-spoofing mechanisms haven't succeeded in authenticating
|
spoofed/dns_replies (basic)
|
A flood of DNS packets coming in response to zone initiated connections that the basic anti-spoofing mechanisms haven't succeeded in authenticating
|
spoofed/dns_replies (strong)
|
A flood of DNS packets coming in response to zone initiated connections that the strong anti-spoofing mechanisms haven't succeeded in authenticating
|
Zombie
Zombie attacks include traffic anomalies identified as a DDoS attack originated by zombies. Table 10-6 describes the different types of zombie attacks.
Table 10-6 Types of Zombie Attacks
Attack Type
|
Description
|
zombie/http
|
A flood of HTTP traffic from many sources that were identified as non-spoofed, but the Guard module anti-zombie mechanisms have not succeeded in authenticating
|
Client Attack
Client attacks include all non-spoofed traffic anomalies. Table 10-7 describes the different types of client attacks.
Table 10-7 Types of Client Attacks
Attack Type
|
Description
|
client_attack/tcp_connections
|
A flow with unusual number of TCP concurrent connections with or without data
|
client_attack/http
|
A flood of HTTP traffic flow
|
client_attack/tcp_ incoming
|
A flood attacking a TCP service when the zone is a server
|
client_attack/tcp_outgoing
|
An attacking flood coming from authenticated IP connections that the zone initiated
|
client_attack /unauthenticated_tcp
|
A flood of ACKs, or FINs, or any other packets without a TCP handshake, or TCP connections that the Guard module anti-spoofing mechanisms have not succeeded in authenticating
|
client_attack/dns (udp)
|
A flood of attacking DNS-UDP protocol flow
|
client_attack/dns (tcp)
|
A flood of attacking DNS-TCP protocol flow
|
client_attack/udp
|
A flood of attacking UDP protocol flow
|
client_attack/other_protocols
|
A flood of non TCP/UDP attacking protocol flow
|
client_attack/fragments
|
A flood of fragmented traffic
|
client_attack/user
|
A user defined attack flood. The attack is defined by a Dynamic filter that was added by a user
|
User Defined
User defined attacks include all anomalies handled by the User filters. These can either function by default or you can configure them manually (see "Configuring Policy Templates and Policies" for further details). Table 10-8 describes the different types of user defined attacks.
Table 10-8 Types of User Defined Attacks
Attack Type
|
Description
|
user_defined/rate_limit
|
An overflow for which the rate was limited by the User filters or by the zone rate-limit command.
|
user_defined/user_drop_filters
|
A flood that was handled by User filters with a drop action
|
Malformed Packets
Malformed packets include all traffic anomalies identified as consisting of maliciously malformed packets. Table 10-9 describes the different types of malformed packets.
Table 10-9 Types of Malformed Packets
Attack Type
|
Description
|
malformed_packets /packets_to_proxy_ip
|
A flood attacking a Guard module proxy IP address
|
malformed_packets /dns_anti_spoofing_algo
|
A flood of malformed packets due to the operation of the Guard module DNS anti-spoofing mechanisms
|
malformed_packets /dns (queries)
|
A flood of malformed DNS packets
|
malformed_packets /dns (short_queries)
|
A flood of short DNS queries
|
malformed_packets /dns (replies)
|
A flood of malformed DNS replies
|
malformed_packets /src ip = dst ip
|
A flood of packets with the zone IP address as their source and destination
|
malformed_packets /zero_header_field
|
A flood of packets in which the port, protocol and IP fields in the header illegally equal zero
|
Zombies
Zombie attacks include traffic anomalies identified as a DDoS attack originated by zombies. The Guard module attack report displays a table listing zombies that are current attacking the zone. Use the show reports details and show zombies commands to view the list of currently attacking zombies.
See Table 10-14 for information on the fields in the show zombies command output.
Report Parameters
The different sections of the report describe different aspects of the traffic flow.
Table 10-10 describes the fields for Attack Statistics and Dropped/ Replied Packets.
Table 10-10 Field Descriptions for Attack Statistics
Field
|
Description
|
Total Packets
|
Specifies the total number of attack packets.
|
Average pps
|
Specifies the average traffic rate in pps units.
|
Average bps
|
Specifies the average traffic rate in bps units.
|
Max. pps
|
Specifies the maximum traffic rate measured in pps units.
|
Max. bps
|
Specifies the maximum traffic rate measured in bps units.
|
Percentage
|
Specifies the number of forwarded, replied, and dropped packets as a percentage of the total received packets.
|
Table 10-11 describes the flow statistics for Detected Anomalies and Mitigated Attacks
Table 10-11 Field Descriptions for Flow Statistics
Field
|
Description
|
ID
|
Specifies the identification number (ID) of the detected anomaly.
|
Start time
|
Specifies the date and time the anomaly was detected.
|
Duration
|
Specifies the duration of the anomaly in hours, minutes, and seconds.
|
Type
|
Specifies the type of anomaly or mitigated attack.
|
Triggering rate
|
Specifies the anomaly traffic rate that violated a policy threshold.
|
% Threshold
|
Indicates the percentage by which the triggering rate is above the policy threshold.
|
Flow
|
Specifies the anomaly flow and mitigated attack flow. The characteristics include the protocol number, source IP address, source port, destination IP address, destination port and indicates whether the traffic is fragmented or not. Any indicates that there is both fragmented and non-fragmented traffic.
|
.
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 parameter
A value of # followed by a number, for any of the parameters, indicates the number of values measured for that parameter.
Viewing Attack Reports
Use the show command to display a list of attack reports for any specific zone or a more detailed report for a specific attack. Enter the following command:
show reports [current | report-id] [details]
Table 10-12 provides the arguments and keywords for the show reports command.
Table 10-12 Arguments and Keywords for the show reports Command
Parameters
|
Description
|
current
|
An attack that is in progress.
The number of bits and packets is not displayed for an ongoing attack. In reports of an attack in progress, the packets and bits fields have a value of zero (0).
|
report-id
|
The identification number of the report.
|
details
|
(Optional) Displays details of the flows and attacking zombies.
|
For example, to view a list of all attacks on the zone, enter the following command:
admin@GUARD-conf-zone-scannet# show reports
The report displays the following output with information about the duration of each attack, when it started and when it ended
.
To view the report for the current attack on the zone, enter the following command:
admin@GUARD-conf-zone-scannet# show reports current
The report displays the following output. For more information about the different sections see the "Report Layout" section.
To view a more detailed report on the detected anomalies flow, the mitigated attacks flow, and view a list of zombies attacks, use the details option.
Table 10-13 describes the flow fields in the detailed report.
Table 10-13 Field Descriptions of Flows in Detailed Report
Field
|
Description
|
Detected Flow
|
Specifies the flow that caused the production of the Dynamic filter. The flow characteristics include the protocol number, source IP address, source port, destination IP address, destination port and indicates whether the traffic is fragmented or not. Any indicates that there is both fragmented and non-fragmented traffic.
|
Action Flow
|
Specifies the 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 address whereas the action flow could indicate all source ports for the specified source IP address.
The flow characteristics include the protocol number, source IP address, source port, destination IP address, destination port and indicates whether the traffic is fragmented or not. Any indicates that there is both fragmented and non-fragmented traffic.
|
Table 10-14 describes the fields in the detailed report referring to zombies attacks:
Table 10-14 Field Descriptions for Zombies Attacks Table
Field
|
Description
|
IP
|
The zombie IP address.
|
Start Time
|
The date and time the zombie connection was initially identified.
|
Duration
|
The duration of the zombie attack.
|
#Requests
|
The number of HTTP get requests sent by the zombie.
|
Note
If there are no zombie s attacks, Report doesn't exist appears under the Zombies heading in the report.
Exporting Attack Reports
You can export attack reports to an FTP server for monitoring and diagnostics capabilities. You can export attack reports in text format or in Extensible Markup Language (XML) format.
Note
The user name and password of the FTP server appear in the show running-config command output. We recommend that you use an anonymous FTP account.
Use the export command to automatically export reports in XML format to an FTP server at the end of an attack. See the xsd file that accompanies the version for a description of the XML schema. Enter the following command:
export reports ftp server full-file-name [login] [password]
Table 10-15 describes the arguments for the export reports command.
Table 10-15 Arguments for the export reports Command
Parameter
|
Description
|
server
|
The IP address of the FTP server.
|
full-file-name
|
The full file name for the report list. The default is the login user's home directory.
|
login
|
(Optional) The FTP server login name.
When you do not insert a login name, the FTP server assumes an anonymous login and does not prompt you for a password.
|
password
|
(Optional) The password for the remote FTP server.
|
The following example shows how to automatically export reports, in XML format, at the end of an attack to an FTP server at IP address 10.0.0.191 using login name user1 and password password1:
admin@GUARD# export reports ftp 10.0.0.191 AGMreports.txt user1
password1
Use the copy command to copy reports to an FTP server manually. You can copy attack reports for attacks on all zones or you can copy a report for a specific zone.
Enter the following command:
copy reports [xml] [details] ftp server full-file-name [login] [password]
Table 10-16 provides the arguments and keywords for the copy reports command.
Table 10-16 Arguments and Keywords for the copy reports Command
Parameter
|
Description
|
xml
|
(Optional) Export the report in XML format. See the xsd file released with the version for a description of the XML schema. By default, reports are exported in text format.
Reports in XML format include all details. If you include the xml option, it is not necessary to include the details option.
|
details
|
(Optional) Export details of flow and attacking source IP addresses.
|
server
|
The IP address of the FTP server.
|
full-file-name
|
The full name of the file. If you do not specify a path the server will save the file in your home directory.
|
login
|
(Optional) The FTP server login name.
The FTP server assumes an anonymous login when you do not insert a login name. The server will not prompt you for a password.
|
password
|
(Optional) The password for the remote FTP server.
If you do not enter a password, you will be prompted for it.
|
The following example shows how to copy a list of all attacks handled by the Guard module, in text format, to an FTP server at IP address 10.0.0.191 using login name user1 and password password1.
admin@GUARD# copy reports ftp 10.0.0.191 AGMreports.txt user1
password1
To copy the attack reports for a specific zone to an FTP server, enter the following command in global configuration mode:
copy zone zone-name reports [current | report-id] [xml] [details] ftp server
full-file-name [login] [password]
Table 10-17 describes the arguments and keywords for the copy zone reports command.
Table 10-17 Arguments and Keywords for the copy zone reports
Command
Parameters
|
Description
|
zone-name
|
The name of an existing zone
|
current
|
(Optional) Export an ongoing attack report (if applicable). The default is to export all zone reports.
|
report-id
|
(Optional) The ID of and existing report. The Guard module exports the report with the specified ID number. Use the show zone reports command to view the details of the zone attack reports.
The default is to export all zone reports.
|
xml
|
(Optional) Export the report in XML format. See the xsd file released with the version for a description of the XML schema. The default is to export reports in text format.
Reports in XML format include all details. If you include the xml option, it is not necessary to include the details option.
|
details
|
(Optional) Export details of flow and attacking source IP addresses.
|
server
|
The IP address of the FTP server.
|
full-file-name
|
The full name of the file. If you do not specify a path the server will save the file in your home directory.
|
login
|
(Optional) The FTP server login name. The FTP server assumes an anonymous login when you do not insert a login name. The server will not prompt you for a password.
|
password
|
(Optional) The password for the remote FTP server. If you do not enter a password, you will be prompted for it.
|
The following example shows how to copy all attack reports on the zone to an FTP server at IP address 10.0.0.191 using login name user1 and password password1.
admin@GUARD# copy zone scannet reports ftp 10.0.0.191
ScannetCurrentReport.txt user1 password1