DDoS攻撃とは。ボリューム型・プロトコル型・アプリ層の仕組みと、CDN/WAF/緩和サービスによる対策

DDoS攻撃（Distributed Denial of Service、分散型サービス妨害攻撃）は、多数の発信元から大量の通信や処理要求を一斉に送りつけ、対象のサーバーやネットワークを正常に利用できない状態に追い込む攻撃です。脆弱性を突いてデータを盗む攻撃とは目的が異なり、狙うのは「可用性」、つまりサービスが使える状態そのものです。情報を抜き取られなくても、サイトやAPIが落ちれば売上や信頼は損なわれます。

DDoS攻撃が厄介なのは、一つひとつの通信は正規の利用者のものと区別がつきにくく、しかも発信元が世界中に分散しているため、単純に「この送信元を遮断する」では止まらない点にあります。IPAの情報セキュリティ10大脅威でもDDoS攻撃は組織向け脅威として継続的にランクインしており、規模の大小を問わず備えが求められるテーマです。

この記事では、DDoS攻撃をボリューム型・プロトコル型・アプリケーション層型の3つに分けて、それぞれ何の資源を枯渇させようとしているのかを原理から噛み砕きます。そのうえで、CDN・WAF・専用の緩和（mitigation）サービスがどの層に効き、どこに効かないのかを運用の判断基準とあわせて整理します。

DDoS攻撃の3類型を一枚で把握する#

まず全体像を早見表で押さえます。攻撃が「どの資源を枯渇させようとしているか」で分けると、対策の当てどころが見えてきます。

この表の「規模感」が示すように、ボリューム型は文字どおり物量で押し切る一方、アプリ層型は少ない通信量でも成立します。「うちは大きな回線ではないから狙われても平気」という発想は、アプリ層型に対しては通用しません。むしろ小さな環境ほど、わずかな負荷で限界に達しやすいのです。

ボリューム型: 回線の帯域を溢れさせる#

ボリューム型は最も直感的なDDoSです。対象のネットワーク回線に、処理しきれない量のパケットを流し込み、帯域を埋め尽くします。高速道路にトラックを大量に流し込んで本来の車（正規利用者の通信）が走れなくする、というイメージが近いでしょう。回線が詰まってしまうため、サーバー自体が健全でも外からは到達できなくなります。

この型でよく使われるのが「リフレクション（反射）」と「増幅（アンプ）」です。攻撃者は送信元IPアドレスを被害者のものに詐称し、DNSやNTP、memcachedといった、小さな問い合わせに対して大きな応答を返すサーバーへ要求を送ります。すると応答が一斉に被害者へ返り、攻撃者が出した通信量の何倍もの量が被害者に降り注ぎます。少ない元手で巨大なトラフィックを生み出せるため、攻撃が大規模化しやすいのです。

ボリューム型の防御で重要なのは、「自社の回線やサーバーに届く前に吸収する」という発想です。攻撃トラフィックが自社の回線に到達した時点で帯域は埋まってしまうため、自分のサーバーでパケットを捨てても手遅れになりがちです。だからこそ、広大な帯域を持つCDNや緩和サービスを前段に置き、攻撃を上流で受け止める構成が有効になります。

プロトコル型: 接続を確立させる仕組みを枯渇させる#

プロトコル型は、通信を成立させるための手続き（プロトコル）の特性を悪用します。代表例がSYNフラッドです。TCP通信は、接続を開く際にSYN・SYN/ACK・ACKという3回のやり取り（3ウェイハンドシェイク）を行います。攻撃者は最初のSYNだけを大量に送り、最後のACKを返しません。サーバーは「接続が完成するのを待つ」状態を大量に抱え込み、待ち行列（接続テーブル）が埋まって新規の正規接続を受け付けられなくなります。

ボリューム型が回線の帯域を狙うのに対し、プロトコル型が狙うのはサーバーやファイアウォール、ロードバランサーが持つ「接続状態を管理するための資源」です。ここが重要な誤解しやすい点で、プロトコル型は必ずしも巨大な帯域を必要としません。比較的小さな通信量でも、状態管理のテーブルを溢れさせれば目的を達せられます。帯域監視だけでは見逃しやすいのはこのためです。

防御策としては、サーバー側でSYN Cookieを有効にして接続テーブルを温存する、ファイアウォールやロードバランサーで不完全な接続を早期に切る、といった手があります。ただし機器自体の状態管理資源にも限界があるため、大規模化した場合は前段の緩和サービスで不正なハンドシェイクを成立前にふるい落とす構成が現実的です。

