亚马逊云科技 WAF 部署小指南（九）利用 Amazon WAF Bot Control 增强网站安全与搜索引擎优化（SEO）表现

WAF Bot Control 作为一个强大的防护工具，可以有效阻止恶意爬虫和 HTTP Flood 攻击，保护网站安全。然而，随着数字营销的发展，企业不仅关心网站安全，还要考虑 SEO 带来的流量。许多人担心 Bot Control 会误拦搜索引擎爬虫，从而影响网站的搜索排名和可见度。本文将详细介绍 WAF Bot Control 如何识别并允许合法的 SEO 爬虫和业务机器人，同时阻挡恶意 bot。并分享如何通过测试和监控，确保 SEO 推广不受 Bot Control 规则的影响，使得企业可以在保障网站安全与优化搜索引擎表现之间取得平衡，充分发挥 Bot Control的优势。

Bot Control 识别合法 SEO 爬虫和业务机器人的方式

Bot Control 托管规则组提供两个级别（inspection level）的保护：

• Common 级别：检测自我标识的机器人，如爬虫、搜索引擎、生成式 AI 应用等，通过分析请求中的 User-Agent 标头等信息来识别常见机器人，标签化流量并阻止无法验证的机器人。
• Targeted 级别：包含 Common 级别的保护，并针对高级机器人提供额外检测，通过速率限制、CAPTCHA 和 JavaScript 挑战（Challenge） 来缓解机器人活动。

Common Bot Control 负责识别并标记合法 SEO 爬虫和业务机器人请求；Targeted Bot Control 并不会对 Common Bot Control 标记的合法 SEO 爬虫和业务机器人活动进行干预。

如何通过 User-Agent 标头识别合法 SEO 爬虫和业务机器人

合法爬虫，如 Googlebot 和 Bingbot，通常使用特定的 User-Agent 字符串进行自我标识。例如，Googlebot 会包含 “Googlebot” 或 “Google” 字样，而 Bingbot 则包含 “Bingbot” 或 “Bing“。Common Bot Control 利用这些独特的标识符来识别来自合法搜索引擎的爬虫。不仅限于搜索引擎爬虫，Common Bot Control 还能识别其他类别的合法机器人，例如用于广告和网站排名的应用程序。Amazon WAF 开发人员指南：机器人控制功能规则列表列出了 Common Bot Control 能够识别的所有类别的机器人。这些不同类别的合法机器人所使用的特定 User-Agent 字符串可以很容易地在互联网上查找到。通过了解和利用这些标识符，网站管理员可以更好地区分合法爬虫和潜在的恶意机器人，从而优化其 Bot Control 策略。

使用反向 DNS 查询验证 User-Agent 的真实性

仅通过 User-Agent 并不足以完全保证它们的真实性，因为恶意爬虫可以伪造 User-Agent 字符串。因此，Common Bot Control 结合反向 DNS 查询等其他验证手段，确保请求确实来自合法的来源。

下面是从真实的 WAF 日志中截取的一部分，IP 地址为 15.177.X.X 的客户端通过 User-Agent 声明它是一个 Amazon Route53 健康检查机器人。

"clientIp": "15.177.X.X",
{
  "name": "User-Agent",
  "value": "Amazon-Route53-Health-Check-Service (ref 28f86b0e-5b01-4b0e-xxxx-307bxxxxxxxx; report http://amzn.to/1vsZADi)"
}

这个请求会命中 Common Bot Control 托管规则组的 CategoryMonitoring 规则。CategoryMonitoring 规则自动执行反向 DNS 查询操作对 User-Agent 的真实性进行验证。我们手工进行一次反向 DNS 查询来解释它的原理：

% dig -x 15.177.X.X +short  # Windows 使用 nslookup 15.177.X.X 命令
ec2-15-177-X-X.eu-west-1.compute.amazonaws.com.

这个客户端的域名以 amazonaws.com 结尾，Common Bot Control 因此能够判断它来自于亚马逊云科技平台。虽然它的格式与 Amazon Elastic Compute Cloud（Amazon EC2）实例的域名格式相同，但 Common Bot Control 能够通过域名中的 ec2-X-X-X-X 部分得知它是一个 Route53 健康检查 agent，能够确认它的 User-Agent 是真实的。如果无法通过 IP 地址查询到域名，或者查询到的域名不属于它所声明的组织（在本例中是 Amazon）和用途（在本例中是 Route53 健康检查)，则说明它的 User-Agent 是伪造的。相应的 Common Bot Control 规则不会对伪造 User-Agent 的请求采取任何动作，而是将该请求传递给后续的 Common Bot Control 规则继续进行检查，直到它命中最后一条 Common Bot Control 规则 SignalNonBrowserUserAgent。

