Basic DDoS Defense
Distributed Denial of Service (DDoS) attack is a common form of network attack, in which attackers send a large number of requests to the target server, making it unable to connect to the network and provide services normally.
DDoS attacks are usually initiated by a large number of "zombie" computers (also known as "bots" or "botnets") distributed around the world, which may be infected with malicious software. Attackers can launch attacks through remote command control to disguise the source of the attack and increase its power.
SYN Flood attack is aimed at semi connected queues. The attacker keeps sending connection establishment requests to the server, but only completes the first step when establishing the connection. In the second step, when the attacker receives the SYN+ACK from the server, they intentionally drop the message and do nothing. This repeated execution of the attack process will quickly fill the server's semi connected queue, and other normal requests cannot establish a connection with the service. The attacker's goal is achieved.
hping3 (another tool developed by Redis authors) can construct TCP/IP protocol packets for system security auditing, firewall testing, DDoS attack testing, and more.
#The - S parameter represents the SYN (synchronization sequence number) for setting the TCP protocol
#- p means the destination port is 80
#- i u10 means sending a network frame every 10 microseconds
#-- random source randomizes the source IP address (simulating more realistic attacks)
#Current host: 192.168.0.2, acting as a "client" to initiate TCP connections
$ hping3 -S -p 80 -i u10 192.168.0.30
#Capture packets on host 192.168.0.30
$ tcpdump -i eth0 -n tcp port 80
#Flags [S] indicate that this is a SYN packet
#A large number of SYN packets indicate that this is a SYN Flood attack
09:15:48.287047 IP 192.168.0.2.27095 > 192.168.0.30: Flags [S], seq 1288268370, win 512, length 0
09:15:48.287050 IP 192.168.0.2.27131 > 192.168.0.30: Flags [S], seq 2084255254, win 512, length 0
09:15:48.287052 IP 192.168.0.2.27116 > 192.168.0.30: Flags [S], seq 677393791, win 512, length 0
09:15:48.287055 IP 192.168.0.2.27141 > 192.168.0.30: Flags [S], seq 1276451587, win 512, length 0
09:15:48.287068 IP 192.168.0.2.27154 > 192.168.0.30: Flags [S], seq 1851495339, win 512, length 0
- The client (attacker) constructs a large number of SYN packets and requests to establish a TCP connection
- After receiving a SYN packet, the server (attacked party) will send a SYN+ACK packet to the source IP (client) and wait for the last ACK packet of the three-way handshake until timeout
- After a period of time, the semi connection queue on the server will become full, making it impossible to establish a new TCP connection
SYN Flood mainly attacks TCP's semi connected queue, so the most important preventive measure is how to prevent the semi connected queue from being filled up by malicious connections?
- The TCP connection on the server will be in SYN-RECEIVED state
- The key to viewing TCP semi open connections lies in the SYN-RECEIVEN status of the connection
First, identify the packets with abnormal status, and then manually limit or set direct packet loss handling.
Firstly, we use the netstat command to identify the packets with status SYN-RECEIVID, and then analyze the abnormal packets within them.
# - n means not resolving the name
# - p represents displaying the process to which the connection belongs
$ netstat -n -p | grep SYN_RECV
# Discovered a large number of SYN-RECV connections with a source IP address of 192.168.0.2
...
tcp 0 0 192.168.0.30:80 192.168.0.2:12503 SYN_RECV -
tcp 0 0 192.168.0.30:80 192.168.0.2:13502 SYN_RECV -
tcp 0 0 192.168.0.30:80 192.168.0.2:15256 SYN_RECV -
tcp 0 0 192.168.0.30:80 192.168.0.2:18117 SYN_RECV -
...
After identifying the source IP address of the abnormal packet, to solve the problem of SYN Flood attack, simply discard the relevant packet and use the iptables command.
$ iptables -I INPUT -s 192.168.0.2 -p tcp -j REJECT
Of course, attackers do not attack with a single source IP address, so the source IP address in SYN Flood attacks is not fixed. In this case, manually limiting a single IP address may not be suitable (of course, the above command operations can also be converted into automated scripts). In addition, it can also be achieved by limiting the rate of SYN packets.
# Limit SYN concurrency to once per second
$ iptables -A INPUT -p tcp --syn -m limit --limit 1/s -j ACCEPT
# Limit the number of new connections established by a single IP within 60 seconds to 10
$ iptables -I INPUT -p tcp --dport 80 --syn -m recent --name SYN_FLOOD --update --seconds 60 --hitcount 10 -j REJECT
Although the above method can limit SYN Flood attacks initiated by a single attack source IP address, it may be ineffective if the attacker launches a large-scale (botnet) SYN Flood attack.
Because in the event of a large-scale SYN Flood attack, server administrators may not be able to SSH login (SSH is also based on TCP) to the server, let alone execute the relevant commands mentioned above, unless a monitor, keyboard, and mouse are plugged in for configuration.
Linux View Default Half Connection Queue Capacity:
# Note: This value may vary in different distributions and Linux versions
$ sysctl net.ipv4.tcp_max_syn_backlog
net.ipv4.tcp_max_syn_backlog = 512
For example, increasing the capacity of the semi connected queue to 65535:
$ sysctl -w net.ipv4.tcp_max_syn_backlog=65535
When Linux fails to check the SYN-RECV status of a connection, the kernel automatically retries:
$ sysctl net.ipv4.tcp_synack_retries
net.ipv4.tcp_synack_retries = 5
Reduce the number of automatic retries to 1:
$ sysctl-w net.ipv4.tcp_unack_restries=1
If you can't handle the massive demand for truth, just refuse directly.
$ sysctl net.ipv4.tcp_abort_on_overflow
net.ipv4.tcp_abort_on_overflow = 0
Enable connection rejection
sysctl -w net.ipv4.tcp_abort_on_overflow=1
In the default TCP three-way handshake process, TCP SYN Cookies send SYN packets from the client to the server. After receiving them, the server should reply with a SYN+ACK packet and enter the SYN-RECV state to wait for the client's ACK confirmation. However, if an attacker sends a large number of SYN packets to the server without replying with an ACK confirmation, the server's semi connection queue will be full and unable to accept normal new connections.
TCP SYN Cookies are a method specifically designed to defend against SYN Flood attacks. SYN Cookies calculate a hash value (SHA1) based on a TCP connection quadruple (including source address, source port, destination address, destination port) and an encrypted seed (such as system startup time), which is called a cookie.
Cookie is used as a sequence number to respond to SYN+ACK packets and release the connection state. After the client sends the last ACK of the three-way handshake, the server will calculate (reverse) this hash value again to confirm that it is the last SYN+ACK response packet returned, and then enter the TCP connection state.
After enabling TCP SYN cookies, there is no need to maintain a semi connected state, and naturally there is no longer a capacity limitation issue with the semi connected queue.
Enable TCP SYN Cookies:
# Temporary configuration, configuration will be lost after restart
$ sysctl -w net.ipv4.tcp_syncookies=1
net.ipv4.tcp_syncookies = 1
After enabling TCP syncookies, the kernel option (half connection capacity) net.ipv4.tcpmax_styn_macklog becomes invalid.
If the configuration needs to be permanently implemented, it should be written to the/etc/sysctl.conf file:
$ vi /etc/sysctl.conf
# Modify the corresponding configuration
net.ipv4.tcp_syncookies=1
net.ipv4.tcp_inack_retrys=1
net.ipv4.tcp_maxsyn_backlog=1024
# Effective immediately
$sysctl-p
Regardless of the type of reflective attack, its attack methods have the following characteristics:
- High traffic: Attackers send large amounts of data (request messages) to the target server or network, causing it to exceed its normal processing capacity
- Large scale and difficult to identify: Attackers operate hundreds or thousands of attack nodes (also known as "bots" or "botnets") to form large-scale attacks, and it is difficult for attack nodes to identify common features (attack traffic and normal traffic appear almost identical)
- Clear and indiscriminate attack: The purpose of the attack is usually to make the target server or network unavailable, and all open ports of the target server will be attacked
- Continuity: Attack behavior can last for hours or even days
It is difficult to achieve absolute prevention of DDoS attacks purely from a technical perspective, after all, websites like Github can only "lie flat" when facing DDoS attacks. Currently, the mainstream solution is basically solved by "adding money", such as stacking hardware, building software, stacking bandwidth, and so on.
- Traffic filtering and cleaning: Use professional DDoS protection equipment or services provided by cloud computing vendors to monitor, filter, and clean traffic in real-time, identify and block abnormal traffic
- Intrusion Detection and Defense: Deploy Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS) to monitor and analyze network traffic in real-time, identify and block abnormal traffic
- Increase bandwidth and resources: Increase network bandwidth and server resources to enhance the system's ability to resist high traffic attacks
- ISP: Cooperate with Internet Service Providers (ISPs) to jointly prevent DDoS attacks
- CDN: Use CDN to distribute traffic as much as possible and minimize the impact of attacks on critical businesses/services
- Flow restriction: Restricting network traffic in critical business/services
- Call the police: Use the power of national justice to sanction them