如何为应用程序实施第 7 层 DDoS 保护

大多数遭受应用程序层攻击的团队已经部署了DDoS防护。只是该防护并未覆盖正确的层级。第七层DDoS防护解决的问题与网络层防护的问题有着本质区别，将它们视为可互换的是生产环境中一种最常见且代价高昂的基础设施错误。.

分层是架构决策，并非仅仅是分类

L3/L4 防护——BGP黑洞、Anycast清洗、SYN洪水防护——基于数据包数量和协议行为进行操作。它们能够出色地吸收100 Gbps的UDP放大攻击或SYN洪水，因为这些攻击仅凭数量就足以与合法流量区分开。硬件可以在不理解数据包内容的情况下以线速处理它们。.

L7攻击有所不同。HTTP洪水、慢速POST、缓存绕过扫描或凭证填充攻击，它们看起来都像是合法的TCP连接，并且具有格式正确的HTTP头。数据包一个接一个地到达，从网络角度来看，每一个都是合法的。直到源服务器崩溃，基于流量的系统才能看到任何异常。.

架构上的后果是不可协商的：L7 检查需要一个完全内联的 HTTP 代理。. 您无法通过 BGP 路由将应用程序层攻击从路径中清除——网络清洗中心只能看到数据包流，无法检查请求正文、标头和会话模式。如果您的 DDoS 提供商没有终止每个 HTTP 连接并将干净的请求代理到您的源服务器，那么无论供应商仪表板上显示什么，您都没有任何 L7 保护。.

看不见的攻击

最危险的 L7 模式也是最少被讨论的： 缓存绕过攻击.

一个了解你应用程序缓存键结构（大多数 CDN 缓存行为都是公开可观察的）的攻击者会构造请求，从而系统性地规避缓存内容。最简单的版本是通过附加一个随机查询参数（?v=7f3a2b, ?t=1718290000) 到每个请求。更具针对性的版本会轮换 Accept-Language 标题, Accept-Encoding 价值，或 X-Forwarded-For 击败缓存规范化规则的地址.

结果：每个请求都直达源站。没有 CDN 缓存命中。没有边缘吸收。在每秒 5000 个请求（产生的带宽不到 50 Mbps）的情况下，一个中档应用服务器可以在两到三分钟内耗尽其数据库连接池。源站响应时间下降，连接队列堆积，健康检查开始失败，负载均衡器将节点标记为不健康。.

从 L3/4 监控仪表板来看，这看起来只是交通量小幅增长。没有触发带宽警报。也没有越过数据包速率阈值。当运营商注意到源错误率上升时，应用程序已经无法访问。.

在SIRAYA观察到的亚太地区部署环境中，这种模式往往被低估，因为团队将监控重点放在带宽图表上，而非源连接深度和缓存命中率。 在五分钟内，缓存命中率从92.1%骤降至15.1%才是真正的先行指标——而大多数团队并未配置此类告警。.

API 终端盲点

还有一种失败模式同样值得关注。WAF 产品通过 JavaScript 验证机制来保护 Web 应用程序：CDN 会分发一段轻量级的 JavaScript 代码片段，验证浏览器能否执行该代码，然后发放一个授权 Cookie。浏览器会自动通过此验证，而无法运行 JavaScript 的机器人则无法通过。.

这在 HTML 应用程序中效果很好。但在 API 端点上则完全失效。.

你的 /api/v1/authenticate 端点、您的 GraphQL 端点、您的 webhook 接收器——这些都不是由渲染页面的浏览器调用的。它们是由移动应用、后端服务、自动化客户端调用的，同样，也由凭证填充工具和 API 洪水脚本调用。 在 API 端点上设置 JS 验证挑战，不仅会破坏您的合法集成，而且对那些本就不遵守该规则的机器人也毫无防护作用。.

