新しいIPアドレスへの切り替えが完了し、メインドメインもDDoS対策CDNを経由するようになりました。次に確認すべきことは二つあります。新しいアドレスが別の場所で公開されていないか、オリジンが外部ネットワークからの直接アクセスを受け付けていないかです。

オリジンIPアドレスの再露出を防ぐには、DNSとアプリケーションの設定を整理し、オリジンへの接続元を制限します。IPv6やCDNを経由しないサービスも確認したうえで、ドメイン名を維持した直接接続テストを行います。

IPアドレスの変更は、旧アドレスが知られてしまった問題への対処です。新しいアドレスが再び攻撃の入口になるかどうかは、そのほかの設定に左右されます。

検証時には、次の二点を別々に確認した記録を残してください。公開設定から新しいアドレスが漏れていないこと、認可されていないリクエストがCDNを迂回してアプリケーションに到達できないことです。

新しいIPアドレスが公開設定に再び現れていないか？

IPアドレスを変更したら、まず自社で管理する資産の一覧を確認します。

メインドメインはCDN経由でも、アップロードAPIが新しいオリジンを直接指している場合があります。本番環境の設定を変更しても、テスト用ドメインが同じサーバーを使い続けていることもあります。こうした見落としがあれば、高度な調査をしなくても新しいアドレスを特定できます。

Cloudflareの オリジン保護に関するガイド でも、DNSのみのレコード、メール基盤、過去のDNSレコードが確認項目に挙げられています。別のCDNを使っている場合も確認すべき点です。

トップページだけでなく、DNSレコード全体を確認する

DNS管理画面からすべてのレコードを確認またはエクスポートします。サブドメイン、ワイルドカードレコード、地域別ルーティング、フェイルオーバーの設定を調べ、外部からの問い合わせで実際の応答も確認します。

以下のコマンドは、Linux、macOS、またはWindows Subsystem for Linux（WSL）に digがインストールされている環境で実行できます。 BINDのdigに関するドキュメント に従い、IPv4のAレコードとIPv6のAAAAレコードをそれぞれ問い合わせます。

dig +noall +answer example.com A
dig +noall +answer example.com AAAA
dig +noall +answer api.example.com A
dig +noall +answer api.example.com AAAA

例示したドメインを自社のものに置き換え、アップロード、ダウンロード、管理、テスト、予備の各ホスト名も確認します。

新しいオリジンのアドレスや、引き続きオリジンに名前解決されるホスト名を探します。ただし、AレコードがあるだけでCDNを迂回しているとは限りません。CDNの接続先もAまたはAAAAレコードで返されることがあります。

結果が表示されなくても、安全とは断定できません。このオプションでは回答セクションだけが表示されます。空の場合は +noall +answerを外して問い合わせの状態を確認し、DNS管理画面、権威DNSの応答、別のネットワークからの結果と照合してください。

IPv4とIPv6の両方を使用する場合は、 IPv6オリジンとIPv4クライアントの接続に関する解説 も参照し、利用者からCDNへの経路とCDNからオリジンへの経路を確認してください。利用者がIPv6でCDNに接続しても、オリジンのIPv6アドレスを公開する必要はありません。

オリジン用ホスト名を変更しても、アドレスが露出することがある

管理しやすいように、新しいオリジン用に長いランダムなホスト名を作り、CDNの管理画面に登録することがあります。

そのホスト名が公開DNSでオリジンに名前解決されるなら、外部から見つけられる可能性があります。推測しにくい名前は偶然見つかる機会を減らせても、アクセス時の認証にはなりません。

CDN事業者がオリジンIPアドレスの直接設定を許可しているなら、オリジンへの接続用に公開DNSレコードを増やす必要はありません。ホスト名が必要な場合は、名前の秘匿に頼らず、接続元の制限とオリジン認証でアプリケーションを保護します。

新しいアドレスの動作確認のために、本番ドメインを一時的にオリジンへ直接向けないでください。一時的なDNS応答でもキャッシュや記録に残ることがあります。その後CDNに戻しても、公開された情報は取り消せません。

オリジンから外部へ接続するときのIPアドレスも確認する

