DDoS攻撃の仕組みと対策入門｜レイヤー別の防御とCDN・クラウドの活用

「サイトが突然重くなり、アクセスログを見ると海外の大量のIPから同じURLに秒間数百のリクエストが来ている」「サーバーを増強したのに数分で再び落ちた」「攻撃は止んだが、翌月のクラウド請求が普段の何倍にもなっていた」。DDoS攻撃は大企業だけの問題ではなく、中小規模のサービスでも競合や愉快犯、脅迫目的で狙われます。

この記事では、DDoS攻撃をボリューム型・プロトコル型・アプリケーション層攻撃の3つに分けてそれぞれの仕組みを説明し、なぜ自前サーバーの増強では防げないのか、CloudflareやAWS Shieldといった標準防御がどう機能するのか、オリジンIPを隠す構成、レートリミットとBot対策、攻撃を受けたときの初動手順、そして防御に成功しても費用で潰される「Denial of Wallet」への備えまでを解説します。CDNの基本的な仕組みはCloudFrontの解説を、WAFはWAFの仕組みと導入を参照してください。

DDoS攻撃の3つのタイプ

ボリューム型：回線を埋める

DDoS（分散型サービス妨害）は、多数の送信元から同時に大量の通信を送りつけ、サービスを使えなくする攻撃です。ボリューム型は最も単純で、サーバーの処理能力ではなくネットワーク回線の帯域を埋めます。UDPフラッドや、DNS・NTP・memcachedなどの応答が大きいプロトコルを悪用して小さなリクエストで巨大な応答を被害者に向けさせる増幅攻撃が典型で、攻撃規模は数百Gbpsから数Tbpsに達することがあります。回線が埋まれば、サーバーがどれだけ高性能でも正規のパケットが届きません。

プロトコル型：接続テーブルを埋める

TCPの3ウェイハンドシェイクを途中で放置するSYNフラッドが代表例です。サーバーはSYNを受けるとSYN-ACKを返して接続状態を保持しますが、ACKが返ってこない半開き接続が大量に溜まると、接続テーブルやファイアウォールの状態管理が枯渇し、新しい正規の接続を受け付けられなくなります。帯域は余っていても、OSやロードバランサーの状態管理の上限が先に尽きるタイプです。

アプリケーション層攻撃：見た目は正常なリクエスト

HTTPフラッドは、ブラウザと区別のつかない正常なGET/POSTを大量に送ります。特に、検索やレポート生成のようにサーバー側で重い処理が走るURLを狙えば、少ない通信量で大きな負荷をかけられます。攻撃者は帯域をほとんど使わず、被害者はDBやアプリサーバーのCPUが尽きる、という非対称性が特徴です。ボリューム型やプロトコル型がネットワーク機器で見分けやすいのに対し、アプリ層攻撃は正規のトラフィックとの区別が難しく、対策も別の層で行う必要があります。

タイプ	枯渇させるもの	代表例	主な防御層
ボリューム型	回線帯域	UDPフラッド、DNS/NTP増幅	CDN・クラウドのエッジで吸収
プロトコル型	接続テーブル・状態管理	SYNフラッド、ACKフラッド	エッジのSYNクッキー、LB
アプリ層	CPU・DB・アプリのワーカー	HTTPフラッド、重いAPIの連打	WAF・レートリミット・Bot判定・キャッシュ

なぜ自前サーバーの増強では防げないのか

「攻撃が来たらサーバーを増やせばよい」という発想は、ボリューム型に対してはほぼ無力です。あなたのサーバーが1Gbpsの回線につながっていれば、10Gbpsの攻撃が来た時点でサーバーの手前の回線が埋まり、サーバーの台数は関係ありません。防御はサーバーの前、つまり攻撃トラフィックが自分の回線に到達する前で行う必要があり、それができるのは世界中に分散した大容量のネットワークを持つCDNやクラウド事業者だけです。アプリ層攻撃に対しては増強が一時的に効くこともありますが、攻撃者側の追加コストがほぼゼロなのに対し、防御側はサーバー費用が線形に増えるため、消耗戦になれば必ず負けます。

CDN・クラウドの標準防御を使う

