利用者から「見知らぬページに転送される」と報告があっても、管理者が開くと正常に見えることがあります。トップページはそのままなのに、広告やダウンロードボタンが突然表示される場合もあります。こうした現象はまとめて「サイトの乗っ取り」と呼ばれがちですが、原因はまったく異なる場所にあるかもしれません。

DDoS対策CDNはこうした問題の防止に役立ちますが、DNSの保護、HTTPS通信、アプリケーション防御、オリジン保護も適切に設定する必要があります。 DDoSトラフィックのスクラビングは主にサイトの可用性を守るもので、侵害されたドメインアカウント、改ざんされたプログラム、悪意ある外部スクリプトを自動修復することはできません。

異常がどの段階で発生するかを特定してから、CDNの導入、ルールの調整、オリジンの修復のどれが有効か判断しましょう。

まず「サイトが乗っ取られた」とは、どのような現象か

ドメインを入力してページが表示されるまでに、ブラウザーはDNSの名前解決、サーバーへの接続、ページの取得、スクリプトの実行を行います。どの段階の異常も、意図しないコンテンツが表示される原因になり得ます。

この表は調査範囲を絞るためのもので、現象一つで原因を断定するものではありません。地域によって異なるIPに解決されるのはCDNの正常な振り分けかもしれません。HTTP 302も正規のログイン処理で使われます。

見極めるべきなのは、許可していないアドレス、ルール、コンテンツがどの段階で生じたかです。

DNSで利用者が誤った接続先へ誘導されるのをどう防ぐか

CDN導入後は、事業者の指定に従い、ドメインからCDNへ接続されるようにします。CNAMEで接続する方法が一般的ですが、DNSプロキシなどを使う製品もあります。

ただし、CNAMEを変更するだけでDNSが安全になるわけではありません。ドメイン登録事業者のアカウント侵害、DNSサービスの認証情報漏えい、利用者側への偽造DNS応答によって、意図した接続経路から外れる可能性があります。

DNSアカウントとドメインの管理権限を守る

ドメイン登録事業者、DNSサービス、CDNの管理画面はいずれも重要な管理入口です。それぞれで多要素認証を有効にし、職務に応じた権限を付与し、退職者のアカウントを削除します。自動処理用のAPIトークンには必要最小限の権限を与えてください。

NS、A、AAAA、CNAMEレコードや関連設定の変更も監視します。NSレコードはドメインを担当する権威DNSサーバーを示すため、特定のAレコードだけを見ていては不十分です。

ドメイン移管ロックは無断移管のリスクを減らせますが、すべてのDNSレコード変更を防ぐとは限りません。ロックの仕組みごとに保護範囲を確認する必要があります。

DNSSECはDNSデータの正当性を検証する仕組みで、Webページを暗号化しない

DNSSECはデジタル署名を使い、DNSデータの出所と完全性の検証を助けます。ICANNの DNSSECの解説 は、署名と信頼の連鎖によって、検証を行うリゾルバーが改ざんされたデータを検出する仕組みを説明しています。

効果を得るには、ドメインへの署名、親ゾーン側の関連レコード、検証の連鎖が正しく設定され、利用者の名前解決経路で実際に検証が行われる必要があります。設定の不整合は名前解決の失敗につながるため、DNS事業者の切り替え時には関連レコードも調整してください。

DNSSECは、正当な管理権限を持つ人によるレコード変更も止められません。アカウントが侵害されると、攻撃者が通常の管理操作でDNSを変更できます。DNSSECとアカウント保護は併用すべきです。

HTTPSが必要な二つの接続区間とは

DDoS対策CDNを導入すると、通常は二つの独立した接続ができます。

• ブラウザーとCDNの間。
• CDNとオリジンの間。

ブラウザーにHTTPSと表示されても、ブラウザーがアクセスした接続先との通信が保護されていることを示すだけで、CDNからオリジンへの接続もHTTPSとは証明できません。

