如何在Linux上模拟和缓解DDoS攻击

在我的上一篇文章谈到了如何使用tcpdump和wireshark，并带您了解了几个用例。今天我们来看看另一个常见的问题，如何缓解 DDoS（分布式拒绝服务）导致的性能下降。

什么是 DDoS？

DDoS 的前身是 DoS（Denial of Service），即拒绝服务攻击，是指利用大量合理请求占用过多目标资源，使目标服务无法响应正常的请求.

DDoS（Distributed Denial of Service）采用基于 DoS 的分布式架构，利用多台主机同时攻击目标主机。这样，即使目标服务部署了网络防御设备，仍然无法应对大量的网络请求。

从攻击原理来看，DDoS 可分为以下几种。

用尽带宽：无论是服务器还是路由器、交换机等网络设备，带宽都有一个固定的上限。当带宽耗尽时，会出现网络拥塞，无法传输其他正常的网络数据包。

耗尽系统资源：网络服务的正常运行需要一定的系统资源，如CPU、内存等物理资源，以及连接表等软件资源。一旦资源耗尽，系统将无法处理其他正常的网络连接。

耗尽应用资源：应用程序的运行通常还需要与其他资源或系统进行交互。如果应用程序一直忙于处理无效请求，也会导致正常请求的处理速度变慢，甚至没有响应。

无论哪种类型的 DDoS，危害都是巨大的。那么，如何发现系统遭受了 DDoS 攻击，如何应对这种攻击呢？让我带您了解一个现实生活中的用例。

案例准备

您需要遵循：

3 台 Linux 主机：应用程序、攻击者、客户端

预安装docker、sar、hping3、tcpdump、curl。

应用服务器

让我们在应用主机上启动一个简单的nginx服务：

[root@app~]#dockerrun-itd--name=nginx--network=hostnginx
a8b3685d5eef0ffa2dead081b88d50d777db04bedbdb77ba886ca89b4bb690d2
[root@app~]#dockerps
CONTAINERIDIMAGECOMMANDCREATEDSTATUSPORTSNAMES
a8b3685d5eefnginx"/docker-entrypoint.…"24secondsagoUp21secondsnginx

客户端

然后，在客户端主机中，使用curl访问 Nginx 正在监听的端口，并确认 Nginx 已经正常启动：

[root@client~]#curl-s-w'Httpcode:%{http_code}
Totaltime:%{time_total}s
'-o/dev/nullhttp://172.31.88.139
Httpcode:200
Totaltime:0.002437s

从这里可以看出，正常情况下，我们访问 Nginx 只需要 2ms（0.002s）。

攻击者

现在，让我们从攻击者主机那里运行hping3命令来interwetten与威廉的赔率体系 Dos 攻击：

#-Smeanssetsyn，-pmeansport80
#-iu10sendapacketframeevery10m-seconds
$hping3-S-p80-iu10--flood192.168.0.30
HPING172.31.88.139(eth0172.31.88.139):Sset,40headers+0databytes
hpinginfloodmode,noreplieswillbeshown

缓解攻击

现在让我们回到客户端主机，再次尝试curl命令：

[root@client~]#curl-s-w'Httpcode:%{http_code}
Totaltime:%{time_total}s
'-o/dev/nullhttp://172.31.88.139
Httpcode:000
Totaltime:10.001s
curl:(28)Connectiontimedoutafter10000milliseconds

这次普通客户端的连接超时，其并没有收到 Nginx 服务的响应。

这里发生了什么事呢？让我们回到主机应用程序，并检查当前的网络状态：

[root@app~]#sar-nDEV1
0849IFACErxpck/stxpck/srxkB/stxkB/srxcmp/stxcmp/srxmcst/s%ifutil
0850docker00.000.000.000.000.000.000.000.00
0850eth022274.00629.001174.6437.780.000.000.000.02
0850lo0.000.000.000.000.000.000.000.00

从这次sar的输出可以看出，网络接收到的 PPS 已经达到 2 万多，但是 BPS 只有 1174kB。因此，可以计算每个包的大小只有54B（）。

包大小不算大，但这是个什么样的包呢？让我们使用tcpdump来捕获：

[root@app~]#tcpdump-ieth0-ntcpport80
0948.287047IP172.31.82.28.27095>172.31.88.139:Flags[S],seq1288268370,win512,length0
0948.287050IP172.31.82.28.27131>172.31.88.139:Flags[S],seq2084255254,win512,length0
0948.287052IP172.31.82.28.27116>172.31.88.139:Flags[S],seq677393791,win512,length0
0948.287055IP172.31.82.28.27141>172.31.88.139:Flags[S],seq1276451587,win512,length0
0948.287068IP172.31.82.28.27154>172.31.88.139:Flags[S],seq1851495339,win512,length0
...

在该输出中，Flags [S]表示这是一个 SYN 数据包。而大量的 SYN 数据包表明这是一次 SYN Flood 攻击。如果我们用wireshark来观察，可以更加直观地看到 SYN Flood 的过程：