Webサイトからメールやアプリケーションのコールバックを送信したり、外部リソースをダウンロードしたりすると、接続先にサーバーの送信元IPアドレスが見える場合があります。

そのアドレスはオリジンへの公開アクセスに使うアドレスと同じ場合もあれば、別の出口経路、NATゲートウェイ、プロキシのアドレスである場合もあります。実際のネットワーク構成を確認してください。外向きの接続で観測されたIPアドレスだけでは、Webサイトのオリジンだとは証明できません。

公開アクセスに使うオリジンアドレスを守る必要がある場合は、メールや外向きの通信に別のサービスや出口経路を使うべきか検討します。出口を分けた場合も、オリジンへの着信制限は維持してください。

CDN経由の通信だけをオリジンで許可するには？

DNSを整理したら、オリジンのアプリケーション用ポートへのアクセスを制限します。

想定したCDN設定から転送されたリクエストはオリジンに届くようにし、不要な直接接続は拒否します。よくある間違いは、許可するアドレス範囲を誤ることと、通信が通らない場所にルールを適用することです。

速度テストで見えたエッジIPではなく、正式なオリジン向け送信元IP範囲を使う

利用者がCDNへの接続に使うIPアドレスと、CDNがオリジンへの接続に使うIPアドレスは異なる場合があります。

オリジンの許可リストは、事業者が公開する正式なオリジン向け送信元IP範囲、または専用の送信元情報に基づいて作成します。次の点を確認してください。

• IPv4とIPv6それぞれに該当する範囲があるか。
• ヘルスチェックの送信元アドレスが別になっていないか。
• エッジ拠点の追加やネットワーク経路の変更に伴い、送信元IP範囲が変わるか。
• 複数CDNの構成、ロードバランサー、必要な外部連携システムに別の入口があるか。

一度のテストで観測した数個のアドレスだけを許可するのは避けてください。便宜上、クラウド事業者の広範な無関係のアドレス範囲まで許可することも避けます。

ルールを変更する前に、信頼できる管理経路と復旧手段を確保します。通常のオリジンリクエストが許可されることを確認してから、ほかの送信元を段階的に拒否してください。トップページだけでなく、ログイン、アップロード、API、ヘルスチェックもテストします。

実際の通信経路上でアクセスを制限する

オリジンの手前にロードバランサーがある場合、サーバーからはCDNの送信元アドレスではなく、ロードバランサーが接続元に見えることがあります。実際の接続元を識別できる適切な場所で制限を適用し、バックエンドへの経路も保護してください。

アプリケーションログに表示される「クライアントIP」が、ネットワーク上の接続元アドレスとは限りません。

NGINXの Real IPモジュールのドキュメント では、信頼できるプロキシが付与したヘッダーから利用者のアドレスを復元する方法が説明されています。この機能を使う場合は、復元した利用者のIPアドレスと元の接続元アドレスを区別し、利用者のアドレスをCDNのオリジン向け許可リストと照合しないでください。

X-Forwarded-Forなどのリクエストヘッダーも、それだけでは信頼できる接続元の証明になりません。アプリケーションがこれらの値を利用できるのは、正しくヘッダーを処理する、確認済みの信頼できるプロキシから届いたリクエストに限られます。

Dockerで公開したポートとIPv6のルールを別々に確認する

コンテナ構成では、ホストのファイアウォールでポートを拒否していても、それだけで十分とは限りません。

Dockerの ファイアウォールとポート公開に関するドキュメント によると、Linuxの構成によっては、公開されたコンテナポートへの通信がDockerの作成した転送ルールを通り、ufwで想定した処理位置より前に転送される場合があります。

コンテナのポート公開、クラウドのセキュリティルール、ホスト上の実際のパケット処理経路をまとめて確認してください。アプリケーションのポートがインターネットに直接公開されたままだと、Webサイトのリバースプロキシを迂回できます。

IPv6にも同じことがいえます。IPv4のルールが有効でも、IPv6が同様に制限されているとは限りません。アプリケーションに必要な待ち受けポートと許可範囲だけを残し、不要な公開入口を閉じてください。

