这不可持续

# 这不可持续 来源: https://www.netmeister.org/blog/defense-ddos.html 2026年10月27日 这一周可真热闹，对吧？大家击个掌——十月是"网络安全意识月"，我觉得咱们都干得相当漂亮。如果《纽约时报》(https://www.nytimes.com/2026/10/22/world/php-vulnerability-websites-cybersecurity-ai.html)和NPR (https://www.npr.org/2026/10/23/g-s1-149503/hacking-php-flaws)都在报道我同时扑救的至少四五场火灾之一 (https://istheinternetonfire.com/)，那我觉得咱们可以说：是的，人们对网络安全已经有意识了。任务完成，那……能不能稍微降降温？ 当前的状况不可持续：0-day四处飞，提前通知和漏洞封禁流程为了营销目的被随意打破 (https://www.akamai.com/blog/security-research/tlp-is-not-a-suggestion)，AI公司先比赛谁犯的罪最多，然后再假装以DDoS开源社区的形式向你兜售保护服务。*"你这项目不错啊。要是有人往里面丢个0-day就可惜了。"* ¹ (https://www.netmeister.org/blog/defense-ddos.html#1) 各公司的人员配置根本扛不住这个，不管业界想灌输什么观念，你没法靠AI解决这个问题。漏洞发现的方式已经根本性地改变了，披露流程实际上已经彻底失效，补丁管理多年来也一直是一场注定失败的战役。严重漏洞被发现和披露的速度，已经远远超过了防御方能跟上的节奏。 这是因为，要准确评估某个漏洞在你自身环境中的可行性，仍然需要大量资源；要发现与特定攻击向量相关的攻击面需要时间，部署修复方案更需要时间。正如我之前说过的 (https://www.netmeister.org/blog/everybodys-lost-their-minds.html#sisyphus)，修复的开发根本不是瓶颈。让我用过去几天的例子来说明： ### "PwnEscape (https://pwn.ai/blog/pwnescape)"（CVE-2026-99999） 最初被披露为"KVM逃逸"漏洞，这个漏洞*同样*适用于其他虚拟化技术以及容器，虽然这方面的讨论并没有得到太多关注。你现在需要评估你的整个系统集群中可能部署了哪些缓解措施，然后确定能否用从上游获取的自定义补丁对内核进行热补丁 (https://www.kernel.org/doc/html/latest/livepatch/livepatch.html)，或者你是否要等上游操作系统供应商发布新内核² (https://www.netmeister.org/blog/defense-ddos.html#2)，然后你只需要重启几千台系统就行了。 AI在这里能帮到你什么？也许你花几千美元的token费用，用最先进的网络安全模型来开发自己的利用代码，但到最后，这并不能告诉你任何你原本不知道的事情，你的防御态势和手头的任务没有任何变化。 ### eMudhra 被入侵事件 (https://emudhra.we-have-a-problem.com/) 这个案例很有意思，不是吗？浏览器确实很快就被修补了，但猜怎么着，你的环境中还有其他一些东西可能使用TLS。比如……*所有的东西*。所以又是老问题，拥有修复方案不是瓶颈。等待上游软件包发布更新只会拖慢你——前提是你得先知道你需要拉取这个更新。 哦，你有详细的软件包清单，或者我该说，你有SBOM？那可真不错。请给我指一下，它列出了哪些各处内嵌的或硬编码的CA信任链 (https://github.com/NixOS/nixpkgs/issues/576475)。是吧，我就知道。³ (https://www.netmeister.org/blog/defense-ddos.html#3) （至少这个事件不是AI生成、AI检测或AI触发的。只是一个纯粹经典的、某个人类发出一声"嗯？" (https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c2)式的发现。我们还会有这样的发现，多少让人欣慰一点。） ### "php2shell (https://www.php.net/archive/2026.php#2026-10-21-5)"（CVE-2026-109618，CVE-2026-109619） 那个据称影响"超过70%网站"的PHP漏洞（一个被广泛引用但从未注明来源的统计数据），是以封禁期（embargo）方式向几个组织披露的。如果你是这个核心圈层的一员，那这应该在一定程度上缓解了你的恐慌模式，至少为你争取到了*一些*时间来为客户部署防护措施，去做那些枯燥的工作——梳理你的资产清单，再次确认攻击面、受影响系统、可能的本地缓解措施等等等等。老一套。 除非封禁被打破了。那你就得再来一次手忙脚乱。你还需要紧跟那些飞速发布（而且越来越被AI废话充斥的）危言耸听的博文，这些博文都是由网络安全厂商的市场团队驱动的，他们争先恐后地想比别人第一个检测到⁴ (https://www.netmeister.org/blog/defense-ddos.html#4)、第一个利用、第一个吹嘘，所有这一切都加剧了你的注意力分散。 当然，你*仍然*需要做实际的工作——核实网上流传的各种利用代码的准确性，其中一些是由真正懂行的人编写的，但更多更多是由那些对该漏洞一知半解的人胡乱拼凑出来的⁵ (https://www.netmeister.org/blog/defense-ddos.html#5)。（下面会详谈。） ### brotli 远程代码执行漏洞 (https://github.com/advisories/GHSA-9v8h-qqgm-4m35)（CVE-2026-111497） 然后，等到了周四，人们开始看到一则NodeJS安全公告 (https://nodejs.org/en/blog/vulnerability/october-2026-security-releases)，其中作为第三个"高"严重性漏洞列出的是"Node.js Brotli 解码器"中的一个问题。好吧，枚举攻击面，检查软件清单，开始部署更新的软件包……老一套。 当然，一旦你仔细看了看，你就会逐渐意识到 (https://www.openwall.com/lists/oss-security/2026/10/23/25)这个问题远不止影响Node.js⁶ (https://www.netmeister.org/blog/defense-ddos.html#6)。所以又一次，拥有上游修复方案 (https://github.com/advisories/GHSA-9v8h-qqgm-4m35)绝对不是你的瓶颈，因为你仍然需要先在*所有*你的技术栈中找出那一堆又一堆的各种 brotli 变体。 当然，就在那个时候，OpenAI开始发推 (https://twitterviewer.net/OpenAI/status/2113766354386084338)"是我们！是我们发现的！"，尽管这个问题早在二月就已经修复了 (https://github.com/google/brotli/commit/0ed4268a4401abcb4472096340477cf4af7d1a2b)，而Mozilla早在四月就注意到了其严重安全影响 (https://bugzilla.mozilla.org/show_bug.cgi?id=2029458)。看来无论是漏洞、入侵还是网络犯罪，AI公司都来者不拒、照单认领。 ### （更多）凛冬将至 所有这些都发生在一周之内，甚至还不能算上前几周那些Linux本地提权漏洞⁷ (https://www.netmeister.org/blog/defense-ddos.html#7)。而且毫无疑问还会有更多这样的披露——多得多。 AI公司有持续发起这场攻势的激励。对于大规模披露发现的行为，最善意的解读是把它当作"verschlimmbessern (https://www.studygermanonline.com/blog/the-verschlimmbessern-in-german)"（越修越坏）的经典案例；而不那么善意的解读则认为，对于一家公司来说，先制造疾病再卖给你治疗方案（而且永远不是治愈方案）是有利可图的。他们得到了一个新玩具，这就是一把锤子，而他们打算抡它抡到底。 数以百万计的美元被花在使用所谓"前沿AI模型"识别漏洞上，我们知道敌对势力正在将Linux内核提交信息等输入他们的模型，实时分析其中的可利用漏洞。如今，同一个漏洞经常被多方独立发现，所以你已经不得不假设，披露封禁期最多只能遏制*机会主义对手的*大规模利用行为。 与此同时，我观察到网络安全防御端有一个令人担忧的趋势，这与整个行业的技能退化趋势如出一辙：AI生成的漏洞报告往往冗长到人类读者根本无法轻松消化。它们用细节淹没你，用不必要的信息压垮你的注意力。由于防御者并不完全理解所描述的漏洞，他们往往相信那些通常被夸大的严重性判断，然后把完整的报告扔给*他们自己的*AI来复现或生成概念验证。 在消耗了几千个token之后，你最终得到一个由"肉身代理"递过来的二进制文件，据说能触发该漏洞，但没有人真正理解它为什么能工作。而实际上，它多半*根本不能*——因为你的环境不同，你的AI缺少那个"肉身代理"没有（或不知道）提供的上下文，因为你的代码库与上游版本不同，或者天知道还有什么其他原因。当你要求明确的运行说明、需要满足的前置条件、以及它的工作原理——你知道，就是那种进攻方工程师以前能写出来的东西——你得到的，你猜对了，是AI吐出来的一篇7000字的`README.md`。⁸ (https://www.netmeister.org/blog/defense-ddos.html#8) ### 事故迷雾 一次扑灭一场火就够累人的了。上面的每一个例子，放在不久之前都够构成一起一年一次的重大事件。同时发生多起这样的事件，正在耗尽你的应急响应人员、工程师、公关和法务团队。 （而且每次几乎*总是*同一批人在驱动这些事件。我没有见过哪个组织人员配置充足，而不依赖同一拨"捉鬼敢死队"——那些掌握着必要部落知识的英雄和公司元老，来弥补你软件资产清单、攻击面枚举和文档中的空白，因为不然你还能找谁？） 在这些事件之间不断切换上下文，意味着你无法专注于任何一件事，这让你更容易漏掉重要信息、被耸人听闻的标题误导、屈服于压力、匆忙发布你并不理解的修复方案——去修复那些在你的环境中可能根本不适用的漏洞。而这反过来又让更多人更容易被机器人的快速而自信的回答所诱惑，领域半吊子开始把他们prompt的输出结果直接粘贴到应急响应频道里。 这不可持续。 ### 如何改善 哦，哈哈，抱歉，我误导了你。当你在那儿滔滔不绝地发牢骚时，你应该以积极的调子结尾，提供一个解决方案⁹ (https://www.netmeister.org/blog/defense-ddos.html#9)，提出建议说我们该如何卷起袖子一起解决问题。唉，我一点头绪也没有。 啊，但这一切肯定只是*暂时*的，对吧？AI会找到所有的漏洞，我们熬过这段披露混乱的黑暗冬天，然后迎来一个所有软件漏洞都已被发现和修复的世界。 如果你能相信这个说法，我羡慕你。我不认为这会发生。如果你要告诉我软件开发者就应该用AI来生成补丁，请记住超过50%的时候 (https://1password.com/blog/why-ai-generated-patches-still-require-human-review)，AI要么没有修复问题、要么引入了新漏洞、要么改变了应用程序的行为。在不断*生产越来越多代码* (https://mstdn.social/@jschauma/117439759243067966)的同时，降低我们自身对复杂软件的理解，这是*制造更多*漏洞的配方，而不是更少。而且，冒着像个复读机的风险再说一遍——*修复漏洞根本不是瓶颈*。 即使当前的状况是暂时的——能暂时多久？一年？两年？在此期间我们该怎么办？在这个经济环境下，雇佣更多信息安全人员不太可能发生 (https://www.apollo.com/wealth/insights-news/insights/daily-spark/no-signs-of-ai-payoff-outside-the-tech-sector)。投资全面改造你的基础设施，让你至少能够自动拉取和部署更新、重启整个集群、并且*安全*地完成所有这些操作，同样不太可能：企业几十年来一直*不做*这些也安然无恙，谁想当那个把资金从"更快更多地写代码"上转移走的VP或高管？更不用说这样的项目本身也要花好几年。 最后一个选项就是简单地接受现状。将会有更多漏洞，包括远程代码执行漏洞，而你将无法跟上它们的节奏。你唯一的选择是限制爆炸半径。假设已被入侵，检测利用行为，限制暴露、横向移动、权限提升等等。如果这听起来像是陈词滥调，嗯，没错，这就是理智的信息安全从业者几十年来一直在要求资金支持的事情。（在"零信任"变成一个空洞的营销术语之前，我们过去就这么叫它。）但这些资金却去了下一个又唱又跳的、基于AI的漏洞管理SIEM仪表板大屏（majing），而它只会漏掉你40%的基础设施和资产。万岁！ 嗯，晚安，祝你好运，确实如此。 2026年10月27日 --- 脚注： \[1\] 这套把戏对企业玩起来效果更好：*"你这供应链不错啊。要是有人往你大部分依赖项里丢几百个0-day就可惜了。最好订阅我们的服务以获取预通知。。"*↩ (https://www.netmeister.org/blog/defense-ddos.html#b1) \[2\] 截至2026年10月27日，即初始披露12天后，以Canonical为例，仍然没有发布修复后的内核 (https://ubuntu.com/security/CVE-2026-99999)，他们认为该问题严重性为"中等"。↩ (https://www.netmeister.org/blog/defense-ddos.html#b2) \[3\] 在某些情况下你最好的选择是直接使用相关语言/框架运行一个简单的fetch脚本 (https://github.com/jschauma/emudhra)。但这同样无法规模化。祝你好运吧。↩ \[4\] 检测到利用尝试是一个至关重要的信号，有助于你评估响应的紧迫性，并可能影响披露时间线。在没有足够把握的情况下就宣布你已观察到针对某漏洞的利用 (https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/)，这对所有响应者都是有害的 (https://twitterviewer.net/naderman/status/2114146087699087548)。↩ (https://www.netmeister.org/blog/defense-ddos.html#b4) \[5\] 别跟我提在任何稍微复杂一点的程序中使用`setjmp(3)`/`longjmp(3)`做错误处理。这确实*巧妙*，但写出*巧妙*的代码很少等于写出*安全*的代码。我不认为除了最简单的情况外，你能安全地使用这个机制，而且这里潜藏着额外漏洞我一点也不会惊讶。而现在"索伦之眼"已经盯上了这个代码库……↩ (https://www.netmeister.org/blog/defense-ddos.html#b5) \[6\] 顺便问一下，有谁知道为什么Google Docs坚持要把`node.js`做成超链接？`.js`不是顶级域名。它真的蠢到只按照`\[a-z0-9.\-\]+\\\.\[a-z\]\{2\}`这样的正则来匹配吗？哦，它还真就是这么蠢。太棒了。↩ (https://www.netmeister.org/blog/defense-ddos.html#b6) \[7\] 在我们先后经历了"DirtyFrag (https://www.dirtyfrag.tech/)"、"GhostLock (https://nebusec.ai/research/ionstack-part-2/)"、"FragGap (https://securityonline.info/fraggap-linux-kernel-cve-2026-53362/)"、"ZapScape (https://github.com/V4bel/Zapscape)"、"Januscape (https://github.com/V4bel/Januscape)"之后，像"Linux kernel LPEs: ZcopyReaper (CVE-2026-43502)*以及还有20多个* (https://www.openwall.com/lists/oss-security/2026/09/08/1)"这样的披露基本上就是家常便饭了，我还忘了还有哪些……