DoS攻撃（Denial-of-Service attack）の基礎と実践対策

本記事は学習用です。作成には ChatGPT と GitHub Copilot を使用しています。

1. 導入：DoS攻撃が狙う「可用性」
2. DoS攻撃の基本概念と分類
1. 2.1 DoS攻撃とDDoS攻撃の違い
2. 2.2 攻撃の観点別分類
3. ネットワーク層の代表的なDoS攻撃
4. アプリケーション層DoS攻撃
5. DoS攻撃の検知とトラフィック分析
1. 5.1 監視すべき主な指標
2. 5.2 ログからの特徴的なパターン
6. 防御・緩和策（ネットワーク／インフラ側）
7. 防御・緩和策（アプリケーション／設計側）
8. 近年の事例と傾向
9. まとめ
A. 参考サイト
B. 関連書籍

1. 導入：DoS攻撃が狙う「可用性」

DoS攻撃（Denial-of-Service attack、サービス拒否攻撃）は、システムやネットワークの「可用性」を狙う攻撃手法で、サーバやネットワーク機器に過剰な負荷を与えたり、脆弱性を悪用することで、正当なユーザがサービスを利用できない状態を意図的に発生させる（ウィキペディア）。

典型的な影響は次のとおり。

Webサイトが表示されない、APIがタイムアウトする
ネットワーク全体が遅くなり、VPNや社内システムに接続できない
決済や申し込みなどビジネス上重要な処理が継続できない
障害対応や機会損失により、金銭的・信用的なダメージが発生する（ntt.com）

DoS攻撃は、単一または少数の端末から行うものに限らない。多数の端末（ボットネット）から同時に攻撃するDDoS攻撃（Distributed Denial-of-Service attack）も広義のサービス拒否攻撃に含まれ、近年は特にこちらの規模と頻度が増加している（株式会社ラック）。

2. DoS攻撃の基本概念と分類

2.1 DoS攻撃とDDoS攻撃の違い

DoS攻撃

少数の攻撃元（1台〜数台）から行うサービス拒否攻撃
アプリケーションのバグや実装上の弱点を突く手法も多い

DDoS攻撃

ボットネットなど多数の攻撃元から行う分散型サービス拒否攻撃
大量トラフィック（フラッディング）で回線や機器の処理能力を飽和させる攻撃が主流（株式会社ラック）

LACの解説では、両者の共通点・相違点が次のように整理されている（株式会社ラック）。

項目	DoS攻撃	DDoS攻撃
攻撃元の数	少ない	非常に多い（数百〜数万）
主な狙い	サーバやアプリのクラッシュ、サービス停止	回線・機器・サーバ資源の枯渇
特徴	発信元を特定しやすい	発信元が分散しており特定・遮断が難しい
対策難易度	比較的低い	高い（ISP・クラウド事業者との連携が必須）

※実務では、フラッディングを伴う大規模攻撃はほとんどがDDoS攻撃だと考えてよい。

本記事では「DoS攻撃」という用語を、狭義（少数の端末からの攻撃）と広義（DDoSを含むサービス拒否攻撃全般）の両方の意味で用いるが、分散性に言及する場合は明示的にDDoSと記載する。

2.2 攻撃の観点別分類

DoS／DDoS攻撃は、主に次の観点で分類できる（クラウド型WAF『攻撃遮断くん』）。

ボリューム型攻撃

大量のパケットやトラフィック量（bps）で回線や機器を飽和させる
例：UDPフラッド、ICMPフラッド、DNSフラッド

プロトコル／ステート枯渇攻撃

TCPの接続状態や機器のセッションテーブルなど、プロトコルやステート管理の弱点を狙う
例：SYNフラッド、ACKフラッド、コネクション枯渇（Connection Exhaustion）

アプリケーション層攻撃（L7 DoS）

HTTPやDNS、アプリ固有のプロトコルなど高位レイヤーを狙う
例：HTTP GET/POSTフラッド、Slow HTTP DoS、重いDBクエリを大量に投げる攻撃

脆弱性悪用によるクラッシュ型攻撃

特定の入力を与えるとアプリケーションやOSがクラッシュする脆弱性を利用
パケット量は少なくてもサービス停止を引き起こす

実務上は、これらが組み合わさった複合型攻撃も多い。