需要说明的是，Common Bot Control 并不会对所有的自我标识的机器人请求执行反向 DNS 查询的验证操作。对于那些来自于个人终端设备的机器人请求（例如 Whatsapp），或者不属于某个特定组织的机器人请求（例如 Okhttp），它们的 IP 地址不可能拥有一个由某个特定组织注册的 DNS 域名，所以对它们执行反向 DNS 查询没有意义。相应的 Common Bot Control 规则会直接对这些无法验证 User-Agent 真实性的请求执行该规则的默认动作，通常是 Block。

如果 Web 应用程序在 WAF 前面部署了反向代理服务，例如内容分发网络（CDN），WAF 看到的 TCP 源 IP 地址都属于反向代理服务器，但可以从X-Forwarded-For 标头中获取机器人的 IP 地址并执行反向 DNS 验证。

标记而非阻止合法 SEO 爬虫和业务机器人的请求

对于通过了验证的机器人请求，Common Bot Control 的相关规则不对该请求采取任何动作，但它会添加机器人名称和类别标签（Label）以及标签 awswaf:managed:aws:bot-control:bot:verified。Bot Control 托管规则组对该请求的检查就此结束。如果 Web ACL 的后面还有其他 WAF 规则，则继续对该请求进行相应的检查，直到命中后续的 WAF 规则或者命中 Web ACL 最末尾的默认 Allow 动作。

在上面的例子中，Common Bot Control 通过反向 DNS 查询验证其 User-Agent 是真实的，所以它为该请求标记了三个标签并且记录到 WAF 日志：

"clientIp": "15.177.X.X",
{
  "name": "User-Agent",
  "value": "Amazon-Route53-Health-Check-Service (ref 28f86b0e-5b01-4b0e-xxxx-307bxxxxxxxx; report http://amzn.to/1vsZADi)"
},
"labels":[
{"name":"awswaf:managed:aws:bot-control:bot:verified"},  # Verified 标签
{"name":"awswaf:managed:aws:bot-control:bot:category:monitoring"},  # 机器人类别标签
{"name":"awswaf:managed:aws:bot-control:bot:name:route53_health_check"}]}  # 机器人名称标签

如果反向 DNS 查询的结果表明其 User-Agent 是伪造的，最后一条 Common Bot Control 规则 SignalNonBrowserUserAgent 会为该请求添加 awswaf:managed:aws:bot-control:signal:non_browser_user_agent 标签，并对其执行规则动作（默认 Block）。

对于那些进行了自我标识，但其 IP 地址不可能拥有某个特定组织注册域名的机器人请求（例如 Whatsapp 或 Okhttp），Common Bot Control 规则不对其执行反向 DNS 查询，直接为该请求添加机器人名称和类别标签以及标签 awswaf:managed:aws:bot-control:bot:unverified，并对其执行规则动作（默认 Block）。例如，某个请求的 User-Agent 是 okhttp/4.12，它会命中 Common Bot Control 托管规则组的 CategoryHttpLibrary 规则。CategoryHttpLibrary 规则不做反向 DNS 查询，直接为该请求添加下面的三个标签，并对其执行规则动作 （默认 Block）。

"labels":[
{"name":"awswaf:managed:aws:bot-control:bot:unverified"},  # Unverified 标签
{"name":"awswaf:managed:aws:bot-control:bot:category:http_library"},  # 机器人类别标签
{"name":"awswaf:managed:aws:bot-control:bot:name:okhttp"}]}  # 机器人名称标签

希望您能够充分理解下面三个常见标签的含义，它们对您观测 WAF Bot Control 至关重要：

• bot:verified：User-Agent 标识该请求由某个特定组织的机器人发起，Common Bot Control 规则对其执行了反向 DNS 查询，并验证其 User-Agent 是真实的。
• bot:unverified：User-Agent 标识该请求由机器人发起，但这个机器人并不属于某个特定的组织，所以 Common Bot Control 规则不对其执行反向 DNS 查询，不验证 User-Agent 真实性。
• signal:non_browser_user_agent 可能有两种情况：
  • User-Agent 标识该请求由某个特定组织的机器人发起，Common Bot Control 规则对其执行了反向 DNS 查询，但验证其 User-Agent 是伪造的。
  • User-Agent 既不是一个浏览器 User-Agent，也不是一个常见的机器人 User-Agent。Common Bot Control 规则不对其执行反向 DNS 查询。该请求有可能是非法的，也有可能是合法的。