エッジ側の暗号化に加え、オリジンの証明書も検証する

ブラウザーからCDNまでは暗号化していても、CDNが公開インターネット上のHTTPでオリジンからコンテンツを取得するなら、後半の通信は平文です。ログイン、注文、APIなど機密性の高いサービスでは、オリジンへの接続もHTTPSにし、証明書を正しく検証してください。

証明書の検証には、有効期限、信頼関係、ホスト名の一致が含まれます。Cloudflareの Full（strict）モードの説明 でも、暗号化された接続と、より厳格なオリジン証明書の要件を区別しています。他社のモード名や利用できる証明書は、それぞれのドキュメントで確認してください。

オリジンの接続先アドレス、HTTP Hostヘッダー、TLSハンドシェイクのServer Name Indication（SNI）も、オリジンの設定と整合させる必要があります。IPに接続するからといって、ホスト名の検証を省略してよいわけではありません。証明書エラーは設定を修正し、検証を長期的に無効化して回避しないでください。

HSTSでブラウザーがHTTPに戻る可能性を減らす

HSTSはブラウザー向けのセキュリティポリシーです。ブラウザーが安全な接続を通じて有効なポリシーを受け取ると、有効期間中は対象ホストにHTTPSでアクセスします。

HTTPSが安定して動作していることを確認してから、テスト用ドメインや限られたトラフィックで短い有効期間を設定できます。例えば、次のHTTPレスポンスヘッダーです。

Strict-Transport-Security: max-age=300

300は300秒を意味し、初期検証に限った設定です。問題がなければ、本番展開計画に沿って徐々に延長します。関連するサブドメインのHTTPSがすべて安定していない限り、 includeSubDomainsを安易に追加しないでください。

MDNの HSTSの説明 によると、通常のHSTSはブラウザーが最初に安全な接続を確立してヘッダーを受け取ってから有効になります。そのため初回アクセスには制約があります。プリロードで緩和できますが、追加の条件を満たす必要があります。

HSTSが保護するのは接続方法です。侵害されたサイトを元に戻すことも、ページ上で実行権限を得た悪意あるスクリプトによる被害を防ぐこともできません。

WAFとオリジン保護でサイト改ざんのリスクをどう減らすか

別の種類の「乗っ取り」は通信途中では起きません。サーバー自体が悪意あるコードを返します。この場合、HTTPSはそのコードを改変されることなくブラウザーへ届けてしまいます。

脆弱性のあるCMS、更新されていないプラグイン、漏えいした管理者パスワード、不審なファイルアップロード、悪用された公開用認証情報などが典型的な入口です。アプリケーションの入口と管理権限を守ることが重要になります。

危険なリクエストをエッジで遮断し、プログラムも修正する

Webアプリケーションファイアウォール（WAF）は、ルールに基づいてSQLインジェクション、クロスサイトスクリプティング、パストラバーサル、不審なアップロードなどの一部を識別し、脆弱性を悪用される機会を減らせます。ただし、すべての変種を検出できるわけではなく、コードの修正や依存ライブラリの更新に代わるものでもありません。

攻撃者が正規の管理者認証情報を入手し、通常の操作でトップページを変更した場合、攻撃パターンの照合だけでは見つからないことがあります。管理権限、ログインの保護、公開前の承認も重要です。

CDN07は WAF・ボット管理・DDoS対策の連携 に関する記事で、ネットワーク攻撃の緩和、アプリケーションリクエストの検査、自動化されたアクセスの識別を、一つのアクセス経路として捉えています。改ざんや不正転送のリスクを抑えるには、管理者ログイン、コンテンツ公開、ファイルアップロードなどの重要な経路にポリシーを適用し、正規のアクセスも維持します。

オリジンのサービスには想定したアクセスだけを通す

オリジンがインターネットから直接アクセスできる状態だと、攻撃者がCDNを迂回して管理画面に接続したり、脆弱性を悪用したりする可能性があります。実際のCDN送信元アドレス範囲、アクセス制御、適切な認証方法を組み合わせて、サービス用ポートへの接続を制限します。

