Summary

  • Cloudflare 观察到，Yandex Search 流量骤降主要体现为已验证爬虫消失；Yandex.Cloud 样本中则同时有普通云应用和带有攻击特征的自动化请求。
  • 来自其他俄罗斯托管 ASN 的一组请求，与此前指向某个客户账户的请求具有相同 JA4、路径、请求头和用户代理特征。这支持“该组观测到的流量发生迁移”，但不能识别运营者，也不能代表整个互联网。

自治系统编号（ASN）说明请求从哪个网络到来。它本身无法说明请求在做什么、由谁控制，或相关活动是否已从别处继续。10 月 Yandex 周边的网络中断恰好呈现了这种边界：搜索网络和云托管网络都失去大量流量，但它们承载的自动化任务并不相同，留下的证据也不同。

Cloudflare 于 10 月 14 日发布分析，依据是其自身网络中的 Radar 和 Bot Management 数据。该公司称，10 月 11 日，Yandex Search（AS13238）的流量比基线低 99%，Yandex.Cloud（AS200350）低 90%。到 10 月 13 日，两者仍比正常水平低 86% 至 90%；截至 10 月 14 日 18:00 UTC，Cloudflare 观察到流量恢复至正常水平的 85%。这些是单一服务商的网络测量，并非俄罗斯互联网的普查结果。

中断的背景也需要谨慎归因。Yandex 公开表示，其萨索沃、卡卢加和弗拉基米尔设施遭到破坏并发生服务中断；Cloudflare 把这些已报道的袭击列在 10 月 7 日至 11 日之间。物理设施受损有助解释网络为何失去容量，却不能识别此前使用这些网络的每项请求由谁发起，也不能证明后来从其他托管商出现的请求由 Yandex 运营。

AS13238 的情况较易理解。Cloudflare 把该 ASN 的 99.5% 观测请求判定为自动化，并把其中 93.6% 的机器人请求列为已验证。采样中包括 YandexBot、YandexRenderResourcesBot 和 YandexImages，符合搜索索引及页面渲染行为。Cloudflare 称，中断前从该 ASN 发往新闻网站的流量约有 90% 是 YandexBot 抓取文章。该网络掉线后，直接影响是 Yandex Search 的抓取和内容发现减少。这里的“机器人”主要指正常执行索引任务的搜索服务，而不是攻击者。

Yandex.Cloud 样本要复杂得多。Cloudflare 称，其评分请求中约 95% 属于机器人，但观察到的机器人请求没有一个通过该公司的验证。这并不等于每条请求都是恶意行为。接近三分之二的请求向网站发送数据，软件和集成服务流量占比较大；软件行业的大多数请求在中断前后均返回 HTTP 200。云 ASN 承载客户工作负载，网络标签不能代替对每个工作负载的行为判定。

Cloudflare 的确观察到若干攻击型特征活动骤减：来自 AS200350 的机器人流量约下降 40%，WordPress 插件探测下降 90%，识别为扫描器的请求下降 93%，针对 Yandex.Cloud 流量的客户拦截下降 70%。就 Cloudflare 的观测范围而言，这些来自该 ASN 的活动确实中断了。但这尚不能回答具体任务是否停止。

为回答这个问题，报告追踪了一个博彩行业客户账户。Cloudflare 称，Yandex.Cloud 在该行业的大部分机器人请求都指向这个账户的多个主机名。10 月 8 日中断之后，来自 AS200350、发往该账户的请求降为零。与此同时，Cloudflare 在 Radist、Selectel 等俄罗斯托管 ASN 上观察到具有相同 JA4 TLS 指纹、罕见路径和请求头、自定义 User-Agent 的请求。其博彩客户样本中的俄罗斯机器人总请求量从事件前的 1.677 亿升至事件期间的 1.701 亿，增长 1.4%。

与国家级总流量曲线相比，这是一组更有针对性的连续性证据：当原来源 ASN 沉寂时，同一个受保护账户上出现了多种请求特征相符的流量。它支持 Cloudflare 对这组观测流量已迁移的判断，但结论必须限定。它不能证明全部机器人都迁移、识别运营者、仅凭单一指纹判断意图，或覆盖 Cloudflare 网络之外的网站。JA4 可以作为追踪线索，却不是人的身份。Cloudflare 自己也指出，若要判断这是否与社交媒体操纵有关，需要其网络之外的数据。

总体占比同样需要把分母写清楚。Cloudflare 报告称，10 月 1 日至 6 日，自动化请求占其全球 HTTP 请求量的 39.4%；10 月 11 日和 13 日分别为 39.5%。俄罗斯来源请求中的自动化比例则从 50.4% 降至 10 月 11 日的 42.2%、13 日的 42.1%。这些是已观测请求的比例，不是全球机器人或操作者的绝对数量。全球占比稳定，可以与地区占比下降、一个 ASN 流量崩塌、某个客户上的任务迁移同时发生。

运营上的教训是把几个问题分开。故障发生时，首先要判断供应商路径是否中断；随后要核实令人担忧的行为是停止了、改变了目标，还是换了托管网络。后一个判断需要时间对齐的基线，以及与目标和请求特征关联的证据，不能只看 ASN 总量。即使某项攻击型自动化后来换了网络，来源 ASN 的骤降仍可能严重影响搜索发现和依赖云服务的普通客户。

Heng Lu 的第 65 篇笔记《Running-Code Primacy》在本文中仅作为编辑视角：判断系统应看已部署组件实际做了什么，而不是把抽象标签当成行为证据。它不是 Yandex、Cloudflare 或这次事件的事实来源。本文只借用一个有限的判断方法：ASN 图表用于定位路径；请求级证据才帮助说明流经该路径的行为，以及路径中断后发生了什么。

来源：Cloudflare 事件分析；Yandex 10 月 9 日数据中心声明；Yandex 10 月 11 日投资者公告；Cloudflare 已验证机器人说明；Heng Lu 第 65 篇笔记; Cloudflare Radar 流量页面.