SYN flood Learn and simple precautions notes!

A: What is a CentOS SYN flood attack?

The CentOS SYN flood attack exploits the three-time handshake (three-way handshake) process of the TCP protocol in IPV4. This protocol specifies that if one side wants to initiate a TCP connection to the other end, it needs to first send a TCP SYN (synchronize) packet to the other.

When the other party receives a TCP Syn+ack packet back, the initiator sends a TCP ACK (acknowledge Character) packet back, so that the three-time handshake is over. In the above process, there are some important concepts.

Not connected queue: In the three handshake protocol, the server maintains an disconnected queue, which is listed as an entry for each client's CentOS SYN package (SYN=J), which indicates that the server has received a CentOS SYN packet and has issued a confirmation to the customer that it is waiting for the customer's confirmation package.

The connections identified by these entries are in the CentOS syn_recv state of the server, and when the server receives the customer's confirmation package, the entry is deleted and the server enters the established state. Or, the TCP server receives the TCP SYN request package.

Before sending the TCP Syn+ack packet back to the TCP client, the TCP server allocates the good one data area specifically to serve the TCP connection that is formed. The connection state that is normally used to receive a CentOS SYN packet without receiving an ACK packet becomes a half-open connection (Half-open Connection).

Backlog parameter: Represents the maximum number of seats that are not connected to a queue. CentOS Syn-ack retransmission times: The server sent out the CentOS syn-ack package, if not received the customer confirmation package, the server for the first retransmission, waiting for a period of time still not received the customer confirmation package, the second retransmission, if the number of retransmissions than the system specified maximum retransmission times.

The system removes the connection information from the semi-connection queue. Note that the time to wait for each retransmission is not necessarily the same. Half-Connection survival time: Refers to the maximum time that an entry for a semi-connected queue survives, or the maximum time a service receives a SYN packet to confirm that the message is invalid.

The time value is the sum of the maximum wait times for all retransmission request packets. Sometimes we also call half-connection survival time of timeout time, CentOS SYN _recv survival time. In the most common CentOS syn flood attack, an attacker sends a large number of TCP SYN packets to the victim in a short period of time, when the attacker is a TCP client and the victim is a TCP server.

According to the above description, the victim allocates a specific data area for each TCP SYN packet, as long as the CentOS SYN packets have different source addresses (which is easy for an attacker to forge). This poses a significant system burden to the TCP server system, which eventually causes the system to fail to work properly.

II: CentOS SYN Cookie principle

One of the means to effectively protect against CentOS SYN flood attacks is the Syn Cookie. The original reason for the SYN cookie is d. J. Bernstain and Eric Schenk invented. The CentOS SYN cookie is a modification of the three-time handshake protocol on the TCP server side, specifically designed to protect against a CentOS syn flood attack.

The principle is that when the TCP server receives the TCP SYN packet and returns the TCP Syn+ack packet, it does not allocate a dedicated data area, but calculates a cookie value based on the CentOS SYN packet. When a TCP ACK packet is received, the TCP server checks the validity of the TCP ACK packet against that cookie value.

If it is legal, then the dedicated data area is allocated for processing future TCP connections. Below the Linux and FreeBSD say how to configure kernel parameters to implement the CentOS SYN Cookie

Three: Under Linux settings

If your server is not configured well, the number of TCP time_wait sockets reaches 20,000 or 30,000, and the server can easily be dragged to death. By modifying the Linux kernel parameters, you can reduce the number of TIME_WAIT sockets on the server.

Time_wait can be viewed with the following command: The following is the code snippet: Netstat-an | grep "Time_wait" | Wc-l under Linux, such as CentOS, you can modify the/etc/sysctl.conf file to achieve the goal.

Add the following lines: Here is the code snippet:

Net.ipv4.tcp_fin_timeout = 30 Net.ipv4.tcp_keepalive_time = 1200 Net.ipv4.tcp_syncookies = 1 Net.ipv4.tcp_tw_reuse = 1 Net.ipv4.tcp_tw_recycle = 1 Net.ipv4.ip_local_port_range = 102465000 Net.ipv4.tcp_max_syn_backlog = 8192 Net.ipv4.tcp_max_tw_buckets = 5000 Net.ipv4.tcp_synack_retries = 2 Net.ipv4.tcp_syn_retries = 2

