通信元のネットワークが停止し、監視グラフが急に下がる。そのとき、サイトへ届いていた不審なアクセスも収まったと判断してよいのでしょうか。

2026年10月14日に公開されたCloudflareのYandex障害分析は、この判断を考える材料になります。Webサービスの運用では、通信元の変化と、守りたい機能へのアクセスの変化を分けて追う必要があります。

その違いを押さえてから、TLSの特徴をまとめるJA4とリクエストログを、収束判断へどうつなげるかを考えてみましょう。

Yandexの検索通信とクラウド通信では、減少の意味が違う

Yandex SearchのAS13238で減った通信は、ほぼ検索クローラーによるものでした。一方、Yandex.CloudのAS200350では、あるギャンブル事業者向けの通信が途絶えた直後、同じJA4、特徴的なパスやヘッダー、独自のUser-Agentを持つリクエストが別のホスティング網から現れました。Cloudflareの観測は、自動通信の移動を示しています。

ここで区別したいのが、自動化の判定と、不正利用の判定です。Cloudflareのボットスコアは、リクエストが自動化されている可能性を1〜99で表します。数値が低いことだけで、そのアクセスを自分のサービスが拒否すべきかまでは決まりません。

例えば、許可している検索クローラーと、想定外の操作を繰り返すスクリプトでは、同じ自動通信でも運用上の扱いが変わります。まず「どのネットワークから来たか」に加えて、「何のためのアクセスか」を分けるところからですね。

JA4はTLSの特徴で通信をまとめる手掛かりになる

通信元が変わっても、クライアントの実装や設定に由来する特徴は比較できます。JA4は、TLS接続の開始時に送られるClientHelloから、その特徴を取り出すフィンガープリントです。

FoxIOのJA4仕様では、TLSバージョン、暗号スイートや拡張の数、ALPNなどを使い、暗号スイートの一覧などを整列してハッシュ化します。送信元IPアドレスを識別子にする仕組みではないため、IPが変わった通信を比較する手掛かりになります。

ただし、JA4には利用者の身元を証明する情報は含まれません。同じ接続特性を持つ別のクライアントが同じ値になることも、仕組みから分かります。そこで、アクセス先のパス、HTTPメソッド、ヘッダー、時間帯を重ねて、関連する通信かを絞り込みます。

JA4の一致は調査の入口、と考えると扱いやすいですね。値が一致しただけで攻撃者や運用主体まで特定することはできません。

監視の集計軸をアクセス先に置き、ASNを横断して比べる

この事例を自サイトの運用へ落とし込むなら、調査対象のエンドポイントを先に固定する方法が考えられます。障害前後で同じ長さの時間窓を取り、そのパスへ届く通信を全ASNで集計したうえで、通信元の内訳を比較します。これは事例から導く監視設計の提案です。

例えば、不審な通信を調べるために特定ASNのフィルターをかけていたなら、一度その条件を外します。そのうえで、特徴的なパスとUser-Agent、取得できる場合はJA4を組み合わせます。「元の通信元では減ったが、同じ特徴の通信は別の場所から届いているか」を確かめるためです。

CloudflareのJA3/JA4ドキュメントでは、フィンガープリントを分析画面やログで利用できます。ただし、Cloudflareでの提供はBot Managementを購入したEnterprise顧客向けです。非TLS通信などでは値が欠けるため、JA4がある行だけを集計すると、調査対象から外れる通信が生じます。

そのため、JA4がない通信も別に残し、パス、メソッド、User-Agentで比較を続けます。取得できる項目に合わせて監視を組み立て、欠損を「不審な通信なし」と扱わないことがポイントです。

遮断条件は正常な通信との重なりを見てから絞る

関連する通信が見つかったら、次は対処する範囲を決めます。CloudflareのBot Feedback Loopの案内は、IP、JA3、ASN、User-Agentなどの特徴を組み合わせた対処を挙げ、JA3で遮断やレート制限を行う前に正常な通信との重なりを調べるよう求めています。

JA4を使う場合も、TLSの特徴だけで広く遮断する前に、対象パスで何が行われているかを確かめたいところです。例えばログイン機能なら、同じ特徴のアクセス群について認証の成功・失敗や頻度を照合し、通常利用を巻き込まない条件へ絞る、という順序が考えられます。これは一律の推奨設定ではなく、サービス側のログと要件に合わせる判断です。

なお、今回の観測対象はCloudflareのネットワーク上の通信です。SNS上の活動全体や、実行者の身元まで断定できる分析ではありません。分析の対象と限界を踏まえて、自サイトのログで判断する必要があります。

冒頭の問いに戻ると、通信元のグラフが下がっただけでは、対処を終える材料が足りません。守りたいエンドポイントへの不審な操作が減ったか、正常な利用を維持できているかまで追うことで、通信元の変化に左右されにくい収束判断につながります。

出典

• Title: Yandex outage: Data shows that instead of going dark, malicious bots went on the move
• URL: https://blog.cloudflare.com/yandex-outage/