截至本文发布时，Common Bot Control 托管规则组能够识别两百多种机器人。您可以在下面截图所示的位置看到 Bot Control 托管规则组所支持的所有标签。如果业务需要，您可以使用这些标签配置合适的 Scope-down 规则。

Figure 1：查看 Bot Control 托管规则组能够识别的机器人种类，以及为它们标记的标签

Bot Control 不对合法爬虫执行 JavaScript 挑战

您在使用 WAF Web Console 为 Web ACL 配置 Bot Control 托管规则组时所看到的规则排列顺序，就是实际执行的规则顺序。WAF 先执行 Common Bot Control，再执行 Targeted Bot Control。上文讲到，对于通过了反向 DNS 查询验证的机器人请求，Common Bot Control 为其添加机器人名称和类别标签以及标签 awswaf:managed:aws:bot-control:bot:verified 之后，Bot Control 托管规则组对该请求的检查就结束了。

虽然这个请求会被继续向后传递给 Targeted Bot Control 规则，但它同时携带着 bot:verified 标记，Targeted Bot Control 有一个内置的 Scope-down 规则，会自动地忽略带有 bot:verified 标记的请求，不对它们做检查。因此，合法 SEO 爬虫和业务机器人不会被 Targeted Bot Control 执行 Challenge 或 CAPTCHA。

根据标签配置后续的 WAF 规则，确保不检查合法的 SEO 爬虫

有些情况下，我们需要在 Bot Control 托管规则组的后边添加额外的自定义规则，进一步地对请求进行检查和处理。我们必须为那些额外的规则配置 Scope-down，不检查带有 awswaf:managed:aws:bot-control:bot:verified 标签的请求，以免误拦。

部署 Bot Control 的步骤和测试 SEO 爬虫的方法

在正式部署新功能之前，有必要进行充分的测试。我们推荐使用 Route53 健康检查在测试环境中进行 Bot Control 测试和监控。它是我们可以控制的合法业务机器人，能够通过反向 DNS 查询验证。网站所有者也可以通过向搜索引擎添加索引的方式来产生合法机器人活动。我们在使用 Amazon WAF 和 Amazon CloudFront 保护您的生成式 AI 应用一文中介绍了 CloudFront 和 WAF 安全仪表盘，这个亚马逊云科技提供的原生安全仪表盘可以提供机器人活动的可见性。另外，一站式集中日志管理和分析平台解决方案 “日志通”（Centralized Logging with OpenSearch, CLO） 可以帮助我们监控和分析 WAF 日志，精准地排错。下文也将基于 CLO 介绍观测方法。如果您希望使用 Amazon Athena 直接查询保存在 Amazon Simple Storage Service（Amazon S3）里的 WAF 日志，您可以从这个 Github repository 找到相关的查询示例。

如下图所示，直接在 CLO 仪表板里过滤带有 awswaf:managed:aws:bot-control:bot:verified 标签的请求。从过滤结果我们可以观察到，Route53 健康检查的请求全都通过 Bot Control 托管规则组的检查，最后命中 Web ACL 默认的 Allow 动作（下图绿色的 bar）。这说明 WAF Bot Control 能够识别并放行合法的自我标识的机器人。

Figure 2：WAF Bot Control 能够识别合法的自我标识的机器人并放行它们的请求

为了进一步验证 Bot Control 确实不会影响 SEO 业务，我们建议采用以下步骤在生产环境中进行渐进式的部署。每个步骤都能够获取充分的观测数据，并且可以随时回退。

阶段一：启用 Common Bot Control，将所有规则的动作设置成 Count，观察 WAF 日志中的 User-Agent，Label 和 Client IP 地址

目标：

• 确认 Common Bot Control 能够识别出合法 SEO 和业务机器人请求并标记bot:verified 标签
• 确认 Common Bot Control 不会错误地将合法 SEO 和业务机器人请求标记成signal:non_browser_user_agent 或者 bot:unverified

观测方法：

按照 Figure 2 所示的方法，在 CLO 仪表盘里过滤带有 bot:verified 标签的请求。CLO 仪表盘支持同时过滤多个关键字，除了 bot:verified，您还可以过滤更具体的机器人类别标签（前提是您的 WAF 日志里存在带有相关关键字的日志条目）。例如：

• awswaf:managed:aws:bot-control:bot:category:search_engine
• awswaf:managed:aws:bot-control:bot:category:content_fetcher
• awswaf:managed:aws:bot-control:bot:category:seo
• awswaf:managed:aws:bot-control:bot:category:advertising
• awswaf:managed:aws:bot-control:bot:category:social_media

