一 DoS攻击

DoS攻击即拒绝服务攻击，如果细分来说包括非常多种类，有UDP洪水，ACK类型，DNS放大请求，NTP放大类型，TCP洪水，HTTP洪水，SYN洪水。总之这些攻击的目的是消耗服务器的带宽，内存，和cpu资源，从而让服务器因资源耗尽对一切过来的请求，只能拒绝或提供性能很差的服务，本文就是模拟SYN洪水攻击，并对这种场景进行分析，提供一些缓解攻击的办法。

二环境和准备

2.1 网络环境

目前采用两台虚拟机和一台物理机实现部署环境，虚拟机均为centos8.5 ，整个网络环境如下：

2.2 软件安装

Nginx部署的web采用Docker简单部署，Dos工具采用hping3 发起syn攻击。

#podman类似docker，几乎可以通用
#-i  以交互模式运行容器，通常与 -t 同时使用
#-t  为容器重新分配一个伪输入终端，通常与 -i 同时使用
#-d  后台运行容器，并返回容器ID
[root@localhost ~]# podman  run -itd --name=nginx3 -.NETwork=host nginx

#测试服务是否启动,虽然是404 但是请求速度还是很快的
[root@localhost ~]#  curl -s -w 'Http code: %{http_code}nTotal time:%{time_total}sn' -o /dev/null http://192.168.31.50
Http code: 404
Total time:0.000963s

攻击工具安装：

yum install hping3

三攻击分析

3.1 hping3 发送SYN包攻击

# -S 发送SYN包，-p 发送的端口80  -i u15 每1us 发送一个包
[root@Miwifi-RA72-srv ~]# hping3 -S -p 80 -i u1 192.168.31.50

3.2 服务机器分析

首先发现访问变慢了，注意有时候并不明显，测试url访问性能：

[root@MiWiFi-RA72-srv ~]#  curl -s -w 'Http code: %{http_code}nTotal time:%{time_total}sn' -o /dev/null http://192.168.31.50
Http code: 404
Total time:31.909641s

时间确实增加了，竟然要31s，注意一定要发一段时间，不然看不到效果。那网络有问题，我们首先要看下网络的流量情况：

[root@localhost ~]# sar -n DEV 3
平均时间:     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s   %ifutil
平均时间:        lo      1.22      1.22      0.06      0.06      0.00      0.00      0.00      0.00
平均时间:     ens33  16441.20  15444.20    963.43    905.56      0.00      0.00      0.00      0.79
平均时间:     ens37      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
平均时间:     ens38      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
平均时间:     ens39      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00

计算平均包长： 963*1024/16441.20=59B ，发现这些都是小包，下面我们需要继续分析下这些包是什么包，利用tcpdump抓包：

tcpdump -i ens33 -n tcp port 80 -w test.pcap

下载下来用wireshark分析下如下： wireshark 打开文件后，通过统计->流量图菜单弹出流分析：

首先我们可以看到192.168.31.200发起了很多的SYN包给192.168.31.50，192.168.31.50给192.168.31.200回复了SYN+ACK包，想建立了TCP连接，但是被192.168.31.200发送RST包中断了，这个和我们预期有些差别，主要是我们的IP没有随机，导致我们会回复RST包，这样虽然半连接也在增多，因为RST会导致终止了，所以消耗资源增加不够快，为了让服务器不回复给我们，我们可以通过hping3的另外选项发送包：

hping3 --rand-source -S -p 80 -i u1 192.168.31.50

抓包后继续用wireshark分析：

可以看到有大量的随机ip对192.168.31.50发起连接， 192.168.31.50对这些ip做响应，但是这些ip其实是欺骗的ip，导致无法收到响应包括RST报文，所以会导致SYN+ACK重发，从而消耗系统的资源。

TCP的三次握手还不清楚的话，可以按照下面的图理解下：

四缓解办法

4.1 封IP

如果我们发现有固定的IP发来大量的SYN包，可以采用iptables 封了这个IP，禁止特定ip来发起连接然后启动防火墙：

#iptables -I INPUT -s 192.168.31.200  -p tcp -j REJECT
#启动防火墙
#systemctl start firewalld

这时候在抓包，发现被拒绝了。

[root@MiWiFi-RA72-srv ~]# hping3    -S -p 80 -i u1 192.168.31.50
HPING 192.168.31.50 (ens33 192.168.31.50): S set, 40 headers + 0 data bytes
ICMP Packet filtered from ip=192.168.31.50 name=UNKNOWN   
ICMP Packet filtered from ip=192.168.31.50 name=UNKNOWN   
ICMP Packet filtered from ip=192.168.31.50 name=UNKNOWN   
ICMP Packet filtered from ip=192.168.31.50 name=UNKNOWN   
ICMP Packet filtered from ip=192.168.31.50 name=UNKNOWN   
ICMP Packet filtered from ip=192.168.31.50 name=UNKNOWN   
ICMP Packet filtered from ip=192.168.31.50 name=UNKNOWN   
ICMP Packet filtered from ip=192.168.31.50 name=UNKNOWN   
[send_ip] sendto: Operation not permitted

tcpdump抓包看下,发现没有回复了，也许是没有来及回复- -

