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

# 8月27日 TCRF DDoS攻击事件回顾 – Xkeeper的博客 来源：https://blog.xkeeper.net/the-cutting-room-floor/tcrf-2026-ddos-postmortem/ ……但在那之前，先简单说说这事件可能的导火索。 我们对AI代理的态度已不是什么秘密。我最近为*The Cutting Room Floor (https://tcrf.net/The_Cutting_Room_Floor)* 添加了一个新功能：如果你使用“Claude-code”用户代理访问网站……就会被列入Claude用户封禁名单。之后，即使你*不再*使用Claude尝试访问网站——也许是因为你想查看它收到的“提示注入 (https://tcrf.net/test.html)”页面——也会看到一个特殊的错误页面（https://tcrf.net/?not-claude-just-visiting=1），上面有个像素化的Claude标志，告诉你“滚出去”： "tcrf.net 403 - 访问被拒绝"，页面两侧是低分辨率、放大的Claude AI标志，下方写着“检测到Claude用户！”你好啊，老朋友。 一位Twitter蓝标用户遇到了这个机制，设法绕过了封禁，随后因自己被封禁这件事变得越来越愤怒。他不仅挖出了那些早已不活跃的“提示注入”版本，还编造了一整个故事，声称它清空了一个虚拟机并擦除了操作系统，将这个编造的悲情故事多次发送给我们的主机提供商，然后还在Twitter上煽动了一群人声讨此事。Kotaku (https://kotaku.com/ddos-attack-breaks-beloved-video-game-wiki-after-ai-bro-was-banned-2000729335) 甚至报道了这些荒唐事。值得注意的是，当他们要求双方评论时，我回应了，而另一位……则跑去问Grok如何起诉诽谤。 LLM让你脑子变坏。一次都不行。 我提这段背景，是因为封禁和Twitter崩溃事件发生在攻击开始*之前*。时机上的巧合似乎不止是巧合。 ## DDoS攻击本身 谈到影响TCRF的DDoS攻击，*通常是*通过机器人或爬虫进行的。它们请求数百个页面，试图耗尽服务器生成无人阅读响应的CPU时间。这类攻击可以通过Anubis (https://anubis.techaro.lol/) 等缓解工具来应对，这些工具会阻止机器人请求页面，直到它们花一秒钟做数学题为止。 但这次攻击并非如此。这次的攻击者旨在单纯饱和服务器的网络连接，用大量的垃圾流量将其淹没，以至于任何合法流量都无法通过。情况糟糕到持续了足够长的时间，以至于Linode不得不禁用（null-route）我们服务器的连接——DDoS流量开始影响Linode的其他客户了。*他们的基础设施无法承受发送给我们的海量垃圾流量。* 我们主Linode的网络图表，显示了过去30天的各种流量水平，包括一次巨大的峰值和持续的背景辐射。你还能看到Cloudflare的缓存对我们带宽的影响。不幸的是，像Anubis这样的反机器人代理对此类问题 (https://bsky.app/profile/xeiaso.net/post/3muabt6dwlk2r) 无效；你需要足够大的带宽来承载所有流量。 以下是事件发生的时间线以及我们的应对措施。 ### 攻击前 *※（除非另有说明，本文所有时间均为太平洋时间。）* 我第一次注意到异常是在**8月27日中午12:11**拍摄的这张截图。主要指标是CPU的紫色部分；这是系统在处理大量垃圾流量。它实际上并非*忙碌*工作（绿色和红色部分），只是垃圾数据。 htop的CPU监测图，大部分显示为紫色。所有这些紫色？坏事了。 显示两个短暂峰值的网络图表，一个约1600 Mbps，更高峰值为2051 Mb/s。我以前从没见过以Mbps为单位的图表。 我们正遭受***巨大***的入站流量洪水。服务器除了将所有这些流量丢弃外什么也没做，但流量如此之大，以至于丢弃垃圾成了它*唯一能*做的事。这次攻击持续了大约半小时，但足以在那段时间内使访问网站变得几乎不可能。 回想起来，很可能是Linode的自动DDoS缓解机制临时启动了，而不是攻击者自己停手了。 ### 主攻击开始（8月27日） 另一张hTOP截图，显示紫色条形。我喜欢紫色，只是不是在这里。 在**晚上7:39**，攻击的另一波开始，使网站下线。攻击向端口80发送了海量垃圾流量，即使大部分在到达任何实际资产之前就被过滤掉了（通过*ufw*或*nginx*规则），这个级别的流量也足以使服务器不堪重负。 但不久之后，流量停止了。*所有*网络流量。即使是明确通过我们服务器防火墙允许的已知安全流量，也被丢弃了。 几小时后的网络图表，显示一个比之前小的峰值，最后值为“85 kbps”（远低于约44 mbps的平均值）。 多封电子邮件提醒我，我运行TCRF的Linode服务器，其入站流量通知阈值（10 Mbps）已被超出，平均值分别为74、43、375和14 Mbps（是的，三百七十五兆）。在这次攻击之前，我只收到过这种通知**5次**。**总共。**这次攻击给了我*46次*，其中一些*还是在我将阈值提高到40Mb/s之后*... ### 初步调查与响应 我们花了一些时间尝试排除故障。Linode网络图表显示没有流量；从各种来源尝试连接都不成功，包括我专门在服务器防火墙中白名单的地址。在穷尽所有选项后，我们在晚上8:34联系了Linode客户支持。 在**晚上10:44**，我们收到了Linode的回复： > 您好，感谢您在我们调查期间耐心等待。我们确认，针对您IP地址（tcrf.net）的近期DDoS活动，一个针对入站TCP端口443流量的自动缓解封锁在路由器级别被触发。由于此封锁由我们的自动DDoS防御系统管理，我们无法提供具体的手动移除时间表。但是，一旦DDoS事件平息且攻击流量清除，系统将自动移除封锁并恢复正常的HTTPS流量。我们正在积极监控我们这边的情况，以确保在流量条件稳定后尽快恢复连接。在此期间，如果您有任何其他问题，请随时告知我们。 简而言之：“*流量太大，我们不得不将其关闭，因为它干扰了我们的硬件。当流量消退时，它会自动重新开启。你无能为力。*”不理想，但是，好吧。我们*能做的*确实不多：它就是无法访问了。 ### 第二天（8月28日） 此时，DDoS攻击尚未停止，已超过12小时。我们再次联系Linode，并于**上午8:56**收到如下回复： > 你好，感谢您的跟进，对于延迟和持续中断您的服务，我深表歉意。我们之前提到的自动路由器级缓解措施仍然激活，因为我们的网络系统仍在持续处理针对您IP的持续攻击流量。我们正在积极跟踪我们这边的情况，并会尽快在此回复最新进展。在此期间，如果您有任何进一步的问题或需要我们协助其他事情，请随时联系我们！最好的问候，K 此时，我开始准备第二台服务器，在攻击持续期间托管一个“状态页面”。其唯一目的是提供一个微小的HTML页面（小于3KB）。我们切换了DNS记录，瞧！状态页面上线了。 我们状态页面在8月28日早些时候的截图，提到访问我们的Bluesky账户 @tcrf.net，并链接到我们的Discord和Patreon / Ko-fi。 任务完成，我起身决定做点其他有建设性的事情，比如吃早餐、洗个澡，甚至跑个腿。 *兴奋过度的主持人声音*：你绝对不会相信接下来发生了什么！ 第二台Linode的网络图表，再次出现一个巨大的1150mbps峰值。来自我们的“备用”服务器。 是的。临时站点上线了？最好也把它打下来。他们确实这么做了；备用服务器宕机了。 如果这还不够，我们的“朋友”还在攻击我运行的其他辅助服务，包括这个博客本身： Uptime Kuma显示右侧有一堆停机通知。这些网站显示为“在线”，因为历史延迟很短（30分钟），并且它们此时已经恢复了。虽然这发生在事件发生几小时后，但你可以看到它产生的大量通知堆。 这种情况下，我无能为力。其中大多数是简单的共享主机，甚至不是VPS，在那种情况下，即使我想用Anubis之类的工具也不行；这完全不在我能控制的范围内。幸运的是，对其他网站的攻击*大多*在一段时间后停止了。 当这一切都在进行时，我也查看了Linode是否有任何可能有所帮助的服务。他们提供“云防火墙”，所以我（连同询问总体情况）询问了此事。在**晚上8:36**，我收到了回复（重点已添加）： > 2026-08-28 你好，我完全理解您希望尽快恢复在线的迫切心情。**不幸的是，在这个特定情况下，云防火墙也无济于事**，因为封锁发生在更上游，在流量到达您Linode自己的防火墙规则之前。**这里最可靠的路径是让自动缓解措施自行运行完毕**，它专门设计为在攻击流量稳定后解除封锁，这是我们推荐您等待的解决方案。我们正在积极监控我们这边的情况，一旦我们看到情况稳定就会通知您。问候，N 我们正在密切关注此情况，以尽快让您恢复正常。在此期间，请随时提出任何问题，我们在此提供帮助！ 所以，我*仍然*几乎无事可做，只能等待，而现在他们已经击垮了主服务器*和*备用服务器。 好吧，至少情况不会更糟了。 Gmail收件箱截图：“请求评论：Kotaku。- 嗨 X！希望你一切都好。...”这下可好了。 （咬牙切齿）*好吧，至少情况不会更糟了。*最终，对方未能回应（再次，跑去问Grok法律建议了），你可以阅读上面的整个故事。 除此之外……我们还收到了发送给Linode / Akamai的虚假滥用报告，没有细节且包含捏造的URL，迫使我们提交同样毫无意义的“此URL不存在，也从未存在过”的回应。（Linode的一次回复中包含一则说明，指出他们有义务处理这些报告，并感谢我总是及时响应。） ### 第三天（8月29日） 今天开始似乎是个好消息。Linode支持在**上午7:07**给我留言： > 你好，我刚才检查了一下，在我们的系统中没有看到您IPv4地址有任何空路由（null routes），所以看来攻击已经停止，服务已恢复正常运行。请问您现在这边情况如何？祝好，A 此时距离攻击开始已经大约一天半了，听起来情况终于缓和了。我们开始检查自己这边的情况，结果……什么也没有。正常运行时间跟踪器仍报告网站宕机；虽然我的SSH连接是通的，但两台服务器的流量日志仍然为空。在**上午7:50**，我们回复了我们的发现，**上午9:09** Linode支持回复： > 你好，我查看了您的两台Linode，看看是什么阻碍了流量。我们确认自动缓解封锁已从两个IP地址移除。您原始IP（xx.xx.xx.xx）上的封锁于昨天凌晨4:43 EDT解除，您备用IP（yy.yy.yy.yy）上的封锁于今天上午11:08 EDT解除。我已重置我们这边的网络，以确保路由方面一切正常。[...] 他们还提供了一些建议（他们提供*企业级*防火墙，第三方代理解决方案可能是最佳选择）。但是，我们应该可以恢复正常了吧？ 支持和我来回沟通，排除网络故障——引导进入救援模式，进行额外的网络测试——但在几个不同的步骤之后...**2026-08-29 下午3:08**： > 你好，感谢您向我们确认情况。我想确认一下，我们的工程师现在正在与我们积极调查此事。他们发现IP xx.xx.xx.xx 目前正被我们的DDoS保护过滤，我可以确认，当前该IP的连接问题是那个封锁导致的。他们目前正在努力移除该封锁，如果他们判定流量已恢复到安全水平的话。我们将在此事上随时向您更新，并在获得新信息时分享。我们已向相关人员强调了此情况的紧迫性，因此我们将尽快解决此问题。感谢您在此期间的持续耐心。在此期间，如有任何问题，请随时与我们联系。问候，C 从早上7点到下午3点，我都坐在我的电脑前，在运行各种故障排除/诊断步骤和等待支持回复之间徘徊……嗯，所有这些都徒劳无功。封锁从未解除。攻击并未结束。在我要求他们澄清不一致之处后，支持在下午3**:49**确认了这一点（重点已添加）： > 你好，我为造成的困惑道歉。您引用我的同事V的消息是基于当时我们支持团队可获取的信息和监控，这些信息表明封锁已解除。由于在支持团队观察到封锁移除的消息后连接并未恢复，我们随后请求了内部团队的进一步调查。**与这些团队进行的进一步调查现已确认，封锁在整个期间一直存在，并未真正解除。** **他们还现已确认，针对您Linode IP的DDoS攻击流量自其初始爆发（约在您提交此工单前一小时，8月27日东部时间晚上10:35左右）以来，尚未恢复到安全水平。** 由于目前流量仍然很大，DDoS缓解封锁将保持到位，并在流量恢复到可接受水平后自动移除。 此时，攻击已持续**1天20小时**：8/27 7:35 PM 至 8/29 3:49 PM。 我起身休息了一会儿，考虑下一步行动。很明显等待是行不通的。无论是谁干的，钱都比脑子多。因为这是纯粹的垃圾流量，像Anubis这样的工具不会有帮助。我们需要一个能够处理这种情况的第3层服务 (https://www.fastly.com/learning/security/what-is-a-ddos-attack#what-is-a-layer-/-ddos-attack)。 众所周知，我不是Cloudflare (https://blog.xkeeper.net/the-cutting-room-floor/self-hosting-and-junk-traffic/) 的忠实粉丝。我决定尝试他们的竞争对手之一：Fastly (https://fastly.com/)。 #### 在Fastly赛道上的生活 Fastly在页眉处有一个“遭受攻击 (https://web.archive.org/web/20260826091354/https://www.fastly.com/under-attack)”链接，建议注册账户 (https://www.fastly.com/signup) 并通过“Fastly的DDoS缓解”路由您的流量。所以我注册了，将其设置在我们的备用服务器前面。虽然Linode不允许我直接为被攻击的机器分配*新*的IPv4地址，但它*确实*允许我*交换*IP……所以我创建了一个新的Nanode™，交换了IP，现在备用服务器有了一个新的IP地址。就这么简单。 我对Fastly的初步印象还不错。我们在**8月30日中午12:00左右**让其上线。我设置了每月10美元的支出限额，配置好一切，不久备用服务器就...