Figure 10: TCP Connection Three-Way Handshake
This section includes the following information about attack mitigation features when you deploy FortiDDoS in Prevention Mode:
This section includes the following information:
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.
Figure 10: TCP Connection Three-Way Handshake
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 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:
The SYN flood mitigation mode behavior applies only when FortiDDoS has detected a SYN flood with either of the following thresholds:
Figure 12 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 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 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.
Figure 14 illustrates the SYN Retransmission mitigation mode 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.
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 or UDP 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:
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. FortiDDoS monitors both the client and the server sides of the connection. A server cannot respond until it has received the complete HTTP request. If it has not responded to the source of the partial request by the end of the observation period, FortiDDoS considers it a slow connection. Not all slow connections are attacks, however, so FortiDDoS uses a client-side threshold to determine attack behavior. If the connection is deemed slow and the rate of partial HTTP requests from the identified source exceeds the configured threshold, it is considered a slow connection attack. The following actions can be taken (same actions as slow TCP connection):
Table 9 summarizes the predefined thresholds for slow connection detection.
| Setting | Moderate | Aggressive |
|---|---|---|
| Slow TCP connection byte threshold | 512 bytes | 2048 bytes |
| Slow TCP connection observation period | 30 seconds | 15 seconds |
To enable aggressive aging when 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.
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:
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.
Source C, which sends an insignificant number of fragmented of packets, is blocked only for the length of the shorter, standard blocking period.
