Cloudflare展示如何防御前沿网络攻击模型
Cloudflare AI··作者 Dan Jones
关键信息
Cloudflare 表示，像 Mythos 这样的前沿模型可以压缩漏洞发现、利用链构建和概念验证生成的时间，从而同时提高攻击速度和攻击规模。公司还指出，AI 辅助修补可能修好一个漏洞却意外破坏依赖代码，因此验证和监控仍然至关重要。
资讯摘要
Cloudflare 表示，在其早前关于 Project Glasswing 的文章中，读者反响最强烈的并不是模型本身有多强，而是“漏洞周边的架构比补丁速度更重要”这一观点。此后，Cloudflare 收到了许多来自 CISO 和安全团队的提问，例如他们自己的架构该是什么样、应该监控什么、从哪里开始，以及 Cloudflare 能提供什么帮助。为了回应这些问题，这篇后续文章把 Cloudflare 自己的安全栈作为“customer zero”案例，也就是先用自家产品保护自己的代码、员工和面向客户的应用。文章强调，这些分层能力对客户同样可用，但其中的原则也可以迁移到其他架构环境中。Cloudflare 解释说，像 Mythos 这样的前沿网络攻击模型并不会改变入侵的基本阶段，但会显著改变攻击者的速度和规模。
原本在漏洞发现、利用链构建和概念验证生成上耗费大量时间的工作，现在可以更快、更大规模地完成，而且更不加选择。Cloudflare 还指出，AI 虽然让开发团队更快发版，但安全团队的工作并不会以同样速度缩短，因为防守方必须在保证代码正确性的前提下关闭所有入口。公司提到，自己曾让 AI 编码助手为内部漏洞自动写补丁，结果发现有些补丁虽然修复了原始问题，却悄悄破坏了依赖它的代码。展望未来，Cloudflare 认为最值得关注的威胁包括发现速度、漏洞利用的规模与适应性，以及模型在大量公开代码和开源依赖中搜索问题的能力。文章随后开始展示一套用于应对这些风险的架构，重点放在监控、分层防护，以及尽可能缩短攻击者把新发现的弱点变成可用入侵路径的时间窗口上。
资讯正文
几周前，我们写过 Project Glasswing，以及当我们把网络前沿模型指向自己的代码时所观察到的情况。自那以后，我们发现，这篇文章中最能引发共鸣的部分是这样一个观点：围绕漏洞的架构，比补丁的速度更重要。
在此后我们与 CISO 和安全团队的交流中，大家提出的问题都很一致：我们的架构到底长什么样，我们应该监控什么，从哪里开始，以及 Cloudflare 能如何提供帮助？
在进入细节之前先说明一点：下面的架构几乎完全建立在 Cloudflare 自己的产品之上，因为 Cloudflare 安全是我们所构建安全产品的 customer zero。Cloudflare 的技术栈已经位于我们的代码、员工以及面向客户的应用程序之前。如果你是 Cloudflare 客户，下面的每一层今天都可以直接使用。如果不是，相关原则仍然适用于你已经构建的任何技术栈。
网络前沿模型究竟改变了什么
在上一篇文章中，我们展示了像 Mythos 这样的网络前沿模型如何改变攻击者的时间线。它可以发现漏洞、推理利用链，并比更早期的模型更快地生成可运行的证明。虽然像 Mythos 这样的模型并不会改变入侵的形态——侦察、初始访问、横向移动、持久化和数据外传仍然都必须发生——但差异在于速度和规模。把它指向开放网络时，模型能快速发现并利用唾手可得的薄弱点。面对加固过的目标，它仍然必须探测、适应，而且往往比谨慎的人类操作者产生更多噪声。
过去，发现、构建利用链以及生成概念验证，是形成一次可用攻击的门槛性约束。前沿模型把这三件事都压缩到了极短的时间内。过去慢而细致的工作，如今变得又快又不加选择。
虽然 AI 正在加速 Cloudflare 以及许多其他公司的开发团队发布代码的速度，但安全团队的工作并没有以同样的方式被压缩。攻击者只需要一个突破口就能进入，而安全团队则需要找出并关闭所有突破口。编写修复、回归测试，并在不破坏其周边代码的情况下发布修复，这些都有 AI 无法消除的约束。我们在让一个 AI 编码助手根据我们自己的漏洞自行编写补丁时，已经吃过这个苦头，正如我们在上一篇文章末尾所描述的那样。其中一些补丁修复了原始漏洞，却悄悄破坏了代码所依赖的其他东西。
随着这些模型变得越来越成熟、能力越来越强，从威胁角度看，我们的主要关注点归结为三件事。每一项都会影响我们在本篇文章后面所介绍的架构。
第一项是发现速度。
前沿模型让搜索大量公开代码变得更容易，其中包括许多公司依赖的开源库。但这并不意味着库中的每一个漏洞都可被利用，也不意味着库漏洞就是大多数漏洞所在。漏洞是否可利用，仍取决于代码的使用方式、攻击者可控输入是否能够触达脆弱路径，以及围绕它的防护措施。不过，被广泛使用的开源库和框架为攻击者提供了一个可在大规模范围内研究的共享攻击面。当那里确实存在一个真实、可达的漏洞时，模型可以帮助发现它，推理可能的利用路径，并比维护者和防御者审查每一种下游使用方式更快地生成概念验证变体。最让我们担心的是，攻击者发现漏洞与防御者得知漏洞存在之间的时间差。如果你没有把这些模型用于自己的代码，最好假定别人会这么做。
第二个是
利用
的数量和适应能力。
模型可以生成某个利用手法的成千上万种变体，并以同样的规模进行侦察。如此庞大的数量会让攻击者占据优势，但未必能突破基于特征的检测。那些迭代中的许多变体仍会拥有相同的底层特征，因此能够拦住第一个的规则也会拦住后面的所有变体。适应能力才是它们绕过基于特征检测的关键。让模型给你展示 SQL 注入，它会返回一个教科书式的例子。告诉它前面有 WAF 拦着，它就会开始探测，学习什么会被拦截，并不断改写载荷，直到能够从阻挡它的规则中溜过去。
第三个是
当漏洞不可避免地被利用时所造成的影响。
没有哪种架构能够做到滴水不漏。漏洞被利用之后，我们会问自己的问题是：在别的东西阻止攻击者之前，凭一个身份、一路径或一组凭据，他们能到达哪里？如果答案是“任何他们想去的地方”，那么问题从来就不是漏洞本身，而是漏洞周围的架构。
Cloudflare 的超能力：可见性
我们看到大约全球五分之一的网络流量，而这些流量会实时告诉我们，哪些载荷正在变异，哪些模式正在被拾取，以及攻击者工具下一步正向哪里移动。有两个团队把这种可见性转化为防御。
首先是
Cloudforce One
，我们的威胁情报、研究和运营团队，隶属于 Cloudflare 安全组织。他们把我们在整个网络中看到的内容转化为可供安全栈其他部分采取行动的洞察：已追踪的对手、新兴攻击活动，以及入侵指标（IOC）。这项工作的难点从来都不是判断什么是恶意的——而是缓解的延迟。对一种新威胁的认知，通常必须先从威胁报告传到情报源，再进入企业防御，之后才能真正用于拦截。攻击者已经学会了比这更快地行动。我们的网络缩小了这一差距：Cloudflare 客户现在可以直接在 WAF 中使用 Cloudforce One 威胁情报，从而阻止高风险流量。
其次，是负责实际检测的 WAF 引擎团队：这包括部署在我们自有资产前方、并向每一位 Cloudflare 客户开放的托管规则集，WAF Attack Score 背后的机器学习，以及那些有时能让我们在 CVE 公开披露之前就推出规则的关系网络。这个团队遍布全球、行动迅速，在攻击概念验证（proof-of-concept）被知晓后的数小时内就会发布规则。一旦检测部署完成，它会在 30 秒内覆盖我们的整个网络，以及所有 Cloudflare 客户。
React2Shell 就是最近的一个例子：一条托管 WAF 规则在官方公告发布前数小时，就已经在保护我们自己的资产，以及 Cloudflare 上的其他所有人。
评分层、我们部署在应用前方的防御，以及对漏洞的隔离，都是建立在这两个团队所看到的信息之上的。
以评分取代特征签名
基于特征签名的防御，是为那种新型利用手段稀少、且变种往往需要数周时间才能出现的世界而构建的。Cloudflare 传统上从新鲜的概念验证到规则上线部署的 SLA 是 12 小时。但随着前沿模型的出现，这已经不够了。检测必须在 CVE 被发现之前就已就位。这就是为什么我们要在传统的基于特征签名的 WAF 前面叠加基于 ML 的检测。
该模型使用大量历史攻击流量进行训练，能够在新型漏洞变种尚未公开之前就将其捕捉到。一个新颖的 SQL injection 或远程代码执行链，几乎总是对模型此前见过的攻击形态进行重新排列，即便具体利用方式是全新的。我们会对每一条请求运行该模型，并依据请求与这些底层形态的相似程度，而不是依据已知恶意签名列表，给出 1 到 99 之间的 WAF Attack Score。分数越低，我们对该请求的处理就越激进。这个分数决定我们是否放行请求。我们也在 AI Security for Apps 中对 AI 提示词采用类似的评分方法：不是把每条提示词与已知恶意提示词列表逐一比对，而是评估它与真实攻击的相似程度。
漏洞周围的架构
只有当这些能力被堆叠在应用前方时，它们才真正有意义，而我们纵深防御方法中的第一层就是 WAF。任何匹配已知恶意模式的流量都会在到达应用之前被丢弃，这样就清除了大部分显而易见的流量，并让下方更专业的层专注于剩余部分。
在 API 入口面上，我们通过 API Shield 运行正向安全模型。我们不去试图预判每一种坏请求，而是描述每个 API 的有效请求应当是什么样子——要么依据 API 自身的定义，要么从我们的真实流量中学习得到——任何不符合要求的请求都无法通过。这样就抵消了前沿 AI 模型的优势：因为我们只允许经过验证的流量，生成数千种新的攻击变体也无法绕过系统。
Cloudflare 的分层架构
Bot Management
在前沿模型能够绘制出网络地图之前，先在我们的网络上捕获探测流量。系统会根据每个请求被自动化的可能性进行评分，所依据的是整个网络中一致的一组信号：客户端的行为方式、它看起来是否像真实浏览器，以及连接是否匹配已知恶意模式。只有当攻击能够找到薄弱点时，它才会真正得手。
零信任网络访问（Zero Trust Network Access）用于所有内部应用。过去在网络内部就默认可信的做法，被针对每位员工访问每一项工具的、按请求逐一验证的身份与策略所取代。当我们的一名工程师发布了一个配置错误的工具时，这一点的价值变得非常清楚。在扁平网络中，所有内容都会暴露在同一个网段上，但在我们的部署里，暴露只止步于该工具本身。之后，我们构建了 Require Access Protection，这样新部署或配置错误的应用在访问策略到位之前就无法被访问。
IdP Federation 让这种默认安全的姿态更容易在整个 Cloudflare 账户中保持一致——而当越来越多的人快速发布内部工具时，这一点就变得更加必要。我们不再要求每个团队分别搭建 SSO，而是统一配置一次身份提供商（IdP），然后在整个组织内共享。新账户会自动获得 SSO，接收方侧的 IdP 连接是只读的，而每个账户中的 Access 策略仍会在正常请求流程中将最终形成的身份作为评估的一部分。
MCP Server Portal 为团队提供了一种受控方式，将 AI 代理连接到企业系统。代理通过一个统一门户访问由中央管理的 MCP 服务器，所有操作都会被记录下来。这样，当代理代表某个人行事时，我们就知道它做了什么、接触了什么，以及它是否本应被允许这样做。我们如何构建它的完整说明，见我们关于 enterprise MCP 的文章。
AI Gateway 置于我们内部 AI 工具之前，其方式与 AI Security for Apps 置于面向客户的 AI 功能之前的方式相同，采用相同的评分机制和相同的可见性。在公司内部，可见性比阻拦更有用，因为在我们能够针对它制定有意义的策略之前，必须先看清工程师们到底在构建什么。
团队可以从哪里开始
前沿模型可以帮助攻击者寻找漏洞、调整载荷并加快行动速度，但它们仍然必须穿过部署在应用前方的分层防御。团队应当从这里开始：
在面向公众的应用前放置检查。
定义什么样的 API 流量才算有效。
使用机器人检测来限制自动化探测。
在任何内部工具可达之前，先要求身份验证和访问策略。
对于 AI 和代理式系统：
通过网关转发模型流量。
让代理通过经过批准的 MCP 服务器连接。
记录它们的行为。
目标是确保当某一层漏掉时，下一层能够限制攻击者能够看到、到达或更改的范围。
这就是围绕该漏洞所构建架构的意义：限制攻击的范围。漏洞也许是攻击的起点，但真正决定其能走多远的，是架构。
我们如何知道这种方法有效？
许多安全栈在白板上看起来固若金汤，但在实际中却不堪一击。这就是为什么我们会持续不断地测试自己的安全体系，无论是在边界还是在环境内部，而且我们的红队会同时参与这两个层面。
在边界层面，前沿模型是我们用来把应用安全栈当作一种自适应攻击者进行测试的工具之一。这些模型与我们的其他红队和检测工作流并列使用，包括：手动测试、威胁情报、观察到的流量模式、概念验证分析，以及来自我们自身网络的信号。综合这些输入，我们可以决定把测试重点放在哪里：新发布的产品、最近发生变化的攻击面，以及攻击者最可能首先探测的路径。最重要的部分是随后展开的流程。一旦有东西漏了进去，我们就识别缺口，使用合适的工具组合来理解它，编写相应的规则或缓解措施，发布更新，然后再测试一次，确保这个缺口已经被关闭。
在环境内部，我们的红队会从“边界已经失败”这一前提出发。他们会查看哪些地方发生了变化，敏感系统在哪里承载风险，以及一条被攻破的身份、路径或凭证是否能够比预期更远地触达系统。当地基于他们发现的结果来调整架构后，他们会针对新版本再次运行同样的场景，以确认这个缺口确实已经关闭。
我们通过在故障期间持续测试其行为来确认这套架构是有效的，而不是依赖单个层级的完美无缺。
如果你的团队也在解决同样的问题，并希望交流经验，欢迎通过 security-ai-research@cloudflare.com 与我们联系。
来源与参考
收录于 2026-06-10