8 月 27 日 TCRF DDoS 攻击事后分析

……但首先，快速题外话，谈谈这可能是由什么引起的。我们对人工智能代理的立场并不是什么秘密。我最近在 The Cutting Room Floor 中添加了一项新功能：如果您使用“Claude 代码”用户代理访问该网站……它会将您添加到 Claude 用户禁止列表中。然后，如果你稍后尝试在没有克劳德的情况下访问该网站——也许是因为你想调查它收到的“提示注入”页面——你会看到一个特殊的错误页面，告诉你退出，上面有像素化的克劳德标志：你好，老朋友，一个 Twitter bluecheck 遇到了这个，逃避了禁令，然后对他被禁止的事实越来越生气。他不仅挖出了长期不活跃的“即时注入”版本，而且还编造了一个完整的故事，讲述它如何将虚拟机清零并擦除操作系统，并将这个编造的悲惨故事多次发送给我们的主机，然后让推特暴徒们仔细研究它。 Kotaku 甚至还报道了一些这样的废话。值得注意的是，当他们要求我们俩发表评论时，我做出了回应，而另一个人……向 Grok 寻求有关起诉诽谤的法律建议。法学硕士会腐蚀你的大脑。一次也没有。我之所以提到这个背景故事，是因为禁令和 Twitter 崩溃就发生在攻击开始之前。这个时机似乎不仅仅是巧合。 DDoS 攻击本身 在讨论影响 TCRF 的 DDoS 时，它们通常是通过机器人或抓取工具完成的。他们请求数百个页面，试图耗尽服务器的 CPU 时间，生成没人会读的响应。可以使用 Anubis 等缓解工具来应对此类攻击，该工具会阻止机器人请求页面，直到它们花一秒钟进行数学计算。这次攻击的情况并非如此。犯罪者的目的是简单地使服务器的网络连接饱和，用垃圾流量压垮服务器，达到任何合法网络都无法通过的程度。这已经够糟糕了，而且已经足够严重了，Linode 不得不对我们服务器的连接进行空路由（禁用）——DDoS 流量开始影响 Linode 的其他客户。他们的基础设施无法处理发送给我们的大量垃圾流量。您还可以看到 Cloudflare 的缓存对我们的带宽的影响。不幸的是，像 Anubis 这样的反机器人代理并不能有效解决此类问题；你需要一个足够大的管道来处理所有的流量。以下是所发生事件以及我们对此采取的措施的时间表。攻击前※（除非另有说明，本文中的所有时间均为太平洋时间。）我注意到的第一点可以追溯到这张截图，拍摄于 8 月 27 日中午 12:11。主要指标是CPU的紫色段；这是来自处理大量涌入的垃圾流量的系统。这实际上并不是繁忙的工作（绿色和红色部分），它只是垃圾。都是紫色的吗？坏的。我以前从未见过这张以 Mbps 为单位的图表。我们收到了大量的传入流量。服务器除了把所有这些都扔进垃圾箱之外没有做任何事情，但它能做的就这么多了。这次攻击持续了大约半个小时，但足以使在此期间几乎无法访问该网站。回想起来，Linode 的自动 DDoS 缓解措施可能是暂时启动的，而不是攻击者自己退出的。主要攻击开始（8 月 27 日） 我喜欢紫色，只是不在这里 晚上 7:39，另一波攻击开始，使一切离线。该攻击向端口 80 发送大量垃圾，即使大部分垃圾在攻击任何实际资产之前被过滤掉（通过 ufw 或 nginx 规则），该级别的流量也足以压垮服务器。但没过多久，交通就停止了。所有网络流量。即使是明确允许通过我们服务器防火墙的已知安全流量也会被丢弃。在这次攻击之前，我已经收到过 5 次这样的通知。曾经。这次攻击给了我 46 ，其中一些是在我将阈值提高到 40Mb/s 之后...... 初步调查和响应 我们花了一些时间尝试排除故障。 Linode网络图显示没有流量；尝试从各种来源进行连接均无效，包括我在服务器防火墙中专门列入白名单的来源。在用尽所有选项后，晚上 8:34，我们联系了 Linode 客户支持。晚上10点44分，我们收到了Linode的回复：您好，感谢您在我们调查期间的耐心等待。我们确认，针对最近针对您的 IP (tcrf.net) 的 DDoS 活动，在路由器级别触发了针对传入 TCP 端口 443 流量的自动缓解块。由于该块由我们的自动化 DDoS 防御系统管理，因此我们没有手动删除该块的具体预计时间。但一旦DDoS事件平息，攻击流量被清除，系统会自动解除封锁，恢复正常的HTTPS流量。我们正在积极监控我们这边的情况，以确保在交通状况稳定后立即恢复连接。请乐