CDNのIP範囲を許可していても、なぜオリジン認証が必要なのか？

CDN事業者が共用するオリジン向け送信元IP範囲を許可すると、通常はリクエストの送信元ネットワークを絞れます。ただし、リクエストが自社サイトのCDN設定を経由したことまで証明できるとは限りません。

該当する転送機能を備えた共用プラットフォームでは、ほかのアカウントからのリクエストも同じ送信元IP範囲を使う可能性があります。より厳密な分離が必要なら、自社サイトに紐づくオリジン認証が可能か確認してください。

方法の一つが相互TLS（mTLS）です。CDNはオリジンサーバーの証明書を検証し、オリジンはCDNが提示するクライアント証明書を検証します。通信の暗号化に加えて、接続元の認証も行えます。

Cloudflareの Authenticated Origin Pullsに関するドキュメント では、共用証明書とカスタム証明書が区別されています。共通のグローバル証明書で証明できるのは、リクエストがCloudflareのネットワークから来たことまでです。自社のアカウントやホスト名をより厳密に識別するには、適切なカスタム設定が必要です。他社製品についても、検証できる範囲、設定方法、プラン条件を個別に確認してください。

オリジンへのリクエストに秘密のヘッダーを使う場合も、いくつかの条件が必要です。HTTPSで送信し、信頼できるCDNの設定からその値を付与または上書きし、オリジンがコンテンツを返す前に検証します。認証情報を公開ログ、フロントエンドのコード、レスポンスに含めないでください。

固定の秘密情報は、漏れると再利用されるおそれがあります。追加の制御として使い、オリジンのネットワーク制限の代わりにはしないでください。

次の二つの設定も、オリジン認証と混同しやすいものです。

オリジンにHTTPS証明書を導入しても、オリジンがCDNを認証していることにはなりません。

Hostヘッダーによる制限だけでは、リクエストの送信元を確認できません。

公開されているサイトのホスト名は、通常、誰でも知ることができます。IPアドレスを知っている人は、同じホスト名を指定してリクエストできます。デフォルトサイトがコンテンツを返さない設定だけでは、誤ってアクセスされる一部のケースにしか対処できません。

外部からCDNを迂回できないことをどう検証するか？

ブラウザーで https://源站IPを直接開けなくても、証明書の名前が一致しないか、適切な仮想ホストにリクエストが届かなかっただけかもしれません。それだけでは、オリジンが直接アクセスを拒否している証拠にはなりません。

より有効なのは、アプリケーションのホスト名を維持したまま、指定したオリジンIPに接続するテストです。

以下の操作は、自分で管理しているサーバー、またはテストの許可を得ているサーバーに限って行ってください。もともと認可されている運用拠点からではなく、許可リストに含まれない外部ネットワークから実行します。

まず、通常の入口から実際にオリジンへ到達することを確認する

以下は、curlがインストールされたLinux、macOS、またはWindows Subsystem for Linux（WSL）環境での例です。

curl -q --noproxy '*' -sS -D - -o /dev/null \
  --connect-timeout 5 --max-time 15 \
  -w '\nhttp=%{http_code} peer=%{remote_ip}\n' \
  'https://example.com/'

ここではルートパスを例にしています。受け入れ検証では、存在が確認でき、読み取り専用で、CDNのキャッシュ対象から明示的に除外したテスト用パスに置き換え、新しいオリジンのログも確認してください。

CDNのキャッシュから応答が返っただけでは、エッジで配信できることしか分からず、新しいオリジンが正常に動いている証拠にはなりません。URLに任意のクエリーパラメーターを追加しても、キャッシュを確実に迂回できるとは限りません。実際のルールとログで確認してください。

次に、ホスト名を維持して新しいオリジンに直接接続する

新しいオリジンのIPv4アドレスが 203.0.113.10の場合、次のようにテストします。

curl -q --noproxy '*' -sS -D - -o /dev/null \
  --connect-timeout 5 --max-time 15 \
  --resolve 'example.com:443:203.0.113.10' \
  -w '\nhttp=%{http_code} peer=%{remote_ip}\n' \
  'https://example.com/'