3. ネットワーク層の代表的なDoS攻撃

このセクションでは、L3/L4（ネットワーク／トランスポート層）で典型的なDoS攻撃を整理する。

3.1 SYNフラッド攻撃

SYNフラッド攻撃は、TCPの3ウェイハンドシェイクを悪用してサーバの接続キューを枯渇させる攻撃である。

TCPの3ウェイハンドシェイクは次の流れで成立する。

sequenceDiagram participant C as クライアント participant S as サーバ C->>S: SYN S-->>C: SYN/ACK C->>S: ACK

SYNフラッドでは、攻撃者は大量のSYNパケットを送りつけるが、最後のACKを返さない、あるいは送信元IPアドレスを偽装（IPスプーフィング）して応答自体が届かない状況を作る。するとサーバ側では「未完了の接続（半開状態）」が大量にキューに溜まり、新規の正当な接続を受け付けられなくなる。

代表的な対策は次のとおり。

SYNクッキーの有効化（Linuxのtcp_syncookiesなど）
未完了接続キューのサイズ・タイムアウト値の調整
FW／ロードバランサでのSYNレート制限

3.2 UDPフラッド／ICMPフラッド攻撃

UDPフラッド攻撃は、UDPパケットを大量に送信して回線やサーバのCPU・メモリを消費させる攻撃である。UDPはコネクションレスでハンドシェイクがないため、攻撃者は非常に高いパケットレートでトラフィックを生成できる（クラウド型WAF『攻撃遮断くん』）。

ICMPフラッド攻撃も同様に、ICMP Echo Request（ping）などのパケットを大量に送出し、回線やルータ・サーバの処理能力を使い切らせる。

これらは、帯域や機器性能に対して「どれだけ短時間に多くのパケット・バイトを送れるか」が勝負になるため、ボリューム型DoS攻撃に分類される。

3.3 リフレクション／アンプ攻撃の基礎

リフレクション攻撃は、送信元IPを標的のアドレスに偽装して、応答トラフィックを標的に向けさせる攻撃である。

アンプ攻撃（増幅攻撃）は、リフレクション先として「小さなリクエストに対して大きなレスポンスを返すサービス」を選ぶことで、攻撃者が出すトラフィックよりもはるかに大きなトラフィックを標的に集中させる。典型例として、DNS、NTP、memcachedなどの誤設定サーバが利用される（クラウド型WAF『攻撃遮断くん』）。

2018年には、公開されたmemcachedサーバを踏み台にしたリフレクション／アンプ攻撃により、GitHubがピーク1.35TbpsのDDoS攻撃を受けた事例が報告されている（セキュリティネクスト）。

※memcachedは本来、インターネットから直接アクセスできない前提のキャッシュサーバであり、インターネットに公開すること自体が設計ミスに近い。

4. アプリケーション層DoS攻撃

4.1 HTTPフラッド攻撃

HTTPフラッド攻撃は、HTTP GET/POSTなどアプリケーション層のリクエストを大量に送ることで、Webサーバやアプリケーション、DBに負荷をかける攻撃である（Cloudflare）。

HTTP GETフラッド
画像やダウンロードファイルなど比較的重いコンテンツを大量リクエストする
HTTP POSTフラッド
フォーム送信などサーバ側処理が重いエンドポイントに大量POSTし、アプリケーションやDB負荷を上げる

特徴は以下。

1リクエストあたりのサイズが小さくても、アプリ側の処理負荷は高い場合がある
正常なユーザのアクセスパターンに似せることで、単純なシグネチャやレート制限をすり抜けやすい
TLS終端やアプリケーションサーバに負荷が集中しやすい

4.2 Slow HTTP DoS（Slowlorisなど）

Slow HTTP DoS攻撃は、HTTPヘッダやボディを極端に遅い速度で送信し続け、Webサーバの同時接続数やスレッド数を枯渇させる攻撃である（クラウド型WAF『攻撃遮断くん』）。

例として、次のようなパターンがある。

ヘッダを1行ずつ、数秒〜十数秒に1回送って接続を維持する
Content-Lengthだけ宣言してボディを最後まで送らない

このタイプの攻撃は総トラフィック量が少ないため、ネットワークレベルのモニタリングでは見逃しやすい一方、アプリケーションやWebサーバの接続リソースを占有するため、L7のメトリクス監視が重要になる。

