Cisco Japan Blog
Share

Talos インシデント対応チームが解説するサービス拒否攻撃への備え


2022年3月25日


ここ数年、恐喝目的や政治的動機によるサービス拒否攻撃が増加しています。大手から中小まであらゆる規模企業や組織が脅威にさらされており、さまざまな攻撃の標的になる恐れがあります。 

既存のインフラを停止に追い込むことを目的として、フォーマットやプロトコルをさまざまに変えながら攻撃が仕掛けられています。こうした攻撃に対処するためには、念入りな準備計画が必要です。

攻撃がもたらす影響を事前に把握しておくことで迅速な対応が可能になり、事業活動にもプラスに働きます。

概要

ここ数年、標的の企業popup_icon政府機関全体popup_iconのインフラを一時的に使えなくすることを狙った攻撃が世界中で見られます。サービス拒否(DoS)や分散型サービス拒否(DDoS)と呼ばれる攻撃です。ボットネットや侵害されたシステムなど複数のネットワークリソースを利用して膨大な量のネットワークトラフィックを生成し、攻撃対象の環境に送りつけてサービスを中断させます。

こうした中断を引き起こすために、攻撃者は複数のリソースを使用してネットワークトラフィックを増幅させ、身元が特定されないようにしています。こうなると、攻撃を防ぐのは容易ではありません。DoS 攻撃や DDoS 攻撃が最終的にもたらす影響はさまざまです。オンラインサービスが中断するだけの場合もあれば、事業全体がオフラインpopup_iconになってしまう場合もあります。どんなに手を尽くしても、攻撃者の性質は変えられず、標的の企業に対して攻撃者が使用するさまざまな戦術、手法、手順(TTP)も変えることはできません。それでも、さまざまなタイプの攻撃活動への対策を立てておけば、影響を軽減し、復旧時間を短縮して、サイバーインシデントのコストを大幅に削減できます。

技術概要

セキュリティの専門家によると、ここ数年で DoS 攻撃の帯域幅が増大し、その影響も拡大する一方とのことです。2004 年、DDoS 攻撃で使用された帯域幅は平均 8 Gbps でした。それが 2015 年にはすでに 400 Gbpspopup_icon ほどになり、2017 年には最大 2.3 Tbpspopup_icon に達しました。

このように増大しているのは主に UDP フラグメンテーションや DNS リフレクションなどの攻撃で増幅効果を使用していることが原因です。専用のツールがなければ、こうした攻撃を検出して封じ込めるのは容易ではありません。特定するのが難しいベクトルがこれまでにもう 1 つ確認されています。アプリケーション層への攻撃に相当するものです。リクエストが有効である間、ヘッドレスブラウザや Slowloris 型の攻撃popup_iconを展開してリソースを消費し続けます。最終的には、新しい接続プールを作成できるソケットがなくなってサーバーにアクセスできなくなりますpopup_icon。これと同様に、Mirai などの大規模なボットネットによる攻撃では IoT デバイスが侵害され、短時間で大量のトラフィックが生成されるようになります。ボットネットは、リフレクションやプロトコルの設定不備を突くのではなく、数千もの侵害したシステムから大量のpopup_iconトラフィックを生成します。

分散型サービス拒否攻撃(DDoS)の種類

DDoS 攻撃には 3 種類あり、それぞれ必要な手順が異なります。いずれもビット/秒で評価します。

ボリューム型 DDoS

ボリューム型 DDoS では、UDP や ICMP など、通常はハンドシェイクpopup_iconを必要としないプロトコルが使用されます。攻撃の目的は、標的のネットワークで使用できるすべての帯域幅を飽和状態にすることです。ボットネットをはじめとするゾンビコンピュータが世界各地から大量のトラフィックを送りつけるため、攻撃の規模はほぼ無限だと言えるでしょう。ハンドシェイクが不要なプロトコルを使用するので、攻撃対象にパケットを送信し続けるのは造作もありません。増幅攻撃も同じカテゴリに分類されます。Network Time Protocol(NTP)popup_iconクエリや Domain Name System(DNS)popup_iconクエリなどのプロトコルの弱点を利用して、リクエストを増幅させてサイズを何倍にも大きくできるからです。

プロトコル DDoS