然后在 CLO Filters 面板里添加一个 userAgent.keyword 过滤条件，观察那些 Verified 请求的 User-Agent 是否带有 "Google" 等关键字。

Figure 3：添加 userAgent.keyword 过滤条件

为了更方便地过滤 User-Agent，我们建议您根据 亚马逊云科技 WAF 部署小指南 (六) 所介绍的方法，在 CLO Filters 面板里永久添加 userAgent.keyword 过滤条件。

现在，您应该可以确认 Common Bot Control 能够识别出合法 SEO 和业务机器人请求并标记 bot:verified 标签了。接下来，按照同样的方法过滤 signal:non_browser_user_agent 和 bot:unverified 标签，以及带有 “Google” 等关键字的 User-Agent。如果发现日志中存在满足这些条件的请求，我们需要通过 CLO Top Client IPs 监控面板记录它们的 IP 地址，然后通过反向 DNS 查询检查 IP 地址的域名，通过 curl ipinfo.io/<IP_ADDRESS> 命令检查 IP 地址的归属，来判断 Common Bot Control 是否存在误判。

回退方法：

从 WAF Web ACL 移除 Bot Control 托管规则组。

阶段二：将 Common Bot Control 规则的动作恢复成默认，继续观察 WAF 日志

目标：

通过阶段一的观测，您应该已经确认 Common Bot Control 的效果是符合预期的。阶段二的目标是在生产环境正式部署 Common Bot Control 并确认 SEO 等业务不受影响。

观测方法：

修改 Common Bot Control 托管规则的配置，保持 inspection level 为 Common，将各个规则的动作恢复成默认动作。为了避免误拦截非浏览器客户端，还需要单独将 CategoryHttpLibrary 和 SignalNonBrowserUserAgent 两条规则的动作 override 成 Count。接下来，采用和阶段一相同的方法观测 WAF 日志，确认 Common Bot Control 的行为仍然符合预期。

回退方法：

将 Bot Control 托管规则组的动作 override 成 Count，或者从 WAF Web ACL 移除 Bot Control 托管规则组。

阶段三：部署 Targeted Bot Control，将所有规则的默认设置成 Count，观察 WAF 日志，确认 bot:verified 请求没有被执行 Challenge 或者 CAPTCHA

目标：

确认 Targeted Bot Control 托管规则不会拦截合法 SEO 爬虫和业务机器人请求。

观测方法：

修改 Bot Control 托管规则组的配置，将 inspection level 改成 Targeted。将所有名称以 TGT_ 开头的规则动作 override 成 Count。

在 CLO Filters 面板里过滤 Rule AWSManagedRulesBotControlRuleSet，Label bot:verified，Non Terminating Matching Rule Action COUNT（这是 override 之后的规则动作）。如果过滤出来的请求数量为 0，说明 Targeted Bot Control 没有拦截合法 SEO 爬虫和业务机器人请求，符合预期。

然后，在 CLO Filters 面板里过滤 Rule AWSManagedRulesBotControlRuleSet，Label bot:verified，Non Terminating Matching Rule Overridden Action CHALLENGE 和 COUNT 和 CAPTCHA 和 BLOCK（它们是原本的规则动作。如果在下拉菜单里存在就都选上）。如果过滤出来的请求数量为 0，说明 Targeted Bot Control 没有拦截合法 SEO 爬虫和业务机器人请求，符合预期。

回退方法：

修改 Bot Control 托管规则组的配置，将 inspection level 改回 Common。

阶段四：为客户端程序集成 WAF JavaScript/Mobile SDK，观察 WAF 日志，确认合法客户端发起的请求都携带了有效的 token

请注意：请先在测试环境中用 Route53 健康检查或者通过向搜索引擎添加索引的方式制造 bot:verified 机器人请求，完成观测，再到生产环境重复相同的观测步骤。

目标：

经过阶段三的观测，您应该已经确认 Common Bot Control 和 Targeted Bot Control 托管规则都不会拦截合法 SEO 爬虫和业务机器人请求。阶段四的目标是确认集成 WAF SDK 之后，合法客户端发起的请求都携带了有效的 token。

观测方法：

