ドメインをCDNに接続しているのに、サーバーの帯域がいっぱいになる。CDN事業者を変えても、オリジンへの攻撃が続く。この場合はまず、攻撃がCDNを迂回してサーバーのIPアドレスに直接届いていないか確認します。

オリジンIPが露出したWebサイトでは、DDoS対策CDNとオリジンへのアクセス制限を組み合わせる方法が考えられます。一方、攻撃でオリジンの上流回線がすでに輻輳している場合や、サービスに公開TCP/UDPポートが必要な場合は、上流でのトラフィックスクラビング、DDoS対策IPサービス、DDoS対策サーバーも併せて検討する必要があります。IPの変更も対策の一部ですが、先に露出の原因を塞ぐことが重要です。

攻撃が届いている場所を特定してからサービスを選ぶ

オリジンは、Webサイトのプログラム、API、ゲームサービスを実際に動かすサーバーです。IPアドレスが知られたことと、サーバーへの侵入は別の問題です。確認すべきなのは、そのアドレスがどの接続を受け付け、攻撃によってどこのリソースが枯渇するかです。

「ブラックホール」は通常、事業者が自社ネットワークを守るため、特定の宛先IPへのトラフィックを破棄する措置を指します。正規のアクセスも停止する可能性があります。発動条件、継続時間、解除方法は、該当する事業者の規定を確認してください。

サービスが停止している場合は、移行を検討する前に、現在の事業者へ攻撃時間、対象IP、流入トラフィック、ブラックホールの有無を確認します。CPU使用率の上昇、Webサイトのタイムアウト、CDNのアラートだけでは、どの層が攻撃されているか判断できません。

オリジンIPが露出すると、DDoS対策CDNの導入後も攻撃されるのはなぜか

Webサイト向けCDNは通常、利用者とオリジンの間に配置されます。利用者はエッジロケーションにアクセスし、必要に応じてエッジがオリジンからデータを取得します。

しかし、攻撃者がオリジンIPを知っていれば、そのIPへ直接接続できます。CDNを通過しないトラフィックが、Webサイト向けプロキシサービスの保護を受けるとは限りません。

負荷は次の2種類に分けて考えます。

• アプリケーションへのリクエスト負荷：ログイン、検索、照会などのAPIに大量のリクエストが届き、アプリケーション、データベース、接続プールのリソースを消費します。
• ネットワークと接続への負荷：大量のパケットや接続が回線容量、ネットワーク機器、サーバーのリソースを消費し、アプリケーションにリクエストが届く前に障害を引き起こすことがあります。

AWSのインフラストラクチャ層への攻撃に関する解説では、UDPリフレクションやSYNフラッドなどがネットワーク容量やシステムリソースを枯渇させ得ること、緩和には攻撃をフィルタリングまたは吸収できる容量が必要なことが説明されています。Webサイトが403を返すことと、オリジンが大規模な攻撃トラフィックに耐えられることは別です。

403は、特定のHTTPリクエストが拒否されたことを示すだけです。オリジンの手前の回線がすでに飽和していれば、Nginxのルールやホストのファイアウォールでリクエストを拒否しても、消費された上流の容量は戻りません。ボトルネックの手前でフィルタリングする場合は事情が異なります。調達時には、トラフィックが実際にどこで破棄・スクラビングされるのか確認しましょう。

導入前に、露出しているオリジンの入口をどう確認するか

ドメイン、アドレス、サービスポートを洗い出す

メインドメインだけを調べるのでは不十分です。自社の公開IPv4・IPv6アドレス、サブドメイン、サービスを一覧にし、特に次を確認します。

• 以前のDNSレコード、テストサイト、管理画面、予備ドメインが今もオリジンを指していないか。
• メインドメインはCDNを経由していても、別のAレコードやAAAAレコードで直接接続できないか。
• メールサービスとWebサイトが同じ公開IPを共有していないか。
• ページのリソース、API設定、公開しているコールバックURLにオリジンのアドレスが含まれていないか。
• SSH、リモートデスクトップ、データベース、管理パネルをインターネット全体に公開する必要があるか。

Cloudflareのオリジン保護のドキュメントでは、プロキシされていないDNSレコード、メールの構成、過去のDNSレコードを確認し、プロキシ導入後にオリジンIPの変更を検討するよう勧めています。現在のDNSにオリジンが表示されなくても、旧アドレスが記録されていないとは限りません。