Cloudflare・AWS Shieldの仕組み

CloudflareはDNSを向けるだけで、全リクエストが世界中のエッジで受け止められ、ボリューム型・プロトコル型の攻撃はエッジのネットワーク容量で吸収されます。無料プランでも帯域無制限のDDoS緩和が含まれており、中小規模のサービスにとっては最も費用対効果の高い第一手です。AWSではShield Standardがすべてのアカウントで自動的に有効で、CloudFront・Route 53・ALBなどに来るネットワーク層・トランスポート層の攻撃を追加費用なしで緩和します。より大規模な攻撃への対応チームやコスト保護が必要な場合は、月額3,000USD（1年契約）のShield Advancedがあります。

いずれも共通するのは、防御が効くのはCDN・LBを経由したトラフィックだけという点です。EC2のパブリックIPに直接来る通信は、Shield Standardの緩和範囲が限定的で、Cloudflareに至っては一切関与できません。

オリジンIPを隠す

CDNの後ろにいるサーバー（オリジン）のIPアドレスが知られていると、攻撃者はCDNを迂回して直接オリジンを叩けます。過去のDNS履歴、メールのヘッダー、エラーページ、サブドメインの設定漏れ（direct.example.comなど）からIPは漏れやすいため、「知られない」より「知られても届かない」構成にします。

1. オリジンのセキュリティグループ／ファイアウォールで、CDNのIPレンジからの通信だけを許可する。
2. CDNからオリジンへのリクエストに秘密のヘッダーを付け、オリジン側で検証する（IP制限の補助）。
3. CDN移行時にオリジンのIPを変更する（過去のDNS履歴に残った旧IPを無効化）。
4. オリジンのドメインを推測しにくい名前にし、DNSに公開しない。

# AWS: CloudFrontのオリジン向けIPレンジ（マネージドプレフィックスリスト）だけを許可
# プレフィックスリストIDの確認
aws ec2 describe-managed-prefix-lists \
  --filters Name=prefix-list-name,Values=com.amazonaws.global.cloudfront.origin-facing \
  --query 'PrefixLists[0].PrefixListId' --output text

# セキュリティグループにそのプレフィックスリストからの443だけを許可
aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --ip-permissions 'IpProtocol=tcp,FromPort=443,ToPort=443,PrefixListIds=[{PrefixListId=pl-xxxxxxxx}]'

# Nginx: Cloudflare経由以外を拒否し、実IPをCF-Connecting-IPから復元
# （CloudflareのIPレンジは公式の一覧から定期更新する）
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
# ... 公式一覧のレンジを列挙 ...
real_ip_header CF-Connecting-IP;

server {
    listen 443 ssl;
    # CDNが付与する秘密ヘッダーがなければ拒否
    if ($http_x_origin_secret != "長いランダム文字列") {
        return 403;
    }
    ...
}

ドメインとDNSの設定変更が伴うため、切り替え手順はドメインとDNS設定のガイドを参考に、TTLを短くしてから実施してください。

アプリ層攻撃への対策｜レートリミットとBot対策

エッジで落とす、キャッシュで受けない

HTTPフラッドはエッジのDDoS緩和だけでは正規リクエストと区別できないことがあり、追加の対策が必要です。

• レートリミット：IPあたり、またはIP＋パスあたりのリクエスト数に上限を設ける。CDNのレートリミットルールで、オリジンに届く前に落とす。ログイン・検索・APIなど重い処理のパスは個別に厳しくする。アプリ側のレート制限は最後の砦として併用する
• Bot判定・チャレンジ：CloudflareのBot FightモードやAWS WAFのBot Control、あるいはJavaScriptチャレンジ／マネージドチャレンジを、攻撃中だけ全体または特定パスに適用する
• キャッシュ可能にする：トップページや一覧など、動的に見えて実は数十秒キャッシュしても問題ないページをCDNでキャッシュすると、フラッドがオリジンに届かなくなる。攻撃対策としてのキャッシュは、平常時の高速化と同じ投資で済む
• 重い処理の保護：検索やレポート生成など計算コストの高いエンドポイントは、認証必須にする、非同期化する、結果をキャッシュする

