Principles and defense methods of SYN Flood Network Attacks

Source: Internet
Author: User

  1 SYN Flood attack introduction:

Denial of Service (DoS) is an effective and very difficult way to defend against, it aims to prevent the server from providing services for users who normally access the server. Therefore, DOS poses a critical threat to enterprises and organizations that rely closely on the Internet to carry out their businesses.

SYN flood is the most effective and popular form of DoS attacks. It uses the three-way TCP handshake to send a large number of SYN connection requests with forged source addresses to the target host, consuming the resources of the target host and thus failing to provide services to normal users.

  1.1 TCP connection establishment process

To understand the basic principles of SYN flood attacks, we must first introduce the three-way handshake mechanism of TCP.
The TCP three-way handshake process is as follows:
1) the client sends a TCP packet with a SYN position to the server, including the port number and initial serial number x used by the client;

2) After receiving the SYN Packet sent from the client, the server sends a TCP packet with both SYN and ACK positions to the client, including the confirmation number x + 1 and the initial serial number y of the server;

Tcp client
Client Port
(1024-65535)
 
TCP Server

Server Port
(1-1023)
SYN
SYN/ack
ACK

3) after the client receives the SYN + ACK packet returned by the server, it returns an ACK packet with the confirmation number y + 1 and x + 1 to the server. A standard TCP connection is complete. 1:

  1.2 attack principles

In SYN flood attacks, hackers send a large number of tcp syn packets with forged source addresses to the affected host, allocate necessary resources to the affected host, and then return the SYN + ACK packet to the source address, wait for the source to return the ACK package, as shown in figure 2. Because the source address is forged, the source end will never return an ACK packet. The victim host will continue to send SYN + ACK packets and add the semi-connection to the port backlog queue, although the common host has a timeout mechanism and default retransmission times, the length of the port semi-connection queue is limited. If a large number of tcp syn packets are continuously sent to the affected host, the semi-connection queue will soon be filled up, and the server rejects new connections, which will cause the port to fail to respond to connection requests from other machines and eventually exhaust the resources of the affected host.

Tcp client
Client Port
(1024-65535)
 
TCP Server
 
Server Port
(1-1023)
SYN
SYN/ack
 
Counterfeit Source Address

  2Several defense technologies

After SYN flood attacks have a major impact on the internet, several effective technologies have emerged to defend against SYN flood attacks.

 2.1 syn-Cookie technology

Generally, when the server receives a tcp syn packet, it immediately allocates a buffer for the connection request and returns a SYN + ACK packet, forming a semi-connection. SYN flood uses this to send a large number of SYN connection requests that forge the source address without completing the connection. In this way, a large amount of server resources are consumed.

Syn-Cookie technology changes the resource allocation policy in the process of establishing standard TCP connections. When the server receives a SYN packet, it generates a cookie using the connection information instead of allocating the buffer immediately. The cookie is used as the initial serial number of the SYN + ACK packet to be returned. When the client returns an ACK packet, the cookie is calculated based on the packet header information and compared with the first 24 digits of the returned confirmation serial number (initial serial number + 1, it is a normal connection. Then, allocate resources and establish a connection.

The clever point of this technology is that it avoids Resource Allocation before the connection information is fully reached, and invalidates the resource consumption of SYN flood attacks. The key to implementation is Cookie computing. Cookie calculation should include the status information of this connection, so that attackers cannot forge cookies. The cookie calculation process is as follows:

1) After receiving a SYN packet, the server calculates a message digest Mac:
MAC = MAC (A, K );
Mac is a message authentication code function in cryptography, that is, a hash function with a key that meets a certain security nature. It can provide the security required in cookie computing.
A is a serial combination of the IP address and port number of both the customer and the server, and the parameter t:
A = source_ip | source_port | dst_ip | dst_port | T
K is the unique key of the server;
The time parameter T is a 32-bit long time counter, Which is incremented by 1 every 64 seconds;

2) generate a cookie:
Cookie = MAC (): 0th to 24 bits of the MAC value;

3) set the initial serial number of the SYN + ACK packet to be returned. The setting process is as follows:
I. Replace the 24-bit high with cookies;
II. The next three bits are replaced by the maximum message length MMS required by the customer;
III. The last 5 bits are t mod 32.
After receiving the SYN + ACK packet from the server, the client returns an ACK packet, which carries a cookie (the initial serial number of the syn ack packet sent by the server is 1, therefore, it does not affect the height of 24 bits). The cookie is re-calculated on the server end, which is compared with the first 24 bits of the confirmation number. If it is the same, it indicates that it has not been modified and the connection is valid. Then, the server establishes the connection.

