Published on

GA4 の参照元に block.sse.cisco.com が現れた ― referrer 一個から Cisco Secure Access と Talos 未分類を辿る

Authors
  • avatar
    Name
    muzzledskr
    Twitter

この記事は何か

GA4 の参照元レポートに、見慣れないドメインが一件だけ立っていた。block.sse.cisco.com / referral。
blockSseCisco

参照元スパムやリファラ汚染への対処記事は世に多いが、この記事はそれではない。これは Cisco Secure Access（SSE）が返す ブロックページのドメインであり、それが referrer として自サイトの計測に乗る、という具体ケースを一件ぶん機序ごと辿る。しかも SSE は自分が業務で運用する側の製品でもある。運用者として日々設定している挙動を、今度は「弾かれた側 = 自分のブログ」の analytics から逆算して観測することになった。

途中で一度、原因を取り違えている。その仮説と、それを否定した根拠も含めて残す。結論だけ知りたい人は最後の一段でいい。

なお、扱うのは個人ブログ（Cloudflare Pages ホスティング、独自ドメイン）の計測データに限る。どこかの企業ネットワークの内部構成には踏み込めないし、踏み込まない。分かるのは自分の側に落ちてきたログだけである。

発端：参照元に一件だけ立った SSE ドメイン

GA4 の acquisition レポート。ユーザーの最初の参照元／メディア別に、(direct) / (none)、(data not available) に並んで block.sse.cisco.com / referral が一件。セッション側にも同じドメインが少数、下位に出ていた。

まず (data not available) について。GA4 は Google シグナルが有効かつ件数が極小のとき、個人が特定されうる行を伏せる。これが データのしきい値（thresholding） で、レポート上の警告アイコンがそのサイン。今回のような単発アクセスをディメンションで割ろうとすると、ほぼ確実に伏字化する。ここは本題ではないので先へ進むが、「件数1のセッションをページ単位で追う」には UI では限界があり、レポート用識別子をデバイスベースに寄せるか、BigQuery export で生イベントを見る必要がある、とだけ書いておく。

本題は block.sse.cisco.com の方だ。

block.sse.cisco.com とは

Cisco Secure Access（SSE ＝ Security Service Edge）が、ドメインや URL をブロックしたときに、本来のページの代わりに返すブロックページのドメインである。DNS レイヤのフィルタや SWG（Secure Web Gateway）がブロックを判断すると、Secure Access の DNS サーバがこのページを表示する。

セキュリティイベントの種別に応じてサブドメインが分かれており、一般ブロックが block.sse.cisco.com、フィッシング判定が phishing.block.sse.cisco.com、マルウェア判定が malware.block.sse.cisco.com といった具合になる（一次情報は末尾）。

つまり referrer に block.sse.cisco.com が乗ったということは、SSE 配下のどこかのネットワークから来た誰かのブラウザが、一度このブロックページを経由している、ということだ。

最初の仮説：ChatGPT DLP 説（そして誤り）

最初に立てた筋はこうだった。

「業務で ChatGPT を使う → ChatGPT が自分の記事をヒットさせる → 社内の Cisco が弾く」。

裏取りのつもりで Cisco の公式手順を読むと、まさに DLP で ChatGPT を制限する設定のドキュメントがある。プロンプトやレスポンスにソースコードが含まれていたらブロックし、block.sse.cisco.com のブロックページを返す、という内容だ。トラブルシュートの節にもブロックページのドメインが明記されている。ドメインが一致している。これか、と思った。

だがこれは referrer の成立条件と噛み合わない。

GA4 で 参照元 / referral が立つには、ブラウザがブロックページ上にいて、そこから自サイトへ遷移し、その遷移の Referer にブロックページが乗る、という物理が必要になる。これが起きるのは、ブロックページに「Continue / 続行」ボタンがあり（＝ Warn ルール、あるいはカテゴリフィルタの警告）、かつ 本来リクエストしていた宛先が自サイトだった場合に限られる。続行を押すと自サイトに着地し、Referer にブロックページが記録される。

DLP-on-ChatGPT ルールは、発火する宛先が ChatGPT のエンドポイントであって、自サイトではない。ブロックは ChatGPT の応答を潰す方向に働き、そこから muzzledskr.dev へ遷移する動線は生まれない。したがって、この経路では自サイトへの referrer は立たない。ドメインが同じでも、機序が違う。

