The SYN flood is a very dangerous and common Dos attack mode in the network environment which is currently built on the IPV4-supported network protocol. So far, there are not many ways to effectively prevent SYN flood attacks, and SYN cookies are among the most famous. SYN Cookie Original Reason d. J. Bernstain and Eric Schenk invented it. There are all kinds of implementations on many operating systems. These include Linux. This article introduces the principles of SYN flood attack and Syn cookies, and more importantly describes how to implement SYN cookies in the Linux kernel. Finally, this paper gives an idea to enhance the current SYN cookie function in Linux. Syn flood attack syn Flood attack is a typical Denial-of-service type (denial of service) attack. The so-called Denial of service attack is through the attack, so that the injured host or network can not provide a good service, so as to indirectly achieve the purpose of the attack. The SYN flood attack exploits the three-time handshake (three-way handshake) process of the TCP protocol in IPV4. Everyone knows that if one end wants to initiate a TCP connection to the other end, it needs to send a TCP SYN packet to the other side, send a TCP syn+ack packet back after receiving it, and send a TCP ACK packet back to the initiator, so the three handshake is over. The initiator of the TCP connection is called the TCP client (TCP clients), and the recipient of the TCP connection is called the TCP server (TCP server). It is noteworthy that when a TCP server receives a TCP SYN request package, the TCP server first assigns a data area dedicated to this incoming TCP connection before sending TCP Syn+ack packets back to the TCP client. The connection state that receives the SYN packet and has not received the ACK packet is generally turned into a half-open connection (Half-open Connection). In the most common SYN flood attack, an attacker sends a large number of TCP SYN packets to the victim within a short time, when the attacker is a TCP client and the victim is a TCP server. According to the description above, the victim assigns a specific data area to each TCP SYN packet, as long as the SYN packets have a different source address (which is easy to forge for attackers). This will cause a large system burden on the TCP server system and eventually cause the system to not function properly.
The SYN cookie Principle syn cookie is a few modifications to the TCP server side three handshake protocol, which is designed to prevent SYN flood attacks. The rationale is that when a TCP server receives a TCP SYN packet and returns a TCP Syn+ack packet, it does not allocate a dedicated data area, but calculates a cookie value based on the SYN packet. When a TCP ACK packet is received, the TCP server checks the legality of the TCP ACK packet against that cookie value. If it is legal, then assign a dedicated data area to handle future TCP connections. As can be seen from the above introduction, the SYN cookie principle is relatively simple. To the practical application, it has many different ways of implementation. Third, the Linux kernel of the SYN cookie implementation of the Linux kernel in the SYN flood has a good protection. The following discussion is done for the Linux2.4.20 kernel. In each sock there is a tcp_opt, which is the sock TCP option. In Tcp_opt there is a tcp_listen_opt, which stores some of the options that this sock holds in the listen state, with an array of open_request structures, with an array length of tcp_synq_hsize (512). All of this means that at a sock, you can open up to 512 half-open connections at the same time (this is the maximum value when you do not consider other constraints, and this is not true in practice). When the array is full, the new open_request replaces an old open_request. This allows the system to be protected from paralysis when SYN flood occurs, even if the Syn Cookie is not started. The problem is that this approach discards normal TCP connection requests in the face of a SYN flood attack. The SYN cookie serves to ensure that, in the face of a SYN flood attack, an illegal TCP connection request can be rejected on the one hand, and the normal connection may be established on the other. The processing of TCP process by Linux kernel is mainly realized in the function of tcp_ipv4.c file. Specifically, when handling TCP SYN packets, the system enters the Tcp_v4_conn_request function. Where call cookie_v4_init_sequence generates a isn (Initial Sequence number). The Linux kernel takes it as a cookie in the SYN cookie process. The Cookie_v4_init_sequence function is defined in the SYNCOOKIES.C file, and it calls the Secure_tcp_syn_cookie function in the random.c file。 The real calculation of the cookie is performed in this function. Two macros are given before the definition of Secure_tcp_syn_cookie function in the Random.c file, which is defined as #define COOKIEBITS 24, respectively.
#define Cookiemask (((__u32) 1 << cookiebits)-1)
Cookiebits represents the bit length of a cookie; Cookiemask is a cookiebits long bit string, all bits are 1. There are also two bit strings, defined as a __u32 two-dimensional array of static __u32syncookie_secret[2][16-3+hash_buffer_size];
All of the bit values are given randomly in the Secure_tcp_syn_cookie, using the Get_random_bytes function. They become the key to making cookies. These two randomly generated bit strings are key to the entire SYN cookie implementation scenario. There is also a switch syncookie_init to control the changes to the two keys. It is also noted that there is a __u16 table static __u16 const msstab[defined in file syncookies.c that contains some possible MSS (Maximum Segment Size) values. The return value of the Secure_tcp_syn_cookie function is the computed isn value, which is the cookie. To describe the convenience, we give the following definition: 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 one that carries the TCP SYN SKB
Count1: = jiffies/(hz*60) minutes value of the current time
Data1: = Msstab The index of the value of the MSS value carried from the last less than SKB (note that two keys are not changed until the system restarts after the first initialization). So you can think of it as a constant value. With the above definition we can get the cookie equals isn: = A+sseq + (count1<<cookiebits) + (B+DATA1) &cookiemask This isn is given to the returned TCP Syn+ack packet, As the ISN value. This is the process of producing cookies. In this process, no storage space is allocated locally for this connection request. When the TCP server receives the TCP ACK packets, it is appropriate to check the SYN cookie. This check process starts with the Cookie_v4_check function in the function tcp_v4_hnd_req. 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, defined in RANDOM.C, is a function corresponding to the Secure_tcp_syn_cookie function described earlier to check the isn value extracted from the TCP ack. In Check_tcp_syn_cookie, the ISN value is assumed to be the following isn: = A+sseq + (count2<<cookiebits) + (B+DATA2) &cookiemask here's A, B is calculated according to the address information and Syncookie_secret in the current SKB, SSEQ is calculated from the SEQ value in this SKB. With these values, the TCP server can reverse the Count2 and data2. Theoretically, as long as this isn is the original isn, there should be count2 = = Count1
Data2 = = Data1
But this conclusion is only a theoretical one. Because the original count1 and data1 are not saved on the TCP server side, they cannot be compared directly. The TCP server takes the following approach: 1 calculates the current minute value count3: = jiffies/(hz*60) is compared with the count2, if the difference exceeds the Counter_tries (4) minutes, the ACK packet is considered illegal. 2 See Data2 is not a legitimate Msstab index, that is, is not less than NUM_MSS, that is (sizeof (Msstab)/sizeof (msstab[0))-1. If less than, then the ACK is considered legal, otherwise it is considered illegal. This is how the SYN cookie is implemented in the Linux kernel Linux2.4.20. Here is a discussion of its rationality. The conclusion is that this scheme can effectively realize TCP connection and prevent SYN flood attack. From the above introduction, legitimate TCP connection requests must be through the SYN cookie process. On the other hand, we look at the behavior that SYN cookies will take when the system is subjected to a variety of 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 and no more packets are sent. The SYN cookie then calculates the corresponding isn value for each SYN packet and returns the Syn+ack packet, which does not allocate any storage space locally and will not be successfully attacked. Based on the SYN cookie principle, it is possible for an attacker to send a large number of ACK packets directly. The SYN cookie then extracts the ISN value of each packet and assumes that it has the following format isn: = A+sseq + (count<<cookiebits) + (B+data) &cookiemask calculates count and data. Since the attackers do not know where A and B are, the inverse count and data are almost impossible to justify, so it is almost impossible for the TCP server to allocate storage space for these ACK packets, which means that the SYN cookie has played a role in resisting SYN flood attacks. IV, SYN cookie Firewall from the above, the main function of the SYN cookie mechanism in the Linux kernel is to prevent the native from Syn flood attack, but in many cases, only this SYN The cookie mechanism is not enough. If we want to consider a gateway-mode firewall, it is not only to protect the native from various network attacks, but also to safeguardProtect all hosts with open TCP ports behind it from these attacks. For example, a local area network has a server open the FTP service to the outside world, this server host may suffer from the Internet SYN flood attack. The firewall then forwards all the attack SYN packets to the victim host. A way to eliminate this situation is to SYN Cookie Firewall. It is an extended form of a SYN cookie. In general, it is a proxy (proxy) mechanism that uses the original SYN cookie principle to implement the TCP three handshake process between the net and the extranet. To facilitate the description, we assume that an external TCP client C would like to connect to a TCP server S in the LAN via firewall F. When a firewall receives a SYN packet from the extranet, it does not forward directly, but caches it locally, and then makes a syn+ack package for the SYN packet according to the original SYN cookie mechanism, noting that the ACK sequence in this Syn+ack package is a specially crafted cookie value C, More importantly, the source address of the package is forged into the address of S (for the convenience of description, we do not consider other factors such as NAT for the moment). So C will receive this syn+ack packet and think it is back from s feedback. C then responds to an ACK packet and believes that the TCP connection with S has been established. Then firewall F receives this ACK packet and checks the ACK sequence number in the ACK according to the SYN cookie principle described above. If considered legal, F sends the locally cached SYN packages from C to S, at which point S responds to a syn+ack packet to C, which also carries a SEQ number, which we set to C '. Of course, this package will not reach C, but by the firewall F interception, F according to the serial number in this packet, and other information, to create an ACK packet response to S. In this case, C believes that it has established a TCP connection with S, and S believes that it has established a TCP connection with C. Future TCP data content can be passed directly through the firewall F, interacting between S and C.
The above diagram is the work of the SYN Cookie firewall, which is equivalent to implementing a proxy for three handshake protocols between TCP server and TCP client. The first "three handshake" is between the TCP client and the firewall, and the second "three handshake" between the firewall and the TCP server. Use the SYN cookie process described earlier in the first "three handshake". One problem occurs when you have two "three handshakes": as shown in the figure, after the first "three handshake", TCP client thinks that the SEQ value of subsequent packets starts with the c+1, and after the second "three handshake", TCP server considers the SEQ value of subsequent packets to be from C ' + Starting at 1, C is cookie,c ' is a random generation of TCP server. C and C ' are almost impossible to equal, which means that after completing the two "three handshake" above, if no other action is taken, subsequent packets from TCP client to TCP server will be discarded as sequential numbers. One remedy is to save a value locally at the firewall δδ= |c-c ' | With this difference, the SEQ value is modified every time a packet passes through a firewall, so that subsequent data traffic can be perfectly transmitted between TCP server and TCP client. Summing up the IPV4 protocol now commonly used has a lot of security problems, of which the weakness of the face of SYN flood attack is a bit. Without changing the TCP three handshake process, TCP server is almost impossible to effectively prevent SYN flood attacks. To ensure complete protection against SYN Flood, you must modify the handshake agreement three times. SYN cookies are a very efficient way to do this. Its idea is relatively simple, mainly how to achieve the specific, Linux system also provides a realization. By studying the code in the Linux2.4.20 kernel, the author has a basic understanding of the way in which the SYN cookie is implemented in the Linux kernel, always writing, sharing, interacting with friends who are equally interested in the SYN cookie.