Description

Net.ipv4.tcp_syncookies = 1 means that the CentOS SYN cookie is turned on, which is a Boolean. When a CentOS syn wait queue overflow occurs, cookies are enabled to protect against a small number of CentOS SYN attacks, which by default is 0, which means close;

Net.ipv4.tcp_tw_reuse = 1 means turn on reuse, which is a Boolean. Allows time-wait sockets to be re-used for new TCP connections, which defaults to 0, which means shutdown;

Net.ipv4.tcp_tw_recycle = 1 means a fast recycle of time-wait sockets in the TCP connection is turned on, which is a Boolean, which defaults to 0, which means shutdown.

Net.ipv4.tcp_fin_timeout = 30 means that if the socket is closed by the local side, this parameter determines how long it remains in the fin-wait-2 state. Unit is seconds.

Net.ipv4.tcp_keepalive_time = 1200 indicates the frequency at which TCP sends keepalive messages when KeepAlive is employed. The default is 2 hours, which is changed to 20 minutes. Unit is seconds.

Net.ipv4.ip_local_port_range = 102465000 indicates the range of ports used for the outward connection. Small by default: 32768 to 61000, 1024 to 65000.

Net.ipv4.tcp_max_syn_backlog = 8192 Indicates the length of the CentOS syn queue, the default is 1024, and the queue length is 8192, which can accommodate more network connections waiting to be connected.

Net.ipv4.tcp_max_tw_buckets = 5000 indicates that the system maintains the maximum number of time_wait sockets at the same time, and if this number is exceeded, the time_wait socket is immediately cleared and a warning message is printed.

The default is 180000, which changes to 5000. For Apache, Nginx and other servers, the parameters of the last few lines can be a good way to reduce the number of time_wait sockets, but for squid, the effect is not small. This parameter controls the maximum number of time_wait sockets, preventing squid servers from being dragged to death by a large number of time_wait sockets.

Net.ipv4.tcp_synack_retries and Net.ipv4.tcp_syn_retries are the number of CentOS SYN retries that are defined. Execute the following command to make the configuration effective: The following is the code snippet:/sbin/sysctl-p If you do not want to modify/etc/sysctl.conf, you can also use the command to modify: The following is the code snippet:/sbin/sysctl-w key=value

Excerpt from: http://www.bingdun.com/news/bingdun/6092.htm

Disadvantages:

In general, there are two simple ways to defend against SYN flood attacks. One is to shorten the wait time (syn Timeout) and increase the queue's SYN packet Maximum capacity (TCP _max_syn _backlog), and the second is to set the Syn Cookie. However, these two methods can only deal with the comparison of the original SYN flood attack. Shortening SYN timeout time only takes effect if the opponent's attack frequency is not high, and Syncookie relies on the other person to use the real IP address. If an attacker sends a SYN message at a rate of tens of thousands of per second and a tool such as sock_raw randomly overwrites the source address in the IP message, the above method is obviously not effective.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Iv. iptables lightweight to prevent syn-flood

CC attack can be regarded as the most depressing attack, hard anti-stop, soft anti-Prevent. But using Linux's iptables can slow down cc attacks.

#iptables-N Syn-flood (does not need to be executed if this chain is available)

Iptables-a input-p TCP--syn-j Syn-flood

Iptables-i syn-flood-p tcp-m limit--limit 4/s--limit-burst 6-j RETURN

Iptables-a syn-flood-j REJECT

650) this.width=650; "Src=" Http://s2.51cto.com/wyfs02/M00/86/FE/wKioL1fQzFXysgXhAAC_GkNXRfY584.png-wh_500x0-wm_3 -wmp_4-s_2767825517.png "title=" 1.png "alt=" Wkiol1fqzfxysgxhaac_gknxrfy584.png-wh_50 "/>

#netstat-nat | grep syn_recv

This article from "[email protected]sc.com" blog, reproduced please contact the author!

SYN flood understanding and simple precaution notes!