SYN flood Attack and defense method (RPM)

Original link: http://blog.csdn.net/bill_lee_sh_cn/article/details/6065704

First, why SYN flood can cause harm
This should start with the implementation of the TCP/IP protocol stack of the operating system. When a TCP port is opened, the port is in a listening state, and continuously monitors the SYN packets sent to that port, and once a SYN message is received from the client, a TCB is assigned to the request (transmission Control Block), usually a TCB requires at least 280 bytes, and in some operating systems the TCB even requires 1300 bytes and returns a SYN ACK command that immediately transitions to syn-received that is the half-open connection state. Some operating systems can open up to 512 half-open connections (such as the Linux2.4.20 Core) on sock implementations. This process is as follows:

As you can see from the above procedure, if you maliciously send a large number of SYN packets to a server port, you can enable the server to open a large number of half-open connections, allocate the TCB, and thus consume a large amount of server resources, and also make the normal connection request cannot be appropriate. The attack initiator's resource consumption is negligible.
Ii. how to defend against SYN flood attack
Let's take a look at the types of SYN flood, as shown in:

1. Direct Attack Attackers use a fixed source address to initiate an attack, which minimizes the cost to the attacker
2. Spoofing Attack attack using the changed source address, this method requires the attacker to constantly modify the source address, in fact, the consumption is not very
3. distributed Direct Attack This attack is primarily an attack using a botnet for fixed source addresses

For the first attack of the guard can use a relatively simple method, that is, to monitor the SYN packet, if the discovery of an IP launched more attack packets, the IP is blacklisted directly. Of course, the following methods can also be used to prevent it.
The use of the above method for a constantly changing source address is not possible, first the SYN message from a spoofed IP may not be too much, not to the denied threshold, and second from the spoofed IP (real) request will be rejected. Therefore, other methods must be used for processing.
1. Invalid connection monitoring release
This method keeps monitoring the system's half-open and inactive connections, removing the connections when a certain threshold is reached, freeing up system resources. This method is equal to all connections, and due to the large number of semi-open connections caused by SYN Flood, normal connection requests are also submerged in which this method is mistakenly released, so this approach belongs to the entry-level SYN flood method.
2. The method of delaying TCB allocation
From the previous SYN flood principle can be seen, the consumption of server resources mainly because when the SYN data message arrives, the system immediately allocates the TCB, thus occupying resources. SYN Flood is difficult to establish normal connection, so when the normal connection is established, then allocating TCB can effectively reduce the consumption of server resources. The common approach is to use SYN cache and SYN cookie technology.
Syn Cache Technology:
This technique is not eager to allocate the TCB when receiving a SYN data message, but instead responds to a SYN ACK message and saves the semi-open connection information in a dedicated hash table (Cache) until it receives the correct response ACK message redistribution TCB. In the FreeBSD system, this cache uses only 160 bytes per half-open connection, much less than the 736 bytes required by the TCB. In the Sent SYN ACK need to use a own sequence number, which can not be guessed by the other side, or for some slightly more intelligent SYN flood attack software, they send a SYN message after sending an ACK message, if their own sequence Number is guessed by the other side, it will be set up a real connection. Therefore, it is common to use some encryption algorithms to generate sequence number that is difficult to predict.
Syn Cookie Technology:
For SYN Attacks, the SYN cache does not allocate the TCB, but in order to determine the correctness of the sequence number in the ACK message sent by the subsequent counterpart, it is necessary to use some space to save the information generated by the sequence. Also caused a waste of some resources.
Syn Cookie technology does not use any storage resources at all, this method is clever, it uses a special algorithm to generate sequence number, this algorithm takes into account the other's IP, port, the IP, port fixed information, and the other side can not know and their own relatively fixed some information , such as MSS, time, etc., after receiving the other's ACK message, recalculate again to see if it is the same as in the other response message (Sequence Number-1), so as to determine whether to allocate TCB resources.
3. Using the SYN Proxy firewall
SYN cache technology and SYN cookie technology are generally a host-protection technology that requires the support of the system's TCP/IP protocol stack, and not all operating systems currently support these technologies. As a result, many firewalls provide a function of the SYN Proxy, the main principle of which is to validate the SYN request that is attempting to traverse, and then release it, describing the process:

As you can see from the (left), the firewall initiates a SYN request to the internal server (Listener) after confirming the validity of the connection, and on the right, all invalid connections cannot reach the internal server. The firewall uses other techniques such as SYN cookie or SYN flood to verify the validity of the connection.
One thing to keep in mind in this way is that the firewall needs to proxy the packets that occur during the entire active connection, as shown in the following:

Because the firewall replaces the Issued SYN ACK packet with the sequence number C, and the server's true response packet has a sequence number C ', which has a difference of |c-c ' |, the serial number is modified when each relevant data message passes through the firewall.

TCP Safe Reset Technology:
This is also a way for the firewall SYN proxy to work as shown in the following:

This method sends out a safe Reset command packet immediately after verifying the connection, allowing the client to reconnect, and the SYN message firewall that appears is directly released. In this way, the firewall does not need to change the serial number of the data packets through the firewall. This requires that the client's TCP stack supports the related conventions in RFC 793, and that the time to establish the connection will be extended due to the two-time handshake process.

Reference documents
1. Traffic Anomaly Detector and Guard (Riverhead Networks) FAQ
2. The SYN cookie principle and its implementation in the Linux kernel
3. Defenses against TCP SYN flooding Attacks

SYN flood Attack and defense method (RPM)