4.3 アプリケーション固有のリソース枯渇攻撃

アプリケーション固有の処理で重いもの（例：全文検索、レポート生成、画像変換）に対して、意図的に多数のリクエストを送ることで、CPUやメモリ、DBリソースを枯渇させる攻撃もある。

例：

「検索API」に高コストなクエリ（ワイルドカード検索、集約処理など）を大量投入
「レポート生成」や「ZIPダウンロード」を多数同時実行
認証処理を大量に走らせて、バックエンドのIDプロバイダやDBを飽和させる

この種の攻撃は正常な利用と境界が曖昧なため、レート制限・ユーザ単位の上限・キューイングなど、アプリケーションレベルでの制御が重要になる。

5. DoS攻撃の検知とトラフィック分析

5.1 監視すべき主な指標

DoS攻撃を早期に検知するには、ネットワークレイヤとアプリケーションレイヤの両方で異常を検出できるようにしておく必要がある。

代表的な監視指標をまとめる。

レイヤ	指標	例	目的
ネットワーク	bps / pps	インターフェース毎のトラフィック量	ボリューム型攻撃の検知
ネットワーク	セッション数	FW・LBの同時セッション数	ステート枯渇攻撃の検知
OS	`SYN_RECV` 数	`ss -s` / `netstat`	SYNフラッド兆候の検知
アプリ	HTTPリクエスト毎秒（RPS）	パス別・ユーザ別RPS	L7フラッドの検知
アプリ	エラー率	5xxやタイムアウト率	可用性への影響把握
DB/キャッシュ	クエリ数、レイテンシ	スロークエリ数など	アプリ層DoSの影響把握

簡単なSYNフラッド確認の例（Linux）：

# TCPの状態サマリ
ss -s

# SYN_RECV の数を確認
ss -ant state syn-recv | wc -l

平常時の値を把握しておき、一定の閾値（例：通常の5〜10倍）を超えた場合にアラートを飛ばす運用が現実的である。

5.2 ログからの特徴的なパターン

DoS／DDoS攻撃時には、ログやメトリクスに次のような特徴が現れやすい。

ごく短時間に、特定IPまたはサブネットからの大量リクエスト
同一URL、同一HTTPメソッドの不自然な集中
ほぼ同じUser-Agentやヘッダを持つリクエストの急増
HTTP 502/503/504などのサーバエラーの急増
パケットキャプチャで、SYNだけが大量に来てACKが返ってこない

実サービスのログ分析では、単一の特徴だけで攻撃と断定できるケースは少なく、複数の兆候を組み合わせて判断することが多い。

6. 防御・緩和策（ネットワーク／インフラ側）

DoS攻撃対策は単一の技術で完結せず、多層防御が前提になる。ここではネットワーク／インフラ側での基本的な対策を整理する。

6.1 ISP／クラウド事業者のDDoS保護サービス

大規模なDDoS攻撃は、自社回線やオンプレ機器だけで吸収することが難しい。そのため、次のようなサービスの利用が一般的である。

CDN／WAF事業者のDDoS保護機能（例：大手クラウド・CDNベンダのL3〜L7防御）（SB C&Sがおすすめするビジネスソリューション）
ISPが提供するトラフィックスクラビングサービス（異常トラフィックのみ別拠点で除去）

近年、CloudflareやFastNetMonなどの事業者は、TbpsクラスのDDoS攻撃を継続的に観測・緩和している。報道によれば、2025年にはCloudflareが単一IPに対するピーク7.3TbpsのUDP系DDoS攻撃を遮断した事例が紹介され、FastNetMonも1.5Bpps（秒間15億パケット）規模の大規模UDPフラッドを緩和したとされる（Tom's Hardware、TechRadar）。

自社だけで吸収しようとせず、上流での遮断・スクラビングを前提に設計するのが現実的である。

6.2 FW／LBでのレート制限・コネクション制御

ネットワーク境界のFW（ファイアウォール）やLB（ロードバランサ）では、次のような制御が有効である。

接続元IPアドレスごとの同時接続数制限
単位時間あたりの新規接続数（SYN数など）の制限
特定ポート・プロトコル（例：不要なUDPサービス）の遮断
不正なフラグ構成のTCPパケット（SYN+FINなど）のドロップ

