Configuring FortiDDoS for asymmetric traffic

This recipe shows you how to set up FortiDDoS on networks with asymmetric traffic.

Configuring FortiDDoS for asymmetric traffic – overview

FortiDDoS Asymmetric Mode is used for a specific BGP-based network design.  With a /24 or larger public subnet, an ASN and 2 (or more) ISPs,  BGP can be configured to support traffic simultaneously on all ISP links

When an inbound packet arrives from ISP-1, your BGP tables may determine that the shortest path back to the client’s Source IP is via ISP-2.  This creates asymmetric traffic, inbound on one link and outbound on a different link. The inbound/outbound asymmetry can be on either link or the session may stay together on either of the single links.  Unless your BGP is configured purely for failover (only one link used at a time) there is almost a guarantee of some asymmetric traffic.

Prerequisites and warning

This recipe assumes you understand the general process for moving FortiDDoS from Learning Mode to Detection Mode to Prevention Mode. Adjusting Asymmetric Mode should be done as part of the initial configuration of the system but it can be changed at any time with little impact on traffic, provided the system is not in Prevention Mode.

However, if you have asymmetric traffic and move the system to Prevention Mode without adjusting the settings as detailed below, you might see a significant impact on TCP traffic.

TCP state tracking

While FortiDDoS is invisible to passing traffic, it does track state conditions of passing TCP flows because many TCP-based attacks use out-of-state packets. Understanding the current state of a session is important for the fastest detection and mitigation of those attacks. 

Asymmetric Mode allows FortiDDoS to infer the state of a TCP session from the packets it is seeing, even though it is not seeing the entire bidirectional “conversation”.

Other attacks like SYN and SYN-per-Destination floods; and any rate floods, can be mitigated no matter if the traffic is symmetric or asymmetric.

No UDP virtual state tracking required

Most firewalls create virtual state machines to track the bidirectional flow of UDP traffic but UDP DDoS attacks are not state-based. The attack either does not expect a response, is itself a reflected response or the response goes to a spoofed Source IP address that is the actual target of the attack.  For most UDP floods, FortiDDoS is looking at rates, sources and anomalies of the inbound traffic to mitigate the attacks.  

An exception to this rule is DNS, where FortiDDoS can match DNS Queries to Responses and drop any unsolicited Responses.  Other DNS features also require FortiDDoS to see the outbound Query.  These will not work correctly with asymmetric traffic designs,  where outbound Queries may not be seen, so additional mitigations are suggested below for Asymmetric Mode.

FortiDDoS Asymmetric Mode and physical link connections

Both links traverse FortiDDoS

No action required.

FortiDDoS “virtually reassembles” TCP session information from both links without disturbing traffic on either link.

DNS Queries and Responses can be matched.  (Also see the comments on Encrypted DNS below.)

Only one link traverses FortiDDoS

Asymmetric Mode settings are required.

FortiDDoS may only see 1/2 of any TCP session. It makes assumptions from seeing partial handshakes with a minor loss of visibility and mitigations.

DNS mitigations must also be changed.

This design has some risks since attacks can originate from the ISP peer or transit provider on the unprotected link. Ensure BGP is set to minimize inbound traffic on the unprotected link.

This design is common in ISP inline protection since there are often several peers or transit providers and larger ISP clients may cause asymmetric traffic with their own BGP.

One link traverses each of two FortiDDoS in HA or Standalone Modes

Asymmetric Mode settings are required on each FortiDDoS as above.

HA can be used to ensure the SPP settings on the Slave FortiDDoS match the Master, in case BGP fails-over traffic on the Master link to the Slave link.

FortiDDoS Asymmetric Mode configuration changes

If your design matches the Asymmetric Mode diagrams above, with only one link (generally the primary inbound link but true for either primary direction) passing through one FortiDDoS, then change the following system settings:

1. Setting Asymmetric Mode

Go to Global Settings > Settings > Settings > Deployment tab

Enable:

  • Asymmetric Mode and
  • Allow Inbound SYN/ACK

FortiDDoS will compensate for unseen TCP session handshake transitions with a slight loss of mitigation as detailed below.

2. Changing SPP TCP settings for Asymmetric Mode for ALL SPPs

For ALL configured SPPs, go to Protection Profiles > SPP Settings > TCP Tab

Then disable (uncheck) the following:

  • Sequence Validation
  • State Transition Anomalies Detection
  • Slow Connections

In Detection Mode:

  • Disable Foreign Packet Validation.

In Prevention Mode

  • Enable Foreign Packet Validation

3. Setting SPP DNS Feature controls for Asymmetric Mode