オリジンに公開IPv6アドレスもある場合は、IPv6で正常に接続できるネットワークからテストします。

curl -q --noproxy '*' -sS -D - -o /dev/null \
  --connect-timeout 5 --max-time 15 \
  --resolve 'example.com:443:[2001:db8::10]' \
  -w '\nhttp=%{http_code} peer=%{remote_ip}\n' \
  'https://example.com/'

上記のIPアドレスは説明用の例です。実行時には置き換えてください。

このオプションは、 curlの --resolve ドキュメント にあるとおり、指定したホスト名とポートに対する接続先アドレスを設定します。URLは引き続きアプリケーションのホスト名を使用するため、HTTPのHostヘッダーとHTTPSハンドシェイク時のSNIホスト名もURLに従います。実際のサイトへのリクエストに近い形で確認できます。

-qはcurlのデフォルト設定ファイルの読み込みを無効にし、 --noproxy '*'はcurlのプロキシ設定の影響を除きます。ただし、システムのVPNやネットワーク経路は変更しません。 peerには今回接続した相手のIPアドレス、 httpには取得したHTTPステータスコードが表示されます。

上記のコマンドは、初期状態ではレスポンスヘッダーのみを表示します。実際のアプリケーションの内容が返るか確認するには、 -o /dev/nullを外してください。

CDNがオリジンへのリクエストでHostヘッダーやSNIホスト名を書き換える場合は、その接続で実際に使う名前もテストしてください。公開ホスト名だけの確認では足りません。

テスト結果から何が分かるか？

http=000は、HTTPステータスコードを取得できなかったことを示します。サーバーが「000」というステータスを返したわけではありません。

オリジンがプライベートCAやオリジン専用の証明書を使用している場合は、管理下のテスト環境で正しい信頼チェーンを設定してください。たとえば適切な --cacertファイルを指定したうえで、アクセス制御を判断します。クライアントがサーバー証明書を信頼しないことと、サーバーがクライアントに認証用証明書の提示を求めることは、検証の方向が異なります。

構成の検証では、外部からのリクエスト、CDNの記録、オリジンのログを照合してください。一度のタイムアウト、単発の403、テスト画面のスクリーンショットだけでは、すべての入口を確認できません。

旧IP、暫定的な許可リスト、切り戻し経路をどう整理するか？

新しいオリジンが正常に動いていても、旧環境がセキュリティに影響を与えることがあります。

残りやすい設定の一つが、古いクライアントの移行期間を延ばすため、旧IP上のリバースプロキシから新しいオリジンへの転送を続けることです。新しいIPを直接公開しなくても、旧入口に届いた悪意あるリクエストを新しいオリジンへ送り続ける可能性があります。

旧アドレスが新しいIPを含むURLへリダイレクトしたり、新しいオリジンのホスト名を直接公開したりする場合は、明確な情報漏えい経路にもなります。

旧入口を廃止する前に、クライアント、定期実行ジョブ、決済サービスからのコールバック、アップロード処理、ほかのシステム連携がまだ利用していないか確認します。移行期間中に必要な入口には適切な保護と認証を適用し、廃止する条件を決めてください。依存する処理の移行を確認したら、不要な転送設定と待ち受けを停止します。

切り戻しの方法も事前に用意します。

CDNの設定に問題が生じた場合は、検証済みの設定に戻すか、保護された予備オリジンに切り替えます。新しいオリジンを指す公開DNSレコードを一時的に作る方法を、標準の切り戻し手段にしないでください。障害対応をきっかけに、アドレスが再び公開されるおそれがあります。

暫定的に許可したオフィスのIP、テスト用サーバー、外部監視サービスについても、用途と有効期限を記録します。CDNのオリジン向け送信元IP範囲を追加するときは、情報源と設定を検証してから許可リストを更新してください。更新に失敗した場合も、すべての送信元を自動的に許可してはいけません。

変更を反映するたびに、DNSレコード、コンテナやロードバランサーの公開ポート、クライアントに渡す予備アドレスの三点を再確認します。通常の変更作業で、公開入口が再び生じやすい箇所です。

IPアドレスが知られた場合、オリジンにはどのような防御が必要か？

