Backlog parameters and SYN flood attacks

In Linux network programming, using the Listen function to listen to sockets, the use of Man in Linux, the 2nd parameter is explained as follows:

The backlog argument defines the maximum length to which the queue of pending connections for SOCKFD may grow. If a connection request arrives when the queue was full and the client may receive a error with an indication of Econnrefus ED or, if the underlying protocol supports retransmission, the request may be ignored so, a later reattempt at connect Ion succeeds.

The backlog parameter defines the maximum value that the "incomplete connections" queue on a SOCKFD socket can grow to, and TCP is connected by a 3-time handshake, so-called "incomplete connection" refers to the server-side reply Syn+ack, waiting for the client ACK to complete the SYN_RCVD state of the connection The definition of this parameter is obscure, it does not explain whether "incomplete connection" refers to a connection in the SYN_RCVD state, or a connection in the established state that has not yet been accepted by the process, or both; in fact, the meaning of the backlog has never been formally defined.

The kernel maintains two queues for any given listening socket: "Incomplete connection" and "Completed connection", and when the process calls accept, the team header item in the "Completed connection queue" will be returned to the process, or if the team is listed as empty, then the process will be put to sleep, It is not awakened until TCP puts an entry in the queue.

The backlog specifies the maximum values for both queues and, once the two queues in the kernel are occupied, the other user's connection request returns a failure (econnrefused); The SYN flood attack is using this principle by not making the last ACK in the TCP three handshake, Leave the server's connection in an incomplete state and drain the system resources. The simple mitigation measures are mainly 1. Shorten the connection timeout time; 2. Reduce the number of retransmission syn+ack; 3. Increase the backlog so that it can accommodate more connections; but this is a stopgap method.

So far, there are not many means to effectively protect against SYN flood attacks, and the SYN cookie is one of the most famous. The SYN cookie principle is invented by D.j.bernstain and Eric Schenk, and it is implemented on many operating systems such as Linux.

The principle of the SYN cookie is that when the TCP server receives the SYN packet and returns the 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 then checks the validity of the TCP ACK packet against that cookie value and, if it is legitimate, allocates a dedicated data area to process the connection.

On a Linux system, you can turn on or off the SYN cookie feature by setting the value of the/proc/sys/net/ipv4/tcp_syncookies (or in/etc/sysctl.conf net.ipv4.tcp_ Value of Syncookies), the value of 0 turns off the SYN cookie function, and a value of 1 opens the SYN cookie feature.

[Email protected]:/home/zzy/unix# cat/proc/sys/net/ipv4/tcp_syncookies

1

Note: Syncookie is a serious violation of the TCP protocol: TCP extensions are not allowed and may have a serious performance impact on some services (such as SMTP forwarding). (This implementation, like the TCP proxy used by BSD, is a violation of the RfC's three-time handshake for TCP connections, but is really useful for defending SYN flood)

If you simply solve the problem of high system load, Linux can be adjusted by the following parameters:

Tcp_max_syn_backlog, Tcp_synack_retries, Tcp_abort_on_overflow, these three files are in the/proc/sys/net/ipv4 directory.

Tcp_max_syn_backlog: How many SYN requests can be cached in memory. The variable needs to be opened tcp_syncookies to be valid. If the server load is high, you can try to increase the value of the variable.

[Email protected]:/home/zzy/unix# Cat/proc/sys/net/ipv4/tcp_max_syn_backlog

128

Tcp_synack_retries: For the second handshake in the TCP three-time handshake, when a SYN connection request from the client is received, the server responds to the Syn+ack packet, and the server is in SYN_RCVD state and waits for the reply ACK packet sent by the client. If the server does not receive an ACK packet from the client, the Syn+ack packet is re-sent until the client's ACK packet is received. This variable sets the number of times the Syn+ack packet is sent, exceeding this number, and the server discards the connection. The default value is 5.

[Email protected]:/home/zzy/unix# cat/proc/sys/net/ipv4/tcp_synack_retries

5

Tcp_abort_on_overflow: Is a Boolean value with a default value of 0 (false off). If turned on, when the server is too busy to accept the new connection, the server sends the RST package to the client, which causes the client to reconnect. This option is only turned on when you are sure that the process is really unable to complete the connection request, which affects the customer's use. (when dealing with services such as SendMail and Apache that are already fully loaded, this option can quickly cause the client to terminate the connection and give the service program a buffer opportunity to handle the existing connection, so many firewalls recommend opening it)

[Email protected]:/home/zzy/unix# Cat/proc/sys/net/ipv4/tcp_abort_on_overflow

0

Backlog parameters and SYN flood attacks