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.
DNS Feature Controls may be completely different for the following types of SPPs:
-
DNS Servers
-
Firewalls and other outbound session originators
-
Web servers and VPN servers
|
DNS is a very complex protocol with many variations. In all cases, when using the configuration below, keep SPPs in Detection Mode and look for excessive inbound DNS drops (more than a few per day). If unsure, contact Fortinet Customer Service & Support. |
DNS Feature Control configuration for Authoritative DNS Servers in Asymmetric Mode
Authoritative DNS servers will see inbound Queries (0-100%) and outbound Responses (0-100%). They are most often attacked with DNS Query Floods, so inbound Query Flood Mitigation can be used.
DNS Feature Control configuration for Firewalls in Asymmetric Mode
Firewalls, WiFi gateways and other outbound originators will see outbound Queries (0-100%) and inbound Responses (0-100%). They may be attacked by both DNS Query Floods and DNS Response Floods.
For DNS Query Floods, use the settings below. For DNS Response floods, use DNS Rcode Thresholds and DNSSEC Thresholds.
DNS Feature Control configuration for web servers and VPN servers in Asymmetric Mode
Web servers and VPN servers should see very little DNS traffic – perhaps occasional DNS outbound Queries for NTP servers, for example. Users can improve this mitigation by ensuring outbound Queries from these servers go via the firewall.
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 one direction 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.
The red-hghlighted "state" checks below must be disabled.
NTP Anomaly Check primarily consists of find 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 and can be used in Asymmetric Mode. This single feature will stop >99% of NTP floods.
When in Asymmetric Mode, use the four NTP Scalar Thresholds — see Thresholds.
The following figure shows the allowed NTP feature configuration for use with asymmetric traffic:
Understanding FortiDDoS Asymmetric Mode for DTLS
Both DTLS Profile features monitor DTLS states and thus must be disabled in Asymmetric Mode.
Use the three DTLS Thresholds for protection from DTLS attacks in Asymmetric mode — see Thresholds.
The following figure shows the allowed DTLS feature configuration for use with asymmetric traffic:
Understanding FortiDDoS Asymmetric Mode for QUIC
Note: The QUIC protocol is very new. As such, developers in that space may not be adhering perfectly to the RFCs. We are also seeing protocol violations when the developer controls both the client and server firmware (often in mobile applications).
The QUIC profile is intended to protect from QUIC attacks but firewall users may legitimately use QUIC for Google, Facebook and other applications.
If in doubt, disable all and use the three QUIC thresholds — see Thresholds.
When using these features:
- Create an identical QUIC Profile for each SPP
- Use Dashboard>Top Attacks to inspect for OUTBOUND QUIC anomaly drops
- If you see regular outbound drops, disable the specific feature or all features and use the Thresholds
The following figure shows the allowed QUIC feature configuration for use with asymmetric traffic:
