はじめに
「CDNのプロキシを通しているから安全」と考えている人は少なくない。だが、CDNの防御が成り立つのは オリジンサーバーのIPアドレスを隠せている場合だけ だ。そしてこの前提は、ホスティング構成によっては最初から崩れていることがある。
この記事では、「契約者にデフォルトのサブドメインを配布するタイプの共有ホスティング」 で起きる構造的な問題として整理する。同じ構成は複数のサービスに共通して存在するため、一般論として理解しておく価値がある。
CDNの防御は「オリジンを隠す」前提に乗っている
CDN（プロキシ型）をセキュリティ目的で使うとき、期待している効果はおおよそ次のものだ。
- WAF（不正なリクエストのフィルタリング）
- DDoS緩和（大量アクセスの吸収・分散）
- オリジンサーバーのIPアドレスの隠蔽
このうち WAFとDDoS緩和は、通信がCDNのエッジを経由して初めて機能する。 攻撃者がオリジンのIPに直接アクセスできてしまえば、CDNは一切関与しないので、これらの防御はまるごとスキップされる。
つまりCDNの防御価値は「オリジンを隠せている」という前提の上に乗っている。この前提が崩れると、残るのは高速化（キャッシュ配信）のメリットだけになる。
問題の入り口：契約者に配られるデフォルトのサブドメイン
多くの共有ホスティングは、契約時に 動作確認用のデフォルトのサブドメイン を各契約者に割り当てる。独自ドメインをCDN経由に設定していても、このデフォルトのサブドメインは別に生き続けていることが多い。
問題は、このサブドメインが オリジンサーバーの生のIPアドレスを直接指している 点だ。
CDNのプロキシを効かせるには、独自ドメインのDNSをCDN側に向ける必要がある。しかしデフォルトのサブドメインはCDNを経由せず、素直にオリジンのIPを返す。ここから次のことが起きる。
- デフォルトのサブドメインを名前解決すると、オリジンの生IPが得られる
- 得られたIPやホスト名から、同じホスティング基盤のサーバー識別子も推測できる場合がある
- そのIPに対して、独自ドメインのHostヘッダを付けて直接アクセスすれば、CDNを完全にバイパスしてオリジンに到達できる
DNSリゾルバの解決結果に頼らず、こちらからAレコード相当のIPを指定してアクセスできるため、CDNのプロキシは意味をなさなくなる。特別な攻撃手法は必要なく、公開情報の範囲だけでここまで到達できてしまうのが厄介な点だ。
「オリジン側でCDN以外を拒否する」対策は正しい。ただし打てないことがある
この問題への正攻法は存在する。オリジンサーバーのファイアウォールで、CDNの発信元IP帯域からのアクセスだけを許可し、それ以外を全部拒否する ことだ。これができれば、生IPが割れていても直接アクセスは弾ける。
ところが、この対策には前提条件がある。「オリジン側のファイアウォールに利用者が手を届かせられること」 だ。
- VPS・専用サーバー・自宅サーバー → 設定できる
- 契約者にサブドメインを配る型の共有ホスティング → 設定権限がそもそも利用者に無いことがほとんど
共有ホスティングはフルマネージドに近く、ネットワーク層の制御を利用者に開放していないケースが多い。結果として 「対策は存在するが、この構成では打てない」 という状態になる。これがこの問題の本質的な詰みどころだ。
共有ホスティングでは『もらい事故』も避けられない
もう一つ、共有ホスティング特有のリスクがある。これは特定サービスに限らず、オリジンが実在する共有型ホスティング全般 に言える。
DDoSは基本的に ドメインではなくIPアドレス宛 に飛んでくる。共有ホスティングでは複数の契約者が同じIPを共有しているため、次のことが起きる。
- 自分は標的でなくても、同じサーバーの別の契約者が狙われただけで巻き添えを食う
- 逆に自分が狙われれば、同居している他の契約者まで巻き込む
自分のサイトのセキュリティをどれだけ固めても、同居している誰かが狙われれば影響を受ける。これは個人側の努力では原理的に防ぎようがない。
生IPはどこから漏れるのか：自分の環境を点検する観点
「CDNを通したから隠れているはず」と思っていても、実際には別経路から生IPが見えていることが多い。以下は、自分の構成を監査するときにチェックすべき代表的な露出経路だ。攻撃手法としてではなく、点検リストとして使ってほしい。
1. 業者が配布するデフォルトのサブドメイン
この記事の主題そのもの。契約者に割り当てられる動作確認用のサブドメインが、オリジンの生IPを直接指している。自分のドメインをCDNで固めても、これは業者側のゾーンなので proxy を切り替える権限すら無いことが多い。
2. DNSレコードごとの proxy 状態のばらつき
CDNのプロキシ有効/無効は、多くの場合 DNSレコード1件ごとの設定 になる。そのため次のような「まだら状態」が起きる。
-
www：プロキシ有効 → IPは隠れる - apex（ドメイン本体）：プロキシ無効 → 生IPが露出
-
mailなどのサブドメイン：プロキシ無効 → 生IPが露出
フロントの www だけ隠れていても、どれか1レコードが素通しなら、そのIPは露出する。「ドメイン全体が守られている」のではなく「プロキシを通した経路だけが守られている」と理解する必要がある。
3. メール関連のレコード（MX・SPF）
MXレコードは仕組み上プロキシできないため、実際のメールサーバーを指す。SPFを書いたTXTレコードに実IP（ip4:）を含めていると、そこからも露出する。WebサーバーとメールサーバーがオリジンのIPを共有していると、メール経由でWebのオリジンまで割れる。
4. 過去のDNS履歴・証明書ログ
CDN導入前に使っていた古いAレコードが、証明書の透明性ログ（CT log）やパッシブDNSのデータベースに記録として残っていることがある。今のDNSを直しても、過去の記録からたどられる。
点検の実務
自分のドメインについて、各レコード（apex、www、mail、その他サブドメイン、MX、TXT/SPF）を一つずつ名前解決し、返ってきたIPが「CDNのIP帯域なのか」「生IPなのか」を確認する。CDN帯域以外を指しているレコードが一つでもあれば、そこが露出経路になっている。
外部からの見え方を確認する：Shodan
DNSレコードの確認に加えて、「インターネット全体をスキャンした結果」から自分のサーバーがどう見えているかを点検できる。セキュリティ研究者やCTFプレイヤーの間で定番なのが Shodan（shodan.io）だ。常時インターネットをスキャンして、各IPで開いているポートや応答（バナー）を蓄積している検索エンジンで、次のような使い方ができる。
-
favicon のハッシュ検索：サイトのfavicon（タブに出る小さなアイコン）から算出したハッシュ（
http.favicon.hash）で、同じfaviconを配信しているサーバーを横断検索できる。CDN背後に隠したはずのオリジンが、同じfaviconをIP直打ちでも配信していれば、ここでヒットしてしまう。Shodanの開発元自身が、これを「CDN背後のサイトが正しく設定され、オリジンIPで直接応答していないかを確認する」用途として挙げている。 -
TLS証明書での絞り込み：証明書の発行者名（
ssl.cert.issuer.cn）や対象名（ssl.cert.subject.cn）で検索し、同じ証明書を提示しているホストを探せる。
自分の資産に対して使えば、「外からどう見えているか」「隠したつもりのオリジンが応答していないか」を確認して対策を打つのに役立つ。逆に言えば、攻撃者も同じ手段でオリジンを探せるということなので、公開前に一度自分で確認しておく価値がある。
なお、Shodanで得た情報を使って、他人のシステムに所有者の意図しない形でアクセスするのは避けること。あくまで自分の管理下の資産の点検に使う。
考察：この問題が示すもの
技術的な事実の先に、いくつか考えておく価値のある論点がある。
責任の所在が曖昧
この露出は、利用者の設定ミスとも事業者の落ち度とも言い切れない。事業者はデフォルトのサブドメインを「動作確認用」として案内しているだけで、利用者は「CDNを入れれば守られる」と思い込む。両者の想定のズレから生まれる、責任の所在がはっきりしないタイプの問題だ。
平時は無害という潜伏性
この穴は普段まったく害を出さない。攻撃されて初めて顕在化するため、事業者も利用者も優先度を上げにくい。顕在化したときには手遅れ、という潜伏性がある。
CDN導入がかえって油断を生む
CDNを入れたことで「対策済み」と思い込み、他の露出経路を点検しなくなることがある。セキュリティ製品の導入そのものが油断を生む、という逆説が起きやすい。
攻撃側と防御側の非対称
攻撃者は露出経路を一つ見つければ足りるが、防御側は全経路を塞がなければならない。この一対多の非対称が、見落とし一つを致命傷に変える。
点検は一度では終わらない
DNSレコードの変更や新しいサブドメインの追加で、露出は後から再発しうる。一度確認して終わりにせず、定期的に自動でチェックする仕組みを持っておくのが望ましい。
結論：防御目的なら『オリジンを握れる環境』とセットで考える
考え方の軸を一つ示しておく。CDNは「壁」ではなく「囮（おとり）」だ。 攻撃者から見える宛先をエッジに一本化し、そこに攻撃を引きつけて吸収・分散する。世界中に分散した巨大なキャパシティを持つ、桁違いに頑丈な囮なので、パケットを流し込むだけで成立するL3/L4のDDoSでも受け止められる。ただし囮が機能する条件はただ一つ、本体（オリジン）の居場所が攻撃者にバレていないこと だ。生IPが露出した瞬間、攻撃者は囮を無視して本体を直接殴れるので、CDNの防御価値は消える。
ここまでを整理すると、こうなる。
- CDNの防御は「オリジンを隠せている」前提に依存する
- 契約者にサブドメインを配る共有ホスティングは、その前提が構造的に崩れている
- オリジンIP拒否という正攻法も、共有ホスティングでは権限が無くて打てない
- さらに共有IPゆえの巻き添えDDoSも避けられない
したがって、CDNを「防御目的で」活かしたいなら、オリジン側を自分で握れる環境（VPS・オンプレ・あるいはトンネル型でインバウンドを閉じる構成）が事実上の必須条件 になる。環境とCDNはセットで考えないと、防御としては意味を持たない。
高速化目的でCDNを使うのは合理的だ。その場合、利用者がわざわざオリジンに直接アクセスするメリットは無いので、生IPの露出は実害として無視できる。逆に言えば、セキュリティ目的では共有ホスティング＋CDNという組み合わせはそもそも成立しにくい、というのが結論になる。
選び分けはシンプルに考えられる。動的なアプリを動かすならオリジンを握れるVPSやオンプレ（必要ならトンネル型）を、静的サイトを配信するだけならオリジンを持たないエッジ配信型を選ぶ。用途がどちらかで、取るべき構成はほぼ決まる。
補足：静的サイトなら、そもそもオリジンを持たない選択肢がある
静的サイト（SSGで生成したもの）を配信するだけなら、エッジ配信型のホスティング（オリジンサーバーという概念を持たない配信） を使うことで、この問題を根本から回避できる。
オリジンが実在しなければ、隠すべき生IPも存在せず、バイパス経路も生まれない。FTPのような認証情報のやり取りも不要になる。用途が静的配信に限られるなら、これが最もシンプルで安全な選択肢になる。
よくある誤解
この話題では、対策になっていないものを対策だと思い込んでいるケースが多い。代表的なものを挙げておく。
誤解1：「証明書を分ければ、直接アクセスはSSLで弾ける」
オリジンにCloudflare Origin CA証明書だけを置けば、直接HTTPSアクセスは証明書が一致せず弾ける、という考え方。方向性は惜しいが、証明書の検証は「接続する側」が自発的に行うもの だという点が抜けている。
攻撃者は検証を無視すればいいだけで、通信自体は成立する。
# 証明書エラーを無視して直接オリジンに到達できてしまう
curl -k https://<オリジンIP>/ -H "Host: example.com"
さらにDDoSは、そもそもTLSハンドシェイクを完了させる必要すらなく、IP宛にパケットを流すだけなので証明書は無関係。証明書の分離は「善良なブラウザ利用者を弾く」効果はあっても、悪意ある直接アクセスやDDoSは止められない。
誤解2：「HTTPSにしておけば生IPアクセスは防げる」
ホスティング側が平文HTTP（80番ポート）を開いていれば、そもそもHTTPSも証明書も経由せず http://<オリジンIP>/ で直接取得されてしまう。HTTPS化は通信の暗号化には意味があるが、生IPへの直接到達を塞ぐ手段ではない。
誤解3：「CDNを通しているから、それだけでDDoSは防げる」
防げるのは「CDNのエッジを経由してきた通信」だけ。オリジンの生IPが割れていて、かつその直接アクセスを拒否できていなければ、攻撃者はCDNを迂回してオリジンに直接DDoSを撃てる。CDNの防御は「オリジンを隠せている」前提とセットでしか成立しない。
誤解4：「共有ホスティングでもCDNを入れればセキュリティが上がる」
多少はマシになるが、この記事で述べた通り、契約者にサブドメインを配る型の共有ホスティングでは生IPが露出しやすく、かつオリジン側のIP帯域制限を打つ権限も無い。防御目的では、環境（オリジンを握れるか）とセットで考えないと意味を持たない。
誤解5：「アプリ側で弾く設定を入れればDDoSも防げる」
.htaccess での拒否や証明書による締め出しは、いずれも アプリケーション層（L7） の対策だ。HTTPリクエストがWebサーバーやTLS処理まで到達して、初めて効く。
一方でDDoSには、そこまで到達させる必要のない層の攻撃がある。
- L3/L4（ネットワーク層・トランスポート層）の攻撃：SYN Flood はTCPの3ウェイハンドシェイクを完了させず、SYNパケットで接続テーブルを枯渇させる。UDP Flood やICMP Flood はコネクションの概念すらなく、宛先IPにパケットを流し込むだけ。帯域枯渇型なら、サーバーの応答内容とは無関係に回線を埋めた時点で成立する。
- L7（アプリケーション層）の攻撃：HTTP Flood のように、TCP接続とTLSを確立し実際にHTTPリクエストを送って初めてリソースを消費させる。
つまり生IPが割れていれば、攻撃者はL7の対策が待つ手前、パケットがオリジンに届いた時点で攻撃を成立させられる。.htaccess や証明書はL7の入口に立つ対策なので、L3/L4のパケットベース攻撃には原理的に届かない。防御はパケットがオリジンに到達する前で止める必要があり、それにはIP帯域でのフィルタリングか、トンネル型でインバウンドを閉じて到達不能にする構成が要る。
おわりに
「とりあえずCDNを通せば安全」という考え方は、オリジンを隠せている前提が満たされて初めて正しい。自分の構成でその前提が本当に成り立っているか（デフォルトのサブドメインから生IPが取れてしまわないか）を一度確認してみてほしい。
なお、この露出があるからといって、今すぐ攻撃されるわけではない。あくまで「攻撃されうる構成」であって、日常的に害が出るものではない。慌てて移行する必要はないが、自分の構成がどこまで守れていて、どこは守れていないのかを正しく把握しておくことには意味がある。そのための地図として、この記事を使ってもらえれば嬉しいです。
長い記事でしたが、最後まで読んでいただきありがとうございました。
この内容が、あなたの構成を見直す何かのきっかけになれば幸いです。