CDNによる配信とDDoS対策

読み：しーでぃーえぬによるはいしんとでぃーどすたいさく　／　英語表記：CDN delivery and DDoS mitigation design

CDNの複数の配信拠点を利用して、オリジンサーバへの集中を抑えるための設計である。キャッシュによる負荷分散に加え、利用者までの経路、サービスの監視、DDoS攻撃を遮断する場所と範囲を検討する。

イマシルちゃんの解説

同じ動画や画像を大勢が見ようとすると、元のデータを置くサーバと回線に通信が集中するんだ。
そこで各地の配信拠点にコピーを保存し、利用者への配信を分担するのがCDNというネットワークサービスだよ。
設計では、どの拠点へ届けるかと、拠点内のどのサーバに任せるかを分けて考えるんだ。
攻撃への対策も大切で、サーバの直前まで大量の通信が届いてから止めると、その途中の回線が混雑してしまう。
配信を分散する仕組みと、通信の入口で攻撃を抑える仕組みを組み合わせることで、ほかの利用者への影響を小さくしていくよ。

より深い解説

配信を分担する二つの段階

CDNでは元のコンテンツを持つオリジンサーバと、各地でコンテンツのコピーを一時保存して配信するサーバを分ける。保存したコピーがキャッシュである。配信拠点はPOP（Point of Presence）とも呼ばれる。要求されたコンテンツをキャッシュから返せれば、元のサーバまで毎回取りに行く必要がなくなる。

利用者がアクセスすると、まず配信を担当する拠点が選ばれる。その拠点ではロードバランサが複数のサーバへ要求を振り分ける。拠点の選択とサーバの選択は別の処理であり、使う情報も異なる。

キャッシュにない場合や更新が必要な場合は、オリジンサーバへのアクセスが発生する。CDNを導入した後も、元のサーバから取得するときの負荷と更新時の通信量を見積もる必要がある。利用者固有の情報を誤って共有キャッシュに保存しないよう、HTTPのCache-Controlなどによる制御も確認する。

サーバの負荷とサービスの状態を分けて確認する

ラウンドロビン方式は接続を順に割り振る。各接続の処理時間が同程度なら負荷を分散しやすいが、大きなファイルの転送とすぐに終わる要求が混在すると、接続を受けた回数だけでは現在の負荷を判断しにくい。このような条件で同時接続数をそろえたい場合は、最少接続数方式が候補になる。ただし接続数とCPU使用率が常に比例するわけではなく、サーバの性能差や処理内容も考慮する。

振り分け先の監視では、確認できる範囲を意識する。ICMP Echoに応答しても、Webサーバのプロセスが停止していることはある。HTTPで特定のURLへアクセスし、期待するステータスや応答内容を確認すれば、アプリケーションの動作まで検査できる。監視用ページだけが成功し、実際の業務処理は失敗する構成にも注意する。

HTTPSをロードバランサで復号してバックエンドへHTTPで転送する構成では、外部からのTLS接続を受け付けるのはロードバランサである。したがって、その装置にサーバ証明書と対応する秘密鍵が必要になる。バックエンドまでHTTPSで再暗号化する構成と、暗号化された通信をそのままサーバへ通す構成では証明書を配置する装置が変わる。IPアドレスだけでなく、どの装置が暗号化通信の終端になるかを追う。

配信拠点への経路を決める

BGPを利用したエニーキャストでは、複数の拠点から同じ宛先プレフィックスへの経路を広告する。利用者のパケットは各ASの経路選択に従い、いずれかの拠点へ届く。地理的な距離だけで配信先が決まるわけではない。

BGPの代表的な判断材料を次に示す。実際の経路選択には適用条件と優先順位があり、この三項目だけで全ての選択を説明できるわけではない。

MEDは通常、同じ隣接ASから受け取った経路同士で比較する。設定によって比較条件が変わるため、「常に全経路のMEDを比較する」と覚えない。AS_PATHの長さだけで決める問題では、他の属性が選択に影響しないという前提を先に確認する。

IXは複数のネットワークが相互接続する場所である。IXで直接ピアリングすれば、トランジット事業者を経由する経路とは異なる経路を使える。IXへの接続だけで全参加者と自動的に経路を交換するわけではなく、BGP接続と経路交換の合意が必要になる。