例として、Linuxのiptablesで1IPあたりの新規接続レートを制限するイメージ：

# 1秒あたり10接続を超えるSYNを許可（バースト20まで）、超過はDROP（例）
iptables -A INPUT -p tcp --syn -m limit --limit 10/second --limit-burst 20 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

※実際に本番系で利用する場合は、サービス特性や通常トラフィックのパターンに応じたチューニングが必須。

6.3 IPスプーフィング対策（アンチスプーフィング）

リフレクション／アンプ攻撃の前提となる 送信元IPアドレスのなりすまし を防ぐには、ISPレベルでの BCP38（送信元アドレスフィルタリング） の実装が重要とされる。送信元としてあり得ないIPアドレス帯を境界ルータで破棄することで、リフレクション攻撃の発信元を減らせる。

しかし現状では、全てのISPで完全に実施されているわけではなく、攻撃者が悪用可能なネットワークが依然として残っているとされる（詳細な実施状況は公開情報が限られており、ここでは断定を避ける）。

6.4 キャパシティプランニングと冗長構成

DoS攻撃に限らず、スパイク的なトラフィックや一時的な負荷増大に耐えるには、余裕のあるキャパシティと冗長構成が前提となる。

帯域の冗長化（複数の回線事業者、複数リージョンの活用）
LBによる水平スケール、オートスケールの設計
重要サービスの分離（管理系・API・静的コンテンツの分離など）

これらは日常的なトラフィックの増加にも有効であり、DoS対策とインフラ設計を切り離さずに考えることが重要である。

7. 防御・緩和策（アプリケーション／設計側）

7.1 レート制限とユーザ単位の上限

アプリケーション側で実装できる最も基本的な防御の1つがレート制限である。

IPアドレス単位のリクエスト数制限
認証済みユーザ単位のAPIコール上限
特定エンドポイント（検索、レポート生成など）の秒間実行数制限

実装例（Nginxの簡易レート制限イメージ）：

http {
    limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;

    server {
        location /api/ {
            limit_req zone=perip burst=20 nodelay;
            proxy_pass http://backend;
        }
    }
}

※この設定例はあくまでイメージであり、実運用ではサービス特性に合わせた値の調整と検証が必要である。

7.2 コストの高い処理の保護

重い処理がDoSの標的になりやすいことを前提に、次のような設計を検討する。

非同期化：時間がかかる処理をキューイングし、バックグラウンドワーカーで実行
キャッシュ：同一条件のリクエストに対してキャッシュを返す（DBや外部APIへの負荷削減）
バルクリクエストの制限：一度に処理できる件数に上限を設ける
リクエストの優先度制御：重要度の高い処理を優先し、低優先度の処理はキューに積む

CPU・メモリ利用率を「U = 使用中のリソース / 総リソース」とすると、DoS攻撃は意図的に「U → 1（100%）」の状態を作り出す攻撃だと捉えられる。そのため、アプリ設計段階で「高コスト処理の上限」を設計することが有効である。

7.3 バックプレッシャーとフェイルファスト

負荷が限界に達した際に、システム全体がクラッシュするのではなく「一部の機能をあきらめる」設計も、可用性を守るうえで重要である。

キューが一定以上溜まったら新規リクエストを429/503で早期に拒否（フェイルファスト）
タイムアウト値を適切に設定し、処理が長時間ぶら下がらないようにする
サーキットブレーカーパターンの利用（下流が不調なときに呼び出しを止める）

これらは平常時のスパイク対策にも有効であり、DoS対策と性能設計を一体として考えるのがよい。

7.4 認証・CAPTCHA・ボット対策

アプリケーション層のDoS攻撃では、「匿名で誰でも叩けるエンドポイント」が狙われやすい。対策として、次のような方法がある。

管理系・高コストAPIには認証を必須にする
公開フォームにはCAPTCHAやメール認証を導入する
既知のボットやクローラのUser-Agent／挙動を制限する
不審なふるまい（短時間の大量アクセスなど）を自動検知して一時的にブロックする

ただし、CAPTCHAなどはユーザビリティとのトレードオフが大きいため、ビジネス要件とバランスを取りながら導入する必要がある。

8. 近年の事例と傾向

8.1 大規模DDoS攻撃の規模拡大

