カテゴリー: SQAT® Security 玉手箱

DDoS攻撃では、事前の対策だけでなく、攻撃を受けた際の迅速な初動対応が重要です。対応が遅れると、サービス停止だけでなく、売上機会の損失や顧客対応の混乱につながるおそれがあります。本記事では、DDoS攻撃を受けた場合の初動対応から、ISP・クラウド事業者との連携、復旧、再発防止までの流れを解説します。

DDoS攻撃の基本的な仕組みや種類、被害、対策については、「DDoS攻撃とは？仕組み・被害・対策を企業向けに解説」もあわせてご覧ください。

DDoS攻撃を受けたときに想定される影響

DDoS攻撃を受けると、大量の通信やリクエストによってWebサイトやサービスの応答が遅延し、場合によっては利用できなくなります。影響はサービス停止だけでなく、決済・予約・受発注などの業務停止、顧客・取引先からの問い合わせ増加などにも及ぶ可能性があります。

また、DDoS攻撃による混乱に乗じて、不正アクセスや情報窃取など別の攻撃が行われる可能性も考慮する必要があります。そのため、単なる通信障害と判断せず、セキュリティインシデントとして状況を確認することが重要です。DoS攻撃が単一または少数の攻撃元から行われるのに対し、DDoS攻撃は多数の端末などを悪用して分散的に行われるため、攻撃元の特定や単純な遮断が難しくなります。

DoS攻撃とDDoS攻撃の仕組みや違いについて詳しくは、「DoS攻撃とDDoS攻撃の違いとは 仕組み・被害・対策を比較解説」をご覧ください。

DDoS攻撃を受けたときの対応の流れ

DDoS攻撃が疑われる場合、場当たり的に設定変更や機器の再起動を行うのではなく、状況を確認しながら段階的に対応することが重要です。基本的な流れは、次のとおりです。

実際の対応方法は、攻撃の種類や規模、システム構成、利用しているクラウド・ネットワークサービスなどによって異なります。重要なのは、技術担当者だけで対応を完結させようとせず、必要に応じて社内外の関係者と連携できる体制を整えることです。

初動対応で最初に行うべきこと

DDoS攻撃を受けた場合、最初に必要なのは、慌てて機器の再起動や設定変更を行うことではありません。まず、発生している事象がDDoS攻撃によるものなのか、通常のアクセス増加やシステム障害なのかを切り分ける必要があります。初初動対応では、攻撃の有無を確認し、被害範囲を把握し、関係者へ連絡するとともに、可能な範囲でログなどの証跡を保全します。

攻撃発生を確認する

最初に、どのような異常が発生しているかを確認します。Webサイトの応答遅延、タイムアウト、サーバーエラー、CPUやメモリ使用率の急上昇、ネットワーク帯域の逼迫、特定URLへのリクエスト集中などが確認ポイントになります。

アクセス解析、サーバーログ、WAFログ、ロードバランサーのメトリクス、クラウド監視サービス、ネットワーク機器のトラフィック情報を確認し、通常時と比べて異常な増加がないかを調べます。平時のトラフィック量やピーク時の傾向を把握していれば、DDoS攻撃なのか、キャンペーンやニュース掲載などによる正規アクセスの増加なのかを判断しやすくなります。

ただし、DDoS攻撃は必ずしも大量通信だけとは限りません。アプリケーション層を狙う攻撃では、一見すると通常のHTTPリクエストに見える通信が集中し、検索機能、ログイン画面、APIなど特定の処理に負荷がかかることがあります。そのため、通信量だけでなく、アクセス先、リクエスト頻度、送信元の分布、レスポンスコードの変化なども確認します。

被害範囲を把握する

次に、どのサービスが影響を受けているかを把握します。コーポレートサイトだけなのか、ECサイトや会員サイトも影響を受けているのか、社内ネットワークや業務システムにも影響があるのかを整理します。被害範囲を確認する際は、外部からの疎通確認だけでなく、社内からの接続状況、監視アラート、問い合わせ件数、取引先からの連絡内容なども確認します。攻撃対象が特定のドメイン、IPアドレス、ポート、URL、APIなどに集中していることがわかれば、後続のトラフィック制御やCDN・WAF設定の調整にも役立ちます。