補強として、もう一つ観測がある。仮に「ChatGPT が記事リンクを出す → クリックして遷移」なら、referrer は普通 chatgpt.com / referral（またはリンク仕様次第で direct）になるはずだ。しかし自サイトの参照元一覧に chatgpt.com は出ていなかった。ChatGPT を発見経路とする素直なクリック流入の痕跡は、少なくとも referrer 上には無い。

DLP 説は、ドメインの一致に引っ張られた誤りだった。宛先が違う。

何が起きていたか：カテゴリ／レピュテーションフィルタ

referrer の署名が指しているのは、DLP ではなく 自ドメインそのものが URL／コンテンツカテゴリのフィルタ（SWG）に触れた線である。

整理すると、辻褄が合うのはこの順序だ。

  1. 誰かが（発見経路は不明。ChatGPT でも検索でもいい）muzzledskr.dev の URL を得る
  2. SSE 配下の環境から直接アクセスしようとする
  3. SWG がこのドメインを「未分類／個人サイト」等のカテゴリで警告またはブロックし、block.sse.cisco.com のページを返す
  4. 続行して着地する
  5. その遷移の Referer にブロックページが乗り、GA4 に block.sse.cisco.com / referral として記録される

発見経路が ChatGPT かどうかは referrer からは判別できない。referrer から確実に言えるのは、「SSE 配下で、自ドメインがフィルタに触れた」という一点だけである。ここは推測と事実を分けておく。

Talos で裏取り

では、なぜ触れたのか。
Cisco の判定は Talos の脅威インテリジェンスに紐づくので、talosintelligence.com のレピュテーションセンターで自ドメインの分類を確認できる。結果は明快だった。

talos_setting

  • CONTENT CATEGORY：No established content categories（カテゴリ未設定）
  • WEB REPUTATION：Unknown（評価未確立）
  • ADDED TO BLOCK LIST：No（Talos のブロックリストには非掲載）
  • NETWORK OWNER：Cloudflare Inc.

読み取れるのは、「危険サイト認定」ではなく 「Talos がまだ分類していない新顔」 という状態だ。Malicious でも Suspicious でもなく、単に評価が存在しない。Talos がリストで明示ブロックしているわけでもない。

つまりブロック／警告は Talos 由来ではなく、各社の SWG が自前ポリシーで「未分類ドメインはデフォルトで警告／ブロック」を敷いている結果と考えるのが妥当になる。個人が新しく立てた .dev ドメインは、この既定ポリシーに嵌まりやすい。加えてホスティングが Cloudflare の共有インフラなので、ドメイン単体の評価が無いと広いレンジの一般評価に丸められ、未分類がより固定されやすい。

referrer 一個から立てた「未分類ゆえの既定ブロック」という仮説が、これで一次情報側から裏付けられた。

対処と、今回の判断

Talos のページには Submit Content Categorization Ticket があり、reclassification を申請できる。技術ブログなら妥当なカテゴリ候補は Computers and Internet や Information Technology あたりで、これらは多くの企業の既定許可カテゴリに入るため、申請が通れば社内網からも素直に読まれる可能性が上がる。Web Reputation 側（Submit Web Reputation Ticket）は Unknown のままでも実害は薄いので、急ぐなら Content Categorization だけでいい。

ただ、今回は申請せず、一旦そのまま未設定にしておくことにした。

分類されれば読まれやすくなる。それは分かっている。一方で、未分類のままだと「一部の企業網からは特殊な弾かれ方をしてから届く」という状態が残る。読まれることを最大化するなら申請、誰がどの経路でどう到達するかを観測材料として残すなら放置、という単純なトレードオフで、今は後者を選んだ、というだけの話だ。動機としては前者の方が真っ当なので、この選択が続くかどうかは自分でも分からない。

まとめ

referrer は一個だった。そこから辿れたのは、SSE のブロックページの機序、DLP との取り違えとその否定、そして Talos 上で自ドメインがまだ無名であるという事実である。

普段は運用する側として設定している SWG の挙動が、今回は自分のブログの計測に落ちてきた一行として観測できた。自分の analytics を、自分が業務で扱う製品の目で読むと、参照元レポートの一行が机上の仕様の実測になる。得られた結論は小さいが、経路は残しておく価値があった。

参照（一次情報）

Discuss on Twitter • View on GitHub