# Cloudflare レートリミットルール（式の例）
# 対象: /api/search へのリクエスト
(http.request.uri.path eq "/api/search")
# 条件: 同一IPから10秒間に20回を超えたらブロック（Free/Proは秒数・アクションに制限あり）
# アクション: Block、期間: 10秒

攻撃を受けたときの初動と「Denial of Wallet」への備え

初動の手順

1. 攻撃かどうかを見極める：CDN・LBのメトリクスで、リクエスト数・送信元の国別分布・User-Agent・対象URLの偏りを確認する。正規のバズや自社のバッチの暴走と区別する。
2. エッジの防御を強める：Cloudflareなら「Under Attack Mode」を有効化して全訪問者にチャレンジを課す。AWS WAFならレートベースルールの閾値を下げ、攻撃元の国やASNをブロックするルールを追加する。
3. オリジンを守る：CDNを迂回した直撃がないか、オリジンのアクセスログとセキュリティグループを確認する。
4. 記録と連絡：時系列・対象・規模・取った対策を記録し、経営層と顧客向けの状況連絡を出す。脅迫メールが来ている場合は支払わず、警察・IPAへの相談を検討する。
5. 収束後の見直し：攻撃が届いた経路をふさぎ、レートリミットの恒久設定を見直す。

Denial of Wallet：防御に成功しても請求で潰される

従量課金のクラウドでは、DDoSを「捌けてしまう」こと自体がリスクになります。オートスケールでサーバーが増え続ける、CloudFrontやLambdaのリクエスト課金が跳ね上がる、転送量課金が桁違いになる、といった形で、サービスは落ちなくても請求が事業を傷つけます。これがDenial of Wallet（EDoS）です。備えとして次を決めておきます。

• 予算アラート：AWS Budgets・GCPの予算アラートで、日次・月次の想定額を大きく超えたら即通知する
• スケールの上限：オートスケーリングの最大台数、Lambdaの同時実行数、API Gatewayのスロットリングに上限を設定し、「無限に捌く」状態にしない
• 安い層で止める：Cloudflareの無料・固定額のDDoS緩和やレートリミットで、従量課金の層に届く前に落とす。CloudFront＋WAFの組み合わせでも、WAFで落とした分はオリジンやLambdaの課金が発生しない
• コスト保護の確認：AWS Shield Advancedには攻撃によるスケールアウト費用のクレジット制度がある。契約するかどうかはサービスの売上規模と照らして判断する

トラブル事例：Cloudflareを入れたのにサーバーが落ちた

症状：Cloudflareを導入済みのサイトがHTTPフラッドで停止。Cloudflareのダッシュボードには攻撃トラフィックがほとんど記録されていなかった。
原因：オリジンのVPSは以前から同じグローバルIPを使っており、過去のDNS履歴サービスからIPが判明していた。攻撃者はCloudflareを経由せず、そのIPに直接HTTPフラッドを送っていた。VPSのファイアウォールは80/443を全開放しており、CDN経由以外の通信を制限していなかった。
対処：ファイアウォールをCloudflareのIPレンジからの443のみ許可に変更し、直撃を遮断。あわせてVPSのIPを変更し、旧IPを解放した。Nginxにはオリジン秘密ヘッダーの検証を追加し、Cloudflare側では/api/配下にレートリミットを設定。「CDNを入れた」だけでは防御にならず、「CDN以外から届かない」状態にして初めて機能する、という典型例でした。

まとめ

DDoSはボリューム型・プロトコル型・アプリ層の3タイプに分かれ、前二者はサーバーの手前で吸収するしかないためCDNやクラウドの標準防御に任せ、アプリ層はレートリミット・Bot判定・キャッシュで対処します。いずれも「オリジンにCDN以外から届かない」構成が前提で、これが崩れると防御は迂回されます。攻撃時の初動手順をあらかじめ決め、予算アラートとスケール上限でDenial of Walletにも備えてください。自社サービスのDDoS耐性の診断や、CDN・WAF・オリジン保護の構成設計については、Harmonic Societyのシステム開発・インフラ支援にご相談ください。