また、DDoS攻撃による負荷によってログ出力や監視自体が遅延している可能性もあります。一つの監視画面だけで判断せず、複数の情報源を突き合わせて状況を確認することが重要です。

関係者へ連絡する

DDoS攻撃の可能性がある場合は、社内の関係者へ速やかに連絡します。情報システム部門、セキュリティ担当、ネットワーク担当、Webサイト運用担当、カスタマーサポート、広報、法務、経営層など、影響範囲に応じて必要な関係者へ情報を共有します。サービス停止が顧客や取引先に影響する場合は、技術的な復旧だけでなく、問い合わせ対応や外部への説明も必要になります。復旧の見通しが立っていない段階でも、「現在確認している事象」「影響を受けているサービス」「現在実施している対応」などを社内で共有しておくことで、対応の混乱を抑えられます。あわせて、契約しているISP、クラウド事業者、CDN、WAF、セキュリティ監視サービス、運用保守ベンダーへの連絡準備も進めます。

ログを保全する

DDoS攻撃への対応では、復旧作業と並行して、可能な範囲でログなどの証跡を保全することも重要です。負荷軽減を優先する過程で設定を変更したり、ログローテーションによって過去のログが上書きされたりすると、後から攻撃状況を確認できなくなる可能性があります。保全対象としては、Webサーバーログ、WAFログ、ロードバランサーログ、DNSログ、ファイアウォールログ、クラウド監視メトリクス、ネットワーク機器のトラフィック情報、アラート履歴などが考えられます。

これらの情報は、攻撃の種類や影響範囲を分析するだけでなく、DDoS攻撃の前後に不正アクセスなど別の事象が発生していなかったかを確認する際にも役立ちます。

ISP・クラウド事業者と連携する

DDoS攻撃への対応では、自社だけで完結しようとしないことが重要です。攻撃トラフィックが自社回線に到達してから遮断しようとしても、すでに回線帯域が逼迫していれば、正規利用者の通信も届かなくなる可能性があります。そのため、攻撃の種類や規模に応じて、ISP、クラウド事業者、CDN、DDoS対策サービスなどと連携し、上流側でトラフィックを制御することが重要になります。

ISPへの連絡

オンプレミス環境や自社回線でサービスを公開している場合、ISPへの連絡が必要になることがあります。自社のファイアウォールで遮断する前に回線が逼迫している場合には、上流側でのフィルタリングや経路制御などの対応が必要になる可能性があるためです。

ISPへ連絡する際は、攻撃を受けているグローバルIPアドレス、影響を受けているサービス、発生時刻、観測している通信量、主なプロトコルやポート、送信元の傾向、現在発生している障害内容を整理して伝えます。また、契約内容によっては、DDoS緩和サービスや緊急時のトラフィック制御オプションが提供されている場合があります。攻撃が発生してから確認するのではなく、平時から連絡窓口、受付時間、必要情報、対応範囲などを把握しておくことが望まれます。

CDN・WAFの活用

WebサイトやWebアプリケーションを公開している場合、CDNやWAFを活用して攻撃トラフィックを緩和できる場合があります。CDNはアクセスを分散し、オリジンサーバーへの負荷を軽減するために利用できます。WAFでは、HTTPリクエストの特徴やアクセス頻度などに応じて、不審なアクセスを制御することが可能です。ただし、CDNやWAFを導入しているだけで、すべてのDDoS攻撃を防げるわけではありません。DNSが適切にCDN経由になっているか、オリジンサーバーへ直接アクセスできる状態になっていないか、必要な防御機能が有効になっているかなどを確認する必要があります。

攻撃中にアクセス制御を強化する場合は、正規利用者まで遮断してしまう可能性にも注意が必要です。ログやトラフィックの状況を確認しながら、段階的に調整します。

クラウド事業者との連携

クラウド環境でサービスを運用している場合は、利用しているクラウド事業者が提供するDDoS対策機能やサポートサービスを確認します。主要なクラウド事業者では、ネットワークレベルのDDoS対策機能や、契約内容に応じたサポートが提供されています。攻撃発生時に支援を受けられるよう、対象リソース、攻撃状況、アプリケーションの正常性、WAFやロードバランサーのログなどを共有できる状態にしておくことが重要です。また、クラウド環境ではスケールアウトによって一時的に処理能力を増やせる場合がありますが、攻撃トラフィックに応じてリソースを増やし続ければ、利用料金が増大する可能性があります。CDN、WAF、ロードバランサー、オートスケーリング、DDoS対策機能などを組み合わせて対応することが重要です。

