Technology Sharing

[HBZ sharing] How to avoid TCP flood attacks

2024-07-12

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

How a conventional flood attack works

  1. When TCP establishes a half-connection during the second handshake, a flood attack can be launched.
  2. A large number of requests initiate TCP connections. During the second handshake, the server will put these requests in the semi-connection queue. Since these malicious attack clients will not confirm the third handshake, these semi-connections cannot be released. The server will wait until the timeout. At this time, the semi-connection queue will be full and normal request connections cannot be answered. This is the method of flood attack.

How to deal with flood attacks in general

  1. When syncookies is enabled, during the first handshake, the server will calculate a hash value (SHA1) based on (source address, source port, destination address, destination port, etc.) and a random number, and then the generated syncookies will be returned to the client in the second handshake. When the client confirms the third handshake, it will send the syncookies to the server again. The server will verify whether the syncookie matches the previous one. If they match, a TCP connection will be established.
  2. The advantage of this approach is that the TCP connection will not be established when the server does not receive or receives syncookies that do not match. When using syncookies, the server will not maintain a semi-connection queue, that is, there is no semi-connection state, because there is no need for semi-connection when using syncookies, so it avoids the semi-connection queue being full and unable to receive new connections.

Scenarios that syncookies cannot solve

  1. When a large number of DDOS attacks are launched, the syncookies method will also be paralyzed. The reason for the paralysis is that the CPU has to calculate a large number of syncookies, which causes the CPU to be killed. Because the calculation of syncookies also consumes CPU performance, facing a huge amount of DDOS, the CPU cannot withstand it. At this time, the only option is to increase the bandwidth and use the hard cap configuration.

Other solutions

  1. Increase the semi-connection queue and the full connection queue (this method is basically ineffective for massive attacks)
  2. Reduce the number of SYN+ACK retransmissions (TCP relies on retransmissions to maintain a stable connection). That is, when a flood attack is received with a large number of SYN requests, the server will not receive a response and will keep retrying until the maximum number of times is reached. Reducing this maximum number can alleviate the problem.

How to check whether it has been attacked by flood

1. 先进行流量查看:
sar -n DEV 1 -h

然后只看eth0即可-->用rxkb/s 和 rxpck/s 这两列相除-->如果得出的包就50-60几字节,
那就说明是小包搞鬼,有可能遭受洪水攻击了,一般来说最大MTU = 1460

2. 如果发现是小包搞鬼,那就再进行网络抓包, 输入如下命令
tcpdump -i eth0 -n tcp port 80

3. 看有多少个[S], 这个表示发起TCP请求阶段,如果[S]过多,那就说明是洪水攻击,这是洪水攻击的特征


4. 进一步确认是洪水攻击,查询半连接的池子大小,以及当前半连接数量
半连接总大小: cat /proc/sys/net/ipv4/tcp_max_syn_backlog
当前半连接数: ss -s 或 netstat -n -p | grep SYN_RECV | wc -1



[S]: SYN,开始连接
[P]: PSH, 推送数据
[F]: FIN, 结束连接
[R]: RST, 重置连接
[.]: 没有Flag,可能是ACK 也可能是URG

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24