DDoS (Distributed Denial of Service) は「多数の送信元から大量の (一見正規な) リクエストを送り、標的のサービスを正規ユーザに使えない状態にする」攻撃。コードに脆弱性がなくても成立する数少ない攻撃クラスで、「正規リクエストの大群」と「攻撃」が原理的に区別不能なため、現代インターネットで最も解決が難しい問題の 1 つ。本稿は DoS との違い・3 分類・Reflection/Amplification・ボットネット・代表事件・防御の階層・被弾時の動きまでを通しで扱う。
難しく見えても本質は次の 3 つだけ。(1) DDoS は 「正規ユーザに見える大量の通信」でサイトを混雑させて落とす攻撃。通信は 1 つ 1 つは合法的で、合計流量だけが問題 — だからパッチでは直らない。(2) 3 つの形がある: 帯域を埋める / TCP の状態を埋める / アプリの計算を埋める。(3) 自社サーバ単体での対策には限界があるので、Cloudflare / AWS Shield / Akamai のような上流の事業者で受け止めるのが現代の正解。— ここを土台に各章を順に開いていけばいい。
DoS と DDoS — 1 vs N の根本的違い #
| 種類 | 送信元 | 主な特徴 |
|---|---|---|
| DoS | 1 つの送信元 | 古典的。Ping of Death / LAND attack など脆弱性ベース。送信元 IP のブロックで簡単に止められる |
| DDoS | 数千〜数千万の送信元 | 現代主流。1 つずつ止めても無意味、踏み台 (botnet / 反射器) を消せない |
| DRDoS | 送信元偽装 + 反射器 | 攻撃者は表に出ない。被害者からは「世界中の正規サーバから攻撃が来ている」ように見える |
DoS は「1 人の攻撃者がコードの脆弱性を突く」モデル — Ping of Death (1996) のように「この特殊パケットを送るだけで対象 OS がクラッシュ」する類で、現代では大半が修正済み。DDoS は「コードが正しくても止められない」ため、本質的に異なる問題になる。「水道のホースを 1 万本同時に向けられる」 — 個々のホースは正常な水だが、合計流量が標的の処理能力を超える。
DoS は 「1 人がカウンターをハンマーで叩き壊す」 — 警備員 (IP block) で簡単に止められる。DDoS は 「1 万人の客が同時にラーメン屋に押しかけ、全員が普通に注文する」状態。客は誰も悪いことをしていないのに、店の処理能力を超えて他の客に出せなくなる。1 人ずつ追い返してもキリがないし、本当の客と区別もできない。だから 「上流の信頼できる事業者 (= 大型整理券配布所) に客を一旦預けて、店に流す数を制限してもらう」のが現代の DDoS 対策の発想。
なぜ本質的に難しい問題なのか #
DDoS が「ベンダーがパッチを出せば終わり」にならない理由はインターネットの構造的問題にある。
- Internet は「相互信頼」で設計された — どこからでもパケットが届くのが基本機能。「無関係な大量のパケットを止める」は後付けの戦い
- 送信元 IP の偽装が可能 — UDP は接続を張らないため、送信元 IP を任意に詐称できる。BCP38 (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 分類 — Volumetric / Protocol / Application #
DDoS は何を枯渇させるかで 3 つに大別される。それぞれ防御方法が違うので、種類を見分けることが対応の最初の判断。
同じ「店を麻痺させる」攻撃でも、狙う場所が違う。① Volumetric (帯域) = 「店の入口の道路を車で詰まらせる」 — そもそも客が辿り着けない。② Protocol (TCP の状態) = 「受付に偽の名前で 10 万人並ばせる」 — 受付が満員で本物の客が登録できない。③ Application (アプリ) = 「全員が一番手間のかかる料理を注文する」 — 厨房 (= DB やアプリ) が回らない。どこが詰まっているかを最初に見分けるのが対応の第一歩。それぞれ対策の打ち手が全く違う。
| ① Volumetric | ② Protocol | ③ Application | |
|---|---|---|---|
| 枯渇対象 | 回線帯域 (Gbps〜Tbps) | 状態テーブル (conntrack 等) | アプリの計算/DB/接続資源 |
| レイヤ | L3 / L4 (IP, UDP) | L3 / L4 (TCP, ICMP) | L7 (HTTP, DNS, TLS) |
| 単位 | bps | pps | rps |
| 代表攻撃 | UDP flood / ICMP flood / DNS amplification | SYN flood / Fragmentation / Smurf | HTTP flood / Slowloris / HTTP/2 Rapid Reset |
| 効く防御 | anycast / BGP blackhole / scrubbing / ACL | SYN cookies / conntrack 拡大 / SYN proxy | WAF + bot management / rate limit / CAPTCHA / cache |
- Volumetric = 「水道管に水を流し過ぎて溢れさせる」(回線をパンクさせる)。家庭・中小企業の対策は本質的に上流任せ — 自社で 100 Gbps の攻撃は受けきれない
- Protocol = 「受付のカウンタを未完了の客で埋める」(SYN flood で TCP ハーフオープン状態を作り尽くす)。SYN cookies で対応可能
- Application = 「正規の手順で重い処理を要求する」(
/search?q=xxxを毎秒 100 万回 / Slowloris で接続を握って放さない)。最も区別が難しい
1 GB/s の UDP flood で帯域を圧迫し、同時に 100 万 rps の HTTP flood をアプリに浴びせる「multi-vector attack」が標準。種類を見分け、それぞれに効く層へ振り分ける運用が必須。
規模感の比較 (2024 年公知の最大級) #
- Volumetric: Cloudflare 5.6 Tbps (UDP 反射, 2024-10)
- Protocol: 数百 Mpps (modern NIC で吸収可だが古い L4 LB は溶ける)
- Application: Cloudflare HTTP/2 Rapid Reset 398 Mrps (2023-08, 過去最大の rps)
Reflection + Amplification — 桁違いの威力 #
DDoS が「Tbps 級」になる主な理由は Reflection (反射) と Amplification (増幅) の組合せ。1 つの小さなクエリを送ると複数倍のデータが別のサーバから返ってくる性質を持つ UDP プロトコルが踏み台にされる。
攻撃者は 「私は被害者です」と差出人を偽装した小さな手紙を、世界中の 「質問されると詳細な資料を送り返してくれるサーバ (= 拡声器)」に送る。サーバは騙されて、大量の応答を「被害者」宛に送り返す。攻撃者は表に出ず、被害者からは 「世界中の正規サーバから攻撃が来ている」ように見える。memcached の場合は 1 byte 送ると 51,200 byte 返ってくる = 5 万倍の増幅。攻撃者が 100 Mbps しか持っていなくても 5 Tbps の砲撃を生成できる、というのが Tbps 級 DDoS の正体。
主な amplification factor (BAF: 1 byte の query で何 byte の response) #
| プロトコル | 増幅率 | ポート |
|---|---|---|
| memcached | x 51,200 | UDP/11211 |
| NTP monlist | x 556 | UDP/123 |
| CharGEN | x 358 | UDP/19 |
| DNS (open resolver) | x 28〜54 | UDP/53 |
| CLDAP | x 56〜70 | UDP/389 |
| SSDP / UPnP | x 30 | UDP/1900 |
| SNMP | x 6 | UDP/161 |
| QUIC reflection | x 12〜43 | UDP/443 |
- UDP はコネクションレス → 送信元 IP をハンドシェイクで検証する段階がない
- TCP は SYN-SYN/ACK-ACK の 3-way が必要 → 詐称送信元には ACK が返ってこないため反射できない
- ISP の BCP38 / uRPF が効いていれば送信元偽装は防げるが、世界の半分以下の ISP しか実装していない
- memcached の x51,200 は「2018 年 GitHub への 1.35 Tbps」を可能にした (memcached 開発側が UDP モードを完全削除)
「攻撃者は 100 Mbps の回線しか持っていなくても、x100 倍の amplifier を踏めば 10 Gbps を出せる」 — これが DDoS が個人レベルで実行可能になっている本体の理由。防御側の根本対策は「世界中の amplifier を閉じる」だが完全には消えない。Shadowserver Foundation や Open Resolver Project が常時スキャンして amplifier 一覧を運用者に通知し続けている。
ボットネット — DDoS の供給側 #
Reflection が「踏み台サーバ」を使うのに対し、ボットネットは「乗っ取った端末そのもの」を使う。Mirai (2016) がデフォルトパスワードのまま放置された Wi-Fi カメラ・ルータを数十万台規模で乗っ取った事件以降、IoT ボットネットが DDoS 供給の主力に。
家庭に置いてある Wi-Fi カメラ・ルータ・スマート家電は、デフォルトパスワード (admin/admin) のまま長期間放置されていることが多い。攻撃者は 世界中をスキャンしてこれらを次々に乗っ取り、自分の指揮下に置いた「ロボット (bot) の軍団」を作る (= ボットネット)。所有者は 自分の機器が攻撃に加担していることに気付かない — ネット接続が少し遅くなる程度。Mirai (2016) で 40 万〜60 万台の IoT が同時動員され Twitter / GitHub / Reddit を巻き込んで止めたのが、ボットネットの脅威を世界に知らしめた事件。家庭ルータのパスワードを変えるのは、こんなに大事な防衛行為。
典型構造 #
- Loader / scanner — Internet 全体に対して 23/tcp (Telnet) / 22/tcp (SSH) / 7547/tcp (TR-069) などを brute force し、デフォルト認証情報リストでログイン試行
- Implant (マルウェア) — 感染端末で常駐し、C2 サーバからの指示を待つ
- C2 サーバ — IRC / HTTP / Tor hidden service / blockchain で次の攻撃先・方法を配信
- 被害者を攻撃 — bot 群が一斉に SYN flood / HTTP flood / UDP flood を撃つ
| ボットネット | 主な感染源 | 規模 / 特徴 |
|---|---|---|
| Mirai (2016) | Wi-Fi カメラ・DVR (デフォルト admin/admin) | 40 万〜60 万台。Krebs / Dyn 攻撃 → ソース公開で派生種が爆発 |
| Mirai 派生 (Satori, Okiru, Reaper など) | IoT 機器の脆弱性 | 数万〜数十万台規模が多数並行運用 |
| Meris (2021) | MikroTik ルータの脆弱性 | 25 万台、HTTP/2 で 21 Mrps |
| Mantis (2022) | クラウド VM 乗っ取り (高品質ボット) | 5,000 台で 26 Mrps の HTTP flood |
| Residential Proxy 業者 | 「無料 VPN」「ブラウザ拡張」 | 合法を装って収集した家庭 IP が攻撃にも使われる |
数十万台の IoT より、数千台の高速回線・データセンター VM の方が単純な rps では効率的。Mantis が 5,000 台で 26 Mrps を出した事例が象徴的。
過去 25 年の代表事件 #
| 年 | 事件 | 規模・特徴 |
|---|---|---|
| 2000 | Mafiaboy (15 歳のカナダ人) | Yahoo!, eBay, CNN, Amazon, Dell を停止。DDoS が一般メディアに登場した最初 |
| 2007 | Estonia 攻撃 | 政府・銀行・メディアが 3 週間ダウン。国家規模 DDoS の最初の本格事例 |
| 2013 | Spamhaus | 300 Gbps、DNS amplification。Cloudflare が初めて防いだ大規模事例 |
| 2016 | Mirai → Krebs (620 Gbps), Dyn (1.2 Tbps) | Twitter / Reddit / GitHub / Netflix が同時に落ちる。IoT ボットネットの脅威が世界に知られる |
| 2018 | GitHub 1.35 Tbps (memcached amplification) | memcached UDP の x51,200。数分で Akamai Prolexic に経路切替 |
| 2020 | AWS 2.3 Tbps (CLDAP reflection) | 公表されている中で過去最大級の Volumetric。AWS Shield Advanced が吸収 |
| 2021 | Meris → Yandex 22 Mrps | 当時最大の rps |
| 2023 | HTTP/2 Rapid Reset (CVE-2023-44487) | Cloudflare 201 Mrps / Google 398 Mrps / AWS 155 Mrps を同時に被弾 |
| 2024 | Cloudflare 5.6 Tbps UDP (Mirai 派生) | 13,000 台の IoT で 80 秒間。L3/4 史上最大 |
| 2025 | Cloudflare 7.3 Tbps | 帯域型 DDoS の規模は毎年更新され続けている |
防御側 (Cloudflare / Akamai / AWS) も急速に容量を拡張しており、2026 年時点で主要な scrubbing 事業者は単独で 100+ Tbps の吸収容量を持つ。
防御の階層 — 何を、どこで、どう止めるか #
DDoS 防御は多層的に組まれる。自社で全部やるのは現実的でなく、上流の事業者にどこまで投げるかがコスト設計の本質。
「自社で 1 Tbps を受け止める」は Google / AWS クラスでも厳しいので、個人サイト / 小規模サービスは「上流の事業者に守ってもらう」のが現実解。最低限やるべき 3 つ。(1) Cloudflare の無料プランを前段に置く — DNS を Cloudflare に向けるだけで anycast 網と DDoS 緩和が無料で付く。(2) Origin の IP を Cloudflare 経由でしかアクセスできなくする — 直撃を防ぐ重要なステップ (Origin の IP が漏れていると Cloudflare を回避されてしまう)。(3) アプリ側にも rate limiting — nginx の limit_req で API は 10 req/s に絞る。これだけで個人サイト向けの大半の DDoS は乗り切れる。
| 層 | 何をするか | 誰が提供 |
|---|---|---|
| Anycast 網 | 攻撃トラフィックを世界中の POP に分散 | Cloudflare, AWS Global Accelerator, Akamai |
| Scrubbing center | 入ったトラフィックを「攻撃」と「正規」に分け、後者だけを origin に転送 | Akamai Prolexic, Imperva, NTT, Verisign |
| CDN + WAF | 静的コンテンツはエッジで返す + L7 フィルタで HTTP flood を弾く | Cloudflare, AWS CloudFront + WAF, Fastly |
| BGP RTBH / FlowSpec | 攻撃宛先の IP/プレフィックスを上流ルータでブラックホール | ISP / Tier-1 キャリア |
| L4 LB / SYN proxy | SYN cookies でハーフオープン状態にしない | F5 BIG-IP, AWS NLB, HAProxy, nginx stream |
| OS 設定 | net.ipv4.tcp_syncookies=1 / conntrack 上限拡大 |
Linux カーネル |
| アプリ層 rate limit | IP / セッション / トークンごとの request 数上限 | nginx limit_req, Cloudflare Rate Limiting |
| 静的化 / circuit breaker | 重い動的ページを cache + 過負荷時の自動 503 | アプリ設計 |
$ 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# /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;
...
}$ 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"}'被弾時の最初の 30 分 #
実際に DDoS を受けたときにやることはほぼ決まっている。事前にランブックを作っておくことが何より重要。
火事になってから消火器の場所を探す人はいない。DDoS も同じで、受けてから「Cloudflare に申し込もう」では遅い — DNS の伝播に時間がかかるし、攻撃中の判断ミスは致命的になる。(1) 平時に Cloudflare / AWS Shield 等を前段に立てておく、(2) 「Under Attack mode を 1 クリックで有効化する手順」を文書化、(3) 「攻撃 → 関係者連絡 → 顧客への status page 更新」のランブックを年 1 回訓練。これを準備していたかどうかで、攻撃当日の被害規模が 10 倍違う。
tcpdump, NetFlow, CDN ダッシュボードで L3/L4 (UDP/SYN flood) か L7 (HTTP flood) かを確認。/api/* /login /search など重いエンドポイントを優先的に絞る。キャッシュも aggressive 化。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 を受けきるのは Google / AWS クラスでも厳しい
- 「DDoS 対策 = CDN/WAF を前段に置く」が現代インフラの最低基準。その後ろに OS の SYN cookies、アプリの rate limit、circuit breaker を多層で積み上げるのが 2026 年の標準形