復旧時に確認すべきポイント

DDoS攻撃の通信量が減少し、Webサイトやサービスが再び利用できるようになっても、すぐに「復旧完了」と判断するのは危険です。攻撃が一時的に弱まっている可能性や、緊急対応として行った設定変更がサービスに影響している可能性があります。また、DDoS攻撃と同時に別の攻撃が行われていなかったかも確認する必要があります。

サービスが正常に利用できるか

Webサイトへアクセスできることだけでなく、ログイン、検索、決済、予約、API連携など、主要な機能が正常に動作しているかを確認します。サーバーやネットワーク機器のCPU・メモリ・帯域使用率、エラー発生状況なども確認し、通常時に近い状態へ戻っているかを確認します。また、攻撃が再開する可能性も考慮し、一定期間はトラフィックやアラートを継続して監視することが重要です。

二次被害が発生していないか

DDoS攻撃への対応中は、大量のアラートやサービス障害への対応に注意が集中します。そのため、同じ時間帯に不審なログインや脆弱性を狙ったアクセスなど、別の不審な事象が発生していなかったかを確認します。WAF、認証、サーバー、ネットワーク機器、EDRなどのログを確認し、通常とは異なる挙動が確認された場合は、必要に応じて追加調査を行います。

一時的に変更した設定がないか

DDoS攻撃への緊急対応として、IPアドレスや地域によるアクセス制限、WAFルールの変更、レート制限などを実施することがあります。こうした設定を残したままにすると、正規利用者のアクセスや業務に影響する可能性があります。攻撃収束後は、変更した設定とその目的を確認し、継続すべき設定と元に戻す設定を整理します。

顧客や取引先への説明

サービス停止などによって顧客や取引先に影響が発生した場合は、必要に応じて障害の発生時刻、影響範囲、復旧状況などを説明します。この段階では、確認できていない原因や被害を断定しないことも重要です。技術部門だけで判断せず、広報、法務、顧客対応部門などと連携して説明内容を整理します。

再発防止に向けて見直すべきこと

サービスを復旧させた後は、今回の攻撃と対応内容を振り返り、次の攻撃に備えます。DDoS攻撃を完全に防ぐことは難しいため、「攻撃を受けないこと」だけではなく、「受けても影響を抑え、早期に復旧できること」が重要です。

攻撃ログやトラフィックの分析

保全したログやトラフィック情報を確認し、攻撃がいつ始まり、どのサービスが狙われ、どのような通信が発生していたのかを整理します。あわせて、検知から関係者への連絡、緩和策の実施、サービス復旧までにどの程度の時間を要したかを振り返ることで、対応上の課題を把握できます。

ネットワーク構成の見直し

まず見直すべきは、ネットワーク構成です。公開サービスが単一の回線や単一拠点に依存していないか、CDNやAnycastを活用できる構成になっているか、オリジンサーバーが直接攻撃を受けやすい状態になっていないかを確認します。また、Webサイト、API、管理画面、社内業務システムなどが同じネットワークに過度に依存している場合、一つの攻撃による影響が複数のサービスや業務へ波及する可能性があります。公開系と管理系の分離や、DNS構成なども含め、攻撃を受けた際に影響が広がりにくい構成になっているかを確認することが重要です。

DDoS攻撃では、回線帯域、ネットワーク機器、DNS、Webアプリケーション、APIなど、攻撃の種類によって影響を受ける箇所が異なります。今回の攻撃でどこがボトルネックになったのかを確認し、その結果をネットワーク構成の見直しに反映することが、次の攻撃による影響を抑えることにつながります。

DDoS対策サービスの導入・見直し

次に、DDoS対策サービスの導入や見直しを検討します。CDN、WAF、DDoSスクラビング、クラウド事業者のDDoS保護機能、ISPのDDoS緩和サービスなど、選択肢は複数あります。重要なのは、自社のサービス特性に合った対策を選ぶことです。静的コンテンツが多いサイトであればCDNによるキャッシュが有効な場合があります。ログインや検索、予約、決済など動的処理が多いサービスでは、WAFやレート制限、アプリケーション層の監視が重要になります。大規模な帯域攻撃が想定される場合は、上流側でのDDoS緩和やスクラビングを検討する必要があります。

