Understanding FortiDDoS Prevention Mode

This section includes the following information about attack mitigation features when you deploy FortiDDoS in Prevention Mode:

• SYN flood mitigation
• DNS flood mitigation
• NTP flood mitigation
• Aggressive aging
• Rate limiting
• Blocking
• Reducing false positives

SYN flood mitigation

This section includes the following information:

• Overview
• ACK Cookie
• SYN Cookie
• SYN Retransmission

Overview

When a client attempts to start a TCP connection to a server, the client and server perform a three-way handshake:

• The client sends a SYN message to the server to request a connection.
• The server creates an entry for the connection request in the Transmission Control Block (TCB) table with status SYN-RECEIVED, sends an acknowledgment (SYN-ACK) to the client, and waits for a response.
• The client responds with an acknowledgment (ACK), the connection is established, and the server updates the entry in the TCB table to ESTABLISHED.
  
  

A SYN flood attack on a server exploits how the server maintains TCP connection state for the three-way handshake in the TCB table. In a spoofed attack, the attacker sends a large number of SYN packets from spoofed IP addresses to the server; or in a zombie attack, the attacker has used a virus to gain control of unwitting clients and sends a large number of SYN packets from legitimate IP addresses to the server. Each SYN packet that arrives creates an entry in the table. The spoofed addresses make it impossible to resolve the three-way handshake, and the TCP connection state in the TCB table remains ‘half-open’ instead of completing the cycle. It never transitions to ‘established’ and ultimately to ‘closed’. As a result, TCB table entries are not “cleaned up” by the expected life cycle, resources can be exhausted, and there can be system failure and outages.

To prepare for SYN flood attacks, FortiDDoS maintains a table of IP addresses that have completed a three-way handshake. This is called the legitimate IP address (LIP) table. Entries in the LIP expire after 1 minute.

When FortiDDoS detects a SYN flood attack, it enters SYN flood mitigation mode. In this mode, the system acts as a proxy for TCP connection requests and uses the LIP table to validate new connections:

• New SYN packets coming from addresses in the LIP table are presumed legitimate and are allowed
• FortiDDoS takes a guarded approach to other SYN packets, and they are processed according to the configured SYN flood mitigation mode option:
  • ACK Cookie
  • SYN Cookie (This is the preferred SYN flood mitigation method.)
  • SYN Retransmission

The SYN flood mitigation mode behavior applies only when FortiDDoS has detected a SYN flood with either of the following thresholds:

• syn: When total SYNs to the subnet exceeds the threshold, the SYN flood mitigation mode tests are applied to all new connection requests.
• syn-per-dst: When the per-destination limits are exceeded for a particular destination, the SYN flood mitigation mode tests are applied to all new connection requests to that particular destination. Traffic to other destinations is not subject to the tests.

ACK Cookie

The figure below illustrates the ACK Cookie mitigation mode option. FortiDDoS sends the client two ACK packets: one with a correct ACK number and another with a wrong number. The system determines whether the source is not spoofed based on the client’s response. If the client’s response indicates that the source is not spoofed, FortiDDoS-F allows the connection and adds the source to the legitimate IP address table. Fortinet recommends this option if you have enough bandwidth in the reverse direction of the attack. (This method generates 2 responses for every SYN. Thus, a 1 Gbps SYN flood will generate 2 Gbps reverse traffic.)

SYN Cookie

The figure below illustrates the SYN Cookie mitigation mode option. FortiDDoS sends a SYN/ACK with a cookie value in the TCP sequence field. If it receives an ACK back with the right cookie, a RST/ACK packet is sent and the IP address is added to the LIP table. If the client then retries, it succeeds in making a TCP connection. Fortinet recommends this option if you cannot use ACK Cookie and you anticipate high volume attacks.

SYN Retransmission

The figure below illustrates the SYN Retransmission mitigation mode option. FortiDDoS drops the initial SYNs to force the client to send a SYN again. If a pre-configured number of retransmitted SYNs arrive within a predefined time period, the FortiDDoS considers the source to be legitimate. It allows the connection to go through and adds the source to the legitimate IP address table. Fortinet recommends this option if you cannot use ACK Cookie and you anticipate low volume attacks.

Aggressive aging

This section includes the following topics:

• Slow connection detection and aggressive aging
• Rate anomalies and aggressive aging
• Idle connections and aggressive aging

Slow connection detection and aggressive aging

Expert use only: These settings should only be enabled by experts of the web servers that are being protected. We highly recommend a WAF be used to protect web servers from slow attacks.

FortiDDoS Slow Connections counts packets in both directions and if the count is not exceeded within a configurable time, the system will remove the session, send a reset to the server, and block the source.

This feature cannot be used with Asymmetric traffic since the system may not see packets in both directions.

In addition, this feature may cause false-positive drops. For example, any server that allows logins normally allows up to 90 seconds for the user to enter the first part of their credentials and then may allow another 90 seconds to enter the second part, plus more time for two-factor authentication. This is too long to rely on packet counting alone for slow connection recognition. Setting the timer to 90 seconds would allow an attacker to build up a very large number of connections before the server has aged them from its table, possibly overfilling the server tables.

Slow connection attacks are Layer 4-7 attacks that aim to make a service unavailable or increase latency to a service. These attacks are not detected by Layer 4 volumetric detection methods because they create legitimate TCP connections. With these attacks, distinguishing attackers from legitimate users is a complex task.

Variations of the Slowloris attack involve opening a legitimate TCP connection and not doing anything at all. Such idle connections fill up the connection tables in firewall and servers.

FortiDDoS can detect slow connection attacks and combat them by 'aggressively aging' slow connections. When slow connection detection is enabled, the system monitors TCP ports 80 by default, and 443 for slow connection anomalies. Monitor ports can be user-configured. If the traffic volume for a connection is below a specified byte threshold during an observation period, the connection is deemed a slow connection attack and the following actions can be taken:

• If the Service Protection > TCP Profile > TCP Session Settings > Aggressive Aging Feature Control > Slow TCP Connections option is enabled, FortiDDoS sends a RST packet to the server so that the server can remove the connection from its connection table.
• If the Service Protection > TCP Profile > TCP Packets Validation > Foreign Packet Validation option is enabled, the subsequent packets for the connection are treated as foreign packets and dropped. The event is logged as a Foreign Packets (Aggressive Aging and Slow Connections) and then as a State Anomalies: Foreign packet (Out of State) event and drops are reported on the Anomaly Drops > Layer 4.
• If Block Sources with Slow TCP Connections option is enabled, FortiDDoS applies the 'Blocking Period for Identified Sources' configured on the Service Protection Policy > Blocking Settings > Blocking Period For Identified Sources (in seconds). The drops based on this blocking period action are also logged as 'Slow Connection: Source flood' events and reported on the Flood Drops > Layer 4 page.

The figure below illustrates how FortiDDoS deployed between the client and server can monitor slow attack threats and take action to aggressively age them.

Note: By default, FortiDDoS uses the MAC address for the management interface (mgmt1) when it sends a TCP reset to aggressively age the connection. To configure a different MAC address for the resets, go to Global Settings > Settings > Settings.

Another slow connection attack, the R U Dead Yet? (RUDY) attack, injects one byte of information into an HTTP POST request. The partial request causes the targeted web server to hang while it waits for the rest of the request. When repeated, multiple simultaneous RUDY connections can fill up a web server’s connection table.

When deployed between clients and servers, FortiDDoS can detect HTTP connections that resemble RUDY attacks and 'aggressively age' the connections in the same way it does for slow TCP connection attacks. When a partial request is sent from a client, it can be dropped.

The following actions can be taken:

• If Service Protection > HTTP Profile > Incomplete Request Action setting is set to Drop, the Incomplete HTTP Packet is dropped. The event is logged as a 'Incomplete HTTP Request' event, and drops are reported on Anomaly Drops > Layer 7 > HTTP Header page.
• If Service Protection > HTTP Profile > Incomplete Request Action setting is Aggresive Aging, the Incomplete HTTP Packet is also dropped. The session entry in the FortiDDoS TCP state table is timed out and an RST is sent to the server. The event is logged as an 'Incomplete HTTP Request' event and drops are reported on Anomaly Drops > Layer 7 > HTTP Header page.
• If the Service Protection > TCP Profile > TCP Packets Validation > Foreign Packet Validation is enabled, subsequent packets for the connection are treated as foreign packets and dropped The event is logged as a Foreign Packets (Aggressive Aging and Slow Connections) and then as a 'State Anomalies: Foreign packet (Out of State)' event and drops are reported on Monitor > Anomaly Drops > TCP State Anomalies page.
• If the Block Sources with Incomplete HTTP Request setting is enabled, FortiDDoS applies the 'Blocking Period for Identified Sources' configured on the Service Protection Policy > Blocking Settings page. The drops based on this blocking period action are also logged as 'Slow Connection: Source flood' events and reported on the Flood Drops > Layer 4 page.

Track Slow TCP Connections should not be enabled if FortiDDoS is in Asymmetric Mode, since it needs to see both directions of traffic to properly determine Byte counts. Large Cookies can also cause Incomplete HTTP Requests. It is recommended that this feature should not be used on SPPs that contain firewalls, gateways, proxies or other devices that originate many outbound sessions to the Internet.

The table below summarizes the predefined thresholds for slow connection detection.

Slow connection detection thresholds

Setting	Moderate	Aggressive	User Defined	None
Slow TCP connection byte threshold	512 Bytes	2048 Bytes	1 – 65535 Bytes	Disabled – ignore entry
Slow TCP connection observation period	30 seconds	15 seconds	1 – 1023 seconds	Disabled – ignore entry

Caution: Source blocking for slow connection detection is disabled by default. Do not enable if it is typical for the SPP to receive traffic with source IP addresses that are proxy IP addresses (for example, a CDN proxy like Akamai). You want to avoid blocking a proxy IP address because the block potentially affects many users that are legitimately using the same proxy IP address.

Rate anomalies and aggressive aging

