DDoS攻撃: 種類、症状、対策

2026年2月17日 • 2 min read

DDoSは新しい現象ではありませんが、今でははるかに簡単で、安価で、スケールしやすくなっています。昔は、いくつかの設定ミスのサーバーや小さなボットネットでサービスを止められました。今は、ほんの一瞬で回線を飽和させたり、ファイアウォールを圧迫したり、「普通に見える」リクエストでアプリケーションを落とす攻撃が日常的に起きます。

この記事は恐怖を煽るためではありません。目的は整理です。DDoSとは何か、現場で重要な攻撃クラスは何か、運用中にどう見抜くか、そして本当に役に立つ対策は何かをまとめます。

(D)DoSとは？

Denial-of-Service (DoS) は、攻撃者がサービスを使えなくする攻撃です。目的は データ窃取ではなく、サービスの 過負荷 やリソース枯渇です。可用性が狙われます。Webが開かない、APIがタイムアウトする、VPNゲートウェイがセッションを受け付けない、DNSリゾルバが追いつかない、といった状態です。

Distributed の “D” は、トラフィックが1つの送信元ではなく、多数の送信元から来ることを意味します。侵害されたデバイスのボットネット、正規のインフラ（reflection/amplification）、またはその組み合わせで実現されます。運用側から見ると、単一の攻撃者ではなく、分散した洪水に見えます。

動機: なぜDDoSが行われるのか？

動機は地味ですが、効果的です。

恐喝: 「払わないならまた落とす」。
活動/政治: 可視化、メッセージ、妨害。
陽動: DDoSで運用を縛り、その裏で別の攻撃を行う。
競合/妨害: チケット販売、リリース、ローンチなどの重要タイミングでは短い停止でも痛い。
コスト攻撃: 完全停止ではなく、クラウド費用やサポート負荷、運用ストレスを増やすことが目的の場合もある。

重要なレイヤー（なぜ重要か）

DDoSはレイヤーで語られます。どのレイヤーかによって、見るべき シグナル と取り得る防御が変わるためです。

Layer 3 (IP): どこから来てどこへ行くか。
Layer 4 (TCP/UDP): ポート、接続、ハンドシェイク、state。
Layer 7 (Application): HTTP(S)リクエスト、API、業務エンドポイント。
“Layer 8”（ビジネスロジック）: 公式ではないが現実的。アプリ内の「重い処理」が狙われる。

ポイントはこれです。Layer 3/4で完璧に見える防御でも、Layer 7では破られることがある。リクエストが正規に見え、アプリに到達してからコストが爆発するからです。

攻撃クラス1: ボリュームと増幅（主にUDP）

ボリューム型は帯域や パケット処理（pps）を狙います。典型は reflection/amplification です。

攻撃者は公開サーバー（例: open DNS resolver）へ小さなリクエストを送る。
送信元IPを偽装し、被害者IPを “source” にする。
サーバーはより大きなレスポンスを被害者に返す。

100バイトのリクエストが1,000バイトのレスポンスを生めば増幅率は10倍です。プロトコルやpayload次第でさらに大きくなります。厄介なのは、被害者から見るとトラフィックが「普通のサービス」から来ており、安易にブロックできない点です。

重要: 増幅は多くの場合、送信元IP偽装に依存します。だからこそ ingress filtering (BCP 38) が重要です。プロバイダがエッジで偽装した送信元を落とせば、このベクトルはかなり難しくなります。

攻撃クラス2: プロトコル/状態の枯渇（TCP/Layer 4）

DDoSは帯域だけではありません。ターゲット側に state を作り続け、テーブルやリソースを埋めるほうが効率的な場合があります。

代表例はTCPの SYN flood:

TCPは通常 three-way handshake で接続します（SYN -> SYN/ACK -> ACK）。
SYN floodではSYNを大量に送るが、最後のACKを返さない。
サーバーは多数の半開き接続（state）を保持し、タイムアウトまで再送を試みる。

これによりメモリやCPUを消費し、送信トラフィックにも影響が出ます。帯域に余裕があっても、セッション管理が満杯になればサービスは落ちます。

近いカテゴリに low and slow があります。実際に接続を確立し、最小限のデータで接続を維持して、Webサーバーやロードバランサの接続上限を踏み抜かせます。大きな帯域スパイクより目立ちにくいのが特徴です。

攻撃クラス3: Layer 7 と “Layer 8”（HTTP、API、高コストエンドポイント）

Layer 7は最も厄介になりがちです。正規トラフィックとの区別が難しいからです。例:

HTTP flood: 動的ページ、検索、ログインフローへ大量リクエスト。
Slowloris/slow headers: ヘッダー/ボディを極端に遅く送って接続を維持する。
高コストなビジネスロジック: DBクエリ、外部API呼び出し、PDF生成、暗号処理、AI/agent workflow などを起動するエンドポイント。

狙いは「トラフィック量」ではなく 1リクエストあたりの仕事量 です。少量でも的確に当てられると、キャッシュされた静的GETの大波より高コストになります。

本番環境でどう検知するか？