For ALL configured SPPs, go to Protection Profiles > SPP Settings > DNS Feature Controls:

  • Disable the first 5 features as seen in the screenshot.
  • Normally do not enable Block Identified Sources.
  • DNS Anti-Spoofing may be used Inbound
  • TC=1 for DNS Flood Mitigation Mode is normal.

SPP DNS Features for Asymmetric Traffic

 

4. Setting SPP DNS Anomaly controls for Asymmetric Mode

DNS Anomalies may be valid depending on other factors which are difficult to discover with asymmetric traffic and false-positive drops of DNS packets can have a significant impact. 

As a rule of thumb, if the SPP contains a major manufacturer:

  • firewall
  • email server
  • web proxy
  • WiFi gateway,

proprietary, encrypted DNS packets are often sent to that vendor’s web or domain filtering service. FortiDDoS cannot decrypt these and sees numerous anomalies resulting in dropped DNS packets, affecting services.  
Unless you know that there is no encrypted DNS in the SPP, these Anomaly features should be disabled.

SPP DNS Anomalies in Asymmetric Mode

After Learning, Traffic Statistics generation and System Recommended Thresholds have been completed for all SPPs:

5. Setting SPP Scalar Thresholds for Asymmetric Mode

For ALL SPPs configured in the system, except SPP-0, navigate to Protection Profiles > Thresholds > Thresholds > Scalars.

If not already set to system maximums (Release 4.7.0+), set ALL Outbound Scalar Thresholds to very high rates (system maximum for each is OK).

 

6. Setting UDP port 53 Threshold

Because DQRM must be disabled in Asymmetric Mode, FortiDDoS has less visibility on DNS Reflected Response Floods.  To improve mitigation, add UDP Port 53 Thresholds to every SPP.

For each SPP configured in the system,  navigate to Monitor > Layer 4 > UDP Ports

Enter 53 in the UDP Port number to be monitored field and click Show Graph.

Set direction to INBOUND and set the correct SPP.

Set the time period
(1h 8h 1d 1w 1m 1y) to as long as you have traffic.

Estimate and record the peak inbound data rate (pps) from the green (Egress) graph line. The example in the screenshot is about
260 pps.

Go to Protection Profiles > Thresholds > Thresholds > UDP Ports. Note, you will see a gap in the ranges between Port 52 and Port 54.

Click +Add and complete the pop-up form as follows:

  • Name:  Anything meaningful (a-Z, 0-9, “-” or “_” only)
  • Port Start53
  • Port End: 53
  • Inbound Threshold:  5x the rate recorded above
  • Outbound Threshold: Leave as default (system maximum)

The UDP Port Threshold does not require a specific naming convention and, does not need to be placed in numerical order within the list.  It will automatically be appended to the list.

UDP Port 53 Threshold

 

Managing Asymmetric traffic environments can be complex. For additional information or assistance, please contact Fortinet Support.

FortiDDoS has no IP nor MAC addresses in the data path and is completely invisible to passing traffic.
Floods of ACKs, SYN-ACKs, RSTs or FINs (in fact any combination of TCP flags) are common. FortiDDoS treats out-of-state packets as anomalies, just like it would treat invalid TCP flag combinations like Xmas Tree (all flags set).
FortiDDoS drops out-of-state packets immediately, without waiting for a threshold to be crossed. FortiDDoS inspects every passing packet for all violations including state.
SYN and SYN-per-Destination mitigation validates that the Source IP is the sender of the original SYN and not spoofed. SYN packets from spoofed Sources are dropped.
A UDP fragment flood, for example.
Attacks reflected off external DNS or NTP servers towwards you, for example.
Attacks reflecting from your DNS server to a target IP, for example.
Some features that require visibility of both Inbound and Outbound traffic will not work correctly and must be disabled, if one direction is not seen.

Many DNS attacks are reflected through 3rd-party Recursive DNS servers. You normally do not want these servers to be prevented from reaching your services, you just want to drop the attack packets.  If you know that your SPP should never be seeing DNS Queries, enable this feature.

DNS Anti-Spoofing may show unexpected results if enabled in Detection Mode

This can depend on the types of attacks seen and servers protected. See DNS server potection Recipe 

If you have subnets / SPP Policies configured in SPP-0, include it in these instructions. If you do not, use the existing learned Thresholds.
This is a rule-of-thumb which you can change if needed.  For example, if you know you have no subnets in SPP-0 (recommended), you can set Outbound Scalar and other thresholds very low for SPP-0 if:
  • both legs traverse the FortiDDoS or
  • if one of 2 HA FortiDDoS sits on the outbound leg.

This will prevent compromised devices from attacking outbound with spoofed IPs.

DNS Reflected Response Floods are used to attack any type of infrastructure or service.

Approximate upwards – single-digit accuracy is not critical