API 网关 DDoS 防护：分层控制与故障预案

API 网关可以认证调用方、验证请求，限制速率、并发和请求体大小，并在高成本工作到达服务前进行负载削减，从而帮助抵御应用层 DDoS。但如果攻击流量在到达网关前就已占满网络链路，网关无法单独阻止攻击。有效的防御需要在上游部署运营商、CDN、Anycast 或流量清洗能力，限制对源站的直接访问，并让网关充当理解应用语义的准入层。

核心要点

• 每种控制都应匹配相应的攻击层；不存在一个覆盖所有故障模式的“DDoS 防护”开关。
• 容量型流量洪峰必须在受限链路上游阻断，而不是等其占满源站链路后再处理。
• 只允许预期的边缘路径访问网关，并保护源站地址，避免攻击者绕过防御。
• 网关不仅要限制请求数量，还要约束资源成本：并发数、载荷大小、分页、批量宽度和高成本操作都很重要。
• 应先建立可信身份并正确恢复经过验证的客户端地址，再执行每客户端策略。
• 在依赖项性能下降的条件下演练检测、升级、缓解与恢复。

从故障点出发，而不是从产品出发

CISA 的 DDoS 指南区分了耗尽带宽、协议或基础设施状态，以及应用资源的攻击。真正有用的问题不是简单地问“网关能否阻止 DDoS”，而是“哪个资源最先不可用，控制措施能否在此之前生效”。

如果 100 Gbit/s 洪峰进入只有 10 Gbit/s 的源站路径，位于该路径之后的网关不可能通过检查请求来摆脱饱和，必须在具备足够容量的位置过滤。反过来，上游网络服务也不一定知道某个看似有效的 GraphQL 查询或导出请求会消耗异常高的资源，这一语义边界必须由网关和应用执行。

使用分层 DDoS 防御架构

1flowchart LR
2    I[互联网] --> E[运营商 / Anycast / CDN / 流量清洗]
3    E --> L[负载均衡器或 L4 防护]
4    L --> G[API 网关]
5    G --> S[隔离的上游池]
6    S --> D[(数据库和依赖项)]
7    O[控制面和管理访问] -. 独立路径 .-> G

各层承担不同职责：

• **运营商或分布式边缘：**在容量型流量到达源站链路前将其吸收或导走，并阻断明显的网络或协议洪泛。
• **负载均衡器/L4 层：**管理连接状态、SYN 行为和传输层健康状态。
• **API 网关：**恢复可信身份、执行认证和验证、限制与分级流量，并观察应用请求。
• **应用和依赖项：**执行操作专用的不变量、成本限制、授权和支出上限。
• **控制面：**保持私有，即使公共数据面承受压力，仍能正常运维。

Web 应用防火墙可以增加特征规则和行为检测，但无法取代容量规划、认证、限流或应用边界。如需查看 Apache APISIX 的具体集成方式，请参阅 chaitin-waf 插件文档。

防止绕过边缘直达源站

攻击者不应能够发现网关或源站地址后绕过上游防御。根据部署方式，可以采用以下控制：

• 通过网络访问规则，只允许文档列明的边缘地址范围访问数据面；
• 在边缘与源站之间使用双向认证连接；
• 使用私有连接或隧道；
• 删除过期 DNS 记录和已泄露地址；
• 为健康检查和管理操作设置独立且受限的路径；
• 监控绕过预期路径到达的流量。

IP 允许列表会变化，自动更新失败时还可能阻断合法流量。应使用运营商发布的地址范围，执行原子更新，在轮换期间保留重叠范围，并准备紧急恢复路径。不要只复制一次地址范围就假定它永远不变。

只能信任由可信代理恢复的原始客户端地址。如果网关直接接受来自互联网的 X-Forwarded-For，攻击者就能自行指定表面来源，从而绕过或嫁祸基于 IP 的规则。应在第一个可信跳点移除不可信的转发请求头，并针对确切的代理链配置地址恢复。

限制应用层资源消耗

OWASP API4:2023将不受限制的执行时间、内存、文件描述符、上传大小、批量操作、分页和第三方支出列为 API 风险。因此，DDoS 防御必须预算工作成本，而不能只统计数据包数量。

速率与配额

按路由和身份设置请求速率。密码重置、报告导出、登录和缓存目录读取不应共用一个随意设置的阈值。尽可能在认证后使用每租户或每凭证策略；仅基于 IP 的限制可能误伤共享网络后的用户，也更容易被分布式攻击者用多个地址分散规避。

并发

即使请求速率很低，慢操作也可能占满所有工作进程或数据库槽位。应在高成本路由和上游池设置并发预算，在形成无界网关或应用队列前拒绝请求。

请求形态与大小

根据场景限制请求体字节数、请求头大小、解压后大小、数组长度、分页、GraphQL 复杂度、批量宽度、压缩包解压膨胀和响应大小。应用内也要再次验证这些限制，因为网关不一定理解所有语义成本。

认证与操作控制

认证会提高攻击成本并支持更公平的归因，但已泄露的凭证仍是有效凭证。应按主体和租户限制敏感操作，检测异常使用，并支持快速撤销。短信、电子邮件、AI 推理等计费依赖项需要设置财务上限和告警。

缓存

缓存稳定的公共读取可以减少上游工作，但攻击者可以使用唯一的查询字符串、请求头或键规避简单缓存。应有意设计缓存键规范化，拒绝没有意义的变化；如果没有正确隔离，绝不能缓存私有响应。

将 APISIX 配置为准入层

Apache APISIX 3.18 提供互补的流量和安全插件。下面的示例路由针对一个高成本公共搜索端点，同时实施请求速率和并发控制：

1curl "http://127.0.0.1:9180/apisix/admin/routes/catalog-search" \
2  -X PUT \
3  -H "X-API-KEY: ${admin_key}" \
4  -d '{
5    "uri": "/v1/catalog/search",
6    "methods": ["GET"],
7    "plugins": {
8      "limit-req": {
9        "rate": 20,
10        "burst": 10,
11        "key_type": "var",
12        "key": "remote_addr",
13        "rejected_code": 429
14      },
15      "limit-conn": {
16        "conn": 80,
17        "burst": 0,
18        "default_conn_delay": 0.1,
19        "key_type": "var",
20        "key": "server_addr",
21        "rejected_code": 503
22      },
23      "prometheus": {}
24    },
25    "upstream": {
26      "type": "roundrobin",
27      "nodes": {
28        "catalog.internal:8080": 1
29      }
30    }
31  }'

其中的数字和键仅作示例。只有可信代理设计正确时，remote_addr 才有意义。server_addr 展示的是面向单实例的安全键，并不是全网关集群共享的计数器。应根据合法突发流量、网关拓扑和测得的上游容量确定实际值。

limit-req 插件限制到达速率，limit-conn 插件限制并发请求。调用方速率策略使用 429，共享容量压力使用 503，让运维人员和客户端可以区分两种情况。

对于上传场景，APISIX 的 client-control 插件可以设置 max_body_size，但当前文档说明它需要 APISIX-Runtime。应确认所用发行版满足这一前置条件，否则应在受支持的监听器或运行时配置中限制请求体，并在应用内再次限制。

APISIX ip-restriction 可以支持允许列表或拒绝列表，但仅靠 IP 封禁无法有效抵御 DDoS：源地址可能数量庞大，在某些层可被伪造，可能由合法客户端共享，也可能发生变化。应将它用于定义明确的信任边界，例如允许的边缘地址范围，而不是作为完整事故响应策略。

保护网关自身

网关策略本身也会消耗资源。受到攻击时：

• 避免为每一个被拒绝的请求同步写日志或调用远程策略服务；
• 对高流量拒绝遥测采样或聚合，同时保留准确的事故计数；
• 限制原始 IP、无限制 User-Agent 等高基数标签；
• 不要在公共监听器上暴露配置分发和管理 API；
• 为健康探针和运维访问预留容量；
• 测试连接频繁建立时的证书与认证成本；
• 确保扩缩容信号在实例完全饱和前到达。

自动扩缩容本身不是 DDoS 缓解措施。扩容可能滞后、触及区域配额、放大成本，或进一步挤压高成本的下游瓶颈。应在自动扩缩容前设置准入控制，并在云服务商支持时配置预算告警和硬性上限。

使用多种信号检测攻击

APISIX 的 prometheus 插件可以导出请求、状态、带宽和延迟信号。应将网关观测与边缘、负载均衡器、主机和应用遥测结合起来：

