DDoS Attack #

DDoS (Distributed Denial of Service, 分散型サービス妨害) は、「多数の送信元から大量の (一見正規な) リクエストを送り、標的のサービスを正規ユーザに使えない状態にする」 攻撃。コードに脆弱性がなくても成立する数少ない攻撃クラスで、「正規リクエストの大群」と「攻撃」が原理的に区別不能 なため、現代インターネットで最も解決が難しい問題の 1 つであり続けている。

「DDoS = 帯域を埋める攻撃」とイメージされがちだが、実態はもっと多彩で、L3/L4 の帯域・状態を埋めるものから L7 のアプリケーションロジックを狙うものまで広い。本稿は DoS と DDoS の違い と DDoS が本質的に難しい理由 から入り、3 つの攻撃カテゴリ を 1 枚の SVG で整理、Reflection + Amplification という DDoS を「桁違いに大きく」する仕組みをもう 1 枚で解剖し、ボットネットの実体、過去 25 年の代表事件、そして 防御の階層 と 被弾時の最初の 30 分 までを通しで扱う。

1. DoS と DDoS — 1 vs N の根本的違い #

DoS は**「1 人の攻撃者がコードの脆弱性を突く」** モデル — Ping of Death (1996) のように「この特殊パケットを送るだけで対象 OS がクラッシュ」する類で、現代では大半が修正済み。DDoS は「コードが正しくても止められない」ため、本質的に異なる問題になる。「水道のホースを 1 万本同時に向けられる」 — 個々のホースは正常な水だが、合計流量が標的の処理能力を超える。

2. なぜ DDoS は本質的に難しい問題なのか #

DDoS が「ベンダーがパッチを出せば終わり」にならない理由は、インターネットの構造的問題 にある:

• Internet は「相互信頼」で設計された — どこからでもパケットが届くのが基本機能。「無関係な大量のパケットを止める」は後付けの戦い
• 送信元 IP の偽装が可能 — UDP は接続を張らないため、送信元 IP を任意に詐称できる。BCP38 (Network Ingress Filtering, RFC 2827) で ISP 側が偽装パケットを落とすべきだが、世界中の ISP の半分以下しか実装していない (CAIDA Spoofer Project の継続調査による)
• アンプ可能なサーバが大量に放置されている — open DNS resolver, NTP monlist, memcached UDP 11211 など、設定不備のサーバが世界中に数百万台残っている
• IoT 機器のセキュリティが壊滅的 — デフォルト admin/admin の Wi-Fi カメラ・ルータが毎日新規に世界中で生まれるため、ボットネットの新規供給が止まらない
• 「攻撃か正規ユーザか」が判別困難 — フラッシュセール開催で正規アクセスが 100 倍になることもあるため、単純な閾値で切ると正規ユーザを落とす

つまり DDoS は 「自社のサーバを完璧にしても、上流の経路や踏み台や送信元偽装の問題は自社で直せない」という構造を持っている。Cloudflare / AWS Shield / Akamai のような巨大事業者の anycast 網と容量で受け止める モデルが現実解になっているのは、この構造的な問題への適応である。

3. 攻撃の 3 分類 — Volumetric / Protocol / Application #

DDoS は何を枯渇させるかで 3 つに大別される。それぞれ防御方法が違うので、種類を見分けることが対応の最初の判断になる。

3 種類の攻撃の対比を 1 文ずつでまとめると:

• Volumetric = 「水道管に水を流し過ぎて溢れさせる」 (回線をパンクさせる)。家庭・中小企業の対策は本質的に上流任せ — 自社で 100 Gbps の攻撃は受けきれない
• Protocol = 「受付のカウンタを未完了の客で埋める」 (SYN flood で TCP ハーフオープン状態を作り尽くす)。SYN cookies で対応可能
• Application = 「正規の手順で重い処理を要求する」 (/search?q=xxx を毎秒 100 万回叩く / Slowloris で接続を握ったまま放さない)。最も区別が難しい

現代の DDoS は複数を組合せる — 1 GB/s の UDP flood で帯域を圧迫し、同時に 100 万 rps の HTTP flood をアプリに浴びせる「multi-vector attack」が標準。

4. Reflection + Amplification — 桁違いの威力を出す仕組み #

DDoS が「Tbps 級」になる主な理由は、Reflection (反射) と Amplification (増幅) の組合せ。1 つの小さなクエリを送ると、複数倍のデータが別のサーバから返ってくる性質を持つ UDP プロトコルが踏み台にされる。

「攻撃者は 100 Mbps の回線しか持っていなくても、x100 倍の amplifier を踏めば 10 Gbps を出せる」 — これが DDoS が個人レベルで実行可能になっている本体の理由。memcached の x51,200 が衝撃を与えたのは、理論上 1 Mbps の入力で 51 Gbps が出せることが現実に示されたから。

防御側の根本対策は 「世界中の amplifier を閉じる」 だが、設定不備のサーバ・古い IoT 機器・正しく設計されていない UPnP などが続々と新規参入するため、完全には消えない。Shadowserver Foundation や Open Resolver Project といった団体が常時スキャンして amplifier 一覧を公開し、運用者に通知する活動を続けている。