アプリケーション層型: 正常に見える要求でサーバーを疲弊させる#

アプリケーション層型（L7攻撃）は、最も見分けが難しい類型です。OSI参照モデルの第7層、つまりHTTPなどアプリケーションが動く層を狙います。代表例がHTTPフラッドで、トップページや、検索・ログイン・カート計算といった「サーバー側で重い処理が走るエンドポイント」へリクエストを集中させます。

この型がやっかいなのは、一つひとつのリクエストがプロトコル的には完全に正常だという点です。きちんとTCP接続を確立し、正しいHTTPリクエストを送ってきます。通信のレベルでは正規利用者とまったく区別がつかないため、「不正なパケットだから捨てる」という単純な防御が効きません。しかもデータベース問い合わせのような重い処理を狙えば、攻撃者は少ない通信量でサーバーのCPUやメモリ、コネクションプールを枯渇させられます。低帯域でも成立する、というのはこの意味です。

防御では、通信の正しさではなく「振る舞い」で判断する必要があります。同一IPや同一セッションからの異常なリクエスト頻度をレート制限で抑える、自動化されたアクセスをBot対策やCAPTCHAでふるい落とす、URLパターンや挙動の異常をWAFで検知する、といった層を重ねます。アプリ層の入力検証やエラー処理の設計そのものも防御の土台になります。基本的な作り込みについては

CISA・FBI・MS-ISACの共同ガイダンスも、DDoSをボリューム型・プロトコル型・アプリケーション型の3つに分類し、各類型ごとに事前対策・対応・復旧の観点を整理しています。

CDN・WAF・緩和サービスをどう使い分けるか#

対策ツールは「どの層に効くか」を理解して組み合わせることが肝心です。一つの製品ですべての類型を完全に止められるわけではありません。

CDN（コンテンツ配信ネットワーク）#

CDNは世界中に分散したエッジサーバーでコンテンツを配信する仕組みで、DDoS対策としても強力です。Anycastにより攻撃トラフィックを地理的に分散させて受け止め、巨大な総帯域でボリューム型を吸収します。静的コンテンツをキャッシュすればオリジンサーバーへの到達自体を減らせるため、アプリ層型の一部もオリジンに届く前に緩和できます。ただし動的処理やログインのように毎回オリジンへ届くリクエストは素通りしうるため、CDNだけでアプリ層型を完全に防げるわけではありません。

WAF（Web Application Firewall）#

WAFはHTTPリクエストの中身を検査し、不正なパターンや異常な挙動を遮断します。アプリケーション層型に対する中心的な防御で、レート制限やBot判定、シグネチャによる検知を担います。一方で、回線帯域を埋め尽くすボリューム型に対しては、WAFが処理する前にそもそも回線が詰まってしまうため単独では力不足です。WAFは上流のCDNや緩和サービスと組み合わせ、「大量の通信を前段で削ってから中身を精査する」という多層構成で活きます。

DDoS緩和（mitigation）サービス#

DDoS専用の緩和サービスは、通信を一度自社の巨大なスクラビングセンターに通し、攻撃トラフィックだけを洗い落として正常な通信をオリジンへ転送します。常時経由させる方式と、攻撃検知時にだけBGPやDNSで経路を切り替える方式があります。ボリューム型からアプリ層型まで広く対応でき、大規模攻撃に備えるなら中核となる選択肢です。導入時は、平常時の通信が増えても遅延が許容範囲か、切り替え時の中断はないか、といった運用面の検証が欠かせません。

平時に備えておくべきこと#

DDoS攻撃は「受けてから考える」と後手に回ります。CISAなどのガイダンスでも、事前準備・検知・対応・復旧をひとつながりの流れとして整えることが繰り返し強調されています。攻撃を100%防ぐことを目標にするのではなく、影響を小さくし早く復旧できる体制を作る、という発想が現実的です。

よくある質問#

まとめ#

DDoS攻撃は「完璧に防ぐ」よりも「影響を小さく、復旧を早く」を目標に据えるのが現実的です。3つの類型がそれぞれ別の資源を枯渇させようとしていることを理解し、層ごとに当てる対策を組み合わせること。そして攻撃を受ける前に検知と連絡の仕組みを整えておくことが、最終的な被害の差を生みます。アプリケーション側の作り込みについては