Understanding FortiDDoS Asymmetric Mode
Understanding FortiDDoS Asymmetric Mode for TCP
FortiDDoS monitors TCP states. For TCP state monitoring to work fully and properly for all types of related mitigation, bidirectional traffic must pass through FortiDDoS.
When only one direction of traffic passes through the device, from FortiDDoS’ perspective, we call it Asymmetric traffic and the appliance must be set in Asymmetric Mode.
Combinations of multiple links and BGP routing tables at the ISPs and the customer can result in inbound and outbound using any combination of the links.
The figure below shows an asymmetric route when an external client initiates the connection, such as a web server request. The initial TCP SYN traverses the network path where FortiDDoS has been deployed, but the SYN-ACK response takes a different route to the client.
Asymmetric route when an external client initiates the connection
The following figure shows an asymmetric route when the internal resource initiates the connection, such as when a backup server initiates a scheduled job. The TCP SYN takes an out-of-path route, and the SYN-ACK packet is the first packet that FortiDDoS sees for the session.
Asymmetric route when an internal server initiates the connection
We have two key recommendations if you plan to deploy the FortiDDoS appliance in a network path where asymmetric routes are possible:
- When feasible, design the network routes so that FortiDDoS sees both sides of the client-server connection. You might be able to do this with the preferred routes, persistence, or active/active synchronization features of the routing devices in your deployment.
- If you cannot avoid asymmetric traffic, enable FortiDDoS Asymmetric Mode. In Asymmetric mode, FortiDDoS can use virtually 100% of its methods to detect abnormal network traffic, with the exception of the parameters noted below. Disabling these parameters results in a very small loss of attack detection capability.
In Asymmetric Mode, the system can parse Layer 4 and Layer 7 headers for most floods and URL-related features. If this feature is off, such floods are not detected when two-way session traffic is not completely seen by the appliance.
You must enable both Asymmetric Mode and the Allow Inbound SYN-ACK option so the system can properly handle asymmetric TCP traffic. When enabled, the system treats an inbound SYN-ACK as if a SYN, and it creates an entry for it in the TCP connection table. It does not increment the syn threshold counter, but it does track syn-per-src in order to protect against attacks that might attempt to exploit this behavior.
TCP state anomaly detection depends on tracking a two-way traffic flow, so some feature options on the Protection Profiles > SPP Settings page do not work in Asymmetric Mode. The table below summarizes the configuration guidelines for these feature options.
Recommended TCP state anomaly detection settings in Asymmetric Mode
| Settings | Guidelines |
|---|---|
| SYN validation | Recommended. This option enables SYN flood mitigation mode. |
| Sequence validation | Do not enable. Depends on tracking a two-way traffic flow. |
| State transition anomalies validation | Do not enable. Depends on tracking a two-way traffic flow. |
| Foreign packet validation | Recommended. In Asymmetric Mode, FortiDDoS can still track foreign packets. |
| Allow tuple reuse | Enabled by default to support standard test environments that reuse tuples in quick succession. The setting is valid in Asymmetric Mode. Recommended to avoid unnecessary logging of the event when it is detected. |
| Allow duplicate SYN-in-SYN-SENT | Not enabled by default, but the setting is valid in Asymmetric Mode. Recommended when FortiDDoS is in Detection Mode to avoid unnecessary logging of the event when it is detected. |
| 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. |
Workflow for getting started with Asymmetric Mode
- Go to Global Settings > Settings > Settings > Deployment tab and enable the following settings:
- Asymmetric Mode
- Allow inbound SYN/ACK
- For each SPP, go to Protection Profiles > SPP Settings and ensure that the following TCP state anomaly options are enabled and no other:
- Syn validation
- Foreign packet validation
- Allow tuple reuse
- Allow duplicate SYN-in-SYN-SENT
- For each SPP, go to Protection Profiles > SPP Settings and ensure that the following TCP state anomaly options are enabled and no other:
- SYN validation
- Foreign packet validation
- Allow tuple reuse
Understanding Asymmetric Mode and DNS
An asymmetric route is one in which the traffic in one direction traverses FortiDDoS system, but traffic in the other direction takes a route that does not go via FortiDDoS. Combinations of multiple links and BGP routing tables at the ISPs and customer can result in inbound and outbound using any combination of the links.
If FortiDDoS is deployed in Asymmetric mode, then most DNS Feature controls must be disabled.
To mitigate many DNS DDoS attacks, FortiDDoS maintains tables for both DNS Queries and Responses. If both Queries and Responses do not go through FortiDDoS, then the functionality must be disabled for the device to work and report attacks properly.
Asymmetric Mode and DNS
In asymmetric mode, the expectation is that FortiDDoS will only see half of most DNS Query/Response transactions. Since DNS is normally UDP and stateless, FortiDDoS cannot make assumptions of the state and may drop DNS Queries and/or Responses as anomalous.
DNS Anomaly Feature Controls are primarily DNS header anomalies. This can be enforced in Asymmetric mode because they work on packet by packet basis rather than maintaining state across packets.
The following figure shows the allowed DNS Feature Control configuration for use with asymmetric traffic:
DNS Feature Control configuration for asymmetric traffic
Understanding FortiDDoS Asymmetric Mode for NTP
FortiDDoS monitors NTP states. For NTP state monitoring to work fully and properly for all types of related mitigation, bidirectional traffic must pass through FortiDDoS. When only one direction of traffic passes through the device, from FortiDDoS’ perspective, we call it Asymmetric traffic and the appliance must be set in Asymmetric Mode.
Combinations of multiple links and BGP routing tables at the ISPs and the customer can result in inbound and outbound using any combination of the links.
If FortiDDoS is deployed in Asymmetric mode, then most NTP Features must be disabled.
To mitigate many NTP DDoS attacks, FortiDDoS maintains tables for both NTP Queries and Responses. If both Queries and Responses do not go through FortiDDoS, then the functionality must be disabled for the device to work and report attacks properly.
Asymmetric Mode and NTP
In asymmetric mode, the expectation is that FortiDDoS will only see half of most NTP Query/Response transactions. Since NTP is UDP and stateless, FortiDDoS cannot make assumptions of the state and may drop NTP Queries and/or Responses as anomalous.
NTP Anomaly Check primarily consists of NTP header anomalies. This can be enforced in Asymmetric mode because they work on packet by packet basis rather than maintaining state across packets.
NTP Reflection Deny feature denies NTP Mode 7 and NTP Mode 6 packets in Queries and Responses.
The following figure shows the allowed NTP feature configuration for use with asymmetric traffic:
Understanding FortiDDoS Asymmetric Mode for DTLS
FortiDDoS monitors DTLS states. For DTLS state monitoring to work fully and properly for all types of related mitigation, bidirectional traffic must pass through FortiDDoS. When only one direction of traffic passes through the device, from FortiDDoS’ perspective, we call it Asymmetric traffic and the appliance must be set in Asymmetric Mode.
Combinations of multiple links and BGP routing tables at the ISPs and the customer can result in inbound and outbound using any combination of the links.
If FortiDDoS is deployed in Asymmetric mode, then all DTLS Features must be disabled.
To mitigate many DTLS DDoS attacks, FortiDDoS maintains tables for both DTLS Queries and Responses. If both Queries and Responses do not go through FortiDDoS, then the functionality must be disabled for the device to work and report attacks properly.
In asymmetric mode, the expectation is that FortiDDoS will only see half of most DTLS Query/Response transactions. Since DTLS is UDP or SCTP and stateless, FortiDDoS cannot make assumptions of the state and may drop DTLS Queries and/or Responses as anomalous.
The following figure shows the allowed DTLS feature configuration for use with asymmetric traffic:
