**发布时间:** 2025-11-05
**厂商:** AWS
**类型:** BLOG
**原始链接:** https://aws.amazon.com/blogs/networking-and-content-delivery/configuring-the-aws-waf-anti-ddos-managed-rule-group-for-your-resources-and-clients/
---
<!-- AI_TASK_START: AI标题翻译 -->
[解决方案] 为您的资源和客户端配置 AWS WAF Anti-DDoS 托管规则组
<!-- AI_TASK_END: AI标题翻译 -->
<!-- AI_TASK_START: AI竞争分析 -->
# 解决方案分析
## 解决方案概述
该文档详细阐述了如何配置 **AWS WAF Anti-DDoS 托管规则组**，以在提供强大的 **第七层 (HTTP) DDoS 防护** 的同时，最大限度地减少对合法用户体验的负面影响。核心挑战在于，默认的缓解措施，特别是基于 JavaScript 的静默挑战（**软缓解**），虽然对标准浏览器用户透明，但可能会意外阻止不支持该机制的客户端，如**单页应用 (SPA)** 的 `fetch` 请求和**原生移动应用**的 API 调用。
该解决方案的技术原理是，规则组通过学习流量模式建立基线，并为异常请求分配“怀疑分数”。根据分数高低，采取不同级别的缓解措施：
- **软缓解 (Soft Mitigation)**：对低、中度怀疑的请求发起 **JavaScript 挑战**。这对攻击者而言会显著增加资源成本，但对合法浏览器用户无感知。
- **硬缓解 (Hard Mitigation)**：对高度怀疑的请求直接**阻止 (Block)**。
方案的目标是指导用户根据其客户端类型（浏览器、SPA、移动端、M2M）和资源敏感度，精细化调整规则组配置，在 **DDoS 缓解效果** 与 **最终用户体验** 之间找到最佳平衡点。
## 核心配置场景与调优策略
### 场景 1：客户端或请求类型不支持原生挑战机制
对于无法处理 JavaScript 挑战的客户端（如原生移动应用），最佳策略是让客户端主动集成以支持挑战。
- **实施方案：**
- 使用 **AWS WAF 客户端集成 SDK**，使客户端能在 DDoS 事件发生前主动完成挑战并获取令牌 (Token)。
- **JavaScript SDK**：适用于基于浏览器的应用，通过在 HTML 头部嵌入 JS 实现页面加载时自动完成挑战。
- **Mobile SDK**：提供 Android 和 iOS 版本，工作流与 JS SDK 类似。
- **关键配置：**
1. 在 Web ACL 中部署 **AWS WAF Targeted Bot Control AMR** 规则组（SDK 的前提条件）。
2. 放宽“豁免 URI 正则表达式” (Exempt URI regular expressions) 至 `\x00`，使所有请求（包括 API 和静态资源）都变为可挑战，因为集成了 SDK 的客户端会携带有效令牌。
3. 添加自定义规则，对 DDoS 事件期间的非 GET 请求（如 POST/PUT）也发起挑战，确保全面覆盖。
```json
{
"Name": "ChallengeNonGetDuringDDoSEvent",
"Priority": 100,
"Action": { "Challenge": {} },
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "ChallengeNonGetDuringDDoSEvent"
},
"Statement": {
"AndStatement": {
"Statements": [
{
"NotStatement": {
"Statement": {
"ByteMatchStatement": {
"FieldToMatch": { "Method": {} },
"PositionalConstraint": "EXACTLY",
"SearchString": "GET",
"TextTransformations": [{ "Type": "NONE", "Priority": 0 }]
}
}
}
},
{
"LabelMatchStatement": {
"Scope": "LABEL",
"Key": "awswaf:managed:aws:anti-ddos:event-detected"
}
}
]
}
}
}
```
### 场景 2：客户端无法使用 WAF 客户端集成
如果无法修改客户端代码以集成 SDK，则需要在用户体验和防护强度之间做出权衡。以下配置选项按防护强度从高到低排列：
1. **仅挑战可疑请求**：将 `ChallengeAllDuringEvent` 规则的动作改为 `Count`。这样，在 DDoS 事件中，非可疑的合法请求将不再被挑战，仅可疑请求会触发挑战。这在保护资源的同时，减少了对大部分合法用户的干扰。
2. **提高挑战敏感度**：将 `Challenge sensitivity` 调整为 `Medium`。这样，低度怀疑的请求将被放行，只有中度和高度怀疑的请求才会被挑战，进一步降低了对可能被误判的合法用户的影响。
3. **豁免更多端点**：在“豁免 URI 正则表达式”中添加最少数量的关键业务端点，使其变为不可挑战。这是一种妥协方案，虽然保证了这些端点的可用性，但也削弱了对它们的软缓解保护。
### 场景 3：不可挑战的请求在被阻止前压垮资源
对于不可挑战的请求（如 POST 或被豁免的 API），它们只有在达到“高”怀疑级别时才会被阻止，这可能导致敏感后端在被保护前就已过载。
- **解决方案：**
1. **降低阻止敏感度**：将 `DDoS block sensitivity` 从 `High` 调整为 `Medium` 或 `Low`，使中低度怀疑的请求也能被提前阻止。这会增加误伤合法用户的风险。
2. **创建自定义软限制**：添加一条基于速率的规则，在 DDoS 事件期间限制来自单一来源（如 IP 或用户凭证）的可疑、不可挑战请求的数量。这在不直接阻止低/中度怀疑请求的情况下，限制了其潜在的冲击量。
```json
{
"Name": "RateLimitSuspiciousUserRequests",
"Priority": 100,
"Action": { "Block": {} },
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "RateLimitSuspiciousUserRequests"
},
"Statement": {
"RateBasedStatement": {
"Limit": "10",
"AggregateKeyType": "CUSTOM_KEYS",
"EvaluationWindowSec": 60,
"CustomKeys": [
{
"Header": {
"Name": "Authorization",
"TextTransformations": [{ "Type": "NONE", "Priority": 0 }]
}
}
],
"ScopeDownStatement": {
"AndStatement": {
"Statements": [
{
"LabelMatchStatement": {
"Scope": "LABEL",
"Key": "awswaf:managed:aws:anti-ddos:ddos-request"
}
},
{
"NotStatement": {
"Statement": {
"LabelMatchStatement": {
"Scope": "LABEL",
"Key": "awswaf:managed:aws:anti-ddos:challengeable-request"
}
}
}
}
]
}
}
}
}
}
```
### 场景 4：可挑战的请求在被阻止前压垮资源
即使请求是可挑战的，如果攻击者能够绕过挑战，或者某些 GET 请求（如复杂的查询页面）本身对后端资源消耗巨大，中低度的可疑流量也可能导致服务不可用。
- **解决方案：**
1. **降低阻止敏感度**：同上，将 `DDoS block sensitivity` 调整为 `Medium` 或 `Low`。
2. **针对敏感端点进行精确阻止**：创建自定义规则，当检测到 DDoS 请求（`awswaf:managed:aws:anti-ddos:ddos-request` 标签）且其访问的是特定的高负载 URI（如 `/products/list`）时，直接阻止。
3. **在事件期间强制 CAPTCHA**：对于极其敏感的资源，可以添加规则，在检测到 DDoS 事件时，对所有可挑战的请求强制执行 **CAPTCHA** 验证。这极大地增加了攻击成本，同时允许合法用户通过验证后继续访问。
## 方案客户价值
- **精细化DDoS防护**：超越“一刀切”的防护模式，允许根据客户端类型（浏览器、SPA、移动应用）和业务特点定制防护策略。
- **优化最终用户体验**：通过客户端集成或调整敏感度，显著减少在 DDoS 攻击期间对合法用户的干扰，特别是保护了现代化应用架构的用户流畅度。
- **平衡安全性与可用性**：提供了一套清晰的权衡框架和可操作的配置选项，使企业能够在防护强度和业务连续性之间做出明智决策。
- **增强对敏感端点的保护**：通过自定义速率限制和 URI 定向阻止等高级策略，为高负载或关键业务 API 提供了额外的、更具针对性的保护层。
## 涉及的相关产品
- **AWS WAF**：提供 Web 应用程序防火墙功能的核心服务平台。
- **Anti-DDoS managed rule group**：本方案的核心，用于检测和缓解 L7 DDoS 攻击的托管规则集。
- **AWS WAF client integrations (JavaScript & Mobile SDKs)**：用于客户端主动完成挑战，是实现最佳用户体验的关键组件。
- **AWS WAF Targeted Bot Control AMR**：使用客户端集成 SDK 的前置条件。
- **AWS Shield Advanced**：作为应对更复杂、更大规模 DDoS 攻击的升级选项，提供 24/7 的专家支持（Shield Response Team, SRT）。
## 技术评估
- **优势**
- **高度灵活性与可定制性**：方案并非“黑盒”，提供了丰富的配置选项和自定义规则示例，能够灵活适应不同的应用架构和流量特征。
- **分层缓解策略**：结合使用软缓解（Challenge）和硬缓解（Block），并基于怀疑分数进行决策，实现了比单一阻止策略更精细、更智能的威胁响应。
- **面向现代化应用设计**：方案直接解决了 SPA 和移动 API 等现代 Web 架构在传统 WAF 防护下面临的痛点，体现了对当前技术趋势的深刻理解。
- **可能的限制**
- **配置复杂度**：要实现最佳平衡，需要对应用流量模式和 WAF 规则行为有深入理解，对缺乏专业安全知识的团队构成一定挑战。
- **依赖客户端集成**：获取最佳用户体验的方案依赖于在前端和移动端代码中实施 AWS WAF SDK，这需要额外的开发和部署成本。
- **潜在的误报风险**：任何基于启发式检测的系统都存在误判风险。尤其在调高阻止敏感度时，可能会影响到部分行为异常的合法用户，方案本身也承认了这种权衡。
<!-- AI_TASK_END: AI竞争分析 -->
<!-- AI_TASK_START: AI全文翻译 -->
# 为您的资源和客户端配置 AWS WAF Anti-DDoS 托管规则组
**原始链接:** [https://aws.amazon.com/blogs/networking-and-content-delivery/configuring-the-aws-waf-anti-ddos-managed-rule-group-for-your-resources-and-clients/](https://aws.amazon.com/blogs/networking-and-content-delivery/configuring-the-aws-waf-anti-ddos-managed-rule-group-for-your-resources-and-clients/)
**发布时间:** 2025-11-05
**厂商:** AWS
**类型:** BLOG
---
希望保护自己免受第 7 层 (HTTP) DDoS 威胁的用户可以使用 [AWS WAF](https://aws.amazon.com/waf/) 的 [L7 Anti-DDoS 托管规则组](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-anti-ddos.html) 在个位数秒内检测和缓解 DDoS 事件。Anti-DDoS 托管规则组具有适用于许多应用程序和客户端的默认配置。然而，有些客户端需要特别关注。基于浏览器的单页应用程序 (SPAs) 发出的 `fetch` 请求，以及原生移动应用程序发出的 API 请求，并不支持所有的缓解措施，并且在检测到事件期间，它们的请求可能会被无意中止。在本文中，我们将指导您如何为不同类型的客户端和资源调整您的 Web 访问控制列表 (web ACL)，以优化您的 DDoS 防护和用户体验。
## AWS WAF Anti-DDoS 托管规则组如何在缓解效果与最终用户影响之间权衡
当 Anti-DDoS 托管规则组被添加到您的 AWS WAF web ACL 配置中时，它会迅速学习您的流量模式并为每个受保护的资源建立基线。它通过将当前流量与这些基线进行比较来识别异常，并为请求分配可疑分数 (suspicion scores) 用于缓解措施。默认情况下，被指定为低和中度可疑的请求会采用一种软缓解 (soft mitigation) 措施，即静默的基于 JavaScript 的浏览器质询 (challenge)。这种质询对于合法用户是无感的，但会显著增加攻击者的资源成本。被指定为高度可疑的、可能参与 DDoS 攻击的请求则会采用一种硬缓解 (hard mitigation) 措施，即即使它们完成了质询也会被阻止。
Anti-DDoS 托管规则组将可质询的请求 (challengeable requests) 定义为使用 GET 方法且 URI 不匹配 [豁免 URI 正则表达式](https://docs.aws.amazon.com/waf/latest/developerguide/waf-anti-ddos-rg-using.html) (即无法处理静默 JavaScript 质询的 URI) 的请求。这些请求被分配了标签 `awswaf:managed:aws:anti-ddos:challengeable-request`。所有其他请求都是不可质询的。
[AWS WAF Challenge 操作](https://docs.aws.amazon.com/waf/latest/developerguide/waf-captcha-and-challenge-actions.html) 是针对可质询请求的软缓解措施。默认情况下，带有 `Accept: text/html` 标头的可质询请求会收到一个 JavaScript 负载，该负载会完成一项任务并颁发一个令牌/Cookie。然后，用户被重定向回原始页面。图 1 以序列图的形式展示了这一过程，后续请求会自动包含此 Cookie。对于其他内容类型的可质询请求，会收到一个 HTTP `202 Request Accepted` 状态码并且无法继续，因为质询未完成。关于质询工作原理的更多细节，可以在这篇 [AWS 网络与内容分发博客文章](https://aws.amazon.com/blogs/networking-and-content-delivery/protect-against-bots-with-aws-waf-challenge-and-captcha-actions/) 中找到。
图 1: 用户、其浏览器和保护资源的 AWS WAF 之间的插入式质询交互序列图
使用软缓解和硬缓解措施有助于在 DDoS 缓解的有效性与 DDoS 事件期间对合法用户的影响之间取得平衡。
您可能已经考虑过通过禁用质询或降低阻止操作的敏感性来最小化对使用不支持此序列的客户端的合法用户的影响，如图 2 所示。但这会带来风险，即您的资源可能无法得到充分的 DDoS 攻击防护，或者合法用户发现他们被错误识别的请求因敏感性提高而被阻止。
图 2: 禁用质询的 AWS WAF Anti-DDoS 托管规则组配置
Anti-DDoS 托管规则组中有许多规则和配置选项，使您能够在 DDoS 攻击期间的资源可用性与可能支持或不支持质询软缓解的合法用户的体验之间找到正确的权衡点。图 3 中的流程图显示了 Anti-DDoS 托管规则组如何根据传入的请求和规则组配置工作。下一节将详细介绍如何更改规则组配置，以便在用户体验和 DDoS 攻击期间的资源敏感性之间做出最佳权衡。
图 3: AWS WAF Anti-DDoS 托管规则组评估每个规则的流程图
## 场景 1: 您的客户端或请求类型不支持质询
默认的 Anti-DDoS 托管规则组配置将 *ChallengeAllDuringEvent* 规则设置为质询。如果合法用户在 DDoS 事件期间使用不支持的客户端发出可质询的请求，他们会体验到服务中断。
为用户提供最佳体验的解决方案是允许他们的客户端完成质询。[AWS WAF 客户端集成](https://docs.aws.amazon.com/waf/latest/developerguide/waf-application-integration.html) 会在 DDoS 事件之外，作为加载资源的一部分，主动完成质询并获取令牌。这些 SDK 需要在 web ACL 中部署 [AWS WAF Targeted Bot Control AMR](https://docs.aws.amazon.com/waf/latest/developerguide/waf-bot-control.html) 。现在，所有请求都可以被 Anti-DDoS 托管规则组视为可质询的。
有两个选项：
- **JavaScript SDK:** 这个 [SDK](https://docs.aws.amazon.com/waf/latest/developerguide/waf-javascript-api.html) 适用于基于浏览器的应用程序。通过在应用程序的 HTML 头部嵌入 JavaScript 来实现，以便在页面加载期间完成质询。Cookie 会在后续请求中自动发送。
- **Mobile SDK:** 这个 SDK 适用于 Android 和 iOS。其底层工作流程与 [AWS 开发者指南](https://docs.aws.amazon.com/waf/latest/developerguide/waf-mobile-sdk.html) 中描述的 JavaScript SDK 类似。如果您有其他类型的客户端无法使用这些 SDK (例如，机器对机器通信)，那么您不能将所有请求都视为可质询的，必须查看下一个场景来处理不可质询的请求。
如果您跨域操作 (例如，一个 SPA `www.company.com` 向 `api.company.com` 发出 `fetch` 请求)，那么您还需要正确配置 [令牌域 (token domain)](https://docs.aws.amazon.com/waf/latest/developerguide/waf-tokens-domains.html) 。这篇 [文章](https://aws.amazon.com/blogs/networking-and-content-delivery/optimizing-web-application-user-experiences-with-aws-waf-javascript-integrations/) 涵盖了跨域配置的不同场景。
为您的资源提供最强 DDoS 请求防护的解决方案是使所有请求都可质询。图 4 显示了将豁免 URI 正则表达式放宽为 `\x00` 以不匹配任何请求。由于使用 SDK 后所有请求都包含令牌，质询不再中断 API 请求和静态资产 (如图片)。
图 4: 将所有请求都设置为质询的 AWS WAF Anti-DDoS 托管规则组配置
非 GET (例如 POST/PUT/DELETE) 请求继续被 Anti-DDoS 托管规则组定义为不可质询的。但是，客户端集成现在包含了令牌，这意味着它们通过了质询。您可以通过在 Anti-DDoS 托管规则组之后添加以下规则，来确保发出这些请求的客户端已经完成了质询。该规则会对匹配 DDoS 事件标签 (`awswaf:managed:aws:anti-ddos:event-detected`) 的非 GET HTTP 方法的请求进行质询。
```json
{
"Name": "ChallengeNonGetDuringDDoSEvent",
"Priority": 100,
"Action": {
"Challenge": {}
},
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "ChallengeNonGetDuringDDoSEvent"
},
"Statement": {
"AndStatement": {
"Statements": [
{
"NotStatement": {
"Statement": {
"ByteMatchStatement": {
"FieldToMatch": {
"Method": {}
},
"PositionalConstraint": "EXACTLY",
"SearchString": "GET",
"TextTransformations": [
{
"Type": "NONE",
"Priority": 0
}
]
}
}
}
},
{
"LabelMatchStatement": {
"Scope": "LABEL",
"Key": "awswaf:managed:aws:anti-ddos:event-detected"
}
}
]
}
}
}
```
## 场景 2: 我们的客户端无法使用 AWS WAF 客户端集成
在这种情况下，您需要在影响使用不支持质询的客户端的合法用户与阻止可能影响资源可用性的 DDoS 请求之间做出权衡。根据您愿意在多大程度上影响合法用户，您可以从更改默认的规则组配置开始。以下配置选项按为您的应用程序提供最强 DDoS 攻击防护的程度从高到低排序，即尽可能少地放宽质询软缓解：
1. **在事件期间允许非可疑请求无需质询：** 将 *ChallengeAllDuringEvent* 规则更改为 *Count* 意味着您的合法用户的非可疑请求在 DDoS 事件期间不再被质询。所有可疑请求仍会受到 *ChallengeDDoSRequests* 规则的质询。来自原生移动应用程序和 SPA `fetch` 请求的合法用户的非可疑请求将不再受到影响。这是以牺牲被错误识别为发出可疑请求的合法用户的不便为代价，来换取对您受保护资源的更强保护。
2. **允许更多可疑请求无需质询：** 如果您仍然担心合法用户被错误识别为发送低度可疑请求，您可以将 *Challenge sensitivity* 更改为 *Medium*。来自低度可疑用户的请求将被允许，这样您的合法用户受影响的可能性就更小了。中度可疑的请求仍会被质询。对于无法支持质询的移动客户端，并且如果您担心低度可疑请求会影响合法用户，这可能是一个可接受的权衡。
3. **不对更多端点进行质询：** 如果您无法支持质询，那么将最少数量的端点添加到此表达式中，以允许您的合法用户通过，同时仍然对其他支持质询的端点使用软缓解。因此，您可能会发现大量不可质询的请求会压垮您敏感的受保护资源。
这些选项改善了用户体验，因为用户受质询影响的可能性降低了。在一定规模下，这可能意味着要么被阻止的 DDoS 请求太少，要么太多合法用户受到他们无法完成的质询的影响。以下场景为此提供了一个解决方案。
## 场景 3: 不可质询的请求在被阻止前压垮了您的资源
您可能仍有一定数量的不可质询的请求，特别是如果质询缓解措施被禁用，或者您使用 AWS WAF 客户端集成的能力有限。不可质询的请求总是被允许，直到它们达到 DDoS 阻止敏感度 (默认为高)。这意味着敏感端点可能会被低度或中度可疑的请求压垮，因为软缓解措施没有被应用。以下常见用例需要特别考虑：
1. 用于表单提交的 POST 请求 (例如来自 HTML 页面)
2. 单页应用 (例如 React) 向 API 端点发出的 fetch 请求，特别是那些会给您的服务器带来负载的端点
3. 原生移动应用程序向 API 端点发出的请求
4. 机器对机器向 API 端点发出的请求
5. 对图片或其他静态资产的请求压垮了您的资源
GET 请求之所以变得不可质询，是因为豁免 URI 正则表达式默认排除了 `/api` 和静态资产。我们建议您缩小此表达式的范围，以确保尽可能多的请求可以被质询。如果这不可能，您有两个选择：
1. **将 DDoS 阻止敏感度从低更新到中 (或高)：** 中度和高度可疑的请求被阻止，理想情况下是在对您的资源产生负面影响之前。将阻止敏感度设置为高也会阻止低度可疑的请求。这限制了被错误识别为中度 (或低度) 可疑 DDoS 请求的合法用户的可访问性，但保持了更广泛的可用性。
2. **通过限制事件期间不可质询请求的数量来创建替代的软限制：** 与其通过阻止低/中度可疑的 DDoS 请求对您潜在的合法用户产生负面影响，不如创建一个基于速率的规则 (rate-based rule)，限制在 DDoS 事件期间允许的不可质询的可疑请求数量。您可以使用聚合键 (aggregation key)，如 IP、用户 (例如使用 `Authorization` 标头)，或特定的敏感端点 URI (例如完成昂贵数据库查询的端点)。在 Anti-DDoS 托管规则组之后添加以下规则，将来自一个用户 (基于 `Authorization` 标头) 的可疑不可质询请求限制为每分钟 10 个。带有低/中度可疑请求的合法用户仍然可以与您的资源交互，同时仍然限制了到达您受保护资源的可疑请求的数量。
```json
{
"Name": "RateLimitSuspiciousUserRequests",
"Priority": 100,
"Action": {
"Block": {}
},
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "RateLimitSuspiciousUserRequests"
},
"Statement": {
"RateBasedStatement": {
"Limit": "10",
"AggregateKeyType": "CUSTOM_KEYS",
"EvaluationWindowSec": 60,
"CustomKeys": [
{
"Header": {
"Name": "Authorization",
"TextTransformations": [
{
"Type": "NONE",
"Priority": 0
}
]
}
}
],
"ScopeDownStatement": {
"AndStatement": {
"Statements": [
{
"LabelMatchStatement": {
"Scope": "LABEL",
"Key": "awswaf:managed:aws:anti-ddos:ddos-request"
}
},
{
"NotStatement": {
"Statement": {
"LabelMatchStatement": {
"Scope": "LABEL",
"Key": "awswaf:managed:aws:anti-ddos:challengeable-request"
}
}
}
}
]
}
}
}
}
}
```
## 场景 4: 可质询的请求在 DDoS 请求被阻止前压垮了您的资源
攻击者可能能够克服质询，导致低度和中度可疑的请求在被阻止为高度可疑请求之前压垮您的服务器。如果一个获取 HTML 页面的 GET 请求给您的服务器带来了足够的负载 (例如一个执行昂贵数据库查询的列表页面)，这可能是一个问题。您有三个选择：
1. **将 DDoS 阻止敏感度从低更新到中 (或高)：** 中度和高度可疑的请求被阻止，理想情况下是在对您的资源产生负面影响之前。将阻止敏感度设置为高也会阻止低度可疑的请求。这限制了被错误识别为中度 (或低度) 可疑 DDoS 请求的合法用户的可访问性，但保持了更广泛的可用性。
2. **通过阻止针对敏感端点的可疑 DDoS 请求来创建替代的软缓解：** 与其一概而论地阻止可质询的低/中度 DDoS 请求，不如创建一个规则，匹配 `awswaf:managed:aws:anti-ddos:ddos-request` 标签，并阻止这些已知请求针对特定的敏感端点。在 Anti-DDoS 托管规则组之后应用以下规则，可以阻止已识别的 DDoS 请求访问敏感的 URI 端点 `/products/list`。
```json
{
"Name": "BlockSensitiveEndpointsDDoS",
"Priority": 100,
"Action": {
"Block": {}
},
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "BlockSensitiveEndpointsDDoS"
},
"Statement": {
"AndStatement": {
"Statements": [
{
"ByteMatchStatement": {
"FieldToMatch": {
"UriPath": {}
},
"PositionalConstraint": "EXACTLY",
"SearchString": "/products/list",
"TextTransformations": [
{
"Type": "NONE",
"Priority": 0
}
]
}
},
{
"LabelMatchStatement": {
"Scope": "LABEL",
"Key": "awswaf:managed:aws:anti-ddos:ddos-request"
}
}
]
}
}
}
```
3. **在事件期间要求完成 CAPTCHA：** 如果您的资源对 DDoS 攻击特别敏感，或者您对负面影响合法用户零容忍，那么您可以要求完成一个 CAPTCHA。这个 CAPTCHA 会显著增加攻击者的资源成本。在 Anti-DDoS 托管规则组之后添加以下规则，强制用户为匹配事件检测标签 (`awswaf:managed:aws:anti-ddos:event-detected`) 的可质询请求完成 CAPTCHA。合法用户仍然可以与您的资源互动。CAPTCHA 尝试将按标准费率收费。关于 CAPTCHA 以及如何集成的更多细节，可以在这篇 [AWS 网络与内容分发博客文章](https://aws.amazon.com/blogs/networking-and-content-delivery/protect-against-bots-with-aws-waf-challenge-and-captcha-actions/) 中找到。
```json
{
"Name": "CAPTCHADDoSEvent",
"Priority": 8,
"Action": {
"Captcha": {}
},
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "CAPTCHADDoSEvent"
},
"Statement": {
"AndStatement": {
"Statements": [
{
"LabelMatchStatement": {
"Scope": "LABEL",
"Key": "awswaf:managed:aws:anti-ddos:event-detected"
}
},
{
"LabelMatchStatement": {
"Scope": "LABEL",
"Key": "awswaf:managed:aws:anti-ddos:challengeable-request"
}
}
]
}
}
}
```
## 结论
在本文中，我们描述了新的 AWS WAF Anti-DDoS 托管规则组如何使用软缓解和硬缓解措施，在资源可用性与合法用户的用户体验之间实现平衡。我们描述了在使用这些缓解措施与不同客户端时常遇到的情况，并解释了即使客户端无法支持质询，如何有效地在用户体验与缓解效果之间进行权衡。
如果您仍然担心自己应对复杂 DDoS 威胁的能力，可以考虑 [AWS Shield Advanced](https://aws.amazon.com/shield/) 。Shield Advanced 提供 24/7 全天候访问 Shield 响应团队 (SRT) 的权限，他们将与您合作，为特定的 DDoS 威胁部署定制的缓解措施。
## 关于作者
### David MacDonald
David 是一名高级解决方案架构师，专注于帮助新西兰的初创公司构建安全且可扩展的解决方案。他的大部分职业生涯都在构建和运营服务于各行各业的 SaaS 产品。
### Joanna Knox
Joanna 是 AWS 在澳大利亚悉尼的一名高级云支持工程师。她拥有网络工程、应用交付和安全方面的背景，专注于帮助客户构建能够抵御 DDoS 和其他安全威胁的弹性架构，并帮助正遭受 DDoS 攻击的客户。工作之余，她喜欢打碟和烹饪。
<!-- AI_TASK_END: AI全文翻译 -->