Anti-SYN Attack in CentOS

Anti-SYN Attack in CentOS

It was slow to log on to the company's official website this morning. log on to the server and check the website access information:

[Root @ web ~] # Netstat-anp | awk '{print $6}' | sort | uniq-c | sort-rn

172 ESTABLISHED

59 CONNECTED

589SYN_RECV

15 STREAM

The SYN is so high, continue to trace the SYN sent by those ip addresses:

[Root @ tweb ~] # Netstat-an | grepSYN | awk '{print $5}' | awk-F: '{print $1}' | sort | uniq-c | sort-nr | more

570x. x

(The ip address will not be written, it is an ip address of Shandong Zaozhuang Unicom), but this ip address has sent so many syn request connections. Originally, the concurrency of our web server is not very high, in this way, normal user requests cannot be matched and the page cannot be opened. Because the hardware firewall is managed by the group's IT department and I have no permissions, I can only take some measures on the local server to partially mitigate SYN attacks.

First, let's talk about the SYN Attack principle:

In TCP/IP, TCP provides reliable connection services and uses three handshakes to establish a connection.

First handshake: when a connection is established, the client sends the syn Packet (syn = j) to the server and enters the SYN_SEND status. Wait for the server to confirm;

The second handshake: when the server receives the syn packet, it must confirm the customer's SYN (ack = j + 1) and send a SYN Packet (syn = k), that is, the SYN + ACK packet, the server enters the SYN_RECV status;

The third handshake: the client receives the server's SYN + ACK package and sends the ACK (ack = k + 1) Confirmation package to the server. After the package is sent, the client and server enter the ESTABLISHED status, complete three handshakes. After three handshakes are completed, the client and the server start to transmit data.

If the user initiates a connection request to the server and only performs a second handshake without responding to the server, the server will not stop waiting for user confirmation, if there are too many such connections, the server's connection queue will be fully occupied, and normal users will not be able to establish a connection. Therefore, we make the following changes directly from the SYN connection:

View the default syn configuration in linux:

[Root @ web ~] # Sysctl-a | grep_syn

Net. ipv4.tcp _ max_syn_backlog = 1024

Net. ipv4.tcp _ syncookies = 1

Net. ipv4.tcp _ synack_retries = 5

Net. ipv4.tcp _ syn_retries = 5

Tcp_max_syn_backlog is the length of the SYN queue. Increasing the length of the SYN queue can accommodate more network connections waiting for connection. Tcp_syncookies is a function that enables or disables the SYNCookie function to prevent some SYN attacks. Tcp_synack_retries and tcp_syn_retries define the number of retries of SYN connections, and reduce the default parameters to minimize the number of SYN connections.

The following are my modified parameters, which can be modified based on the actual situation of your server:

[Root @ web ~] # More/etc/rc. d/rc. local

#! /Bin/sh

# Thisscriptwillbeexecuted * after * alltheotherinitscripts.

# Youcanputyourowninitializationstuffinhereifyoudon't

# WanttodothefullSysVstyleinitstuff.

Touch/var/lock/subsys/local

Ulimit-HSn65535

/Usr/local/apache2/bin/apachectlstart

#####

Sysctl-wnet.ipv4.tcp_max_syn_backlog = 2048

Sysctl-wnet.ipv4.tcp_syncookies = 1

Sysctl-wnet.ipv4.tcp_synack_retries = 3

Sysctl-wnet.ipv4.tcp_syn_retries = 3

To make the configuration take effect immediately without restarting the server, you can execute

# Sysctl-wnet.ipv4.tcp_max_syn_backlog = 2048

# Sysctl-wnet.ipv4.tcp_syncookies = 1

# Sysctl-wnet.ipv4.tcp_synack_retries = 3

# Sysctl-wnet.ipv4.tcp_syn_retries = 3

Some people also like to use the access control list to prevent SYN attacks, which slows down syn attacks to a certain extent:

Syn flood attacks

# Iptables-AINPUT-ptcp -- syn-mlimit -- limit1/s-jACCEPT

-- Limit1/s: Limit the number of syn threads per second.

Anti-Port Scan

# Iptables-AFORWARD-ptcp -- tcp-flagsSYN, ACK, FIN, RSTRST-mlimit -- limit1/s-jACCEPT

Death ping

# Iptables-AFORWARD-picmp -- icmp-typeecho-request-mlimit -- limit1/s-jACCEPT

#> Iptables-save>/etc/sysconfig/iptables

View, # iptables-L

ACCEPTtcp -- anywhereanywheretcpflags: FIN, SYN, RST, ACK/SYNlimit: avg1/secburst5

ACCEPTtcp -- anywhereanywheretcpflags: FIN, SYN, RST, ACK/RSTlimit: avg1/secburst5

ACCEPTicmp -- anywhereanywhereicmpecho-requestlimit: avg1/secburst5

View the syn connection again:

[Root @ web ~] # Netstat-an | grepSYN | awk '{print $5}' | awk-F: '{print $1}' | sort | uniq-c | sort-nr | more

2010.92.10.220

1125.43.36.199

Apparently, the number of SYN connections has come down.