Table Of Contents
Attack Reports
Overview
Report Structure
Attack Timing
Attack Statistics
Dropped/ Replied Packets
Detected Anomalies
Mitigated Attacks
Report Procedures
Viewing the Report List
Viewing an Ongoing Attack Report
Viewing a Specific Report
Viewing a Report in Detail
Detected Anomalies
Mitigated Attacks
Zombies
Exporting Reports
Exporting a Report List
Exporting a Zone Report
Report Analysis
Viewing Dropped Traffic Statistics
Attack Reports
This chapter describes the Guard attack reporting process, the report structure, and viewing options. The chapter concludes with examples of attack reports and their analysis.
Overview
The Guard provides the user with an attack report for each Zone to help in forming a clearer picture of an attacked zone (or zones). The attack report details an attack that begins at the production of the first Dynamic filter and ends at protection termination. The Guard records the relevant details during an attack and organizes the data under the report category columns. The produced report (or reports) is available for view and covers past and ongoing attacks.
Report Structure
The attack report consists of data fields and tables. These are grouped under the following categories:
Figure 12-1 Report Structure
Note 
The Guard attack report displays an additional Zombies table when the user issues the show zone reports details and show zombies commands. See the "Zombies" section for further details.
Attack Timing
The Attack Timing category supplies general information relating to attack timing. The Attack Timing category consists of the following fields:
•Attack Start—This field displays the attack beginning date and time.
•Attack End—This field displays the attack-end date and time. A value of "Attack in progress" indicates that the viewed attack is ongoing.
•Attack Duration—This field displays the attack duration.
Attack Statistics
The Attack Statistics category provides a general analysis of the Guard Received traffic flow. The Guard analyzes the received traffic into Received, Forwarded, Replied, and Dropped traffic. These are distributed and quantified in various units and their calculated percentage (per the Received flow). The results are displayed in a table. Following are the table rows:
•Received—This row represents the total amount of the diverted traffic.
•Forwarded—This row represents the legitimate traffic the Guard forwarded on to the zone.
•Replied—This row represents the traffic the Guard anti-spoofing and anti-zombie mechanisms sent back to the source in a verification attempt.
•Dropped—This row represents the traffic the Guard dropped.
The table columns represent the following quantifications:
•Total Packets—This column represents the total amount of the attack packets.
•Average pps—This column represents the traffic average in packets-per-second units.
•Average bps—This column represents the traffic average in bits-per-second units.
•Max. pps—This column represents the maximum measured amount of traffic in packets-per-second units.
•Max. bps—This column represents the maximum measured amount of traffic in bits-per-second units.
•Percentage—This column represents the percentage the Forwarded, Replied, and the Dropped packets make of the Received packets.
Dropped/ Replied Packets
The Dropped/Replied Packets table analyzes the packets that were dropped and replied. The table classifies the packets by their type (spoofed or malformed) and by their handling mechanism (filter types, or rate limiter). Again, the packets are quantified in various units and their calculated percentage (per the received flow). The table rows represent the following:
•Rate Limiter—This row represents the packets the zone rate limiter and user filters rate limiters' dropped.
•Flex Filter—This row represents the packets the flex filter dropped.
•User Filters—This row represents the packets the user filters dropped.
•Dynamic Filters—This row represents the packets the dynamic filters dropped.
•Spoofed—This row represents the packets that were identified by the Guard 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—This row represents the packets analyzed as malformed as a result of their malformed structure or due to the Guard's anti-spoofing mechanisms.
The table columns represent the following quantification:
•Total Packets—This column represents the total amount of packets.
•Average pps—This column represents the traffic average in packets-per-second units.
•Average bps—This column represents the traffic average in bits-per-second units.
•Max. pps—This column represents the maximum measured amount of traffic in packets-per-second units.
•Max. bps—This column represents the maximum measured amount of traffic in bits-per-second units.
•Percentage—This column represents the percentage the rate limiter, the various filters, and the spoofed and malformed packets make of the total packets the Guard dropped and replied.
Detected Anomalies
The Detected Anomalies category displays a table detailing the traffic anomalies the Guard detected in the zone's traffic. The table columns provide the detected anomaly details. The Guard regards as an anomaly a case in which a traffic flow required the production of a dynamic filter (with a 'to-user-filter' action). The Guard clusters detected anomalies produced by the same policy under the same anomaly type. This is provided there wasn't a large timing gap between their productions. The Guard typifies anomalies by their relating protocols and services. For example, an anomaly type can be Tcp_incoming to denote an anomalous flow attacking a server's TCP services. The Guard also represents flows of clustered anomalies by their common traffic characteristics. For example, a destination port would denote flows with identical characteristics destination port. An asterisk (*) indicates flow characteristic the Guard couldn't identify or that more than one value was measured for the anomaly's parameter. A pound sign (#) indicates the number of values measured for the anomaly's parameter.
The table columns represent the following:
•ID—This column represents the anomaly identification number.
•Start Time—This column represents the anomaly detection date and time.
•Duration—This column represents the anomaly duration in hours, minutes, and seconds.
•Type—This column represents the detected anomaly type. The detected anomaly type is derived from the policy template that detected it.
The anomaly types are:
Anomaly Type
|
Description
|
tcp_connections
|
A detected flow with unusual number of TCP concurrent connections with or without data
|
HTTP
|
A flow attacking HTTP well known ports
|
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 with an unusual flow of ACKs, or FINs, or any other packets without a detected TCP handshake
|
DNS (udp)
|
An attacking DNS-UDP protocol flow
|
DNS (tcp)
|
An attacking DNS-TCP protocol flow
|
udp
|
An attacking UDP protocol flow
|
other_protocols
|
An non TCP/UDP protocol attacking flow
|
Fragments
|
A detected flow with an unusual quantity of fragmented traffic
|
tcp_ratio
|
A detected flow with an unusual ratio between different types of TCP packets (e.g. SYN packets versus FIN/RST packets)
|
ip_scan
|
A detected flow initiated from source IP address that tried to access many zone destination IP addresses.
|
port_scan
|
A detected flow initiated from source IP address that tried to access many zone ports
|
USER
|
An anomaly flow detected by the user
|
•Triggering Rate—This column represents the anomaly traffic rate that violated the policy threshold.
•%Threshold—This column represents the exceeding percentage of the triggering rate above the policy threshold.
Note The Guard displays N/A when no data is available in the Triggering Rate and %Threshold columns.
•Flow—This column represent the anomaly traffic data. The following figure describes the data fields:
The flow fields are:
•Protocol Number—This field represents the protocol number.
•Source IP—This field represents the source IP address of a traffic flow.
•Source Port—This field represents the source port of a traffic flow.
•Destination IP—This field represents the destination IP address of a traffic flow.
•Destination Port—This field represents the destination port of a traffic flow.
•Fragmentation—This field represents an indication of the fragmentation characteristics of the traffic flow.
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 the mitigated attack's parameter.
Mitigated Attacks
The Mitigated Attacks table details the steps the Guard took to protect the zone (Mitigated Attacks). The report supplies the mitigation timing details, then it proceeds to state the mitigated attack type. The Guard defines the mitigation type according to the utilized mechanisms. These indicate the attack type and sub-type.
For example, if the Guard utilized an anti spoofing mechanism (i.e. a basic anti-spoofing) against the attacking flow of syn packets, the mitigated attack would be typed as spoofed/tcp_syn_basic.
If an attack required the use of a specific mechanism to mitigate a flow of short DNS queries, mitigated attack would be typed after the mechanism's name: malformed_packets /dns (short_ queries).
An asterisk (*) indicates a flow characteristic the Guard couldn't identify or that more than one value was measured for the mitigated attack's parameter. A pound sign (#) indicates the number of values measured for the mitigated attack's parameter.
The Guard clusters mitigation actions belonging to the same type under a single action type. The Mitigated Attacks table provides information on the mitigated attack flow.
The Mitigated Attacks table consists of the following columns:
•ID—This column represents the attack identification number.
•Start Time—This column represents the attack detection date and time.
•Duration—This column represents the attack duration in hours, minutes, and seconds.
•Type—This column represents the attack types. The attack types are:
–spoofed - This type includes all traffic anomalies identified as a DDoS attack coming from a spoofed source. The following table displays the various spoofed attack types and their descriptions:
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's 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 anti-spoofing mechanisms haven't succeeded in authenticating
|
spoofed/tcp_fragments
|
A flood of TCP fragmented packets that the Guard anti-spoofing mechanisms haven't succeeded in authenticating
|
spoofed/udp_fragments
|
A flood of UDP fragmented, packets that the Guard 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 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's 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's initiated connections that the Strong anti-spoofing mechanisms haven't succeeded in authenticating
|
–zombie—This type includes traffic anomalies identified as a DDoS attack originated by zombies. The following table displays the various zombie attack types and their descriptions:
Attack Type
|
Description
|
zombie/http
|
A flood of HTTP traffic from many sources, that were identified as non-spoofed, but the Guard anti-zombie mechanisms haven't succeeded in authenticating
|
–client_attack—This type includes all non-spoofed traffic anomalies. The following table displays the various client attack types and their descriptions:
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. Also, TCP connections that the Guard anti-spoofing mechanisms haven't succeeded in unauthenticating.
|
client_attack/dns (udp)
|
A flood of attacking DNS-UDP protocol.
|
client_attack/dns (tcp)
|
A flood of attacking DNS-TCP protocol.
|
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 the user.
|
–user-defined—This type includes all anomalies handled by the user filters. These could either function by default or be user configured (see Chapter 10, "Advanced Policy Procedures" for further details). The following table displays the various client attack types and their descriptions:
Attack Type
|
Description
|
user_defined/rate_limit
|
A overflow that was rate limited by the user filters
|
user_defined/user_drop_filters
|
A flood that was handled by the user filters
|
–malformed_packets—This type includes all traffic anomalies identified as consisting of maliciously malformed packets. The following table displays the various client attack types and their descriptions:
Attack Type
|
Description
|
malformed_packets /packets_to_proxy_ip
|
A flood attacking a Guard's proxy IP address
|
malformed_packets
/dns_anti_spoofing_algo
|
A flood of malformed packets due to the operation of the Guard's DNS anti-spoofing mechanisms
|
malformed_packets
/dns (queries)
|
A flood of mal-formed DNS packets
|
malformed_packets
/dns (short_queries)
|
A flood of short DNS queries
|
malformed_packets
/dns (replies)
|
A flood of mal-formed 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 some of the fields in the header illegally equal zero
|
Report Procedures
For any zone the user may view:
•An attack report list
•A current attack report
•A specific attack report
Viewing the Report List
The user is able to view a comprehensive list of attack reports for any specific zone. When applicable, the list includes a report of a current attack (denoted by: current in the report). To view a comprehensive list of all attack reports perform the following:
1. From the Zone command group level, type the following:
admin@GUARD-conf-zone-<zone-name># show reports
2. Choose ENTER. The following sample screen appears:
admin@GUARD-conf-zone-scannet# show reports
Report ID
|
Attack Start
|
Attack End
|
Attack Duration
|
current
|
Sep 15 2003 15:12:43
|
Attack in progress
|
N/A
|
12
|
Sep 14 2003 17:57:20
|
Sep 14 2003 17:57:20
|
15:23:50
|
|
|
.......
|
|
4
|
Sep 11 2003 11:03:53
|
Sep 11 2003 11:10:00
|
00:06:07
|
3
|
Sep 10 2003 09:56:58
|
Sep 11 2003 08:42:45
|
22:45:47
|
2
|
Sep 09 2003 17:54:07
|
Sep 09 2003 18:14:08
|
00:20:01
|
1
|
Sep 09 2003 17:02:39
|
Sep 09 2003 17:23:04
|
00:20:25
|
The above screen sample indicates a list of 13 reports. Twelve of the reports indicate past attacks and the one denoted by current indicates an attack in progress. The user may view the current report and observe the attack data, the detected anomalies and the protection steps that are being taken.
Viewing an Ongoing Attack Report
The user is able to view details of an ongoing attack report (if applicable).
To view details of an ongoing attack report perform the following:
1. From the Zone command group level, type the following:
admin@GUARD-conf-zone-<zone-name># show reports current
2. Choose ENTER. The following sample screen appears:
Attack Start : Dec 30 2003 16:28:06
Attack End : Attack in progress
Attack Duration: 00:08:34
Attack Statistics:
|
|
|
|
|
|
|
|
Total Packets
|
Average pps
|
Average bps
|
Max pps
|
Max bps
|
Percentage
|
|
|
|
|
|
|
|
|
|
|
64278.54
|
1430.85
|
899196.24
|
56.14
|
|
|
|
2172.89
|
23.03
|
14433.88
|
1.95
|
|
|
78.17
|
44526.32
|
96.82
|
55010.13
|
41.91
|
|
|
|
|
|
|
|
|
|
Flow: 6 * * 192.168.200.254 80 no fragments
|
|
|
|
|
|
|
|
|
client_attack/
tcp_connections
|
|
|
Flow: 6 (#52) * 192.168.200.254 80 no fragments
|
The report of an ongoing attack indicates the following:
•The attack statistics table indicates that 56.14% of the traffic is legitimate traffic, forwarded to the zone. Most of the attack traffic, 41.91% is dropped.
•The Dropped/Replied Packets table indicates that almost all of the attack traffic consists of non-spoofed traffic (99.84%) and is handled by the Guard's Dynamic filters.
•The Detected Anomalies table indicates that the Guard detected an anomaly in the form of an HTTP flood. The TCP protocol flow either has more than one value or is of unidentified source address and port (as indicated by the parameter value of '*') is destined to IP address 192.168.200.254, port 80. This unfragmented traffic violated the policy threshold at a rate of 997.44 packets per second, which is 897.44% above the policy threshold.
•The Mitigated attacks table indicates that the Guard has begun taking a protective action against a non-spoofed traffic attack. This action involved mechanisms that take care of flows with unusual number of TCP concurrent connections whether with or without data. These mechanisms are aimed at an unfragmented TCP protocol flow coming from 52 any source IP address (as indicated by the parameter value of '#') and source port that is undetermined, and destined to IP address 192.168.200.254 port 80.
Viewing a Specific Report
The user is able to view the details of a specific report.
To view the details of a specific report perform the following:
1. From the Zone command group level, type the following:
admin@GUARD-conf-zone-<zone-name># show reports <report-id>
Where:
Parameters
|
Description
|
<report-id>
|
The ID number of the desired report
|
2. Choose ENTER.
Viewing a Report in Detail
The Guard clusters detected anomalies produced by the policy under the same anomaly type (see the "Detected Anomalies" section for further details). The guard enables the user to view the clustered anomalies. The Guard enables the user to view a specific zone's ongoing or specific attack reports. The detailed report includes, in addition, a section detailing Zombies' related information (see the "Zombies" section for further details).
To view a report in detail perform the following:
1. From the Zone command group level, type the following:
admin@GUARD-conf-zone-<zone-name># show reports
[current|<report-id>] details
Where:
Parameters
|
Description
|
current
|
(Optional) current—The details of an ongoing attack report (if applicable).
|
<report-id>
|
(Optional) The ID number of the desired report
|
2. Choose ENTER.
The Guard report details, in addition to the information provided in the non-detailed attack reports, displays the following:
•Dynamic filters clustered under a detected anomaly type
•Dynamic filters clustered under the mechanisms used to mitigate an attack
•The list of attacking zombies if a zombie attack is in progress
Detected Anomalies
The following information is displayed for each detected anomaly:
admin@GUARD-conf-zone-scannet# show reports current details
|
|
|
|
|
|
|
Flow: 6 * * 192.168.200.254 80 no fragments
|
|
|
|
|
|
Detected Flow: 6 * * 192.168.200.254 80 no fragments
Action Flow : 6 * * * 80 no fragments
|
•Detected Anomaly—The Detected Anomalies table columns supply details regarding the anomaly flow. The table columns provide information on the detected anomaly (see the "Detected Anomalies" section in this chapter for further details).
•Detected Anomaly Details—The detected anomaly details provide information on the dynamic filters, clustered according to the producing policy, that constitute the detected anomaly. For each Dynamic filter, information is provided on the anomaly flow, the flow that caused the production of the dynamic filter and action flow, the flow that was addressed by the dynamic filter (the flow the dynamic filter took action against).
The Detected Anomalies table columns provide details regarding the anomaly flow. The table columns represent the following:
–Start Time—This column represents the dynamic filter activation date and time.
–Duration—This column represents the dynamic filter duration in hours, minutes, and seconds.
–Threshold—Indicates the threshold of the policy that produced the dynamic filter. When, temporarily, no data is available the Guard displays N/A.
–Rate—Indicates the traffic rate measured for the dynamic filter in packets per second (pps). When, temporarily, no data is available the Guard displays N/A.
–Detected Flow—This row represents the flow that caused the production of the dynamic filter. The columns represent the dynamic filter traffic data (see the flow parameters detailed in the "Detected Anomalies" section for further details).
–Action Flow—This row represents the flow that was addressed by the dynamic filter. The action flow could be of 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 will indicate all source ports for the specified source IP. The columns represent the dynamic filter traffic data. See the flow parameters detailed in the the "Detected Anomalies" section for further details.
Mitigated Attacks
The following information is displayed for each mitigated attack:
... ... ...
|
|
|
|
|
client_attack/
tcp_connections
|
|
|
Flow: 6 (#52) * 192.168.200.254 80 no fragments
|
|
|
|
|
|
|
|
|
Detected Flow: 6 192.168.200.150 * 192.168.200.254 80 no fragments
Action Flow : 6 192.168.200.150 * * * no fragments
|
|
|
|
|
|
|
|
|
Detected Flow: 6 192.168.200.130 * 192.168.200.254 80 no fragments
Action Flow : 6 192.168.200.130 * * * no fragments
|
•Mitigated attack—The Mitigated Attacks table columns provide details regarding the mitigated attack flow. The table columns provide information on the mitigated attack (see the "Mitigated Attacks" section in this chapter for further details).
•Mitigated attack Details—The mitigated attack details provide information on the mechanisms that were used to mitigate the attack. For each mitigation mechanism, information is provided on:
–The detected attack flow—the flow that was mitigated.
–The action flow—the flow that was addressed by the mitigation mechanism (the flow the mitigation mechanism took action against).
The Mitigated attack table columns supply details regarding the mitigated attack flow. The table columns represent the following:
–Start Time—This column represents the dynamic filter activation date and time.
–Duration—This column represents the dynamic filter duration in hours, minutes, and seconds.
–Threshold—Indicates the threshold of the policy that produced the dynamic filter.
–Rate—Indicates the traffic rate measured for the dynamic filter in packets per second (pps).
–Packets—The number of packets counted for the mitigated attack flow.
–Bits—The number of bits counted for the mitigated attack flow.
Note The number of bits and packets is not displayed for an ongoing attack. Thus, when displaying the report details of an attack in progress, the packets and bits fields will have a value of zero (0).
–Detected Flow—This row represents the detected flow that was mitigated. The columns represent the dynamic filter traffic data (see the flow parameters detailed in the "Mitigated Attacks" section above for further details).
–Action Flow—This row represents the flow that was addressed by the mitigation mechanism. The action flow could be of a wider range than the detected flow. For example, the detected flow could indicate a specific destination port for a specific destination IP whereas the action flow will indicate all destination ports for the specified destination IP. The columns represent the dynamic filter traffic data (see the flow parameters detailed in the "Mitigated Attacks" section above for further details).
Zombies
The following information relates to attacking zombies:
•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
Exporting Reports
The Guard enables the user to perform report export procedures to an FTP server. These procedures are:
•Exporting a Report List
•Exporting a Zone Report
Exporting a Report List
The user may export an attack report list to an FTP server.
To export an attack report list perform the following:
1. From the Global command group level, type the following:
admin@GUARD# copy reports ftp <server> <full-file-name> [<login>]
[<password>]
Where:
Parameters
|
Description
|
<server>
|
The IP address of FTP server.
|
<full-file-name>
|
The full file path name.
Note The default is the user's home directory when a path is unspecified.
|
<login>
|
(Optional) The FTP server login name.
Note The FTP server assumes an anonymous login when the user does not insert a login name. The server will not prompt the user for a password.
|
<password>
|
(Optional) The password for the remote FTP server.
|
2. Choose ENTER. The following sample screen appears:
admin@GUARD# copy reports ftp 10.0.0.191 Guard-reports.txt user
password
Exporting a Zone Report
The user may export a specific zone's attack report to an FTP server.
To export a specific zone's attack report to an FTP server perform the following:
1. From the Global command group level, type the following:
admin@GUARD# copy zone <zone-name> reports [current|<report-id>]
[details] ftp <server> <full-file-name> [<login>] [<password>]
Where:
Parameters
|
Description
|
<zone-name>
|
The zone name
|
current
|
(Optional) The Guard exports an ongoing attack report (if applicable).
|
<report-id>
|
(Optional) The Guard exports the report with the specified ID number. See the "Viewing the Report List" section for further details.
The ID is an integer.
|
[details]
|
(Optional) The Guard exports a detailed report. See the "Viewing a Report in Detail" section in this chapter for further details.
|
<server>
|
The FTP server IP address
|
<full-file-name>
|
The full file path name.
Note The default is the user's home directory when a path is unspecified.
|
<login>
|
(Optional) The FTP server login name.
Note The FTP server assumes an anonymous login when the user does not insert a login name. The server will not prompt the user for a password.
|
<password>
|
(Optional) The password for the remote FTP server.
|
2. Choose ENTER. The following sample screen appears:
admin@GUARD# copy zone scannet reports current ftp 10.0.0.191
ScannetCurrentReport.txt user password
To export a specific zone's detailed attack-report to an FTP server perform the following:
1. From the Global command group level, type the following:
admin@GUARD# copy zone <zone-name> reports [current|<report-id>]
details ftp <server> <full-file-name> [<login>] [<password>]
See the above table in this section for parameter description.
2. Choose ENTER.
Report Analysis
This section exemplifies two cases of report analysis. The aim of these examples is to familiarize the reader with report analysis and interpretation. The first analysis example is performed on the following sample report:
Attack Start : Jan 06 2004 12:06:23
Attack End : Attack in progress
Attack Duration: 00:04:27
|
|
|
|
|
|
|
Flow: 6 * * 192.168.200.254 80 no fragments
|
|
|
|
|
|
|
|
Flow: 6 * * * * no fragments
|
Note The Guard attack report displays an additional Zombies table when the user issues the show zone reports details and show zombies commands. See the "Zombies" section for further details.
The report first displays initial data on the attack time and duration (see the "Attack Timing" section), then, the Attack Statistics table (see the "Attack Statistics" section). The attack statistics table displays that Guard replied 98.77% of the traffic. This significant amount of replied traffic indicates that a spoofed attack is going on.
The Dropped/ Replied Packets table confirms the idea of a spoofed attack. The anti-spoofing mechanisms (Spoofed) row indicates that the Guard tried to authenticate a quantity of 266251 packets at an average of 986.11 packets per second (see the "Attack Statistics" section).
The Detected Anomalies information block displays one recorded anomaly (see the "Detected Anomalies" section). Anomaly ID 1 indicates that an unfragmented TCP protocol traffic flowing from source IP address 192.168.100.48 and unidentified source port is destined to IP address 192.168.200.254 port 80. The spoofed traffic violated the policy threshold at a rate of 1019.11 packets per second (Triggering Rate). The triggering rate was 1938.22% above the policy threshold.
The Mitigated Actions table displays a single protective action. Action ID 1 indicates that the Guard utilized its basic anti-spoofing mechanism to handle an unfragmented TCP protocol spoofed TCP SYN attack. The attack flow triggering rate was 1001.97 packets per second.
Following is the next report example:
Attack Start : Sep 22 2003 22:42:33
Attack End : Attack in progress
Attack Duration: 13:06:15
|
|
|
|
|
|
|
Flow: 17 * * 192.168.200.254 53 no fragments
|
|
|
|
|
|
|
Flow: 6 * * 192.168.200.254 * no fragments
|
|
|
|
|
malformed_packet/
DNS(short_queries)
|
|
|
|
Flow: 17 * * * 53 no fragments
|
|
|
|
spoofed/
tcp_syn-ack(basic)
|
|
|
Flow: 6 * * * * no fragments
|
The attack statistics table indicates that the Guard dropped most of the received traffic (87.9%), replied 12.07%, and forwarded 0.02% over to the zone. This may indicate traffic with mixed legitimate, spoofed, and other malicious type flows. The Dropped/Replied Packets table displays that out of the replied/dropped flows most were dropped by the Guard's mechanisms handling malformed traffic (87.92%), further 12.08% were replied by the anti-spoofing mechanisms. This indicates a mixed attack made mostly of malformed packets, and, to a lesser degree, of spoofed traffic handled by the user filters (see the user-defined item in the "Mitigated Attacks" section for further details).
The Detected Anomalies table displays two anomalies. The anomaly Type and Flows information indicate a UDP flow (typed as DNS UDP) and a TCP flow (typed as tcp_outgoing). These anomaly flows and types indicate mixed anomalies.
The Mitigated Attacks table displays the protective actions the Guard took. The mitigated attack types indicate two types of mitigation. These are the malformed-packets mechanisms handling the DNS short queries and the anti-spoofing mechanisms handling the tcp_syn-ack (basic). This points at the varied type of an attack the Guard stopped.
Examples of the flow notations the Guard uses can be found in both Detected Anomalies and Mitigated Attacks tables. The following example demonstrates this: in the Detected anomalies table, anomaly ID numbered 1 displays a UDP protocol, unfragmented, flow of unidentified source IP address and port, destined to IP address 192.168.200.254 port 17.
Viewing Dropped Traffic Statistics
The user may 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 (see the below sample screen for further details).
To view the dropped traffic distribution perform the following:
1. From the Zone command group level, type the following:
admin@GUARD-conf-zone-<zone-name># show drop-statistics
2. Choose ENTER. The following sample screen appears:
admin@GUARD-conf-zone-scannet# show drop-statistics
|
|
|
|
|
|
Incoming TCP unauthenticated-basic:
Incoming TCP unauthenticated-strong:
Outgoing TCP unauthenticated:
UDP unauthenticated-basic:
UDP unauthenticated-strong:
Other protocols unauthenticated:
TCP fragments unauthenticated:
UDP fragments unauthenticated:
Other protcols fragments unauthenticated:
NON DNS packets to DNS port:
Bad packets to proxy addresses:
TCP anti-spoofing mechanisms related pkts:
DNS anti-spoofing mechanisms related pkts:
Anti-spoofing internal errors:
|
|
|
|
|
The table columns display the following:
•pps—This column displays the rate in packets per second units.
•bps—This column displays the rate in bits per second units.
•Packets—This column displays the traffic in packets.
•Kbits—This column displays the traffic in kilobits.
The table rows display the following:
•Total Drop—The total amount of dropped traffic.
•Dynamic filters—The traffic amount the dynamic filters dropped.
•User filters—The traffic amount the user filters dropped.
•Flex filter—The traffic amount the flex filter dropped.
•Rate limit—The traffic amount the rate limiter dropped.
•Incoming TCP unauthenticated basic—The traffic that the TCP Basic anti-spoofing mechanisms dropped. In the attack reports, these packets are counted under the spoofed packets in the Dropped/ Replied Packets table.
•Incoming TCP unauthenticated-strong—The traffic that the TCP Strong anti-spoofing mechanisms dropped. In the attack reports, these packets are counted under the spoofed packets in the Dropped/ Replied Packets table.
•Outgoing TCP unauthenticated—The zone-initiated-connections traffic that the TCP anti-spoofing mechanisms dropped. In the attack reports, these packets are counted under the spoofed packets in the Dropped/ Replied Packets table.
•UDP unauthenticated-basic—The UDP traffic that the Basic anti-spoofing mechanisms dropped. In the attack reports, these packets are counted under the spoofed packets in the Dropped/ Replied Packets table.
•UDP unauthenticated-strong—The UDP traffic that the Strong anti-spoofing mechanisms dropped. In the attack reports, these packets are counted under the spoofed packets in the Dropped/ Replied Packets table.
•Other protocols unauthenticated—Other than TCP and UDP traffic 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.
•TCP fragments unauthenticated—TCP fragmented packets 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.
•UDP fragments unauthenticated—UDP fragmented packets 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.
•Other protocols fragments unauthenticated—Other than TCP and UDP fragmented packets 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 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's 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's proxy IP address that the Guard protection mechanisms dropped.
•TCP anti-spoofing mechanisms related pkts—The amount of dropped packets due to side-operations of the Guard's 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 amount of packets dropped packets due to side-operations of the Guard's 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 amount of packets dropped due to the Guard's anti-spoofing mechanisms errors. In the attack reports, these packets are counted under Packets table.
•Land attack—The amount of packets dropped due to having an 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 amount 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.