• 运营商边缘的每秒数据包数和比特数；
• 新建、已建立、重置和超时的连接数；
• 请求数、可信身份数量，以及地理和网络分布；
• 按路由统计的 429、503、认证失败和验证拒绝；
• 请求大小和操作成本分布；
• 网关 CPU、内存、套接字、事件循环延迟和上游连接；
• 上游延迟、饱和度、队列深度和依赖项支出；
• 缓存命中率和缓存键基数。

要为正常营销活动、发布、合作伙伴批处理和移动端重试行为建立基线。热门发布与攻击在边缘看起来可能相似，但所需的业务决策不同。应自动执行边界明确的安全保护，同时保留责任清晰的策略升级路径。

建立事故响应手册

DDoS 事故响应手册应在事故发生前明确负责人、阈值和行动：

1. 检测并分类。 确认饱和的资源、协议、路由、身份和区域。
2. 保护控制能力。 确认运维访问、配置下发和可观测性仍可用。
3. 寻求上游协助。 提前掌握运营商或流量清洗服务的升级渠道和所需信息。
4. 应用可逆策略。 优先收紧高成本路由或受影响身份，并记录变更和到期时间。
5. 保障关键流量。 根据业务优先级隔离健康检查、认证、支付或运维路径。
6. 沟通。 说明影响和缓解措施，但不要公开可帮助攻击者绕过控制的细节。
7. 逐步恢复。 分阶段移除紧急规则，并观察攻击是否再次出现或客户端是否产生重试洪峰。
8. 复盘证据。 更新容量、基线、允许列表、联系人和应用限制。

避免留下没有负责人或到期时间的永久性紧急规则，否则它们往往会成为之后的可用性事故。

在不制造事故的前提下测试

DDoS 测试应与基础设施提供商和内部安全团队协调，在授权环境和流量范围内进行。可以从受控的应用层场景开始：

• 符合正常营销活动预期的突发流量；
• 跨大量源地址的分布式请求；
• 缓慢且占用并发的请求；
• 体积较大但符合模式的载荷；
• 使用有效凭证重复发起高成本操作；
• 流量保持高位时，上游池容量下降或部分节点失效；
• 高拒绝率导致的日志和指标压力。

验证控制措施能在受保护资源到达不安全点之前生效，合法关键流量仍能获得预期服务，告警能正确识别故障层，而且具备回滚能力。网络规模的模拟需要基础设施提供商明确配合；未经授权，不要直接用互联网负载生成器冲击生产环境。

DDoS 就绪检查清单

• 哪条链路、状态表、工作进程池、数据库或付费依赖项会最先失效？
• 容量型流量能否在到达该点前被过滤？
• 攻击者能否绕过受保护边缘直接访问源站？
• 是否只信任已知代理提供的转发请求头？
• 速率、并发、载荷、批量、分页和支出限制是否按路由设置？
• 网关能否低成本拒绝请求，而无需等待日志或远程依赖？
• 关键路由和运维访问是否隔离？
• 运营商升级与策略变更是否已有经过测试的负责人和流程？
• 紧急规则是否可逆且有时间限制？
• 是否演练过从攻击以及随后客户端重试洪峰中恢复？

总结

API 网关是 DDoS 防御中理解应用语义的一环，而不是完整防御。应在受限网络链路之前部署高容量缓解措施，防止攻击者绕过边缘直达源站，再使用网关身份、验证、速率、并发和大小控制保护应用资源。将这些控制与依赖项限制、高效遥测和经过演练的事故响应手册结合，才能让系统按设计方式降级，而不是要求一个网关吸收所有类型的攻击。

常见问题

API 网关能否阻止容量型 DDoS 攻击？

如果攻击在到达网关前就占满网络链路，则不能。必须由运营商边缘、CDN、Anycast 或流量清洗能力在上游过滤。网关仍然适合执行理解应用语义的准入控制。

仅按 IP 限流足以防御 API DDoS 吗？

不足。分布式攻击者会使用大量地址，而合法用户可能共享一个地址。应将可信客户端地址处理与基于身份、路由、并发、载荷和操作成本的控制结合起来。

自动扩缩容能否解决应用层 DDoS 攻击？

自动扩缩容可以增加容量，但也可能滞后、触及配额、增加成本或压垮固定的依赖项。因此还需要明确的准入限制和支出控制。

后续步骤

找出每个公共 API 最先饱和的资源，并确认上游缓解措施在哪里生效。然后核对当前部署支持的 APISIX 限流和并发限制选项。如需集中管理 Apache APISIX 安全策略，可以进一步了解 API7 Enterprise。