過去数年で、DDoS攻撃の規模はTbpsクラスまで拡大している。

2018年：GitHubに対するmemcachedベースのリフレクション攻撃（ピーク1.35Tbps）（セキュリティネクスト）
2025年：Cloudflareが単一IPに対する7.3Tbps、37.4TBのトラフィックを45秒間で観測・緩和した事例が報じられている（Tom's Hardware）
同年：FastNetMonが1.5BppsのUDPフラッド攻撃を緩和した事例が報じられている（TechRadar）

これらの事例は、攻撃者が利用できるリソース（ボットネット、誤設定サーバ）が増え続けていることを示しており、従来の数百Mbps〜数Gbpsを前提としたDoS対策では不十分になりつつある。

8.2 産業制御システムなどへの影響

IPA（情報処理推進機構）は、制御システム向けのセキュリティ資料の中で、決済サイトや企業のWebサービスが攻撃者集団からDDoS攻撃を受けた事例に触れ、制御システムにおいてもネットワークやサービスを使用不能にする攻撃への備えが必要であると指摘している（独立行政法人情報処理推進機構）。

産業制御システムやIoT機器は、インターネットとの境界が曖昧な構成になりやすく、かつ可用性が安全性に直結するため、従来以上にネットワークセグメンテーションやアクセス制御の徹底が求められる。

8.3 攻撃のサービス化と低コスト化

DDoS-for-hire（DDoS攻撃の代行サービス）の存在や、マルウェアに感染したIoT機器の増加により、攻撃者が大規模DDoS攻撃を実行するハードルは下がっていると考えられる。

不正ツールやボットネットの利用料金が低価格化
ダークウェブなどで「攻撃サービス」が売買される
脆弱なIoT機器やCPE（ルータ等）が大量にボットネット化される（TechRadar）

その結果、特定の大企業だけでなく、中小企業や個人の運営するサービスも標的になり得る状況になっている。

9. まとめ

DoS攻撃はサービスの可用性を狙う攻撃であり、単一端末からのDoSに加え、多数の端末からのDDoS攻撃が大きな脅威となっている（ウィキペディア）。
攻撃手法は、ボリューム型（UDPフラッドなど）、プロトコル／ステート枯渇型（SYNフラッドなど）、アプリケーション層攻撃（HTTPフラッドやSlow HTTPなど）、脆弱性を突いたクラッシュ型など、多様化している（クラウド型WAF『攻撃遮断くん』）。
検知には、ネットワーク・OS・アプリケーションの各レイヤで、トラフィック量・セッション数・RPS・エラー率など複数指標を監視することが重要である。
防御は1つの技術では完結しない。上流でのスクラビング、FW／LBのレート制限、インフラのキャパシティ設計、アプリ側のレート制限・キューイング・フェイルファストなどを組み合わせる必要がある（SB C&Sがおすすめするビジネスソリューション）。
攻撃規模は年々拡大し、TbpsクラスのDDoSも珍しくなくなりつつある。インターネット接続性のあるシステムは規模を問わず標的になり得るため、「自分たちのサービスは狙われない」という前提は危険である（Tom's Hardware）。

実務でDoS対策を検討する際は、ネットワークエンジニア・インフラエンジニア・アプリケーションエンジニアが共同で、可用性要件と許容ダウンタイム、コストを踏まえた現実的な防御戦略を設計することが重要である。

A. 参考サイト

Wikipedia「DoS攻撃」（ウィキペディア）
NTTコミュニケーションズ：DDoS攻撃とは？意味と読み方、対策方法（ntt.com）
LAC：DDoS攻撃とは｜攻撃の目的や種類、被害事例や対策方法を解説（株式会社ラック）
SHADAN-Kun：DoS攻撃・DDoS攻撃とは？意味と対策方法をわかりやすく解説（クラウド型WAF『攻撃遮断くん』）
SHADAN-Kun：DDoS攻撃の主な攻撃手法8つの特徴をまとめてみた（クラウド型WAF『攻撃遮断くん』）
Cloudflare Learning Center：HTTPフラッドDDoS攻撃（Cloudflare）
Akamai：GETフラッド DDoS攻撃とは（Akamai）
IPA：制御システムの今あるセキュリティ脅威と対策について（PDF）（独立行政法人情報処理推進機構）