こうした入口をまだ整理していない場合は、当社のオリジンIPが露出する経路と保護方法の記事を資産の棚卸しに活用し、現在の設定を一つずつ検証してください。

ssがインストールされたLinuxのオリジンでは、まず次の読み取り専用コマンドを実行できます。

ss -lntup

ssのマニュアルに記載されたオプションによると、このコマンドは待ち受け中のTCPポートと関連するUDPソケットを一覧表示し、アドレスとポートを数値で示すとともに、対応するプロセスの表示を試みます。プロセス情報の一部には適切な権限が必要です。

Local Address:Portに注目してください。0.0.0.0や[::]にバインドされたサービスはアクセス範囲を確認すべきですが、ローカルで待ち受けているだけで公開インターネットから到達できるとは限りません。クラウドのセキュリティグループ、ファイアウォール、ポート転送も確認します。逆に、IPv4だけではIPv6の入口を見落とす可能性があります。

直接接続の検証には正しいホスト名を使う

ブラウザーで「https://源站IP」にアクセスできなくても、CDNを迂回できない証拠にはなりません。サーバーはホスト名に応じてサイトや証明書を選ぶ場合があり、IPへの直接アクセスでは既定のサイトを見ているだけかもしれません。

次のコマンドは、curlがインストールされたLinuxまたはmacOSのターミナルで使用します。自身が所有する、または管理を許可されたオリジンのみをテストしてください。例示のドメインとドキュメント用IP 192.0.2.10を実際の設定に置き換え、オリジンへの接続が許可されたリストに含まれない外部ネットワークから、1回リクエストを送ります。

curl --noproxy '*' -sS --connect-timeout 5 --max-time 10 \
  --resolve 'www.example.com:443:192.0.2.10' \
  -D - -o /dev/null \
  -w '\nstatus=%{http_code} remote=%{remote_ip}\n' \
  'https://www.example.com/'

curlの--resolveに関する説明によると、このオプションで指定したホストとポートに対する接続先アドレスを設定できます。このテストではURLのホスト名とHTTPSハンドシェイクで使うサーバー名を維持しながら、指定したオリジンIPに接続します。--noproxy '*'はローカルのプロキシ設定を回避し、2つのタイムアウト指定は待機時間を制限します。

まずremoteが対象のオリジンアドレスか確認し、レスポンスヘッダーとオリジンのログを併せて判断します。

オリジンでCloudflare Origin CA証明書を使用している場合、CloudflareのOrigin CAドキュメントによると、プロキシを停止してブラウザーから直接アクセスすると、証明書が信頼されないというエラーが生じることがあります。別のCDNに切り替える際も、既存の証明書を信頼すると決めつけず、オリジン証明書の検証要件を個別に確認してください。

このような低頻度の確認は到達性を調べるためのものです。DDoS対策能力の試験ではなく、1回の成功・失敗から、すべての地域やプロトコルでの結果を推定することもできません。

DDoS対策CDNとオリジンの分離を優先すべきケース

主なサービスがWebサイトやHTTPS APIで、既存サーバーが正常に動作し、主な課題が悪意あるリクエストと入口の露出であれば、アプリケーションサーバーを維持する方法をまず検討できます。Webサイトの入口をDDoS対策CDNで受け、オリジンへのアクセス範囲を絞ります。

通常はアプリケーションの移行作業を減らせますが、次の3点を併せて実施する必要があります。

保護が必要な入口をすべて接続する。

トップページだけでなく、ログインAPI、画像用ドメイン、ファイルのアップロード・ダウンロード、WebSocketなども確認します。各サービスへの対応可否、タイムアウトやサイズの制限は事業者の実際の設定に基づいて確認してください。キャッシュヒット率を上げるために、動的レスポンスに含まれる利用者の個人データを誤ってキャッシュしないようにします。

オリジンが受け付ける接続元を制限する。

事業者からオリジン向けの実際の送信元IPアドレスと更新方法を入手し、通常のオリジンへのリクエスト、ヘルスチェック、運用管理のアクセスを区別します。CDNからの接続を許可するからといって、管理パネルやデータベースまで同じCDNアドレスに公開する必要はありません。

オリジンへのリクエスト認証を検討する。

送信元IPの許可リストは接続元を絞れますが、共有の送信元IPだけでは顧客ごとのリクエストを区別できない場合があります。自社サービスに適した専用の認証情報や相互TLS認証に対応するか確認し、秘密情報の保護、ローテーション、失効方法も確かめてください。Hostヘッダーだけでは、リクエストが自社のCDNから来たことを証明できません。