上記をすべて確認しても、公開オリジンIPが今後絶対に発見されないとは保証できません。

接続元の制限とオリジン認証は、CDNを迂回するアプリケーションへのリクエストを減らします。しかし、攻撃トラフィックでオリジンの上流回線が埋まった場合、サーバーで通信を破棄しても、消費された帯域は回復しません。オリジン側の事業者がどこで通信をフィルタリングするか、データセンターのトラフィックスクラビング能力、回線容量は別途確認が必要です。

懸念がある場合は、 オリジンIP露出後の防御方法 も参照し、IPレイヤーの保護を追加すべきか検討してください。ほかのポートを提供しているサーバーや、直接攻撃を継続して受けているサーバーでは、 DDoS対策サーバーのプラン が対象のプロトコルと攻撃範囲をカバーできるかも評価できます。

CDN07の DDoS対策CDNの導入プラン を検討する際は、オリジンのアドレス、すべてのアプリケーション用ホスト名、プロトコルとポート、IPv6の利用状況、既存のアクセス制限をまとめて提示してください。当社のエッジ拠点、帯域幅、セキュリティポリシーは、アプリケーションの要件に応じて調整できます。オリジン向け送信元IPの範囲、ヘルスチェックの送信元、利用できる認証方法は、個別のプランで確認が必要です。

プライベートなオリジン接続やトンネルを検討している場合も、製品が対応しているか、障害時の復旧と運用をどう行うか確認してください。DDoS対策CDNに接続しただけで、オリジンにこうした機能が備わるわけではありません。

よくある質問

IPを変更した後、過去のDNSレコードから新しいIPが分かるか？

過去のレコードに記録されているのは、通常、以前公開されていたアドレスです。それだけで新しいIPが自動的に分かるわけではありません。ただし、新しいアドレスが公開DNSに現れたり、特定可能な別のサービスとIPを共有したりすると、サイトとの関連が再び判明する可能性があります。新しいアドレスが再公開されていないか、公開されても直接アクセスに悪用できないかを確認してください。

オリジン用ホスト名をランダムな文字列にすればよいか？

簡単な推測は難しくなりますが、セキュリティを保証するものではありません。その名前が公開DNSでオリジンに名前解決されるなら、発見される可能性があります。接続元の制限と認証も組み合わせてください。

正しいHostヘッダーだけを許可すれば、CDNの迂回を防げるか？

それだけには頼れません。リクエストの送信者は公開されているアプリケーションのホスト名を指定でき、HTTPSクライアントは対応するSNIも送信できます。Hostによる制限は誤ったサイトへのアクセスを減らすのに役立ちますが、オリジンリクエストの送信元と接続元の認証は別途必要です。

IP変更直後にスキャンされたら、新アドレスが漏れたということか？

スキャンだけでは判断できません。公開IPアドレスには、特定のWebサイトとは無関係な探索が届くこともあります。リクエストが正しいアプリケーションのホスト名を指定しているか、実際の内容を取得できるか、公開設定に新しいアドレスが含まれているかを調べてください。

CDNの専用IPを購入すれば、オリジンのアクセス制限は不要か？

不要にはなりません。利用者向けのCDN専用IP、CDNからオリジンへの送信元IP、オリジンIPは、それぞれ通信経路上の異なる場所のアドレスです。専用IPの役割は製品構成によって異なります。オリジンについては引き続き、迂回経路、接続権限、ネットワーク層の防御を確認してください。

導入後は、次の四つの検証結果を残してください。

• 公開DNSとクライアント設定が、新しいオリジンを再び指していないこと。
• 通常のCDN経由のリクエストが、実際に新しいオリジンへ到達すること。
• 認可されていないネットワークから、保護対象のアプリケーションの内容を直接取得できないこと。
• 旧入口、暫定ルール、IPv6の設定をすべて確認済みであること。

現時点でIPの変更とDNSの更新だけを済ませている場合は、 CDN07の技術相談窓口 に現在のホスト名、プロトコル、構成情報をお知らせください。オリジン向け送信元IPの範囲と導入条件を確認してから、オリジン側の制限と検証を進められます。