Diagnosis and processing of TCP Flood Attack (SYN FLOOD)

Syn Flood introduction

Summary The website was attacked many times, the most violent TCP flood attack, namely SYN FLOOD.

Syn Flood is one of the most popular DOS (Denyed Services Attack) and DDOS (Distributed Denial Service Attack). This is a TCP protocol defect, send a large amount of counterfeit TCP connection request, commonly used IP or IP The first handshake package (SYN package) that sent a massive request connection, the attack server responded to the second handshake (SYN + ACK package), because the other party is a counterfeit IP, the other party will never receive the package and will not Respond the third handshake. “Semi-connection” that caused a large number of SYN_RECV status, and will retry the second handshake package, stuffed with TCP waiting for the connection queue, resource exhaustion (CPU full load or insufficient memory), let normal Business request connection does not come in.

For detailed principles, there are many introductions on the Internet, there are many ways to meet, but most of them have no effect, here we introduce how we diagnose and deal with it.

2. Diagnostics

When we see the business curve, check the machine and DNS, found that the external Web mechanic should be slow, the CPU load is high, SSH login is slow or even some machines can not log in, check the system syslog:

# tail -f / var / log / messages

Apr 18 11:21:56 Web5 kernel: Possible Syn Flooding on port 80. Sending cookies.

Check the number of connections, and SYN_RECV connection is more special:

# Netstat -n | awk ‘/ ^ TCP / {++ S [$ NF]} end {for (a in s) Print A, S [A]}’

Time_wait 16855

Close_wait 21

SYN_SENT 99

Fin_wait1 229

FIN_WAIT2 113

Established 8358

SYN_RECV 48965

Closing 3

Last_ack 313

According to experience, check the number of connections as follows:

# Netstat -n | awk ‘/ ^ TCP / {++ S [$ NF]} end {for (a in s) Print A, S [A]}’

Time_wait 42349

Close_wait 1

SYN_SENT 4

Fin_wait1 298

FIN_WAIT2 33

Established 12775

SYN_RECV 259

Closing 6

Last_ack 432

The above is the two characteristics of TCP flood attacks. Execute NetStat -NA> Specify a file to keep a crime.

3. Emergency treatment

The other party IP feature is viewed according to NetStat:

# Netstat -na | GREP SYN_RECV | More

Use iptables to temporarily seal the maximum suspect’s IP or IP segment, such as the other party’s counterfeit 173. *. *. * Number segment to attack, short-term disable 173. *. *. * This large size (to confirm that you should not be sealed) Your own local IP!)

# iptables -ainput -s 173.0.0.0/8 -p tcp -dport 80 -J DROP

Then analyze the crime, analyze the business, analyze the normal IP and subnet segments in the normal IP and subnet segments in the normal IP and subnet segments in the normal IPTables. Such emergency treatment is easily injured, and it is not an ideal way to cause the SSH landing without the server because it is wrong.

4. Use F5 block attack

After all, the emergency treatment is too passive, because the F5 of this machine is idle, the operation and maintenance uses F5 to block attacks, using the way: Let the customer have three handshakes and F5, and F5 is forwarded to the backend business server. The phenomenon that is later attacked when f5 is attacked:

1. The number of connections is more than 5 million, and the attack is stopped after the attack is stopped.

2. After modifying the VS mode of our business on the F5, the CPU consumption of F5 is 7%, and the attack is restored.

3. Use the F5 gear effect. Later, after the attack is invalid, users rarely attack, after all, the attack is also cost.

5. Adjust system parameter gear attack

What should I do without F5? Is this advanced and expensive equipment? I have tested the following parameter combinations to significantly reduce the impact, and I will not use F5 anti-attacks after preparation.

The first parameter TCP_SYNACK_RETRIES 0 is the key, indicating that the second handshake (SYN + ACK package) gives the client IP, if you do not receive the third handshake (ACK package), do not try, speed up recycling “Semi-connection”, do not power resources. Do not modify this parameter, analog attack, 80 ports that are attacked after 10 seconds are unable to serve, the machine is difficult to log in; use the command netstat -na | grep syn_recv to detect “Semi-Connection” HOLD for 180 seconds;

Modify this parameter is 0, and then simulates the attack. After 10 minutes, the 80-port that is attacked can be served, the response is slightly slow, just SSH is sometimes logged in; detect “semi-connection” only HOLD 3 seconds release .

