Linux detection and prevention of DDOS attacks skills

As a webmaster, not only to ensure the website traffic increases, but also to prevent DDOS attacks, then how to detect DDOS attacks under Linux system? How to prevent DDOS attacks? This is all a learning.

1, the use of tools to detect View netstat SYN connection

netstat -n -p -t

Active Internet connections (w /o servers)

Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name

tcp 0 0 192.168.0.200:5050 192.168.0.38:48892 TIME_WAIT -

tcp 0 0 192.168 .0.200:5050 192.168.0.38:36604 TIME_WAIT -

tcp 0 0 192.168.0.200:5050 192.168.0.38:52988 TIME_WAIT -

tcp 0 0 192.168.0.200:5050 192.168.0.38: 38911 TIME_WAIT -

tcp 0 0 192.168.0.200:5050 192.168.0.38:58623 TIME_WAIT -

tcp 0 0 192.168.0.200:43690 192.168.0.200:61616 ESTABLISHED 10415/java

Of course, all of the above are normal connections. Of course, if TIME_WAIT is too much, it is definitely not normal. (Either attacked or parameter tuning is required.)

In the case of a malicious attack by DDOS, it will be seen in the system. Many connections are in the SYN_RECV state (SYN_RECEIVED state in the WINDOWS system). The IP addresses are random, indicating that this is a SYN attack with IP spoofing.

tcp 0 10.11.11.11:23 124.173.152.8:25882 SYN_RECV-

tcp 0 10.11.11.11:23 236.15.133.204:2577 SYN_RECV-

tcp 0 10.11. 11.11:23 127.160.6.129:51748 SYN_RECV-

The port status of a specific host is as follows:

CLOSED: No connection is active or in progress

LISTEN: The server is waiting for an incoming call

SYN_RECV: A connection request has arrived, waiting for confirmation

SYN_SENT: The application has started, opening a connection

ESTABLISHED: Normal data transfer status

FIN_WAIT1: The application says it has completed

FIN_WAIT2: The other side has agreed to release

ITMED_WAIT: Waiting for all packets to die

CLOSING: Both sides try to close at the same time < Br>

TIME_WAIT: The other side has been initialized to release

LAST_ACK: Wait for all groups to die

A slightly more detailed explanation can be seen in Baidu Encyclopedia's interpretation and extension of the ESTABLISHED state .

There are many statistics on the specific SYN_RECV status. I will introduce the two scripts here:

netstat -an |  Awk ‘/^tcp/{++S[$NF]} END {for(a in S) print a, S[a]}’

The above script will list the connections for all states. number.

netstat -n -p -t |  Grep SYN_RECV |  Grep :80 |  Wc -l

Of course, the above 80 is specifically for web sites subject to DDOS attacks.

2, LINDOS DDOS SYN attack prevention

Prevention also mainly from two aspects, one is sysctl's own configuration on the syn side, the second is the firewall strategy.

sysctl -w net.ipv4.tcp_syncookies=1 # tcp syncookie, default off

sysctl -w net.ipv4.tcp_max_syn_backlog=1280 # syn queue, default 1024," 1280 may not work Stable, need to modify the kernel source parameters

sysctl -w net.ipv4.tcp_synack_retries=2 # syn-ack handshake state retry times, default 5, changed to 1 or 2 when subjected to syn-flood attacks

sysctl -w net.ipv4.tcp_syn_retries=2 #External syn handshake retry times, default 4

The above four places are frequently mentioned on the Internet, of course, there are also unmentioned Check it out with the following command.

[root@web3 nginx]# sysctl -a| Grep syn

net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 60

net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent = 120

net.ipv4.tcp_max_syn_backlog = 1024

net.ipv4.tcp_syncookies = 1

net.ipv4.tcp_synack_retries = 5

net.ipv4.tcp_syn_retries = 5

fs.quota.syncs = 25

If not attacked, the above parameters are not recommended for modification. It is said that there is a risk of increasing the instability of the host.
Previous123Next page Total 3 pages