好吧，我管理的一台 Ubuntu 服务器今天遭受了 DDoS 攻击。通常这很不愉快，但也不是什么大问题。几次服务器负载过高后，问题就过去了。今天的情况显然不同。说实话，我多年来一直受到服务器攻击的伤害。但今天感觉不一样。请继续阅读。
解决方案是通过重新启用阻止通过调用纯 IP 地址进行访问的ModSecurity规则来解决的。这意味着，如果主机名为，IP 地址为，并且我有一个启用了 & 的虚拟主机。并且已启用阻止通过调用纯 IP 地址进行访问的规则，则访问者在访问 时将获得正确的内容，但如果他们尝试通过 访问网站，则会被 ModSecurity 阻止。问题解决了！curlmygreatsite.com123.456.78.90mygreatsite.comModSecuritycurlmygreatsite.com403: Forbidden123.456.78.90
但在袭击发生时，有三件事是清楚的：
- Apache 进程激增：Apache 进程负载
Munin急剧上升，并且始终是正常情况下的 3 倍。 - 没有记录相应的网络流量：没有通过 Apache 记录的相应流量，也没有反映在 AWStats 中。这种情况持续了几个小时。这涉及服务器上所有虚拟主机的所有日志，包括将连接到裸 IP 地址的默认虚拟主机。
- 服务器负载适中，但未达到典型的攻击级别：虽然整体服务器负载很高，但只有个位数 - 4、5、6、7 等... - 而不是典型的 DDoS，负载可以达到两位数甚至三位数，如 20、30 甚至 120（！！！）。
对我来说，第 3 项是这次攻击中最不寻常的部分。我从未经历过服务器负载基本相当于大流量日的 DDoS，也没有经历过与攻击相关的疯狂服务器负载。
此外，从命令行运行elinks获取 Apacheserver-status表明连接池在重新启动后的几分钟内就会疯狂填满：
elinks http://localhost/server-status?refresh=1
而除了这些，我刚刚注意到Ubuntu 安全补丁今天专门讨论curl问题。这一具体问题引起了我的兴趣：
libcurl 错误地验证了包含文字 IP 地址的通配符 SSL 证书。
问题是：到底发生了什么？我知道重新启用ModSecurity规则可以阻止攻击，但它是否与libcurl问题？如果是这样，我该如何检测或证明这一点？除此之外，如果问题出在libcurl——我假设是来自利用漏洞的武器化客户端——那么这是否意味着有人可以简单地保留被黑客入侵的旧版本curl再次进行 DDoS？并且，任何黑客都可以下载源代码并对其进行修补，那么为什么今天会出现洪水？
我猜是补丁让curl更多人意识到了漏洞，而全球脚本小子的“热情”在漏洞被发现后的几个小时内引发了疯狂的扫描浪潮？但同样，这让我很困惑，因为它是在客户端curl安装上，对吗？我无法想象curl服务器端会成为受害者。