08:29:26.872385 IP 192.168.31.200.60180 > 192.168.31.50.http: Flags [S], seq 633025815, win 512, length 0
08:29:26.872389 IP 192.168.31.200.60181 > 192.168.31.50.http: Flags [S], seq 1327904571, win 512, length 0
08:29:26.872488 IP 192.168.31.200.60182 > 192.168.31.50.http: Flags [S], seq 1677934026, win 512, length 0
08:29:26.872498 IP 192.168.31.200.60183 > 192.168.31.50.http: Flags [S], seq 940613549, win 512, length 0
08:29:26.872510 IP 192.168.31.200.60184 > 192.168.31.50.http: Flags [S], seq 245284800, win 512, length 0
08:29:26.872514 IP 192.168.31.200.60185 > 192.168.31.50.http: Flags [S], seq 620067640, win 512, length 0
08:29:26.872612 IP 192.168.31.200.60186 > 192.168.31.50.http: Flags [S], seq 1859432659, win 512, length 0
08:29:26.872622 IP 192.168.31.200.60187 > 192.168.31.50.http: Flags [S], seq 2106267374, win 512, length 0
9856 packets dropped by kernel

这种局限性很大，一旦攻击端改成随机ip或者DDoS攻击，那么就不好封IP了。

4.2 限制每秒的SYN报文

# 限制syn并发数为每秒1次 这个可能会误伤啊，如果用户比较多很多被限制了
#iptables -A INPUT -p tcp --syn -m limit --limit 1/s -j ACCEPT

# 限制单个IP在60秒新建立的连接数为10
# iptables -I INPUT -p tcp --dport 80 --syn -m recent --name SYN_FLOOD --update --seconds 60 --hitcount 10 -j REJECT

#删除
# 查看规则
iptables -nL --line-number
# 删除规则 第二行
 iptables -D INPUT 2

怎么知道规则生效那，除了上面的，还可以通过查看连接状态：

[root@localhost ~]# netstat -an|grep RECV|wc -l
128

加上规则后，这个数量为0，表示被拒绝了。

4.3 内核参数调整

增大半连接长度 通过上面的TCP三次握手图可以知道，如果增加了半连接队列的长度，一定程度上可以缓解下Dos攻击。

半连接队列长度 = roundup_pow_of_two(max_t(u32,min(somaxconn,sysctl_max_syn_backlog,backlog),8) +1)) roundup_pow_of_two为最接近2的指数次幂，简单理解为向上按照2的指数次幂取整。不同的系统版本。

tcp_max_syn_backlog是指定所能接受SYN同步包的最大客户端数量，即半连接上限；
somaxconn是指服务端所能accept即处理数据的最大客户端数量，即完成连接上限。默认值：

[root@localhost ~]# cat /proc/sys/net/ipv4/tcp_max_syn_backlog
128
[root@localhost ~]# cat /proc/sys/net/core/somaxconn
128

backlog 为用户程序设置的队列长度。更改方法如下：

[root@localhost ~]# sysctl -w net.ipv4.tcp_max_syn_backlog=1024
net.ipv4.tcp_max_syn_backlog = 1024
[root@localhost ~]# sysctl  net.ipv4.tcp_max_syn_backlog
net.ipv4.tcp_max_syn_backlog = 1024
[root@localhost ~]# sysctl -w net.core.somaxconn=1024
net.core.somaxconn = 1024
[root@localhost ~]# sysctl  net.core.somaxconn
net.core.somaxconn = 1024
永久更改可以将配置写入到/etc/sysctl.conf中
[root@localhost ~]# vim /etc/sysctl.conf
net.core.somaxconn = 1024
net.ipv4.tcp_max_syn_backlog = 1024
#生效
[root@localhost ~]# sysctl -p

顺便聊下全连接，完成三次握手的会将连接信息放到全连接队列中，我们可以通过：

ss -lnt
[root@localhost ~]# ss -lnt
State      Recv-Q     Send-Q         Local Address:Port          Peer Address:Port     Process     
LISTEN     0          128                  0.0.0.0:111                0.0.0.0:*                    
LISTEN     0          128                  0.0.0.0:80                 0.0.0.0:*

在Listen中其中Send-Q 为全连接队列的长度，Recv-Q为目前使用了多少。全连接队列的大小= min(backlog, somaxconn） backlog为用户设置的队列长度，somaxconn同上，为系统参数。

减少syn-ack重发次数 服务器端收到SYN连接后会回复SYN+ACK，如果回复失败会进行多次重试，默认5次，我们可以减少重试次数：

[root@localhost ~]# sysctl net.ipv4.tcp_synack_retries
net.ipv4.tcp_synack_retries = 5
[root@localhost ~]# sysctl -w net.ipv4.tcp_synack_retries=1
net.ipv4.tcp_synack_retries = 1
[root@localhost ~]# sysctl net.ipv4.tcp_synack_retries
net.ipv4.tcp_synack_retries = 1

开启SYN cookie 对于半连接的队列长度，设置多长合适那，不太好设置，我们可以打开SYN cookie，这样在连接队列满了之后，会根据SYN的包计算一个cookie值，这个cookie作为将要返回的SYN ACK包的初始序列号，服务器端不再保存任何信息，客户回一个ACK包时候，根据包头信息计算cookie值，在于返回的确认序列号对比，如果相同，则是一个正常连接，如果不合法，则返回一个RST报文，这其中校验cookie是否合法时候，还要判断ACK时间是否为4分钟内到达，是才合法。

缺点看起来好像cookie方式比较完美，但是由于不再服务器端保存任何信息，所以就无法重发SYN+ACK报文，由于有一定计算量，且如果对方采用ACK攻击，那么服务器端需要计算比较，也无法预防的。

[root@localhost ~]# sysctl -w net.ipv4.tcp_syncookies=1
net.ipv4.tcp_syncookies = 1

同样，永久生效需要写入到/etc/sysctl.conf中去。

五总结

Dos攻击，特别是DDos攻击，采用的是发送大量包的方法来消耗服务器端的资源，上面的手段也只能减缓攻击，不能彻底解决问题，业界对这种攻击一般用流量清洗的办法，将DDos攻击的流量和正常用户请求分离出来，或者增加CDN缓存，和WAF等方式。

DoS攻击多角度查看和缓解办法