What about a flood attack?

Flood attack is a more common network attack, the general embodiment is the machine is slow (high CPU), SSH and other network services landing slow even the situation, even in the # Netstat-n | awk '/^tcp/{++s[$NF]} END {for (a In S) print A, S[a]} ' command, found that the number of SYN_RECV is much larger than the number of established (almost 5~8 times more than), and then look at the system log or use #dmesg, the following statement appears:

Possible SYN flooding on port 80. Sending cookies.

Principle Understanding

Flood attack principle is to take advantage of the TCP three handshake vulnerability, the bad people fake a lot of fake IP address, these IP a similar flood of the brain to your server to initiate the request, and then the server honestly and orderly received the SYN, and then one of the return ACK, However, because these IP are not actually exist, so this step is stuck, and then need to wait in the corresponding data area for some time, after the time limit, the server will think these links are necrotic, completely abandon them. And then accept the new link, but because "flood" too big, will cause the system overload, so the CPU is too high and so on.

In this case, Linux by default in the form of sending cookies to protect themselves, the principle is that when the server receives the client's SYN packet is not deliberately set up a data area to return to Syn+ack, but according to Syn to set a cookie, The server will check the legality of the link according to the cookie, if the link is not lawfully discarded directly, if it is legal to set a data area to save the entire link.

What should I do?

Find this situation to use # Netstat-na |grep Syn_recv|more in the first time to quickly locate the problem IP, and then iptables all drop off.

If it is found that flood attacks are not from malicious IP attacks, but ordinary multiuser access, then it is the problem of their own servers, this time need to change the value of/proc/sys/net/ipv4/tcp_syncookies from 1 to 0, which means to shut down the protection of flood attacks.

If you feel that the entire valve is closed, the entire server seems to be less secure (there is a side effect), then you can appropriately expand some of the threshold, the specific file can be changed as follows:

1)/proc/sys/net/ipv4/tcp_max_syn_backlog This file is to specify how many SYN requests the system can cache, this value is generally 512 by default, some servers may be 1024 strong, but note that Please do not change this number easily to more than 1024, may appear to ignore the phenomenon of broadcasting;

2)/proc/sys/net/ipv4/tcp_synack_retries, this means that when the client does not return Ack+syn, the server will give several chances to continue to try the link with the client, which is 5 times by default. Can be suitably changed to small, or simply 0, to speed up the recovery of semi-connected. Of course, change to 0, is also a disadvantage, is that users may connect to the Internet station, but the general normal IQ users will refresh, so that will reconnect, so this drawback is not what;

3)/proc/sys/net/ipv4/tcp_abort_on_overflow, this value by default is 0, if changed to 1, the server will be slow when the link, send a reset package to quickly restart the link, the value is opened according to the situation;

Extended

There are many files in/proc/sys/net/core and/proc/sys/net/ipv4, here is a brief description of some file uses.

1)/proc/sys/net/ipv4/ip_local_port_range: The port allocation range when the machine is actively connected to other machines;

2)/proc/sys/net/core/netdev_max_backlog: The maximum number of packets that are allowed to be sent to the queue when the network device receives a packet at a rate that is faster than the rate at which the kernel processes these packets;

3)/proc/sys/net/core/wmem_max: Maximum TCP data send buffer (bytes);

4)/proc/sys/net/core/rmem_max: The largest TCP data receive buffer (bytes);

5)/proc/sys/net/ipv4/tcp_timestamps = 0: Timestamp option, in conjunction with the preceding net.ipv4.tcp_tw_reuse parameter, is a Boolean value, 0 or 1.

This article is from "Life is waiting for Gordo" blog, please make sure to keep this source http://chenx1242.blog.51cto.com/10430133/1773403

What about a flood attack?