In addition to the slow connection detection, you can use Service Protection > TCP Profile > Aggressive Aging Feature Control > High Concurrent Connection per Source option and HTTP Profile > Aggressive Aging Flood option to reset the connection (instead of just dropping the packets) when the high-concurrent-connection-per-source and HTTP rate anomalies are detected.

The figure below illustrates aggressive aging when high concurrent connection or HTTP rate anomalies are detected.

Note: The initial drops resulting from aggressive aging appear in logs and reports as SYN per Source flood drops or HTTP method flood drops, as appropriate. If the TCP session feature control option foreign-packet-validation option is also enabled, subsequent packets from these sources are dropped as foreign packet anomalies because the packets are correlated with a connection that has been reset.

Idle connections and aggressive aging

FortiDDoS maintains its own massive TCP connection table. To reserve space in this table for active traffic, FortiDDoS periodically uses aggressive aging to reset inactive connections based on the idle timers configured in Service Protection > TCP Profile > TCP Session Idle Timeout.

Rate limiting

FortiDDoS maintains rate meters for packets, connections, and requests. It drops packets that exceed the maximum rates (which are based on history, heuristics, and a multiplier that you specify or based on an absolute limit that you specify).

Rate limiting thresholds are not only a good way to detect attacks, but also an effective method to protect servers. When deployed between client and server traffic, the rate limits ensure that a server is not inundated with more traffic than it can handle.

When FortiDDoS drops packets that exceed the maximum rates, the originating client retransmits the packets. Traffic originating from attackers is likely to be marked by extended blocking periods, while traffic originating from legitimate clients is likely to find itself within the acceptable rates as thresholds are reevaluated.

Blocking

In Prevention Mode, traffic that exceeds protection profile thresholds is blocked for the configured blocking period. When blocking period is over, the threshold is checked again.

The below examples assume that the blocking period has the default value of 15 seconds.

Example 1: Too many packets with a specified protocol

• The system drops incoming packets with the protocol that are destined for a specific network (specified as a subnet) for 15 seconds. It forwards all other packets.
• The system tracks the source of the packets to determine if this is a single-source attack.
• After 15 seconds, the system checks the rate of the packets against the threshold again.

Example 2: Too many mail messages to an SMTP server

• The system drops incoming TCP packets destined for port 25 on the mail server (or the mail server’s network) for 15 seconds. It forwards all other packets.
• The system tracks the source of the packets to determine if this is a single-source attack. If there is a single source, the appliance blocks all packets from that source for 15 seconds.
• After 15 seconds, the system checks the rate of the packets against the threshold again.
• Mail clients assume that the network is slowing down because TCP packets are lost. The clients start to send packets at a slower rate. No mail messages are lost.

Example 3: Too many SYN packets to a web server

• The system checks SYN packets destined for a web server. If they come from an IP address in the legitimate IP address table, the system permits them to continue to the web server. The appliance allows these packets as long as their rate is lower than the new-connections threshold (designed to indicate zombie floods). The system forwards all other SYN packets.
• If the IP address does not exist in the legitimate IP address table, and if the SYN flood mitigation method is SYN cookie, the system performs a proxy three-way handshake to validate the IP address.
• After 15 seconds, the system checks the packet rate against the threshold again.

Example 4: Too many concurrent connections from a single source

• If there are too many concurrent TCP connections from a single source, the system blocks new connections until the number of concurrent connections is less than the threshold.
• Once the concurrent connection count goes down, the system allows the source to establish new connections.
• The system tracks the source of the connections to determine if this is a single-source attack. If there is a single source, the appliance blocks all packets for 15 seconds.
• After 15 seconds, the system checks the connection rate against the threshold again.

Reducing false positives

When the FortiDDoS-F system blocks traffic because it exceeds the threshold of a specific traffic parameter, it blocks subsequent traffic with the offending characteristic. As a result, during the blocking period, the system might block traffic from legitimate sources in addition to traffic from a malicious source.

The system uses the following mechanisms to minimize the impact of these false positives:

• Because the blocking period is short (1 to 15 seconds), the system frequently checks to see if the traffic no longer exceeds the threshold that detected the attack.
• The system simultaneously attempts to determine whether the attack is not spoofed and can be attributed to one or a few sources. If it can identify these sources (called source attackers), it applies a “multiplier” to them. The multiplier makes traffic from these source attackers more likely to exceed the most active source threshold, which causes the system to apply a longer blocking period.
• If it identifies attackers, the system can stop blocking traffic from legitimate sources as soon as the standard, shorter blocking period is over, but continue to block traffic from source attackers for a longer period.

The figure below illustrates how the FortiDDoS system responds immediately to attacks but then adjusts its attack mitigation activity to packets from specific sources only.

In this example, the standard blocking period is 15 seconds and the blocking period for source attackers is 60 seconds (the default value). The multiplier for source attackers is 16, and the most active source threshold is 100 packets per second.

When Source B sends 90 fragmented packets, the calculated rate is 1440 packets per second, which exceeds the most active source threshold. But when Source C sends 2 fragmented packets per second, the calculated rate of 32 packets per second does not exceed the threshold. Thus, the system applies the longer blocking period to Source B only.

Source C, which sends an insignificant number of fragmented of packets, is blocked only for the length of the shorter, standard blocking period.