プロトコルの弱点を悪用した攻撃がプロトコル DDoS です。SYN フラッド、Smurf、フラグメントパケットなどの攻撃を展開します。ロードバランサやファイアウォールなどのネットワーキングデバイスの処理能力を消費して、他のエンティティに応答できないようにします。デバイスのほとんどは FIFO(先入れ先出し)の原則に従ってネットワークパケットを処理します。この処理は稼働中のサーバーがアプリケーションなどのリソースにサービスを提供する前に行われるため、サービス中断の原因になります。通常、レイヤ 3 と 4 がプロトコル DDoS 攻撃の標的になります。

アプリケーション DDoS

アプリケーション DDoS では、POST リクエストや GET フラッドを大量に送りつけるなどアプリケーション間の連携手法を利用して、TCP/IP スタックのレイヤ 7 でアプリケーションを制御不能にします。実行は最も困難と言われながらも、この手の DDoS 攻撃を展開するソフトウェアプログラム(Slowloris など)がすでに開発されています。特定のアプリケーションプロトコル(HTTP や SMTP など)でフォーマットされたデータを送信するため、データが境界デバイス上の初期フィルタリングを通過して、処理アプリケーションに到達します。アプリケーションはデータベースに接続されていることが多いため、攻撃の影響がバックエンドシステムにまで及ぶ場合があります。

防御の備え

DDoS 攻撃に備えた計画は、事業継続計画にとって非常に重要です。事業のインフラとサービスの実状を反映した正式なリスク評価手順に沿って、事業継続計画を評価する必要があります。利用しているサービスの実際の攻撃対象領域(ネットワーク、接続、帯域幅、デバイス)が不明なままでは DDoS がもたらす影響を把握することはできません。

攻撃者はボットネット(Mirai)を利用して標的をすばやく切り替えることができるため、DoS 攻撃に対する保護を計画するときは、さまざまなシナリオに備えることが重要です。

正式なアセット検出を実行して外部の攻撃対象領域を評価する

事業継続にはアセットが関連しているため、アセットを洗い出して各アセットの重要性を確認します。そうすることにより、接続状態を常に維持する必要があるシステムと、そうしたシステムが DoS 攻撃に直面した場合に事業にもたらす影響が明らかになります。適切な緩和計画を策定するには、重要なアセットのリストが必要です。ネットワーク図、企業向け製品サイト、パブリック IP アドレス、公開されている NAT アドレス、データベースのリスト、システムホスティングの詳細、IPAM をはじめとするデータソースを精査して、攻撃者から見て組織の最も脆弱な部分を特定します。

DoS 攻撃がデータベース、ルータ、スイッチなどのバックエンドシステムに与える影響を評価する

公開しているインフラとさまざまなバックエンドシステムとの依存関係ツリーとデータフローマッピングを策定して、攻撃を受けた場合の最悪のシナリオを理解します。これで、総攻撃を受ける前に「what-if」シナリオを把握できるようになります。

シングルポイント障害となるシステムを特定する

前の手順で策定した依存関係ツリーとデータフローマッピングに基づいて、シングルポイント障害となるシステムを必要に応じてバックアップから復帰できるようにします。システムがダウンした場合は、クイック復元の手順に従ってシステムを再稼働させることができます。少なくとも年に 1 回は実施する事業継続計画演習の一環として、定期的にバックアップと復元の手順をテストします。可能であれば、長期的な戦略計画を作成して、シングルポイント障害となるシステムのレジリエンスを高めることをお勧めします。

インシデント対応計画を精査する

攻撃を受けた場合に発動できる堅固な事業継続計画を文書化し、インシデント対応計画の追加のガイダンスに従いますpopup_icon。従業員が外部システムを使用し、ネットワークへの代替ルート(多要素認証による独自の VPN 接続など)を確保できるようにします。攻撃に関する情報を従業員に通知するときは、ネットワーク外で利用できるテキストメッセージなどを使用します。また、進行中の攻撃について警察や地元のコンピュータ緊急対応チーム(CERT)に通知するためのプロセスも文書化することをお勧めします。

ISP の詳しい連絡先が分かるようにしておく

ボリューム型攻撃を受けたときに攻撃をある程度緩和するには、ISP が非常に重要な存在となります。攻撃の予兆が見られたら ISP が適切な技術リーダーに連絡できるように、ISP との連絡手段をインシデント対応計画に含めることが重要です。技術リーダーは、ISP が DDoS 攻撃に対して実行できる支援策や緩和策を把握しておく必要があります。

DDoS 攻撃を自動的に緩和できるように高性能の DDoS デバイスを外部に導入する

DDoS からの保護に関して、攻撃を受けた場合に役立つ適切なインフラとサービスを備えた企業と契約を結び、サービスレベル契約(SLA)に合意します。Cisco Secure Firewall アプライアンスは、シスコパートナーである Radware と簡単に統合してエンドカスタマーに提供することができます。DDoS を緩和または保護するサービスを提供する企業は通常、DDoS トラフィックを吸収するためのさまざまな機能を保持しています。そうした機能により、顧客のネットワーク環境が飽和したり強制的にオフラインになったりするのを防ぎます。

オペレーティングシステムやアプリケーションスタックなどの外部デバイスを強化する

アプリケーションをはじめとするコンポーネントにストレステストを実施して、膨大な量のトラフィックを安全に処理できることを確認します。サポートライブラリへのパッチの適用と、可能であれば基礎となるソフトウェア向けのさまざまな強化オプションpopup_iconの導入に集中して取り組む必要があります。

デバイスを適切に構成して環境の「ノイズ」を減らす

システム管理者とセキュリティ担当者の懸命な取り組みによって環境にデバイスが増え続け、そうしたデバイスから自動的に生成されるアラートの数がますます増えています。環境から不要なノイズをなくすには、アラートの忠実度が高いアラートディフェンダーで構成を強化する必要があります。時間をかけて取り組まなければなりません。必要に応じて、ベンダーと外部のサービスプロバイダーも構成の微調整に参加してもらいます。デフォルト設定を修正し、忠実度の低いアラートは自動的に処理されるようにさまざまな構成を調整します。

静的コンテンツにはコンテンツ配信ネットワーク(CDN)を使用する

外部コンテンツは CDN を介して公開するようにします。通常、CDN は Cloudflare や Akamai などのサービスによって DDoS から保護されるようになっているからです。

インシデントへの備えができていることを確認する

インシデントが発生した場合の適切な手順の特定と準備を目的としたインシデント対応の準備状況の評価popup_icon机上演習popup_iconその他の演習popup_iconを実行することで、実際に攻撃が展開される前にレジリエンスをテストできます。また、攻撃に組織的に対応する中で果たすべき役割をしっかりと認識できます。

DDoS 攻撃を受けた場合の緩和策

専門のプロバイダーやツールの支援がなければ、攻撃を緩和するためにできることはごく限られます。それでも、不要なリスクを減らして DDoS 攻撃の影響を受けないようにする方策はあります。ここでは、そのいくつかをご紹介します。

  • 侵入防御システム(IPS)を導入していても、大量のトラフィックが送りつけられれば、セキュリティデバイスが制御不能になる場合があります。ただし、外部のファイアウォールで攻撃をブロックできるほか、SNORT® などpopup_iconの IPS で保護を強化できる可能性があります。この点は特にレイヤ 7 の DDoS 攻撃の場合に重要です。リフレクション攻撃は IPS では止められません。この手の攻撃を受けた場合は、他の手順が必要になることがあります。
  • また、フロントエンドサーバー、データベース、アプリケーションがクラウドベースであるときに特に有効な方法ですが、リソースの自動スケールを追加で導入できる場合は CPU、メモリ、帯域幅を増やすことができます。
  • ISP と共同でボリューム型 DDoS を巨大インフラにリダイレクトして、組織の帯域幅を超えるトラフィックを緩和します。
  • 外部のルータでリバース パス フォワーディング(RPF)を使用して、IP アドレススプーフィングが緩和されるようにします。
  • 事業を展開していない国を発信元とする接続を拒否します。
  • 可能であればパケットタイプごとにバーストサイズとトラフィック優先順位を構成して、トラフィックに制限を課します。トラフィックが通過しても境界デバイスが制御不能に陥らなければ、グローバル ACL を導入して境界デバイスへの DDoS トラフィックの優先順位を下げることができます。
  • 公開システムの ICMP パケットレート、SYN パケットレート、DNS TTL に制限を適用します。
  • ログから IP 攻撃のリストを取得して、トラフィック量でソートします。境界デバイスからのサンプルのパケットキャプチャに基づいて、トラフィックのプロファイリングを試みます。ただし、攻撃者の数がかなりの数になる場合があるため、必ずしも有効な方法とは言えません。
  • 攻撃について役員会や最高情報セキュリティ責任者(CISO)に報告します。お客様に影響が及ぶ場合は、公式声明を出してお客様に攻撃について説明し、支援の要請が受付電話や IT サポートに殺到しないようにします。

 

本稿は 2022 年 03 月 16 日に Talos Grouppopup_icon のブログに投稿された「Preparing for denial-of-service attacks with Talos Incident Responsepopup_icon」の抄訳です。

 

Tags:
コメントを書く