また、対策サービスは導入して終わりではありません。緊急時の連絡窓口、対応開始条件、保護対象のIPアドレスやドメイン、ログの取得方法、誤検知時の解除手順、費用条件を事前に確認しておく必要があります。攻撃発生時に初めて管理画面を開く状態では、十分な対応ができないおそれがあります。

DDoS攻撃に備えて平時から準備しておくこと

DDoS攻撃が発生してから対策や連絡体制を検討していては、初動が遅れるおそれがあります。攻撃による影響を抑え、迅速に対応・復旧するためには、ネットワーク構成やDDoS対策サービス、インシデント対応手順などを平時から確認し、実際の攻撃を想定した訓練を行っておくことが重要です。

インシデント対応手順の見直し

対応手順には、攻撃発生時の確認項目、社内連絡先、外部事業者の連絡先、判断権限、ログ保全方法、顧客告知の流れ、復旧判断基準を含めます。特にDDoS攻撃では、技術部門だけでなく、カスタマーサポート、広報、営業、法務、経営層との連携が必要になるため、役割分担を明確にしておくことが重要です。

また、インシデント対応手順は一度作成しただけでは十分ではありません。サービス構成の変更、クラウドへの移行、新しいWAFやCDNの導入、担当者の異動、外部ベンダーの変更などがあれば、それにあわせて手順も更新する必要があります。古い連絡先や現在は利用していないシステム名などが残っていないか、定期的に確認しておきましょう。

DDoS攻撃を含むセキュリティインシデントでは、事前に対応手順を整備しておくことが重要です。関連記事「セキュリティインシデントとは？基礎知識と代表的な事例を解説」もあわせてご覧ください。

訓練の実施

DDoS攻撃への対応力を高めるには、訓練の実施が有効です。実際の攻撃時には、監視アラート、問い合わせ、社内報告、外部事業者との連絡が同時に発生します。手順書を読むだけでは、こうした混乱の中で適切に動けるかは分かりません。

訓練では、「Webサイトの応答が急激に悪化した」「特定APIに大量アクセスが集中している」「ISPから異常トラフィックの連絡があった」など、具体的なシナリオを用意します。そのうえで、誰が最初に状況を確認するのか、どの情報を集めるのか、誰がISPやクラウド事業者へ連絡するのか、どの段階で顧客告知を検討するのかを確認します。

訓練後は、手順の不備や連絡体制の弱点を洗い出し、改善します。DDoS攻撃の対応では、攻撃を完全に止めることだけでなく、被害を限定し、事業への影響を抑え、利用者に適切に説明することが重要です。そのためには、平時からの準備と訓練が欠かせません。

まとめ

DDoS攻撃を受けた場合は、単にサーバーを復旧させるだけでなく、攻撃状況の確認、影響範囲の把握、関係者への連絡、ISP・クラウド事業者などとの連携を並行して進める必要があります。また、通信量が減少したからといって、すぐに対応を終了するのではなく、サービスが正常に利用できることや、DDoS攻撃の前後に別の不審な事象が発生していないことを確認することも重要です。

DDoS攻撃を完全に防ぐことは困難ですが、平時から連絡体制やログ取得、外部事業者との連携方法を整理しておくことで、攻撃発生時の混乱を抑え、サービスへの影響を最小限にすることができます。

【参考情報】

• CISA「Understanding Denial-of-Service Attacks」（https://www.cisa.gov/news-events/news/understanding-denial-service-attacks）
• NCSC UK「Denial of Service (DoS) guidance」（https://www.ncsc.gov.uk/collection/denial-service-dos-guidance-collection）
• Canadian Centre for Cyber Security「Defending against distributed denial of service (DDoS) attacks – ITSM.80.110」（https://www.cyber.gc.ca/en/guidance/defending-against-distributed-denial-service-ddos-attacks-itsm80110）
• JPCERT/CC「インシデント対応依頼」（https://www.jpcert.or.jp/form/）

編集責任：木下

Security NEWS TOPに戻る
バックナンバー TOPに戻る