アクセス制限を強める前に、正常なオリジンへの接続、運用管理、監視、証明書の更新が引き続き機能するか確認します。「それ以外の送信元をすべて拒否」というルールを本番環境へ一度に適用すると、自社のサービスを止めてしまう可能性があります。

CDN07のDDoS対策CDNサービスは、コンテンツ配信とDDoS対策を組み合わせ、エッジロケーション、帯域、セキュリティポリシーに応じた構成を検討できます。海外に既存のオリジンを持つWebサイトは、現在の構成に照らして評価できます。具体的なオリジン認証方式、送信元アドレスの管理、対応ポートは導入前に個別に確認してください。

オリジンの上流対策やDDoS対策サーバーに予算を振り向けるべきケース

攻撃がオリジンのネットワーク可用性に直接影響している

事業者がオリジンIPへの継続的な大規模攻撃を確認し、回線の輻輳やブラックホールがオリジンへの接続に影響しているなら、Webサイト向けCDNプランのアップグレードだけでは現在の障害を解消できない可能性があります。

現在の事業者が上流の保護を追加できるか、サービスに合うDDoS対策IPサービスがあるか、IP変更と完全なアクセス制限を組み合わせられるか、適切な保護を備えたサーバーへの移行が妥当かを比較します。

DDoS対策サーバーへの移行だけが選択肢ではありません。既存の基盤で必要な上流スクラビングを利用できるなら、データベースの移動、ストレージの切り替え、ネットワークの再設定を減らせる可能性があります。逆に、必要な保護やネットワーク接続を既存基盤が提供できなければ、移行を検討する根拠になります。

DDoS対策サーバーの調達時には、攻撃トラフィックの処理場所、保護対象のIPとポート、契約上の上限を超えた場合の扱いを確認します。CPUやメモリの増強はアプリケーションの処理に役立ちますが、回線の保護には代わりません。

CDN07は香港のDDoS対策サーバーも提供しています。オリジンの配置先を変える必要がある場合は、サーバーリソース、ネットワーク接続、保護条件を一つの構成として評価できます。保護範囲、通常時の帯域、上限超過時の規定は、見積書とサービス契約に明記してもらいましょう。

Webサイト向けCDNでは直接扱えないポートを使用する

ゲームの対戦通信、音声通信、独自のTCP/UDPプロトコルは、ドメイン名を使っているだけで通常のWebトラフィックになるわけではありません。プロトコル、ポート、接続時間、クライアントの接続方法を確認します。

例えば、ゲームの公式サイトはWebサイト向けCDNを利用できても、ゲーム接続用のポートには別の保護が必要な場合があります。クライアントを変更できるプロジェクトでは、ゲームセキュリティSDKとDDoS対策IPサービスの比較を参考に導入作業を比較できます。クライアントを変更できない場合は、サーバー側の対策が既存プロトコルに対応するか、特に確認してください。

DDoS対策サーバーも、あらゆるサービスを自動的に保護するわけではありません。ポート、プロトコル、接続数、スクラビングのポリシー、攻撃中のサービス条件を具体的に確認する必要があります。

IPを変更すれば解決するか。新しいアドレスの再露出をどう防ぐか

IP変更によって、既知の旧アドレスで元のサービスを提供しなくなり、そのアドレスが狙われ続けるリスクを減らせます。ただし、ドメイン、メール、API設定に残る露出経路は自動的には解消せず、新しいアドレスが将来見つからない保証もありません。

次の順序で進めることを勧めます。

1. 依存関係を整理する。旧IPに依存するプログラム、外部サービスのコールバック、データベースの許可リスト、監視を特定し、設定のバックアップと切り戻し計画を用意します。
2. 新アドレスとアクセスルールを準備する。新しいオリジンで本番サービスを受ける前に、必要なCDNからの接続と管理アクセスを設定し、IPv4とIPv6を確認します。
3. CDNから新しいオリジンへの接続を検証する。トップページだけでなく、証明書、オリジンのホスト名、ログイン、アップロード、API、長時間接続を確認します。
4. 段階的に切り替えて監視する。CDNとオリジンのログを照合し、異常なステータスコード、リクエスト数、サービス処理の成功状況を確認します。
5. 旧アドレスと見落とした入口を処理する。移行完了を確認してから旧入口を停止し、予備ドメインが迂回経路として残らないようにします。

デバッグのために新しいオリジンIPを一時的に公開DNSへ登録し、後で削除する方法は避けてください。切り替えに失敗した際も、影響を評価せずに利用者のトラフィックをすべて無防備なオリジンへ直接向けないでください。

