[Safety Tutorial] SYN Flood attacks, SYN cookie defense, and kernel parameter modification for Linux/FreeBSD

HackerIt is a desirable and promising career. I appreciate good hackers and hate bad hackers. The so-called bad hacker is the kind of guy who causes someone on the other side to work overtime.

    SYN Flood attacks are a typical denial of service attack. The so-called denial of service attack is to indirectly achieve the purpose of the attack by making the victim host or network unable to provide good service. Hackers like to play this to show that they are level, capable, and courageous by making the other party work overtime, but in fact, it is nothing.

   1: What is a SYN Flood attack?

    SYN Flood attacks take advantage of the three-way handshake process of the TCP protocol in IPv4. This protocol stipulates that if one end wants to initiate a TCP connection to the other end, it needs to first send a TCP SYN (synchronize) packet to the other party, and the other party sends a TCP SYN + ACK packet back after receiving it, and then the initiator sends a TCP ACK (ACKnowledge Character) packet back, so that the three handshakes are over.

    In the above process, there are some important concepts:

    The queue is not connected: In the three-way handshake protocol, the server maintains an unconnected queue that opens an entry for each client's SYN packet (syn=j) that indicates that the server has received the SYN packet and issues a confirmation to the customer, awaiting the customer's confirmation packet. The connection identified by these entries is in a Syn_RECV state on the server, and when the server receives a confirmation packet from the customer, the entry is deleted and the server enters the ESTABLISHED state. In other words, when the TCP server receives the TCP SYN request packet, before sending the TCP SYN+ACK packet back to the TCP client, the TCP server must first allocate a data area to serve the TCP connection formed by this hand. Generally, the connection state when the SYN packet is received but the ACK packet has not yet been receivedHalf-open connection（Half-open Connection）。

    Backlog parameter: Indicates the maximum number of unconnected queues.

    SYN-ACK number of retransmissions: After the server sends the SYN-ACK packet, if the customer confirmation packet is not received, the server performs the first retransmission, waits for a period of time and does not receive the customer confirmation packet, and performs the second retransmission, if the number of retransmissions exceeds the maximum number of retransmissions specified by the system, the system deletes the connection information from the semi-connection queue. Note that the waiting time for each repass is not necessarily the same.

    Semi-connected survival time: Refers to the maximum time that an entry in the semi-connection queue survives, that is, the maximum time from the time the service receives the SYN packet to the time when the packet is confirmed to be invalid, and the time value is the sum of the maximum waiting time for all retransmission request packets. Sometimes we also call semi-connected survival time time, SYN_RECV survival time.

    In the most common SYN flood attack, the attacker sends a large number of TCP SYN packets to the victim in a short period of time, at which point the attacker is the TCP client and the victim is the TCP server. According to the description above, the victim would assign a specific data zone to each TCP SYN packet, as long as the SYN packets had different source addresses (which would be easy for attackers to forge). This will put a lot of strain on the TCP server system and eventually cause the system to not work properly.

    2. The principle of SYN cookies

    One of the ways to effectively prevent SYN Flood attacks is SYN cookies. SYN Cookie Reason D. Invented by J. Bernstain and Eric Schenk.

    SYN cookies are a modification of the TCP server-side three-way handshake protocol to prevent SYN Flood attacks.Its principle is:When the TCP server receives a TCP SYN packet and returns a TCP SYN+ACK packet, it does not allocate a dedicated data area, but calculates a cookie value based on this SYN packet. When a TCP ACK packet is received, the TCP server checks the legitimacy of the TCP ACK packet based on that cookie value. If legal, a dedicated data area is allocated to handle future TCP connections.

    Let's talk about how to configure kernel parameters to implement SYN cookies in Linux and FreeBSD

    Three: Linux settings

    If your server configuration is not good, 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, the number of TIME_WAIT sockets on the server can be reduced.

    TIME_WAIT can be viewed with the following command:

On Linux, such as CentOS, you can achieve this by modifying the /etc/sysctl.conf file.

    Add the following lines:

Illustrate:

net.ipv4.tcp_syncookies = 1 means SYN Cookies are enabled, which is a BOOLEAN. When SYN waits for the queue to overflow, enable cookies to deal with it, which can prevent a small number of SYN attacks, and the default is 0, which means it is closed.
net.ipv4.tcp_tw_reuse = 1 means that reuse is enabled, which is a BOOLEAN. Allows reusing TIME-WAIT sockets for new TCP connections, defaulting to 0, indicating closure;
net.ipv4.tcp_tw_recycle = 1 means to enable fast recycling of TIME-WAIT sockets in TCP connections, which is a BOOLEAN, and the default is 0, which means it is closed.
net.ipv4.tcp_fin_timeout = 30 means that if the socket is closed by a local request, this parameter determines how long it will remain in the FIN-WAIT-2 state. The unit is seconds.
net.ipv4.tcp_keepalive_time = 1200 indicates how often TCP sends keepalive messages when keepalive is used. The default is 2 hours, changed to 20 minutes. The unit is seconds.
net.ipv4.ip_local_port_range = 1024 65000 indicates the range of ports used for outward connections. The default case is small: 32768 to 61000, changed to 1024 to 65000.
net.ipv4.tcp_max_syn_backlog = 8192 indicates the length of the SYN queue, which is 1024 by default, and the length of the increased queue is 8192 to accommodate more network connections waiting for connection.
net.ipv4.tcp_max_tw_buckets = 5000 indicates the maximum number of sockets that the system maintains at TIME_WAIT the same time, and if this number is exceeded, TIME_WAIT sockets will be immediately cleared and a warning message will be printed. The default is 180000, changed to 5000. For servers such as Apache and Nginx, the parameters in the previous lines can reduce the number of sockets TIME_WAIT well, but for Squid, the effect is not great. This parameter controls the maximum number of TIME_WAIT sockets to prevent the Squid server from being dragged out by a large number of TIME_WAIT sockets.
net.ipv4.tcp_synack_retries and net.ipv4.tcp_syn_retries define the number of SYN retries.

Run the following command to make the configuration take effect:

If you don't want to modify /etc/sysctl.conf, you can also use the command to do so:

Fourth, set up under FreeBSD

    yayu's personal learning point of view: the defense against syn in FreeBSD may not be the same as in Linux, the parameters configured are not exactly the same, and the relevant configuration and understanding may not be correct :)

    There is one in the TCP linkMSL(max segment lifetime)The concept ofMaximum generation timeThe MSL value is taken for 30 seconds in general implementations, and some implementations take 2 minutes. "Passive shutdown" in the TCP state machine: From CLOSE_WAIT to LAST_ACK, there is a rule as follows: When TCP performs an active shutdown and sends back the last ACK, the connection must stay in the TIME_WAIT state for twice as long as the MSL. This allows TCP to send the last ACK again in case it is lost (the other end times out and resends the last FIN).

    The existence of this rule has the consequence that the link (client address, port and server-side address, port) on that address cannot be used during this 2*MSL time. For example, if we close a link after creating it and then quickly restart the link, then the port will be unavailable.

    TIME_WAIT time is 2*MSL. So you can reduce TIME_WAIT time by adjusting net.inet.tcp.msl. For the web server, this value can be adjusted to 7500 or 2000 (access a web, the page cannot be flashed for more than 4~15 seconds, you can consider giving up -_-)

    Parameter setting reference:

On FreeBSD, yayu didn't see a command like "/sbin/sysctl -p" that could make the contents of /etc/sysctl.conf effective, so he just used the command: