好的，我pipe理的Ubuntu服务器今天成为DDoS攻击的受害者。 通常这是不愉快的，但没有那么大的交易。 几个高服务器负载时刻，然后通过。 今天显然不同。 为了logging，我有多年的服务器攻击疤痕。 但今天感觉不一样。 阅读。
该解决scheme通过重新启用ModSecurity规则来解决，该规则防止通过调用纯IP地址进行curl访问。 这意味着如果主机名是mygreatsite.com ，IP地址是123.456.78.90并且我为mygreatsite.com启用了虚拟主机。 而且ModSecurity是通过调用纯IP地址阻止curl访问的规则来激活的，那么当访问者访问mygreatsite.com ，访问者将获得正确的内容，但是如果他们尝试访问，则被ModSecurity阻止403: Forbidden该网站通过123.456.78.90 。 大问题解决了！
但是在袭击发生的时候，有三件事情是清楚的：
Munin反映的Apache处理负载高于平常水平，持续高出3倍。 对我而言，第3项是这次攻击中最不寻常的部分。 我还没有经历过一个DDoS的服务器负载基本相当于一个繁忙的交通日，而不是一个疯狂的服务器负载连接到攻击。
另外，运行elinks获取Apache server-status显示连接池在重新启动的几分钟内就像疯了一样充满：
elinks http://localhost/server-status?refresh=1
而过去的任何一件事 ，我只是注意到一个Ubuntu安全补丁今天专门为curl问题。 这个具体的问题引起了我的兴趣：
libcurl不正确地validation包含文字IP地址的通配符SSL证书。
所以这里是一个问题：发生了什么？ 我知道重新启用一个ModSecurity规则阻止了攻击，但它可以以任何方式连接到libcurl问题 ？ 如果是这样，我该如何检测或certificate？ 而过去，如果问题出在libcurl – 我假设这个问题是来自使用这个缺陷的武器化客户端 – 那么这是否意味着有人可以简单地把一个黑客老旧的版本curl到DDoS中去呢？ 而且写下来，任何黑客都可以下载源代码并修补它，以便今天为什么洪灾呢？
我的猜测是， curl的补丁让更多人意识到全球脚本小子的缺陷和“热情”，在发现漏洞的几个小时内就带来了大量的扫描。 但是，这又让我困惑，因为它在客户端curl安装，正确？ 我无法想象curl在服务器端将是这个受害者。