一种会导致此安全隐患的常见部署模式：在主域上配置了 WAF 和机器人管理规则，其中 /api/* 这些路由要么被挑战规则排除在外，要么由一个完全不具备 WAF 覆盖范围的独立源地址进行处理。而 API 端点——这些端点通常是数据外泄、账户接管和服务中断的高价值攻击面——则处于暴露状态。.

对于 API 路径，第 7 层 DDoS 防护需要一套不同的工具集：基于经过身份验证的令牌或 API 密钥（而非 IP 地址）进行速率限制， TLS 指纹分析（使用 JA3/JA4 签名识别非浏览器客户端）、请求正文异常检测，以及针对每个端点的 RPS 阈值——这些阈值应根据实际流量基线进行调整，而非采用全局默认值。.

为什么基于 IP 的速率限制在 APAC 规模下会失败

基于 IP 的速率限制是大多数团队首先会采取的控制措施，而在许多亚太地区的部署中，它带来的问题比解决的问题还要多。.

东南亚、韩国以及中国部分地区的移动运营商网络使用大规模运营商级NAT（CGNAT）。成千上万的合法用户可以共享一个公共IP地址。为阻止恶意爬虫而设置的IP速率限制会触发主要移动运营商的IP块，导致真实用户的合法流量在中途被丢弃。这表现为429错误突然激增，并且主要集中在移动用户细分群体中——这通常归咎于CDN，有时归咎于应用程序，很少能追溯到速率限制配置。.

与此同时，一个财力雄厚的攻击者通过住宅代理网络进行攻击，会将攻击流量分散到成千上万个 IP 地址上，使得每个 IP 地址的独立请求速率都低于任何能够解决 CGNAT 问题的阈值。.

在应用层，更稳妥的做法是根据经过身份验证的会话、API 令牌或行为指纹来限制速率，而不是根据 IP 地址。对于无法采用上述方法的未经验证的端点，应考虑采用较短时间窗口的突发流量限制，并结合渐进式验证强度提升机制，而非对每个 IP 地址实施硬性限制。.

源 IP 暴露，令边缘防护失效

如果攻击者知道您的源服务器的 IP 地址并直接对其发起攻击，那么部署一个具备完整 WAF 和 L7 DDoS 防护功能的 CDN 也无法提供任何保护。.

源IP地址比大多数团队预期的更容易被发现。历史DNS记录（CDN迁移前）、SSL证书透明度日志、应用程序级错误消息中留下的IPv6地址、CDN未涵盖的子域上的A记录，或配置错误的暂存环境的响应——这些中的任何一个都可能暴露源服务器。攻击者在发起应用层攻击之前会例行收集这些信息，特别是为了绕过边缘保护。.

修复方法是将源 IP 隐藏视为 L7 DDoS 防护架构的强制性要求，而不是锦上添花。在防火墙层面，仅接受来自 CDN 提供商已发布的 IP 地址范围的入站 HTTP/HTTPS 连接，并拒绝所有其他连接。对于更高安全要求的设置，请用出站隧道（Cloudflare Tunnel、AWS PrivateLink 或同等产品）完全替换直接的源暴露，这样源完全不需要接受公共入站连接。.

选择正确的防御架构

实际的决定不是“L3/4 或 L7”，而是理解哪个层代表了您主要的攻击面。.

如果您运行的基础设施因其本质（例如大型 DNS 解析器、金融交易所、处理大量连接的在线游戏平台）而成为流量攻击的目标，您就需要一个高容量的任播网络来覆盖 L3/L4 层，并置于所有其他层之上。.

如果您运行的是 Web 应用程序或 API，那么风险几乎肯定集中在 L7 层。中等规模的应用程序通常不会遭遇 500 Gbps 的 UDP 洪水攻击。 它可能会遭遇每秒30,000次针对未经过身份验证的密码重置端点的HTTP请求，或是8,000个慢速连接占用所有可用工作线程，又或是针对性爬取，旨在耗尽您的搜索索引查询配额。.

对于大多数 Web 和 API 工作负载而言，在 CDN 边缘实施的 L7 内联防护所覆盖的实际攻击面，比仅靠 L3/4 清洗要更广。. 两层结合是生产级的解决方案，但如果您必须优先考虑覆盖范围，同时考虑成本或运营复杂性，那么应用程序层就是现代攻击的着陆点。.

SIRAYA 针对在亚太地区部署的应用程序推荐的一种常见架构采用三层架构：第一层是集成 WAF 和机器人管理功能的任播 CDN 边缘节点，作为首个接触点；第二层是在负载均衡器层实施源服务器级连接速率限制（采用保守调优以避免 CGNAT 误报）， 以及在 API 网关层针对经过身份验证的 API 路径实施的每端点速率限制。每个层级处理其最擅长检测的内容；不期望任何单一层级能够阻止所有攻击。.

WAF 模式部署的风险

一种出人意料地频繁出现的运行故障：部署在“检测”或“仅记录”模式下的 WAF 规则集，在流量激增之前从未被提升至“阻止”模式。.

这种思路可以理解——团队希望在严格执行规则之前先观察一下误报情况。但“检测模式”并非防护措施，而是监控手段。在面临真实攻击的生产环境中，一个仅记录事件而不进行拦截的WAF系统，只能为事后报告提供素材，而无法真正预防事件发生。.

更佳的操作实践是：首先在风险较低的终端（静态资源路径、文档页面）上以分批模式部署并进行监控，随后逐步将规则执行范围扩展至敏感度更高的路径，例如身份验证和 API 终端。这种做法既能在观察期内避免整个应用程序暴露在风险中，又能增强对规则调优的信心。.

第7层DDoS防护并非买来后便可置之不理的产品。它需要根据您具体应用程序的流量模式、API架构、身份验证模型以及用户地理分布进行配置。 在真实的定向攻击中，默认配置很少能奏效。能够抵御攻击的团队，是那些根据自身基线流量调整了规则、准确掌握缓存系统在高负载下的行为，并且在攻击者开始搜寻源服务器之前就已将其隐藏的团队。.