Overview
SYN Flood is a very dangerous and common DoS attack method in the network environment built on IPv4-supported network protocols. So far, there are not many effective methods to prevent SYN Flood attacks, and SYN Cookie is one of the most famous methods. SYN Cookie principle was invented by D. J. Bernstain and Eric Schenk. Various implementations are available in many operating systems. Including Linux. This article introduces the principles of SYN Flood attacks and SYN cookies respectively. More importantly, it introduces how to implement SYN cookies in the Linux kernel. Finally, this article provides an idea to enhance the SYN Cookie function in Linux.
1. SYN Flood Attack
SYN Flood attack is a typical Denial-of-Service (Denial of Service) attack. The so-called denial of service-type attacks means that the victim host or network cannot provide good services through attacks, thus indirectly achieving the purpose of attacks.
SYN Flood attacks use the Three-Way Handshake process of TCP in IPv4. Everyone knows the Protocol stipulates that if one end wants to initiate a TCP connection to the other end, it needs to first send the tcp syn packet to the other end, and the other end sends a tcp syn + ACK packet back after receiving the packet, the initiator sends the tcp ack packet back, and the three-way handshake ends. The initiator of the TCP connection is called "TCP Client", and the receiver of the TCP connection is called "TCP Server )". It is worth noting that when the TCP server receives the tcp syn request packet, before sending the tcp syn + ACK packet back to the TCP client, the TCP server must first allocate a data zone dedicated to serve the upcoming TCP connection. Generally, the Connection status when the SYN packet is received but the ACK packet is not received is Half-open Connection ).
In the most common SYN Flood attack, an attacker sends a large number of tcp syn packets to the victim in a short time. In this case, the attacker is a TCP client and the victim is a TCP server. According to the above description, the victim will allocate a specific data zone for each tcp syn packet, as long as these SYN packets have different source addresses (this is easy for attackers to forge ). This will cause a great burden on the TCP server system, and eventually the system will not work properly.
Ii. Principles of SYN Cookie
SYN Cookie is a method used to modify the three-way handshake protocol on the TCP server to prevent SYN Flood attacks. The principle is that when the TCP server receives the tcp syn Packet and returns the tcp syn + ACK packet, a cookie value is calculated based on the SYN Packet instead of a dedicated data zone. When receiving a tcp ack packet, the TCP server checks the validity of the tcp ack packet based on the cookie value. If valid, assign a dedicated data area to process future TCP connections.
From the above introduction, we can see that the principle of SYN Cookie is relatively simple. In practical applications, there are multiple implementation methods.
Iii. SYN Cookie implementation in Linux Kernel
SYN Flood is well protected in the Linux kernel. The following discussions are all about the Linux 2.4.20 kernel. Each sock has a tcp_opt, which is the TCP option of the sock. In tcp_opt, there is a tcp_listen_opt, which stores some options saved by the sock in the LISTEN State. There is an array of the open_request structure and the array length is TCP_SYNQ_HSIZE (512 ). All of these indicate that a maximum of 512 semi-open connections can be enabled at the same time in a sock (this is the maximum value when other constraints are not taken into account, which is not actually reached ). When the array is full, the new open_request replaces an old open_request. In this way, even if the SYN Cookie is not enabled, the system will be protected from paralysis when the SYN Flood occurs. The problem is that this method will discard normal TCP connection requests in the face of SYN Flood attacks. The role of SYN Cookie is to ensure that illegal TCP connection requests can be rejected and normal connections can be established in the face of SYN Flood attacks.
The Linux kernel processes the TCP flow mainly through the function implementation in the tcp_ipv4.c file. Specifically, when processing a tcp syn packet, the system enters the tcp_v4_conn_request function. Call cookie_v4_init_sequence to generate an ISN (Initial Sequence Number ). The Linux kernel uses it as a Cookie in the SYN cookie process.
The cookie_v4_init_sequence function is defined in the syncookies. c file. It also calls the secure_tcp_syn_cookie function in the random. c file. The actual computation of cookies is carried out in this function.
Two macros are given before the secure_tcp_syn_cookie function is defined in the random. c file. Their definitions are as follows:
# Define COOKIEBITS 24
# Define COOKIEMASK (_ u32) 1 <COOKIEBITS)-1)
COOKIEBITS indicates the cookie bit length. COOKIEMASK is a COOKIEBITS long bit string, and all bits are 1.
Two other bits are defined as a _ u32 two-dimensional array.
Static _ u32syncookie_secret [2] [16-3 + HASH_BUFFER_SIZE];
All the bit values are randomly assigned in secure_tcp_syn_cookie. Use the get_random_bytes function. They are the keys used to create cookies. These two randomly generated bits are the key to the entire SYN Cookie implementation scheme. In addition, syncookie_init controls the changes to the two keys.
It also needs to be noted that in the file syncookies. c defines a table named static _ const msstab [], which stores possible MSS (Maximum Segment Size) values.
The returned value of the secure_tcp_syn_cookie function is the calculated ISN value, that is, the cookie. For ease of description, we provide the following definitions:
Tmp1: = saddr + daddr + (sport <16) + dport) + syncookie_secret [0]
Tmp2: = saddr + daddr + (sport <16) + dport) + syncookie_secret [1]
Tmp11: = HASH_TRANSFORM (tmp1 [16], tmp1)
Tmp22: = HASH_TRANSFORM (tmp2 [16], tmp2)
A: = tmp11 [0] [17]
B: = tmp22 [1] [17]
Sseq: = ntohl (skb-> h. th-> seq) The skb here is the skb carrying tcp syn.
Count1: = jiffies/(HZ * 60) minute value of the current time
Data1: = msstab
The last index that is earlier than the MSS value carried in skb (it is worth noting that the two keys will not be changed after the first initialization until the system restarts. Therefore, it can be considered as a constant value .)
With the above definition, we can get that cookie is equal
Isn: = A + sseq + (count1 <COOKIEBITS) + (B + data1) & COOKIEMASK
The isn is assigned to the returned tcp syn + ACK packet as the ISN value. This is the process of cookie generation. During this process, no storage space is allocated for this connection request locally.
When the TCP server receives a tcp ack packet, it must check the SYN Cookie accordingly. This check process starts with the cookie_v4_check function in the tcp_v4_hnd_req function. Cookie_v4_check calls the cookie_check function, and the cookie_check function calls the check_tcp_syn_cookie function.
The check_tcp_syn_cookie function is defined in random. c.
Secure_tcp_syn_cookie function. Check the ISN value extracted from tcp ack.
In check_tcp_syn_cookie, assume that the ISN value is as follows:
Isn: = A + sseq + (count2 <COOKIEBITS) + (B + data2) & COOKIEMASK
Here, A and B are calculated based on the address information in the current skb and syncookie_secret; sseq is calculated based on the seq value in this skb.
With the preceding values, the TCP server can calculate count2 and data2. Theoretically, as long as the isn is the original isn
Count2 = count1
Data2 = data1
However, this conclusion is just a theoretical case. Because the original count1 and data1 are not saved on the TCP server, the comparison cannot be performed directly. The TCP server adopts the following methods:
1) Calculate the current minute Value
Count3: = jiffies/(HZ * 60)
If the difference between count3 and count2 exceeds COUNTER_TRIES (4) minutes, the ACK package is considered invalid.
2) Check whether data2 is a valid msstab index, that is, whether it is smaller than NUM_MSS, that is, (sizeof (msstab)/sizeof (msstab [0])-1 ). If the value is less than, the ACK is legal; otherwise, the ACK is deemed invalid.
The above describes how to implement SYN Cookie in Linux kernel Linux2.4.20. Next we will discuss its rationality. The expected conclusion is that this scheme can effectively implement TCP connections and prevent SYN Flood attacks.
As mentioned above, valid TCP connection requests must pass the SYN Cookie process. On the other hand, we can see the behavior of SYN cookies when the system is under various SYN Flood attacks. The most common SYN Flood attack is when an attacker sends a large number of tcp syn packets as a TCP client instead of sending other packets. In this case, the SYN Cookie calculates the corresponding ISN value for each SYN Packet and returns the SYN + ACK packet. In this case, no storage space is allocated locally, so no attack is successful.
Based on the SYN Cookie principle, attackers may directly send a large number of ACK packets. In this case, SYN Cookie extracts the isn value of each packet and assumes that it has the following format:
Isn: = A + sseq + (count <COOKIEBITS) + (B + data) & COOKIEMASK
Calculate count and data.
Because the attacker does not know A and B, the counter-calculated count and data are almost impossible to make sense. Therefore, the TCP server is almost impossible to allocate storage space for these ACK packets, this indicates that SYN cookies play a role in resisting SYN Flood attacks.
Iv. SYN Cookie Firewall
From the above introduction, we can see that the main function of the SYN Cookie mechanism in the Linux kernel is to prevent the local computer from SYN Flood attacks. However, in many cases, it is not enough to implement such a SYN Cookie mechanism. If we want to consider a gateway-based firewall, it should not only protect the local machine from various network attacks, but also protect all hosts with open TCP ports after it from these attacks. For example, if a server in a LAN opens the FTP service to the outside world, the server host may be vulnerable to SYN Flood attacks from the Internet. At this time, the firewall will forward all attack SYN packets to the affected host.
One way to prevent this is SYN Cookie Firewall. It is an extension form of SYN Cookie. In general, it uses the original SYN Cookie principle to implement a proxy mechanism for TCP three-way handshake between the Intranet and the Internet.
To facilitate the description, we assume that an external TCP client C wants to connect to a TCP server S in the LAN through firewall F.
When the firewall receives a SYN packet from the internet, it does not directly forward it, But caches it locally. Then, it creates a SYN + ACK packet for the SYN Packet Based on the original SYN Cookie mechanism, note that the ACK sequence number in this SYN + ack package is a specially crafted cookie value c. More importantly, the source address of this package is forged into the S address (for convenience of description, we do not consider NAT and other factors for the time being ). In this way, C will receive the SYN + ACK packet and think it is returned from S. C then responds to an ACK packet and thinks that the TCP connection with S has been established. Then, the firewall F receives the ACK packet and checks the ACK sequence number in the ack according to the SYN Cookie principle described above. If the request is valid, F sends the locally cached SYN packet from C to S. Then S will respond to a SYN + ACK packet to C, which also carries a seq number, we set it to C '. Of course, this package does not reach C, but is intercepted by firewall F. F creates an ACK package to respond to S based on the serial number and other information in the package. In this case, C thinks that he has established a TCP connection with S, and S thinks he has established a TCP connection with C. In the future, the content of TCP data can directly pass through firewall F and interact between S and C.
It is the working principle of SYN Cookie Firewall, which is equivalent to implementing a proxy for the three-way handshake protocol between the TCP Server and the TCP Client. The first "three-way handshake" is performed between the TCP Client and the firewall, and the second "three-way handshake" is performed between the firewall and the TCP Server. The SYN Cookie process described above is used for the first "three-way handshake. One problem occurs when two "three-way handshakes" are performed: after the first "three-way handshakes" are performed, the TCP Client considers that the seq value of subsequent data packets starts from c + 1, after the second "three-way handshake", the TCP Server considers that the seq value of the subsequent data packet starts from C' + 1, c is cookie, and c is randomly generated by the TCP Server. C and C' are almost impossible. That is to say, if no other operation is performed after the two "three-way handshakes" are completed, in the future, data packets from the TCP Client to the TCP Server will be discarded because the sequence number is incorrect. One remedy is to save a Delta value locally on the firewall.
Delta = | c-C' |
This difference is used to modify the seq value of each data packet when it passes through the firewall, so that the subsequent data traffic can be transmitted perfectly between the TCP Server and the TCP Client.
Summary
Currently, the widely used IPv4 protocol has many security issues, and the weakness in the face of SYN Flood attacks is one point. Without changing the TCP three-way handshake process, the TCP Server is almost impossible to effectively prevent SYN Flood attacks. To completely prevent SYN Flood, you must modify the three-way handshake protocol. SYN Cookie is a very effective method. Its idea is relatively simple, mainly about how to implement it. Linux also provides an implementation. By studying the code in Linux2.4.20 kernel, the author basically understands the method of implementing SYN Cookie in the Linux kernel and summarizes it into text to share and communicate with friends who are equally interested in SYN Cookie.