5. ボットネット — DDoS の供給側 #

Reflection が「踏み台サーバ」を使うのに対し、ボットネット は 「乗っ取った端末そのもの」を使う。Mirai (2016) が デフォルトパスワードのまま放置された Wi-Fi カメラ・ルータ を 数十万台規模で乗っ取った 事件以降、IoT ボットネットが DDoS 供給の主力になっている。

ボットネットの典型構造:

• Loader / scanner — Internet 全体に対して 23/tcp (Telnet) / 22/tcp (SSH) / 7547/tcp (TR-069) などを brute force し、デフォルト認証情報のリストでログイン試行
• Implant (マルウェア) — 感染した端末で常駐し、C2 (Command & Control) サーバ からの指示を待つ
• C2 サーバ — IRC / HTTP / Tor hidden service / blockchain で 次の攻撃先・攻撃方法を配信
• 被害者を攻撃 — bot 群が一斉に target に対し SYN flood / HTTP flood / UDP flood を撃つ

近年の傾向は 「数より質」 — 数十万台の IoT より、数千台の高速回線・データセンター VM の方が単純な rps では効率的。Mantis が 5,000 台で 26 Mrps を出した事例が象徴的。

6. 過去 25 年の代表事件 #

「毎年最大記録が更新される」のが DDoS 業界の常態。防御側 (Cloudflare / Akamai / AWS) も急速に容量を拡張しており、2026 年時点で主要な scrubbing 事業者は単独で 100+ Tbps の吸収容量を持つ。

7. 防御の階層 — 何を、どこで、どう止めるか #

DDoS 防御は 多層的 に組まれる。自社で全部やる のは現実的でなく、上流の事業者にどこまで投げるか がコスト設計の本質。

具体的な防御ツールの組合せ例:

# Linux サーバ単体での最低限 (帯域以外)
sudo sysctl -w net.ipv4.tcp_syncookies=1            # SYN flood 緩和
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=8192    # 受付バックログ拡大
sudo sysctl -w net.netfilter.nf_conntrack_max=2000000

# nginx の rate limiting
# /etc/nginx/conf.d/rate.conf
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
location /api {
    limit_req zone=api burst=20 nodelay;
    ...
}

# Cloudflare の API で攻撃時の "Under Attack mode" を即座に有効化
curl -X PATCH "https://api.cloudflare.com/client/v4/zones/$ZONE/settings/security_level" \
     -H "Authorization: Bearer $TOKEN" \
     -H "Content-Type: application/json" \
     --data '{"value":"under_attack"}'

8. 被弾時の最初の 30 分 #

実際に DDoS を受けたときにやることはほぼ決まっている。事前にランブックを作っておくことが何より重要。

1. 被害確認 — どのサービスが落ちているか / どの帯域・rps が異常か / origin 直撃か CDN 経由か
2. 攻撃の種類を識別 — tcpdump, NetFlow, CDN ダッシュボード で L3/L4 (UDP/SYN flood) か L7 (HTTP flood) か を確認
3. CDN/WAF を防御モードに — Cloudflare の "Under Attack mode" / AWS Shield Advanced の Engagement Hotline / Akamai の SOC へ連絡
4. 送信元 IP/国の絞込み — 攻撃元の集中地域があれば一時的に GeoIP block
5. Origin の隔離 — origin の IP を CDN 側 IP のみ許可に。直撃を防ぐ
6. rate limiting の厳しい設定 — /api/* /login /search といった重いエンドポイントを優先的に絞る
7. キャッシュの aggressive 化 — 動的 page も短時間 cache
8. 法執行機関への連絡 — 国によるが、被害規模が大きければ警察 / NICTER / JPCERT への通報を並行
9. 顧客への状況開示 — Status page 更新、SNS で進捗を出す
10. 事後分析 — 攻撃 IP リスト / amplifier の特定 / 追加防御策 / RTO・RPO の見直し

「DDoS の最良の対策は事前準備」。1 度受けてからカード払いで Cloudflare Enterprise に切り替えるより、普段から CDN/WAF の前段に立てて、攻撃を受け流す経路を持っておく ほうが圧倒的に安全。個人サイトでも Cloudflare の無料プランは L7 緩和に十分効く。

DDoS は「コードに脆弱性がなくても成立する数少ない攻撃クラス」であり、インターネットの open 設計と amplifier の遍在 という構造的問題に根ざしているため、ベンダーパッチで解決できない性質を持つ。Volumetric / Protocol / Application の 3 分類と、Reflection + Amplification が「桁違いの威力」を生むメカニズムを理解しておくと、ニュースで「N Tbps の DDoS」と聞いたときに何が起きていたかがすぐに頭の中に組み立てられる。

防御の根本は 「上流に投げる」 こと — Cloudflare / Akamai / AWS Shield のような anycast 網と scrubbing 容量 を持つ事業者に守らせる。自社運用で 1 Tbps の攻撃を受けきるのは、AWS / Google / Microsoft クラスでも厳しい。「DDoS 対策 = CDN/WAF を前段に置く」 が現代インフラの最低基準であり、その後ろに OS の SYN cookies、アプリの rate limit、circuit breaker を多層で積み上げるのが 2026 年の標準形である。