CPUとRAMだけを見ていると遅れます。実務では、ベースラインといくつかの堅牢なメトリクスが効きます。

トラフィック: エッジ（router/firewall/load balancer）でのbpsとpps。
接続系: 新規接続/s、オープンセッション、SYN backlog、TLS handshakes/s。
HTTP系: RPS、レイテンシ（p95/p99）、4xx/5xx比率、タイムアウト。
上流症状: packet loss、RTT増加、リンク飽和、BGPイベント。
ログ/WAF: 不審なパス、無効なヘッダー、未完了リクエストの増加、怪しいUA/パターン。

最重要はシンプルです。ベースラインが必要。 ベースラインがないと全部「多い」に見える。あると「小さいパケット」や「未完了リクエスト」が異常に見えます。

対策: 現場で効くもの

アプローチは大きく2つ: make（自前）か buy（サービス利用）。多くのチームでは “buy” のほうが現実的です。DDoS対策はすぐに「片手間では無理」な規模になるためです。

1) アプリの前に置く: CDN/WAF/DDoSプロバイダ

WebやAPIではこれが最も効果的なことが多いです。

Anycastでトラフィックを多数拠点へ分散。
WAFで分かりやすいLayer 7パターンを遮断。
Bot対策、rate limit、challenge/responseで「安い攻撃」を減らす。

注意: すべてがHTTPではありません。VPN、VoIP、ゲームサーバー、UDP系プロトコルなどを公開している場合は、設計に合わせた別の防御が必要です。

2) rate limiting とタイムアウトを正しく

地味ですが効きます。

ICMP/“ping”: 完全禁止ではなく制限（調査に必要）。
HTTP: IP/token/route単位で制限、特に高コストなエンドポイント。
遅いリクエスト: 未完了ヘッダー/ボディに厳しいタイムアウト。

例（Nginx、かなり単純化）:

limit_req_zone $binary_remote_addr zone=api_per_ip:10m rate=10r/s;

location /api/ {
  limit_req zone=api_per_ip burst=40 nodelay;
}

銀の弾丸ではありませんが、攻撃コストを押し上げられます。

3) アーキテクチャ: 重い処理を切り離す

Layer 7のDDoSは帯域ではなく、1リクエストが重い箇所 を狙います。通常の企業システムにはそれが多く存在します。ログイン、検索、PDFエクスポート、レポート、アップロード、複雑なDBクエリ、外部API呼び出しなどです。

よくある例: 顧客ポータルのエクスポートボタン（「請求書PDF」「レポート生成」「ZIPで一括DL」）。普段は数分に一回程度でも、攻撃では毎分数百回から数千回叩かれます。問題は帯域ではなくCPU（レンダリング）、DB（クエリ）、worker pool（スレッド/接続）です。外からは「遅い」に見えますが、内側ではタイムアウトやキュー詰まりが起きます。

良いニュースは、全部を作り直す必要はないことです。少しの設計変更でブレーキを入れられます。

キャッシュ（エラーページ含む）、適切なTTL、エッジキャッシュ。
高コスト処理は非同期（キュー）へ: 「今すぐPDF」ではなくジョブ化して後で返す。
入力バリデーションと早期中断: 複雑度の制限、1リクエスト当たりのハードリミット。
ログイン/検索/アップロード/エクスポートは別保護: 専用のrate limit/timeout、必要なら専用worker。
劣化運用スイッチ（feature flags）: デプロイなしで一部機能を一時停止。

4) upstream 対策: filtering、scrubbing、緊急プラン

規模が大きい場合、トラフィックを 回線に到達する前 に落とす必要があります。

プロバイダ側のfiltering / scrubbing center
一時的なブロック（例: 「なぜWebサーバーにUDPが？」）
緊急ルーティング（例: “protected” IPへ切り替え）

これは 事前に プロバイダと合意していないと機能しません。インシデント中に即席で始めるのは遅くて高いです。

DDoS専門家がいないチーム向けチェックリスト

棚卸し: 公開サービスは何か（HTTP/DNS/VPN/mail/VoIPなど）。
単一障害点: DNS、reverse proxy、load balancer、単一リージョン。
Observability: bps/pps、RPS、レイテンシ、エラー、接続数、ベースライン前提のアラート。
デフォルト強化: timeouts、limits、ヘッダー最大サイズ、接続上限、backpressure。
プロバイダ計画: scrubbing担当、フィルタ可能範囲、エスカレーション経路。
Runbook: 「XならY」＋連絡先、しきい値、スイッチ（feature flags）。
練習: 制御された負荷試験とインシデントドリル（合法かつ合意の上で）。

最後に: テストは合法かつ有益に

DDoSのテストはセンシティブです。公開インターネット、第三者システム、許可のないインフラに触れるのは論外。代わりに、次を行いましょう。

自前のstagingで負荷試験（高コストエンドポイント中心）。
依存関係のchaos test（キャッシュ停止、DB遅延、制限強化）。
対応手順の訓練: アラート、連絡、プロバイダエスカレーション、緊急策。

参考リンク

それでは、また次回お会いしましょう。 Joe