SYN Flood (SYN flood) is a typical DoS (Denial of Service, denial of service) attack. The effect is that the server runs out of TCP connection resources and stops responding to normal TCP connection requests.
Speaking of the principle, we have to start with how TCP establishes a connection. The two sides of the communication must go through at least three successful information exchanges before they can enter the connection full-open state (Full-Open), which is called the TCP three-way handshake to establish a TCP connection.
This article assumes that the connection initiator is A, and the connection receiver is B, that is, B listens for the connection request sent by A on a certain port (Port). As shown in the figure below, A is on the left and B is on the right.
A first sends a SYN (Synchronization) message to B, asking B to be ready to receive data; B feeds back a SYN-ACK (Synchronization-Acknowledgement) message to A after receiving it. This message has two purposes: (1) To A Confirm that it is ready to receive data. (2) At the same time, A is also required to be ready to receive data. At this time, B has confirmed the receiving status to A, and waits for A's confirmation. The connection is in a half-open state (Half-Open) , as the name implies, it is only half-opened; A sends an ACK (Acknowledgement) message to B again after receiving it, and confirms to B that it is ready to receive data. At this point, the three-way handshake is completed, and the "connection" is established. According to the request of the other party, it has entered a state where it can receive messages. The above "status" that each other requires confirmation from each other is mainly the message sequence number (SequenceNum) to be used by both parties. In order to ensure that the message arrives at the upper-layer application of the receiver in the sending order, TCP needs to use the message sequence number to mark the sending sequence of the message. TCP is a "duplex" connection and supports two-way communication at the same time, that is, both parties can send messages to each other at the same time. sequence number); SYN-ACK and ACK messages open the B→A one-way communication channel (A learns the message sequence number of B)
The above discussion is to establish a connection under ideal conditions where both parties are honest and trustworthy and the network is normal. However, the actual situation is that the network may be unstable and may lose packets, so that the handshake message cannot reach the other party, or the other party may deliberately not follow the rules, deliberately delay or not send the handshake confirmation message. Assuming that B provides services through a TCP port, when B receives the SYN message from A, it actively feeds back the SYN-ACK message, so that the connection enters a half-open state, because B is not sure of the SYN-ACK message it sent to A or A Whether the feedback ACK message will be lost halfway, so a Timer will be set for each half-open connection to be completed. If the ACK message from A has not been received after the time has passed, the SYN-ACK message will be resent to A until It will only give up after retrying more than a certain number of times.
Being a good person comes at a price. In order to help A to connect smoothly, B needs to allocate kernel resources to maintain a half-open connection. Then when B faces a large number of big flickers of A [1], as shown in the figure above, a SYN Flood attack is formed. . Attacker A can control the broiler to send a large number of SYN messages to B but do not respond to ACK messages, or simply forge the Source IP in the SYN message, so that the SYN-ACK messages fed back by B are lost in the sea [2], resulting in a large number of half-doses that B is destined to fail to complete. Open connections occupy until resources are exhausted and stop responding to normal connection requests [3].
Next, let’s talk about coping strategies. The simplest and crudest way is to increase the connection capacity of the TCP port and reduce the resource consumption time of the half-open connection. On Linux, the following configuration can be modified to increase the upper limit of the TCP half-open connection queue size:
/proc/sys/net/ipv4/tcp_max_syn_backlogYou can reduce the time to wait for an ACK message in the half-open state or the number of retries to send a SYN-ACK message:
/proc/sys/net/ipv4/tcp_synack_retriesOr enable some kind of half-open connection recycling mechanism, so that when the half-open connection queue is full, the operation of "removing the old and welcoming the new" is performed. Of course, not all systems support this mechanism.
The above method is more like a stopgap measure, which only relieves the system pressure when being attacked, and slightly raises the defense threshold, but also affects the establishment of some normal requests, such as reducing the number of SYN-ACK retries. It will reduce the connection success rate of some normal users with poor network environment; and the attacker can improve the attack effect by changing the strategy slightly. Part of the normal waiting half-open connection is dequeued before the ACK message arrives.
Another idea is to stifle the attack in the cradle, such as deploying routers that support "IP anti-counterfeiting", filtering out SYN messages with forged IP addresses, or increasing the protection awareness of netizens and reducing the scale of the broiler network, etc., but this is too much. Ideally, sometimes the attacker has a high-level background, and there is no need to catch the broiler before attacking, hehe, you know ☺.
The above two ideas do not directly hit the crux - any SYN message, no matter who the source is, will consume some of B's resources to save the half-open state, and gradually achieve the effect of "dove occupying the magpie's nest". SYN Cache and SYN Cookies are two schemes proposed based on this observation.
The starting point of SYN Cache is mainly aimed at the problem of "dove occupying a magpie's nest". The basic principle is as follows: construct a global Hash Table to cache all the current half-open connection information of the system, and clear the relevant information from the Cache if the connection is successful; Hash Table There is also a limit to the capacity of each bucket in the . When B receives a SYN message, it will add the half-open connection information to the Hash Table, in which the generation of the key is very important. It not only uses the information contained in the SYN message (such as Source IP, Port, etc.), but also needs to do It is difficult for an attacker to guess, and it is usually generated by a secret function, so that all half-open connections, whether good or bad, are evenly distributed to different "buckets" seemingly randomly, which greatly increases the difficulty of the attack. Because in order to achieve the DoS effect, the attacker needs to make each bucket reach the full state, and also have a fast enough "filling bucket" speed, so that the normal half-open connection is kicked out of the bucket before the establishment is completed. Such attacks are estimated to be exposed long before they reach their goals.
The main focus of SYN Cookies is to try to eliminate the resource consumption of the half-open connection. The principle is similar to the HTTP Cookies technology. B encodes the half-open connection information into "Cookie" through a specific algorithm, which is used as the message number (SequenceNum) for B to A. It is returned to the connection initiator A along with the SYN-ACK message, so that B does not save any information until the connection is completely established. If A is a normal user, it will send the last handshake message (ACK) to B, and B will verify the content of the "Cookie" and establish a connection after receiving it; if A is an attacker, it will not send back an ACK message to B, and B will also There is no loss, that is to say, a simple SYN attack will not cause B's connection resource consumption. Of course, this scheme also has certain shortcomings. The most obvious one is that B does not save the half-open state of the connection, so it loses the ability to resend the SYN-ACK message. On the one hand, it will reduce the connection success rate of normal users, on the other hand, it will lead to In some cases, both parties in normal communication will misunderstand whether the connection is successfully opened. For example, the third handshake message (ACK) sent by A to B is lost halfway. In this case, the upper-layer application needs to adopt a special policy to deal with it.
Of course, all of these schemes are not perfect and each has its own advantages and disadvantages. The final strategy may be a combination of several schemes to form a defense system that resolves the attack locally in advance without affecting the entire system.
In the actual attack, the attacker is unlikely to send a large number of SYN messages violently, which will expose himself in advance, but first sniff out the TCP configuration parameters of the attacked object, such as the expiration time of the semi-connected state, the queue upper limit, etc., and master the rhythm. More tailored attack messages are sent to occupy the nest in the most economical and undetectable way, filling the half-connected queue.
Forging Source IP (IP Spoofing) has certain attention. You cannot choose a real host with TCP connection capability, because the TCP protocol requires that when it receives an inexplicable SYN-ACK message, it directly returns an RST message, which instead prompts the attacked B. A fake half-open connection can be terminated early to clear it from the queue.
This means that the connection resources of a specific port (Port) are exhausted and cannot accept new connection requests, and the connections that have been established on the port and other ports that have not been attacked are not affected.