在 CLO 仪表盘里过滤带有awswaf:managed:token:absent标签的请求（这些请求没有携带 token）；同时，按下图所示的方法添加一个 filter，排除带有 bot:verified 标签的请求。如果您的 WAF 规则还配置了 Scope-down，允许某些客户端通过非 WAF SDK 的渠道访问 Web 应用程序，您也需要将它们排除出过滤条件。如果过滤出来的请求数量为 0，说明 WAF SDK 让合法客户端都携带了 token，符合预期。如果您看到了符合过滤条件的请求，请通过观察 Top Client IPs、Top Countries or Regions、Top User Agents、Top Labels with Host, Uri 等监控面板确认它们都是非法机器人请求。

Figure 4：设置过滤条件，确认合法客户端发起的请求都携带了有效的 token

回退方法：

WAF Web ACL 无需回退。但如果观测结果不符合预期，您需要检查并修改客户端 WAF SDK 的代码。

阶段五：将 Targeted Bot Control 规则恢复成默认的动作，确认合法客户端、合法 SEO 爬虫和业务机器人请求都不会被拦截，完成部署工作

作为一个面向所有场景的托管规则，Targeted Bot Control 必须也考虑没有集成 WAF SDK 的场景 – 有可能某个合法客户端发起的第一个请求是 HTTP HEAD 或者 POST 请求。非 GET 请求无法完成原生的 CAPTCHA 或 Challenge，无法获取 token。为了避免误拦截，Targeted Bot Control TGT_TokenAbsent 规则的默认动作是 Count，而 TGT_VolumetricIpTokenAbsent 规则会放行某个 IP 地址在 5 分钟内发起的前 5 个请求，即使那 5 个请求没有携带有效的 token。

但是在集成 WAF SDK 之后，所有由人类发起的请求都会提前完成 Challenge，并携带有效的 token。所以您需要将 TGT_TokenAbsent 规则的动作 override 成 Challenge。如果您还在使用默认版本的 Bot Control 托管规则组，则需要将它的版本改成 Version_3.0。

Figure 5：更改 Bot Control 托管规则组的版本为 Version 3.0

请注意：请先在测试环境中用 Route53 健康检查或者通过向搜索引擎添加索引的方式制造 bot:verified 机器人请求，完成观测，再到生产环境重复相同的观测步骤。

目标：

确认集成 WAF SDK 之后，Targeted Bot Control 不会拦截合法客户端、合法 SEO 爬虫和业务机器人发起的请求；同时，它能够拦截非法机器人的请求。

观测方法：

保持 inspection level 为 Targeted；将所有名称以 TGT_ 开头的规则的动作恢复成默认动作；单独将 TGT_TokenAbsent 规则的动作 override 成 Challenge。

在 CLO 仪表盘里过滤 Rule AWSManagedRulesBotControlRuleSet，以及 Action CHALLENGE。如果过滤出来的请求数量为 0，则符合预期。如果您看到了符合过滤条件的请求，请通过观察 Top Client IPs、Top Countries or Regions、Top User Agents、Top Labels with Host, Uri 等监控面板确认它们都是非法机器人请求。在这个步骤，请勿使用 Action CAPTCHA 作为过滤条件，因为它是一个 terminating action，即使 WAF SDK 能够处理 CAPTCHA 逻辑，相应的请求也会出现在过滤结果中。

使用下面的 cURL 命令制造一个非法机器人请求，然后再次在 CLO 仪表盘里过滤 Rule AWSManagedRulesBotControlRuleSet，以及 Action CHALLENGE。这一次，您应该在过滤结果中看到这个 cURL 请求，因为 cURL 无法完成 Challenge，使得 Challenge 动作变成了一个 terminating action。

# macOS/Linux
curl -vso /dev/null -H "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:130.0) Gecko/20100101 Firefox/130.0" https://<YOUR_URL>
# Windows
curl -vso NUL -H "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:130.0) Gecko/20100101 Firefox/130.0" https://<YOUR_URL>

回退方法：

将所有名称以 TGT_ 开头的规则动作 override 成 Count。

总结

通过阅读本文，您应该已经了解了 WAF Bot Control 如何精准识别并允许合法的 SEO 爬虫和业务机器人，同时有效阻挡恶意 bot。我们还详细介绍了从测试到生产环境逐步部署 Bot Control 的操作指南，确保 SEO 推广不受影响。通过这些策略，企业能够在保障网站安全的同时，优化搜索引擎表现，最大化网站的业务价值。借助 WAF Bot Control，您可以实现安全与流量之间的平衡，推动业务更稳健地发展。更多 WAF SDK 介绍，以及跨 Origin 场景 Cross-origin resource sharing（CORS）策略和 WAF token domain 的问题，请阅读 Using AWS WAF intelligent threat mitigations with cross-origin API access 了解详情，或者联系亚马逊云科技架构师咨询。

本篇作者