Understanding FortiDDoS Prevention Mode

2. 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.

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 from ‘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 5 minutes.

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:

Figure 12 illustrates the ACK Cookie 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 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.)

Figure 13 illustrates the SYN Cookie 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.

Figure 14 illustrates the SYN Retransmission option. FortiDDoS drops the initial SYNs to force the client to send a SYN again. If a preconfigured 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.

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

• 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.

This section includes the following topics:

Slow connection attacks are Layer 7 attacks that aim to make a service unavailable or increase latency to a service. These attacks are not detected by Layer 4 detection methods because these are 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” idle connections. When slow connection detection is enabled, the system monitors TCP ports 21, 22, 23, 25, 80, and 443, as well as user-configured HTTP service ports, for slow connection anomalies. 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 SPP aggressive aging track-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 SPP TCP state anomaly detection foreign-packet-validation option is enabled, subsequent packets for the connection are treated as foreign packets and dropped. The event is logged as a “State Anomalies: Foreign packet” event and drops are reported on the Monitor > Anomaly Drops > TCP State Anomalies page.

• If the SPP source blocking option is enabled, FortiDDoS applies the “Blocking Period for Identified Sources” configured on the Global Settings > Settings page. The event is logged a Source Flood and drops are reported on the Monitor > Flood Drops > Layer 3 page.

Figure 15 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, the slow connection observation period starts. If a response for this partial request is not sent by server before the observation period expires, the connection is deemed a slow connection attack and the following actions can be taken:

• If the SPP aggressive aging track-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.

Table 9 summarizes the predefined thresholds for slow connection detection.

Table 9: Slow connection detection thresholds
Setting	Moderate	Aggressive
Slow TCP connection byte threshold	512 bytes	2048 bytes
Slow TCP connection observation period	30 seconds	15 seconds
HTTP partial request per source threshold	100 partial requests	20 partial requests
HTTP partial request to response observation period	120 seconds	5 seconds

Note: To enable the system to send TCP resets to the desintation server when the these thresholds are reached, go to Protection Profiles > SPP Settings and select the Aggressive aging TCP connection feature control option track-slow-tcp-connections.

To enable the system to block traffic from the offending source IP address, go to Protection Profiles > SPP Settings and enable Source blocking for slow connections.


	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.

In addition to the slow connection detection, you can use the SPP aggressive aging TCP connection feature control options to reset the connection (instead of just dropping the packets) when the following rate anomalies are detected:

Figure 16 illustrates aggressive aging when high concurrent connection or Layer 7 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.

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. This behavior is not configurable, and it generates no logs.

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.

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 following examples assume that the blocking period has the default value of 15 seconds.

• 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.

• 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.

• 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.

• 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.

When the FortiDDoS 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:

• 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.

Figure 17 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.