身に覚えのない管理者、ファイルの改ざん、認証情報の漏えいなど、侵入の兆候があれば、別途インシデント対応が必要です。IP変更やDDoS対策の導入は、侵入調査の代わりにはなりません。

見積もりでは何を比較すればよいか

「何Gbpsまで防御できるか、月額はいくらか」だけでは十分ではありません。自社サービスの入口と障害の記録を事業者へ共有し、同じ課題に対する解決費用として比較します。

Webサイトへの悪意あるリクエストとオリジンIPへの攻撃を同時に受けている場合は、DDoS対策CDNと保護されたオリジンを組み合わせられます。ただし、両方を購入することを前提にはしません。まず不足している保護を特定し、必要な層を追加します。

アプリケーション側の認証、適切なレート制限、脆弱性の修正も継続してください。当社のWAF、ボット管理、DDoS対策の連携では、各仕組みの役割を説明しています。選定時には、ネットワーク攻撃、悪意あるリクエスト、サービスの不正利用をそれぞれどのポリシーで処理するか確認し、すべてを「DDoS対策」という名称だけで判断しないようにします。

よくある質問

オリジンIPが露出していても、DDoS対策CDNは有効ですか。

はい。CDNを通るトラフィックには、そのコンテンツ配信と保護を適用できます。ただし、既知のオリジンIPへの直接接続には別の対策が必要です。アクセス制限、オリジンへのリクエスト認証、アドレス変更、上流での保護などを検討します。

CDNのエッジからだけオリジンへの接続を許可すれば、すべてのDDoS攻撃を防げますか。

いいえ。主な効果は、オリジンがサービスへの接続を受け付ける送信元を絞ることです。フィルタリングがホスト内で行われ、攻撃で上流回線が輻輳していれば、正常なCDNからの接続も失敗する可能性があります。フィルタリングの場所、上流容量、事業者のスクラビング方法も確認してください。

サーバーIPを変更できない場合、移行するしかありませんか。

必ずしもそうではありません。まず現在の事業者に既存アドレスの上流保護が可能か尋ね、サービスと管理用の入口を制限できるか確認します。保護能力、プロトコルへの対応、ネットワーク条件が要件を満たさなければ、移行費用を比較します。

DDoS対策サーバーへ移行した後も、DDoS対策CDNは必要ですか。

Webサイトにコンテンツ配信、表示速度の改善、入口でのきめ細かなポリシーが引き続き必要かによります。サーバーとCDNの役割には重なる部分も異なる部分もあります。すでに満たしている要件のために重複して購入する必要はありません。

オリジンにpingが通らなければ、IPの秘匿は成功していますか。

いいえ。pingはICMPを使い、WebサイトのHTTPS接続とは異なります。サービスへの直接接続を許可しているかは、実際のホスト名、ポート、プロトコルで検証してください。過去にIPが露出したかどうかもpingでは分かりません。

対策が有効だったことをどう確認しますか。

正規の利用者がサービスを使えるか、CDNが安定してオリジンへ接続できるか、許可されていない送信元がアクセス制御を迂回できないか、以前のドメインやIPv6の入口が制限されたかを、それぞれ確認します。大規模攻撃への対応能力は、サービス条件、スクラビングの仕組み、双方が許可したテスト計画に照らして評価する必要があります。数回のcurlリクエストでは証明できません。

オリジンIPが露出した後、次に何をすべきですか。

• DDoS対策CDNが主に保護するのは、CDNを通過するトラフィックです。オリジンへの直接攻撃は別途評価します。
• アクセス制御は迂回経路を減らせますが、上流回線の保護には代わりません。
• IP変更は、露出経路の調査、オリジンへの接続確認、旧入口の廃止と併せて進めます。
• DDoS対策サーバーへ移行するかは、ネットワーク保護、サービスのプロトコル、既存基盤の能力によって判断します。

サービスのドメイン、プロトコルとポート、対象利用者の地域、オリジンの所在地、事業者が提供する攻撃記録を整理してください。オリジンアドレスやログは、機密設定を公開せず、アクセスを管理できる連絡手段で共有します。

CDNの導入とオリジンの移行を比較する際は、この一覧を用意してCDN07に保護構成をご相談ください。入口、CDNからオリジンへの接続、オリジン自体を分けて整理してから、製品の組み合わせと見積もりを決めれば、不足している保護に予算を充てられます。