CDNの送信元IPを複数の顧客で共有している場合、そのIPだけを許可しても、リクエストが自社サイトのものとは証明できないことがあります。追加のオリジンリクエスト認証が必要かどうかは、事業者の機能と自社の構成に基づいて判断してください。

IPv6、以前のサブドメイン、管理パネルに迂回経路がないかも確認します。IPv4だけを制限し、AAAAレコードがオリジンを直接指していれば、保護には抜けがあります。すでにオリジンの露出が問題になっている場合は、 オリジンIPの保護と迂回経路の確認方法 も参考に調査してください。

これらの対策は、防御の迂回やオリジンへの侵入の機会を減らすものです。プログラムがすでに変更されている場合は、信頼できる版を復元し、侵入経路を修正し、漏えいした認証情報にも対処する必要があります。

外部スクリプトによる不正リダイレクトをCDNは直接検出できるか

サイトが直接侵害されていなくても、アクセス解析、広告、チャットサポートなどの外部スクリプトが原因で、意図しないリダイレクトが発生することがあります。

ブラウザーが読み込むスクリプトは、ページ上で与えられた権限に応じて動作します。HTTPSのアドレスから配信されているだけで、内容が常に安全とは限りません。外部サービスのアカウント侵害、リソースの差し替え、スクリプトの処理変更がページに影響する可能性があります。

CSPでページが読み込み・実行できるものを制限する

Content Security Policy（CSP）は、リソースの取得元、スクリプトの実行条件、一部のページ動作を制限できます。正規の機能への影響を調べるため、まずはレポート専用モードから始められます。

例えば、次のレスポンスヘッダーはテストの出発点になります。すべてのサイトにそのまま適用できる最終ポリシーではありません。

Content-Security-Policy-Report-Only: default-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'

リソースの取得元を原則として同一オリジンに設定し、オブジェクトの埋め込み、ベースURL、フォーム送信にも制約を設けます。 Report-Onlyなので、実際にはリクエストを遮断しません。まずブラウザーの開発者ツールで違反を確認し、集中的に収集する必要があればレポート送信先を設定します。

MDNの CSP導入ガイド でも、このテスト方法が紹介されています。本番で強制する前に外部依存を洗い出し、必要な取得元、nonce、ハッシュのルールを設計して、ログイン、決済、サポート機能を検証してください。

CSPは「すべてのリダイレクトを禁止する」万能な設定ではありません。許可したスクリプト自体に問題があれば、広すぎる取得元の許可リストでは防げない可能性があります。

バージョン固定のリソースには整合性検証を使う

Subresource Integrity（SRI）では、ページにリソースの期待されるハッシュを指定できます。ブラウザーはスクリプトやスタイルシートのダウンロード後に照合し、一致しなければ読み込みを拒否します。

MDNの SRIの説明 によると、異なるオリジンのリソースには、配信サーバー側の適切なCORS対応と、対応する crossorigin属性も必要です。 MDN

SRIはバージョンが固定され、内容を予測できるリソースに適しています。更新時にはハッシュも変更してください。攻撃者がメインページとハッシュ値の両方を書き換えられるなら、SRIだけでは安全を保証できません。公開フローとページ自体の保護も必要です。

不審なリダイレクトが起きたら、どの順序で調べるか

発生時刻、完全なURL、端末、通信事業者、検索結果からのアクセスかどうか、転送前後のドメインを記録します。「サイトが乗っ取られた」という一言だけで済ませないでください。こうした違いが再現条件になることがあります。

以下のコマンドは、 digと curlがインストールされたLinuxまたはmacOSのターミナルで使えます。例のドメインとアドレスは置き換えてください。自身のサイトを確認するためのもので、攻撃トラフィックは発生させません。

1. DNS設定と照合し、CDNの正常な振り分けを乗っ取りと誤認しない

