Summary

  • Yandex Searchの通信減少は主に検証済みクローラーの消失だった。一方、Yandex.Cloudの観測には通常のアプリ通信と攻撃的な自動処理が混在していた。
  • ある顧客アカウントへの通信がAS200350から消えた後、同じJA4、経路、ヘッダー、User-Agentを持つリクエストが別のロシア系ホスティングASで見つかった。これは観測された一連の通信の移動を裏づけるが、運営者の身元やインターネット全体の状況を証明しない。

自律システム番号（ASN）は、リクエストがどのネットワークから届いたかを示す。しかし、その処理内容や管理者、別のネットワークで継続しているかまでは示さない。10月にYandexの周辺で起きた障害は、この違いをはっきり表した。検索ネットワークとクラウド網の双方で通信量が落ちたものの、そこで動いていた自動処理の役割と残した証拠は同じではなかった。

Cloudflareは10月14日、自社ネットワークのRadarおよびBot Managementのデータを用いた分析を公表した。同社によると、10月11日の通信量はYandex SearchのAS13238で基準値を99％下回り、Yandex.CloudのAS200350では90％下回った。13日も両ネットワークは平常時より86〜90％少なく、14日18時（UTC）の観測では通常の85％まで戻っていた。これは一事業者のネットワーク上の測定値であり、ロシアのインターネット全体を数えたものではない。

障害の背景についても、情報源を分けて扱う必要がある。Yandexはサソヴォ、カルーガ、ウラジーミルの施設で被害とサービス中断があったと公表し、Cloudflareは報告された攻撃を10月7日から11日にかけて記録している。施設への被害はネットワーク容量の低下を説明するが、以前そのネットワークを使っていた各リクエストの操作者を示すものではない。また、他社網で後に観測された通信をYandexが運営していたことも、公開資料からは確認できない。

AS13238の状況は比較的明快だ。Cloudflareが観測した同ASNからのリクエストの99.5％は自動化と判定され、そのボット通信の93.6％は同社の検証済み分類に入った。サンプルにはYandexBot、YandexRenderResourcesBot、YandexImagesが含まれ、検索インデックス作成やページ描画と整合する。Cloudflareによると、障害前にこのASNからニュースサイトへ向かった通信の約90％は、記事を取得するYandexBotだった。通信が途絶えた主な影響は、Yandex検索でのクロールとコンテンツ発見が減ったことだ。ここでの「ボット」は大半が検索サービスを指し、攻撃を意味しない。

Yandex.Cloudのサンプルには、異なる用途が同居していた。Cloudflareはスコア対象リクエストの約95％をボットと分類したが、観測したボット通信に検証済みのものはなかった。それでも、未検証という分類だけで全てが悪意ある通信になるわけではない。リクエストの3分の2近くはウェブサイトへデータを送信し、ソフトウェアや連携機能が大きな割合を占めた。ソフトウェア分野のリクエストは、障害の前後を通じて過半数がHTTP 200を返していた。クラウドASNは顧客の処理を運ぶ。ネットワーク名を個々の処理に対する判定として扱うことはできない。

一方、Cloudflareは攻撃的な特徴を持つ一部の動きが縮小したと報告した。AS200350からのボット通信は約40％減り、WordPressプラグイン探査は90％、スキャナーと判定されたリクエストは93％減少した。同社の顧客によるYandex.Cloud通信のブロックも70％減った。少なくともこの観測範囲では、AS200350から届く活動は確かに途切れた。しかし、それだけでは特定の処理自体が停止したとは言えない。

その点を調べるため、Cloudflareは賭博分野の顧客アカウントに着目した。Yandex.Cloudからこの分野へ送られたボット通信のほぼ全てが、複数のホスト名を持つ同一アカウントを標的にしていたという。10月8日の障害後、AS200350からそのアカウントへの通信はゼロになった。同時にRadistやSelectelを含む別のロシア系ホスティングASから、同じJA4 TLS指紋、珍しいリクエスト経路とヘッダー、独自のUser-Agentを持つ通信が現れた。Cloudflareが賭博アカウント向けに観測したロシア発ボット通信は、障害前の1億6,770万件から期間中の1億7,010万件へ、1.4％増えていた。

国全体の通信曲線を比べるより、この比較は連続性を示す力が強い。旧ASNが見えなくなった時期に、同じ顧客の境界で複数のリクエスト特性が一致したからだ。Cloudflareがこの観測対象の通信は移動したとみる根拠にはなる。ただし結論の範囲は限定的である。全てのボットが移ったこと、管理者の身元、単独の指紋から分かる意図、Cloudflare外のサイトへの通信は示していない。JA4は通信を結びつける手掛かりであり、人間の身元ではない。ソーシャルメディア操作との関係を判断するには、Cloudflare網の外のデータが必要だと同社自身も述べている。

集計値を読む際は分母も明示したい。Cloudflareのデータでは、10月1〜6日に全世界のHTTPリクエストに占める自動化通信の比率は39.4％、11日と13日は39.5％だった。ロシア発HTTPリクエストに占める比率は、基準期間の50.4％から11日の42.2％、13日の42.1％へ下がった。これは観測リクエストに占める割合であり、ボットや操作者の絶対数ではない。世界比率が安定していても、地域比率の低下、特定ASNの崩落、顧客一社に向けた通信の移動は同時に起こり得る。

運用上は、問うべき順序がある。まず事業者への経路が落ちたかを確認する。その次に懸念する挙動が止まったのか、宛先を変えたのか、ホスティング先を替えたのかを見る。後者には時間軸を揃えた基準値、宛先、リクエスト特性の証拠が必要であり、ASN別の総量だけでは足りない。攻撃的な処理が他社網へ移ったとしても、元の通信が落ちれば検索での発見や通常のクラウド顧客に実害が及び得る。

Heng LuのNote 65「Running-Code Primacy」は、ここでは編集上の視点に限って用いる。抽象的なラベルよりも、稼働中の構成要素が実際に何をしているかを見る、という考え方である。Yandex、Cloudflare、今回の障害を裏づける資料ではない。この記事での応用も限定される。ASNのグラフは経路を示し、リクエスト単位の証拠が、その経路で何が行われ、経路が失われた後に何が起きたかを検討する助けになる。

出典：Cloudflareの障害分析、Yandexの10月9日付施設発表、Yandexの10月11日付投資家向け発表、CloudflareのVerified Bots資料、Heng Lu Note 65; Cloudflare Radarのトラフィック画面.