This section discusses some of the questions that users often have about the attack log events.

To keep its reporting processes manageable, the system does not always report a source or destination IP address in the DDoS attack log. For example, for an HTTP GET flood, the system reports the protocol of the dropped packets but not their destination IP address or port.

To determine the destination of an attack, use the SPP policy configuration to organize your network into subnets that you specify. Then use reporting tools such as Log & Report > Report Browse to see which subnet is under attack.

During a SYN flood attack, the system reports a SYN flood, identifies the SPP that is under attack, and reports how many packets it has dropped. SYN floods are spoofed—the reported source of the packets is not their true source. Trying to determine the source IP address or report potentially millions of source IP addresses that have no consistent pattern is resource-intensive and does not help you to determine the identity of the attacker.

For some types of attacks, such as TCP and ICMP checksum errors, the system collects aggregate data and reports every 5 minutes only. If the appliance reported each dropped packet as soon as it dropped it and generated some kind of alert every time it dropped a packet, it would log events and generate alerts continuously.

This section discusses some of the questions that users often have about reports.

Reports are presentations of DDoS attack log database queries. The attack categories and types reported correspond with the DDoS Attack log categories and event types. Refer to Table 63 for descriptions.

If you change the SPP policy configuration or the resources it monitors, the data can become skewed. For example, if you remove a subnet from the profile, or change the servers that are deployed in the subnet, or change the services offered by those servers, the traffic history becomes less relevant.

Fortinet strongly recommends that you reset the traffic history for a profile before you make any significant changes to its configuration. Go to Protection Profiles > Factory Reset > Factory Reset.

If you do not reset traffic statistics, changes to an SPP policy can result in counter-intuitive data accumulated in the longer reporting periods (year, month). For example, if a subnet belonged to the default SPP-0 before you assigned it to SPP-1, a report filtered by SPP-1 includes the SPP-0 traffic history for that subnet.