dig +short NS example.com
dig +short CNAME www.example.com
dig +short A www.example.com
dig +short AAAA www.example.com

結果をドメイン登録事業者、DNSサービス、CDNの管理画面にある想定設定と照合します。ネットワークごとに異なるエッジIPが返るのは珍しくありません。名前解決の経路が許可されたサービスにつながっているかが重要です。

ローカルでは異常でも別のネットワークでは正常なら、ルーター、プロキシ、ローカルのDNS環境も調べます。ただし、二つの結果が異なるだけでDNSハイジャックとは断定できません。

どの地域からも同じ無許可の宛先に解決されるなら、端末のDNS設定を何度も変えるより、アカウントのログイン履歴と設定変更記録を優先して確認します。

2. どのレスポンスがリダイレクトを返したか確認する

次のGETリクエストはレスポンスヘッダーを表示し、本文を破棄します。リダイレクトを自動追跡しません。

curl --noproxy '*' -sS \
  --connect-timeout 10 --max-time 20 \
  -D - -o /dev/null \
  https://www.example.com/

-D -はレスポンスヘッダーをターミナルに出力し、 --noproxy '*'は今回のリクエストで環境のプロキシ設定を使わないようにします。インターネットへ直接接続してよいテスト環境で実行してください。

ステータスコードと Locationを確認します。301、302、307、308なら、転送先が想定どおりか調べます。各段階を確認してから次のアドレスに進み、不明な転送先に管理者の認証情報などを入力しないでください。

curlの公式マニュアル に、これらのオプションの用途が説明されています。curlはブラウザーのようにページのJavaScriptを実行しないため、このコマンドで転送されなくても、悪意あるブラウザー側のリダイレクトがないとは言えません。

200が返ってもブラウザーで読み込み後に別ページへ移るなら、開発者ツールを開き、ネットワークログを保持してください。画面遷移を開始したスクリプト、ページ内容、リクエストの経路を調べます。HTMLのリフレッシュによる転送や、ブラウザー拡張機能、Service Workerの影響も確認します。

3. 許可された環境でオリジンとCDNの応答を比較する

自身のオリジンにアクセスする権限がある場合、許可されたテスト環境からCDNを経由せず、応答を比較できます。

curl --noproxy '*' -sS \
  --connect-timeout 10 --max-time 20 \
  --resolve 'www.example.com:443:192.0.2.10' \
  -D - -o /dev/null \
  https://www.example.com/

192.0.2.10は文書用の例示アドレスです。実際のオリジンアドレスに置き換えてください。コマンドはURL中のドメインを維持するため、Host、SNI、証明書の検証に利用できます。

この例は、オリジンがそのドメインでHTTPSを提供する前提です。実際のオリジン接続で別の名前や独自の信頼チェーンを使う場合は、 -kで検証を飛ばすのではなく、実際の構成に合わせてテストを調整してください。比較のためだけにオリジン全体をインターネットへ公開するのも避けます。

オリジンは正常でCDN経由の応答だけ異常なら、キャッシュ、リダイレクトルール、エッジ処理、設定変更を重点的に調べます。両方で異常なら、アプリケーション、Webサーバー設定、データベースの内容を確認します。

比較する際は、できる限り同じパスと発生条件を使ってください。スマートフォンや特定のCookieだけで発生する異常は、通常のcurlリクエストでは再現できないことがあります。

4. 原因を修復してからキャッシュに残った内容を消す

侵入や無断の設定変更を確認したら、必要なログと異常な内容のサンプルを保存します。そのうえで信頼できる設定や公開版を復元し、不正なルールを撤回し、漏えいしたアカウントとトークンに対処して、最初の侵入経路を修正してください。

認証情報のローテーションは信頼できる端末から行い、復旧用メールアドレスと既存のセッションも確認します。漏えいしたAPIトークンや不正なセッションを残したままパスワードを一つ変えるだけでは、問題が再発しかねません。

