Understanding FortiDDoS Detection Mode

In Detection Mode, FortiDDoS logs events and builds traffic statistics for SPPs, but it does not take actions: it does not drop or block traffic, and it does not aggressively age connections. Packets are passed through the system to and from protected subnets. Any logs and reports that show drop or blocking activity are actually simulations of drop or block actions the system would have taken if it were deployed in Prevention Mode.

When you get started with FortiDDoS, you deploy it in Detection Mode for 2-14 days so that the FortiDDoS system can learn the baseline of normal inbound and outbound traffic. The length of the initial learning period depends upon the seasonality of traffic (its predictable or expected variations) and how representative of normal traffic conditions the learning period is. Ensure that there are no attacks during the initial learning period and that it is long enough to be a representative period of activity. If activity is heavier in one part of the week than another, ensure that your initial learning period includes periods of both high and low activity. Weekends alone are an insufficient learning period for businesses that have substantially different traffic during the week. Thus, it is better to start the learning period on a weekday. In most cases, 7 days is sufficient to capture the weekly seasonality in traffic.

At the end of the initial learning period, you can adopt system-recommended thresholds (usually lower than the factory default) and continue to use Detection Mode to review logs for false positives and false negatives. As needed, you repeat the tuning: adjust thresholds and monitor the results.

When you are satisfied with the system settings, change to Prevention Mode. In Prevention Mode, the appliance drops packets and blocks sources that violate ACL rules and DDoS attack detection thresholds.

Important: In Detection Mode, the FortiDDoS system forwards all packets, but a simulated drop might be recorded. TCP session control options depend on the true TCP state, and simulated drops when the appliance is in Detection Mode can lead to unexpected results. For example, if the system records a (simulated) drop for a TCP connection, when subsequent packets arrive for the connection, the system treats them as foreign packets because the state table entry indicates the session has already been closed.

The table below summarizes our guidelines for SYN flood mitigation and TCP session state settings in Detection Mode.

SYN flood mitigation and TCP state anomaly detection settings

Settings	Guidelines
Global Settings > Settings
SYN Flood Mitigation	The SYN flood mitigation mode settings are not applicable and disregarded. In Detection Mode, the FortiDDoS system does not drop packets, so it cannot test the legitimacy of source IP addresses.
Protection Profiles > SPP Settings > TCP session feature control
SYN validation	Do not enable. This option enables SYN flood mitigation mode, which is not applicable in Detection Mode.
Sequence validation	Do not enable. Simulated “drops” in Detection Mode lead to incorrect window validations for subsequent session packets.
State transition anomalies validation	Do not enable. Simulated “drops” in Detection Mode lead to faulty tracking of session state.
Foreign packet validation	Do not enable. Simulated “drops” in Detection Mode lead to unexpected foreign packet violations.
Allow tuple reuse	Exception to the rule. Enabled by default to support standard test environments that reuse tuples in quick succession. The setting is valid in Detection Mode. Recommended to avoid unnecessary logging of the event when it is detected.
Allow duplicate SYN-in-SYN-SENT	Exception to the rule. Not enabled by default, but the setting is valid in Detection Mode. Recommended to avoid unnecessary logging.
Allow duplicate SYN-in-SYN-RECV Allow SYN anomaly Allow SYN-ACK anomaly Allow ACK anomaly Allow RST anomaly Allow FIN anomaly	Do not enable.