Amazon WAF Bot Control是亚马逊云科技的一款安全防护工具，可以提供对常见且普遍存在的机器人流量（如爬虫、扫描器和爬虫）的可见性和控制。下文将详细介绍Amazon WAF Bot Control识别并允许合法的SEO爬虫和业务机器人，同时阻挡恶意bot，同时逐步介绍从测试到生产环境逐步部署Bot Control的操作指南。
亚马逊云科技官网：点击直达（注册立享200+免费服务）
说明：新用户注册免费计划或付费计划均可直接获得$100美元服务抵扣金，通过完成5个入门学习任务，可额外获得每个任务20美元的服务抵扣金，总共获得最高$200美元服务抵扣金。抵扣金可用来抵用付费套餐和免费套餐的超出部分。
一、Amazon WAF Bot Control识别合法SEO爬虫和业务机器人的方式
Amazon WAF Bot Control托管规则组提供两个级别（inspection level）的保护：
- Common级别：检测自我标识的机器人，如爬虫、搜索引擎、生成式 AI 应用等，通过分析请求中的User-Agent标头等信息来识别常见机器人，标签化流量并阻止无法验证的机器人；
- Targeted级别：包含Common级别的保护，并针对高级机器人提供额外检测，通过速率限制、CAPTCHA和 JavaScript挑战（Challenge） 来缓解机器人活动。
Common Bot Control负责识别并标记合法 SEO 爬虫和业务机器人请求；Targeted Bot Control并不会对 Common Bot Control标记的合法SEO爬虫和业务机器人活动进行干预。
1、通过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 策略。
扩展阅读：《网站robots.txt文件全面解析》
2、使用反向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 验证。
3、标记而非阻止合法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 查询。该请求有可能是非法的，也有可能是合法的；
- 可以在下面截图所示的位置看到 Bot Control 托管规则组所支持的所有标签。如果业务需要可以使用这些标签配置合适的 Scope-down 规则。
在使用 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 标签的请求，以免误拦。
四、部署Amazon WAF Bot Control的步骤和测试SEO爬虫的方法在正式部署新功能之前有必要进行充分的测试。官方推荐使用 Route53 健康检查在测试环境中进行 Bot Control 测试和监控。它是我们可以控制的合法业务机器人，能够通过反向 DNS 查询验证。网站所有者也可以通过向搜索引擎添加索引的方式来产生合法机器人活动。
亚马逊云科技提供的原生安全仪表盘可以提供机器人活动的可见性，一站式集中日志管理和分析平台解决方案 “日志通”（Centralized Logging with OpenSearch, CLO） 可以帮助我们监控和分析 WAF 日志，精准地排错。下文也将基于 CLO 介绍观测方法。
如下图所示，直接在 CLO 仪表板里过滤带有 awswaf:managed:aws:bot-control:bot:verified 标签的请求。从过滤结果我们可以观察到，Route53 健康检查的请求全都通过 Bot Control 托管规则组的检查，最后命中 Web ACL 默认的 Allow 动作（下图绿色的 bar）。这说明 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” 等关键字。
为了更方便地过滤 User-Agent，建议在 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 等监控面板确认它们都是非法机器人请求。
回退方法：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。
请注意：请先在测试环境中用 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。
相关推荐：
《谷歌E-E-A-T解读：如何利用网站质量评分优化谷歌SEO》
(本文由美国主机侦探原创，转载请注明出处“美国主机侦探”和原文地址！)
微信扫码加好友进群
主机优惠码及时掌握
QQ群号：938255063
主机优惠发布与交流