オリジンが正常であることを確認してから、影響を受けたCDNキャッシュを削除します。オリジンの修復前にキャッシュだけを削除すると、エッジが悪意あるページを再びキャッシュする可能性があります。利用者側のブラウザーキャッシュ、保存されたリダイレクト、Service Workerも残る場合があり、別途確認が必要です。

復旧の確認は、管理者のパソコンでトップページを見るだけでなく、異常が起きた端末、ネットワーク、流入経路でも行ってください。

CDN07導入時に防止策をどう組み込むか

CDN07のDDoS対策CDN はWebサイトの配信高速化とDDoS対策を提供し、エッジロケーション、帯域、セキュリティポリシーを調整できます。不正転送や改ざんの防止は、単に攻撃緩和容量を増やすのではなく、実際のリスクに沿って設定してください。

例えば、コンテンツサイトでは管理画面からの公開作業や外部スクリプトに注目します。ECサイトではログイン、注文、決済に関連する経路を保護する必要があります。SaaSではテナントごとのドメイン、API、管理権限も考慮します。防御ルールは、こうした具体的な入口に対応させます。

導入作業は三つの領域に分けて整理できます。

DNSSECは通常、DNS事業者とドメイン登録事業者との連携が必要です。CSPやSRIにはアプリケーションまたはレスポンスヘッダーの設定が関わります。既存のプラットフォームで利用できるか、誰が維持管理するかを導入時に確認してください。DDoS対策CDNを購入しただけで、すべてが自動的に完了するわけではありません。

よくある質問

DDoS対策CDNでサイトの乗っ取りを完全に防げますか。

完全には防げません。アクセスの入口、通信経路、アプリケーションへのリクエストの保護には役立ちますが、ドメインアカウント、オリジンのプログラム、外部スクリプト、利用者の端末には別のリスクがあります。

HTTPSを使っているのに広告ページへ転送されるのはなぜですか。

HTTPSが保護するのは通信であり、ページの内容が安全であることまでは保証しません。悪意ある内容はオリジン、データベース、外部スクリプトのほか、変更されたCDNルールやローカルのブラウザー環境に由来する可能性があります。

スマートフォンだけ転送される場合、通信事業者によるハイジャックですか。

それだけでは断定できません。サーバー側の処理やスクリプトは、端末、ネットワーク、流入元、セッションによって異なる内容を返せます。端末とネットワークを比較し、実際の転送経路を保存してください。

CDNを導入した後もDNSSECは必要ですか。

役割が異なります。CDNはコンテンツを代理・配信し、DNSSECはDNSデータの検証を助けます。DNSサービスとドメインの構成が対応し、適切に運用できるなら併用できます。

CDNを変えて正常に戻ったら、以前のCDNが侵害されていた証拠になりますか。

そうは判断できません。切り替えと同時にキャッシュ、ルール、名前解決、アクセス経路が変わる場合があります。原因の特定には、実際の応答と設定変更の記録を確認する必要があります。

オリジンを修復したのに、一部の利用者に悪意あるページが表示されるのはなぜですか。

CDNやブラウザーのキャッシュ、保存されたリダイレクト、Service Workerに内容が残っている可能性があります。侵入経路が完全に塞がっていない場合もあります。現在のオリジンの応答、エッジの応答、影響を受けた端末からの実際のリクエストを比較してください。

サイトの不正転送や改ざんを防ぐには、DNS、通信、設定、コンテンツのすべてを信頼できる状態に保つ必要があります。DDoS対策CDNは重要な役割を担えますが、各層の管理責任も明確にしておきましょう。

導入を検討している、または異常を調査している場合は、影響を受けたURL、発生時刻、地域と通信事業者、機密情報を除いた応答記録を CDN07の技術相談窓口 へ共有できます。DNS、ルール、オリジン接続の状況と併せて原因を調べるための資料になります。提出前にCookie、Authorizationヘッダー、アクセストークンなどの機密情報を削除し、具体的な証拠に基づいて調査を進めてください。