Syn-Cookie technology implements stateless three-way handshakes without storing any information on the server during connection establishment, thus effectively defending against SYN flood attacks. However, this method also has some weaknesses. Because cookie computing only involves part of the packet header's confidence, during the connection establishment process, no information is stored on the server side, so many features of the Protocol are lost, for example, timeout retransmission. In addition, because the computing of cookies has a certain amount of computing workload and increases the delay time for connection establishment, syn-Cookie technology cannot be used as a defense means for high-performance servers. The dynamic resource allocation mechanism is usually used. After a certain amount of resources are allocated, the cookie technology is adopted, which is implemented in Linux. Another problem is that when we avoid SYN flood attacks, we also provide another Denial-of-Service attack method. The attacker sends a large number of ACK packets, so that the server is busy with computing and verification. Even so, syn-Cookie technology is still an effective technology in preventing SYN flood attacks.

 2.2 solution to address status monitoring

The solution to address status monitoring is to use monitoring tools to monitor TCP connection data packets in the network and process the packets. The main reason for processing is the source address of the connection request.

Each source address has a corresponding status. There are four statuses in total:
Initial State: Any source address in the initial state;
New status: the status of the source address that exists cannot be determined when the source address appears for the first time or appears for multiple times;
Good status: determines the status of the source address;
Bad status: the status when the source address does not exist or is unavailable.
The specific action and status conversion are determined based on the bit code value in the TCP Header:

1) Listen to the SYN Packet. If the source address appears for the first time, set the source address to the new status; if the source address is in the new or bad status; the RST position of the package is 1 and then resend. If the package is in good state, no processing is performed.

2) An ACK or RST packet is monitored. If the source address is in the new status, the packet is in the good status. If the source address is in the good status, the packet is changed to the new status. If the source address is in the bad status, the packet is changed to the new status; if it is in bad state, it is converted to new state.

3) Listening to syn ack packets from the slave server (the destination address is ADDR) indicates that the server has established a semi-connection for the connection request sent from the ADDR, to prevent too many semi-connections, send an ACK packet to the server to establish a connection and start timing. If the ACK packet has not been received, the ADDR is not reachable, if the status of ADDR is good at this time, the status changes to New. If the status of ADDR is new, the status changes to bad. If the status of ADDR is bad, the status changes.
Figure 3 shows the status transition:

Initial State
Good
New
Bad
Ack/rst
SYN
Ack/rst

ACK packet validation timeout
Ack/rst

ACK packet validation timeout

The following describes how the address status monitoring method can defend against SYN flood attacks.

 

1) For a SYN packet with a forged source address, if the source address appears for the first time, the source address is in the new State. when listening to the server's SYN + ACK packet, indicates that the server has established a semi-connection for the connection request of the source address. At this time, the monitoring program sends an ACK packet to complete the connection on behalf of the source address. In this way, the number of semi-connections in the semi-connection queue is not many. The timer starts timing. Because the source address is forged, the ACK packet is not received. After the timeout, the monitoring program sends the RST packet, the server releases the connection, and the status of the source address changes to bad. Then, the monitoring program will send an RST packet for each Syn packet from the source address.

2) for a valid Syn packet, if the source address appears for the first time, the status of the source address is new. The server responds to the request, sends SYN + ACK packets, and the monitoring program sends ACK packets, the connection is established. Then, the ACK from the client will soon arrive, and the source address will be in good state. The server can handle the ACK packets that are repeated.
From the above analysis, we can see that the monitoring-based method can effectively defend against SYN flood attacks without affecting the connection of normal users.

  3 Summary

This article introduces the basic principles of SYN flood attacks, and describes in detail two effective and convenient defense methods: syn-Cookie technology and monitoring-based source address status technology. Syn-Cookie technology enables stateless handshakes to avoid SYN flood resource consumption. The monitoring-based source address status technology can monitor the status of each IP address connected to the server, and actively take measures to avoid the impact of SYN flood attacks. These two technologies are currently the most mature and feasible technologies used to defend against SYN flood attacks.
 
 
References
1. Yan xuexiong, Wang qingxian, Li meilin. Principles and prevention methods of SYN flood attacks. Computer Applications, 2000
2. Sun Xi, Zhu Xiaoyan, Wang Yulin. TCP flood attacks and countermeasures under DDoS. network security technology and application, 2004
3. Li Lei, Zhao Yongxiang, Chen changjia. Principles of tcp syn Flooding and its countermeasures. Network and application, 2003
4. Chen Bo. Principles, implementation and prevention of SYN flood attacks. Computer Application and Research, 2003

The following describes in detail the two effective defense measures: syn-Cookie and address status monitoring.

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.