要求と配信データの向きを分けて追う

利用者が要求を送るときの宛先は配信サービスである。一方、配信拠点がデータを返すときの宛先は利用者側になる。往路と復路では参照する宛先プレフィックスが異なるため、通過するASが同じになるとは限らない。

経路図を読むときは、次の順に整理する。

1. 追っているパケットの送信元と宛先を決める。
2. その時点のルータが持つ、宛先への経路候補を取り出す。
3. 問題文や設定で与えられた優先条件を適用する。
4. 応答についても送信元と宛先を入れ替えて確認する。

例えば配信拠点が利用者側プレフィックスへの不正な経路を受け入れると、配信データが誤った方向へ送られるおそれがある。「受信した経路情報」は、そのルータから当該宛先へ送信する通信の判断に使われる。この関係を押さえると、経路広告の矢印と実際のデータの向きを混同しにくい。

BGP接続と経路情報をそれぞれ保護する

BGPのTCP接続を保護する認証と、広告された経路が適切かを判断するフィルタリングは役割が異なる。共有秘密に基づくTCP MD5認証は、秘密を知らない相手による不正なBGP接続やTCPセグメントの偽装を防ぐために用いられてきた。後継にはTCP-AOもある。

接続相手が正しくても、誤ったプレフィックスを広告する可能性は残る。そこで許可するプレフィックスやAS番号を定め、経路フィルタリングを行う。経路情報を登録するIRRのデータは、フィルタ作成に利用できる。IPアドレスなどの資源の利用権限を証明するRPKIでは、どのASがプレフィックスを広告してよいかをROAで示し、経路の起点ASを検証する。起点の検証だけで、途中のAS_PATH全体の正しさまで保証されるわけではない。

攻撃の観測と遮断を組み合わせる

DDoS攻撃の検知には、流入する通信量や送信元、宛先、ポート番号などの情報を使う。NetFlowは通信フローの情報を収集装置へ送る仕組みであり、フローの偏りや増加を調べる材料になる。観測した結果を使ってどのルータへ遮断を指示するかは、別に設計する必要がある。

宛先ベースのRTBHでは、攻撃対象へのホスト経路などをBGPで配布する。BGPコミュニティを目印にし、その経路を受け取ったルータで廃棄用インタフェースへ向けると、対象宛てのパケットを入口で捨てられる。IPv4の1アドレスだけを対象にするホスト経路のプレフィックス長は32ビットである。

サーバ近くのファイアウォールだけで捨てる構成と比べ、内部の回線や機器へ攻撃トラフィックを運ばずに済む。ただし自組織の入口より上流の回線が既に飽和している場合は、その入口での遮断だけでは解決しない。必要に応じて接続事業者側での対策も組み合わせる。

FlowSpecも攻撃を自動で正しく見分ける仕組みではない。条件が広すぎれば正常な通信まで止まり、条件が狭すぎれば攻撃が残る。許可した管理元だけがルールを配布できるようにし、適用後の通信量と誤遮断を監視する。攻撃終了後の解除手順も用意する。

導入時に確認すること

キャッシュ率の高い配信と、毎回元のサーバへ処理を依頼するサービスでは、CDNによる負荷軽減の度合いが異なる。オリジンサーバへ直接到達できる経路が残ると、CDNを迂回したアクセスも発生し得る。公開する入口、許可する接続元、証明書、ログの取得場所を整理する。

障害時にはPOP全体、拠点内のロードバランサ、個々のサーバを区別して監視する。経路を切り替えた際に継続中の接続がどうなるかも試験し、全ての通信が無停止で移ると決めつけない。

参考資料

• IPA「令和6年度春期」問題・解答例・採点講評のネットワークスペシャリスト午後Ⅰ問1。
• RFC 9111でHTTPキャッシュの保存・再利用条件を確認できる。
• RFC 4271とRFC 7454でBGPの属性、経路選択、運用上の保護を確認できる。
• RFC 2385とRFC 5925でBGPにも利用するTCP接続の認証を確認できる。
• RFC 5635、RFC 8955、RFC 3954で通信の観測と遮断方法を確認できる。

午後での問われ方

実際の試験ではここに出る！全1問

ネットワークスペシャリスト

午後Ⅰ

• R6春 問1

この用語が出てくる記事

• RTBH
• BGP FlowSpec