事实上，SYN Flood 是互联网上最经典的 DDoS 攻击。从上图也可以看出它的原理：

客户端构造大量 SYN 包，请求建立 TCP 连接；

服务器收到包后，会向源 IP 发送一个 SYN+ACK 包，并等待三次握手的最后一个 ACK 包，直到链接超时。

这种等待状态的 TCP 连接通常也称为半开连接（Half-Open Connection）。由于连接表（Connection Table）的大小是有限的，而大量的半开连接会导致连接表快速填满，从而无法建立新的 TCP 连接。

从下面的 TCP 状态图可以看到，此时服务器端的 TCP 连接会处于SYN_RECEIVED状态：

我们可以使用netstat来查看所有连接的状态，但需要注意的是SYN_REVEIVED的状态通常缩写为SYN_RECV。

[root@app~]#netstat-n-p|grepSYN_REC
tcp00172.31.88.139:80172.31.82.28:12503SYN_RECV-
tcp00172.31.88.139:80172.31.82.28:13502SYN_RECV-
tcp00172.31.88.139:80172.31.82.28:15256SYN_RECV-
tcp00172.31.88.139:80172.31.82.28:18117SYN_RECV-
...

从结果中可以发现，存在大量的SYN_RECV状态的连接，源 IP 地址为172.31.82.28。现在，让我们统计一下正处于SYN_RECV状态的连接数：

[root@app~]#netstat-n-p|grepSYN_REC|wc-l
193

找出源 IP 后，只需丢弃相关数据包即可解决 SYN 攻击的问题。此时，iptables可以帮你完成这个任务：（注意：Serban 在评论中建议“在这种情况下，DROP比可能REJECT更好”）

[root@app~]#iptables-IINPUT-s172.31.82.28-ptcp-jREJECT

执行上述命令后，让我们再次从客户端主机尝试curl：

$curl-w'Httpcode:%{http_code}
Totaltime:%{time_total}s
'-o/dev/null--connect-timeout10http://172.31.88.139
Httpcode:200
Totaltime:1.572171s

但一般来说，SYN Flood 攻击中的源 IP 是不固定的（例如，您可以通过将--rand-source选项添加到hping3命令来随机化源 IP）。此时，刚才的方法并不适用。

幸运的是，我们还有许多其他方法可以达到类似的目的。例如，我们可以通过两种方式限制同步数据包的速率：

#Limitthenumberofsynconcurrencyto1persecond
$iptables-AINPUT-ptcp--syn-mlimit--limit1/s-jACCEPT
#LimitthenumberofnewlyestablishedconnectionsforasingleIPin60secondsto10
$iptables-IINPUT-ptcp--dport80--syn-mrecent--nameSYN_FLOOD--update--seconds60--hitcount10-jREJECT

到目前为止，我们已经初步限制了 SYN Flood 攻击。但这还不够，因为我们的案例只是单一的攻击源。

如果多台机器同时发送 SYN Flood，则该方法可能直接失效。因为您可能无法通过 SSH 连接到机器（SSH 也是基于 TCP 的），更不用说执行上面的那些排查命令了。

TCP 优化

为了缓解多台机器的 SYN Flood 攻击，我们可以将半开连接容量从默认的 256 增加到 1024：

$sysctlnet.ipv4.tcp_max_syn_backlog
net.ipv4.tcp_max_syn_backlog=256
$sysctl-wnet.ipv4.tcp_max_syn_backlog=1024net.ipv4.tcp_max_syn_backlog=1024

另外，每当连接状态为 SYN_RECV 的连接时，如果连接失败，内核会自动重试，默认重试次数为 5 次。您可以通过执行以下命令将其减少到 1 次：

$sysctl-wnet.ipv4.tcp_synack_retries=1
net.ipv4.tcp_synack_retries=1

此外，TCP SYN Cookies 也是一种特殊的防御 SYN Flood 攻击的机制。SYN Cookies 根据连接信息（包括源地址、源端口、目的地址、目的端口等）和加密种子（如系统启动时间）计算哈希值（SHA1）。该哈希值称为 cookie。启用 SYN Cookies 后，无需再保持半开连接状态，同时半开连接的数量也将没有限制。

$sysctl-wnet.ipv4.tcp_syncookies=1
net.ipv4.tcp_syncookies=1

需要注意的是，上面sysctl命令所修改的配置是临时的，重启后将会丢失。您可以通过将它们添加到/etc/sysctl.conf文件中使其持久化。例如：

$cat/etc/sysctl.conf
net.ipv4.tcp_syncookies=1
net.ipv4.tcp_synack_retries=1
net.ipv4.tcp_max_syn_backlog=1024
$sysctl-p

结论

今天，我们谈到了在分布式拒绝服务 (DDoS) 情况下的缓解措施。DDoS 利用大量伪造请求，使目标服务消耗大量资源来处理这些无效的请求，进而无法正常响应正常用户请求。

由于 DDoS 分布的流量大和难以追踪等特点，目前没有办法完全防御 DDoS 带来的问题，因此只能缓解其造成的影响。

审核编辑：汤梓红