Side effects of this parameter is 0: When the network is very poor, if the other party does not receive the second handshake bag, it may be connected to the server to fail, but for the general website, the user refreshes the page. These can be verified when TCPDUMP capture is verified when the peak period or network condition is not good.

Based on the previous capture experience, this situation is rare, but for the sake of insurance, this parameter can be enabled only when it is attacked by TCP flood.

TCP_SYNACK_RETRIES The default is 5, indicating retransmission 5 times, waiting for 30 ~ 40 seconds each time, “Semi-Connect” default HOLD lives approximately 180 seconds. explain in detail:

THE TCP_SYNACK_RETRIES SETTING TELLS The Kernel How Many Times To Retransmit The SYN, ACK Reply TO

An Syn Request. in Other Words, this Tells The System How Many Times To try to Establish a Passive

TCP Connection That Was Started by Another Host.

THIS VARIABLE Takes An Integer Value, But Should Under No Circumstances Be Larger Than 255 for The

Same Reasons as for the TCP_SYN_RETRIES VARIABLE. Each Retransmission Will Take Aproximately 30-40

Seconds. The default value of the tcp_synack_retries variable is 5, and hence the default timeout

Of Passive TCP Connections Is Aproximately 180 Seconds.

The reason why TCP_SYNACK_RETRIES can be changed to 0, because the client also has a TCP_SYN_RETRIES parameter, the default is 5, even if the server is not retransmitting the SYN + ACK package, the client will also re-send SYN handshake. explain in detail:

THE TCP_SYN_RETRIES VARIABLE TELLS The Kernel How Many Times To try to Retransmit The Initial SYN

Packet for an Active TCP Connection Attempt.

THIS VARIABLE Takes An Integer Value, But Should Not Be Set Higher Than 255 Since EACH

Retransmission Will Consume Hue Amounts of Time As Well As Some Amounts of Bandwidth. EACH

Connection Retransmission Takes Aproximately 30-40 Seconds. The Default Setting IS 5, Which

Would Lead to an Aproximate of 180 Seconds Delay Before The Connection Times Out.

The second parameter NET.IPV4.TCP_MAX_SYN_BACKLOG 200000 is also important, and the specific value is limited by memory.

The following configuration, the first parameter is the most important, the second parameter is auxiliary, the remaining parameters are other functions: # vi /etc/sysctl.conf

1234567891011121314151617181920 # Maximum parameters FS.FILE-MAX 819200 # Used to deal with sudden concurrent Connect request NET.CORE.SOMAXCONN 65536 # maximum TCP data reception buffer (bytes) net.core.rmem_max 1024123000 # maximum TCP data send buffer (bytes) NET.CORE.WMEM_MAX 16777216 # Network Device Receiving the rate of packets than the rate of the package, the maximum number of packets allowed to send to the queue NET.CORE.NETDEV_MAX_BACKLOG 165536 # This machine actively connects other machines Port allocation range Net.IPv4.ip_local_port_range 10000 65535 # …… …

Make the configuration take effect:

# sysctl -p

Note that when the following parameters face the external network, do not open. Because the side effects are obvious, please google if you have already opened, please change it to 0, then execute sysctl -p off. Because of the experiment, the connection of a large number of TIME_WAIT status is not much impact on the system:

12345678 # Send SyncOokies to the other party when the semi-connect queue is overflow, there is no need after the half connection queue does not need NET.IPV4.TCP_SYNCOOKIES 0 # time_wait status connection reuse function net.ipv4.tcp_tw_reuse 0 # Timestamp option, with the front NET.IPv4 .TCP_TW_REUSE Parameter Team with Net.ipv4.tcp_timeStamps 0 # TIME_WAIT Status Connection Recycling Function NET.IPV4.TCP_TW_RECYCLE 0

In order to handle a large number of connections, you need to change another parameter:

# vi /etc/security/limits.conf

Add a line below to indicate that each user can open 40,09,600 file handles (including connections):

* -nofile 409600

6. Reference

File handle Do not exceed system restrictions /usr/include/linux/fs.h, related links: http://blog.yufeng.info/archives/1380

#define nr_open (1024 * 1024) / * ABSOLUTE UPPER LIMIT ON FD NUM * /

Detailed explanation of kernel parameters: http://www.frozentux.net/ipsysctl-tutorial/chunkyhtml/tcpvariables.html

7. Conclusion

TCP flood attacks have no perfect solutions, I hope this article will help you and let you know quickly.