はじめに（この記事で分かること）#

Cloudflareを入れるとoriginサーバーのIPアドレスが隠れる。この理解は正しいが、十分ではない。faviconハッシュ、DNS履歴、証明書ログ、メールヘッダ、非プロキシのサブドメイン——これらの痕跡から、originのIPアドレスは探索される。

Shodan/Censysの記事で説明したSSH鍵とfaviconハッシュの相関は、この記事で説明するorigin IP探索の一部だ。この記事では、探索の7経路を攻撃者の視点で整理し、各経路の対策を対にして示す。

前提: 脅威モデルの整理#

origin IPを探索する相手は、脅威モデル入門で整理した5種類の相手のうち、主に2者だ。

攻撃者は、originサーバーを直接攻撃するためにorigin IPを探す。CDNを通した攻撃はレート制限やWAFで防げるが、originを直接攻撃されるとこれらの防御を迂回される。

セキュリティ研究者やペネトレーションテスターも、同じ手法を使って組織のインフラを把握する。

7つの探索経路#

経路1: faviconハッシュ#

サイトのfavicon.icoをMurmurHash3でハッシュ化し、Shodanでhttp.favicon.hash:<値>を検索する。同じfaviconを使っている全サーバーが一覧で表示される。

Hive Securityの分析では、1つのfaviconハッシュから、ある組織の全インフラ（363ホスト、373 IP、5,091開放ポート）が一括で特定された。

Cloudflareで隠している場合でも、originサーバーがCloudflareを通さずにfaviconを配信している場合（例: 直接IPでアクセスした場合）、Shodanはそのfaviconを収集する。

経路2: DNS履歴#

SecurityTrailsなどのDNS履歴サービスは、ドメインの過去のAレコードを記録している。Cloudflareを導入する前のorigin IPが履歴に残っている場合、そのIPはすでに公開されている。

経路3: 証明書ログ#

Certificate Transparency（CT）ログは、発行されたすべてのTLS証明書を記録する。crt.shでドメインを検索すると、過去に発行された全証明書の一覧が表示される。

originサーバーに本物のドメイン名が含まれた証明書を直接443で提示している場合、そのサーバーは「自分の住所をCTログに公開している」のと同じだ。CensysやShodanはCTログを検索して、証明書のSANとIPアドレスを相関する。

経路4: 非プロキシのサブドメイン#

mail.example.com、dev.example.com、staging.example.comなどのサブドメインがCloudflareのプロキシを通さずにoriginサーバーを直接指している場合、そのサブドメインのDNSレコードからorigin IPが判明する。

MXレコード（メールサーバー）はCloudflareのプロキシを通せないため、必ずoriginまたは別のメールサーバーのIPを露出する。

経路5: Google Analytics IDの相関#

Google AnalyticsのトラッキングID（UA-XXXXX-Xなど）をShodanで検索すると、同じIDを使っている全サーバーが一覧で表示される。originサーバーがCloudflareの裏でGoogle Analyticsスクリプトを読み込んでいる場合、originのIPがShodanのデータベースに記録されている可能性がある。

経路6: CSPヘッダ#

Content-Security-PolicyヘッダにoriginサーバーのIPや内部ドメインが含まれている場合、Shodanはこのヘッダを収集して検索可能にする。

経路7: メールヘッダ#

originサーバーから直接メールを送信した場合、Received:ヘッダにoriginのIPアドレスが記録される。このヘッダは受信者だけでなく、メールヘッダ分析ツール（MXToolboxなど）で誰でも確認できる。

対策#

経路対策
faviconハッシュサーバーごとに別のfaviconを使う。originとclearnetで別物にする
DNS履歴CDN導入前のIPが履歴に残っている場合、サーバーのIPを変更する
証明書ログoriginの443で本物のドメイン名入り証明書を直接提示しない。CDN専用のSNIで返す
非プロキシのサブドメインすべてのサブドメインをCDNプロキシ経由にする。メールは外部サービスを使う
Analytics IDサイトごとに別のAnalytics IDを使う。または匿名性重視のサイトではGAを使わない
CSPヘッダoriginのIPや内部ドメインをCSPに含めない
メールヘッダoriginから直接メールを送らない。外部のメール送信サービス経由にする

限界と残るリスク#

origin IPの隠蔽は、IPアドレスを隠すだけで、人を匿名化するわけではない。決済の痕跡、ドメイン登録、アカウント情報は別の問題として存在する。決済手段の匿名化はVPNを匿名で支払う方法で、ドメインの匿名取得はWEBサイトを匿名で運営するで扱う。

originが見つからない状態でも、originサーバー自体の脆弱性は存在する。originに到達できる攻撃者は、CDNの防御を迂回して直接攻撃できる。originの硬化（パッチ適用、最小権限、ファイアウォール）は、origin IPの隠蔽と並行して行う必要がある。

まとめ#

CDNでorigin IPを隠すことは、攻撃面を縮小する第一段階だ。しかし、faviconハッシュ、DNS履歴、証明書ログ、非プロキシのサブドメイン、メールヘッダのいずれか一つが露出していれば、originは特定される。

自分のインフラを守るには、攻撃者と同じツール（Shodan、crt.sh、SecurityTrails、faviconハッシュ計算）を使って、自分のoriginが露出していないかを定期的に確認する。

origin IPの隠蔽と、SSHを公開しない設計は、別の課題として扱う。SSHの公開を回避する構成は、踏み台サーバーとWireGuardでSSHを公開しないで扱う。

出典#