クラウド環境における脅威 – パート 2: 分散サービス拒否攻撃


本記事は、Microsoft Security のブログ “Threats in the Cloud – Part 2: Distributed Denial of Service Attacks” (2014 年 2 月 7 日公開) を翻訳した記事です。

 

インターネットに接続して利用する Web サイト、ポータル、クラウド サービスなどのサービスの運用や使用をしている組織では、サービスを妨害する恐れのある脅威について知っておく必要があります。このシリーズの最初のパートでは、ドメイン ネーム システム (DNS) 攻撃とそれに伴うサービスの妨害や大量ユーザーのマルウェア感染について説明しましたが、ここでは分散サービス拒否 (DDoS) 攻撃について、最新版のマイクロソフト セキュリティ インテリジェンス レポート (第 15 版) の洞察を交えながら説明します。

分散サービス拒否 (DDoS) 攻撃
インターネットのクラウド サービスやマイクロソフトのオンライン サービスに悪影響を及ぼすことを企てるために使われる、もう 1 つの一般的な攻撃ベクトル(手段や経路)は、DDoS 攻撃です。マイクロソフトでは、DDoS を防御する手段として、DoS攻撃 や DDoS 攻撃による影響を回避するための対策を日常的に講じることで、サービスやお客様にアップタイムと可用性を確実に提供しています。攻撃の一般的な種類には、SYN フラッド、DNS アンプ攻撃、不正な形式の TCP や UDP のパケット、HTTP や DNS に固有のアプリケーション レイヤーの悪用などがあります。自由に利用できる多くの DDoS ツールキットで使用されている一般的な攻撃手法の 1 つでは、固定ペイロードを含む断片化された IP パケットが関係しています。

たとえば、2013 年 3 月に大きく報じられた DDoS 攻撃の例では、攻撃者が DNS アンプ攻撃を使って最大で 300 ギガビット/秒 (Gbps) のトラフィックで Spamhaus の迷惑メール防止サービスを攻撃しました。この攻撃について詳しくは、Michael McNally (マイケル・マクナリー) 氏が寄稿した ISC Knowledge Base (ISC ナレッジ ベース) の記事「DNS アンプ攻撃とは?」(英語情報) をご覧ください。

DDoS 攻撃は、図 1 のようにトラフィックの毎秒パケット数と毎秒ビット数の両方が大幅に上昇するので、一般に監視テレメトリで発見されます。図 1 に見られる 30 Mbps 攻撃は名目上のものですが、検出されないままでいると、サービスの可用性に影響する可能性があります。たとえサービス自体はユーザーが引き続き利用できたとしても、ユーザーがサービスへの接続に利用している帯域幅が枯渇し、その結果、サービス速度の低下、サービスの断続的な接続、信頼性の低下、サービスへの接続不可が発生することがあります。

図 1: DDoS 攻撃中の監視テレメトリの流れ

 

IP の断片化が関係する一般的な攻撃は、「A」(図 2 のように 16 進数では 0x41) のような 1 文字の ASCII 文字が何度も繰り返され、ユーザー データグラム プロトコル (UDP)、伝送制御プロトコル (TCP)、インターネット コントロール メッセージ プロトコル (ICMP)、KRYPTOLAN、多目的メッセージ トランザクション プロトコル (VMTP)、インターネット プロトコル バージョン 6 (IPv6)、拡張名前サービス (XNS) などの複数の通信プロトコルを使用して転送される、パディングされたペイロードが含まれている可能性があります。パケットには通常、1,518 バイトの完全なペイロードが含まれ、ターゲット システムの複数のデスティネーション ポートに UDP の断片が送信されます。

図 2: DDoS 攻撃による UDP の断片化

 

1 回の 60 秒間のDDoS 攻撃で、マイクロソフトでは断片化されたトラフィックを送信する 8,985 個以上の固有の IP アドレスを検出しました。この攻撃の間、サービスは受信パケットを拒否せざるを得なかったため、実際の攻撃件数は確認されているデータよりかなり多かった可能性があります。その後の調査で、ホストが最近の DDoS 攻撃に参加したことがわかり (Microsoft Digital Crimes Unit から合法的な方法で入手)、それによると、一般的な攻撃ツール (Backdoor:Perl/IRCbot.E) が UDP フラッディング攻撃に使用されたことが判明しました。IRCbot のようなツールを使えば、クラウド サービス、Web サイト、ポータルなどに損害を与える可能性のある攻撃を誰でも簡単に起動できます。マイクロソフトや他のクラウド サービス プロバイダーは、そのような攻撃を軽減するための防御対策や手法を講じていますが、そのためにはリソースを集中的に使用する場合があります。

リスク管理の指針
DDoS 攻撃の軽減は困難であることが考えられるため、クラウド サービス プロバイダーや Web サイトの運用者は、この種の攻撃に備えておく必要があります。以下は、その具体的な指針をまとめたものです。

DNS アンプ攻撃を防ぐためには、すべての DNS 管理者が相互に進んで協力し合うことが重要です。米コンピューター緊急事態対策チーム (US-CERT) では、攻撃者が DNS サーバーを使って攻撃をしかけてこないようにするために管理者が行うべきことをいくつか提示しています。ここでは、その一部について説明しますが、詳しくは、https://www.us-cert.gov/ncas/alerts/TA13-088A (英語情報) をご覧ください。

    • ほとんどの DNS アンプ攻撃では、インターネット上のコンピューターから送信された DNS クエリを解決するオープン DNS ネーム サーバーを利用しています。そのため、システム管理者はドメイン外部のホストから受信したクエリを無視するよう DNS サーバーを構成する必要があります。ネットワーク内の誤った構成の DNS サーバーを検出するために管理者が利用できる多くのツールには、以下のようなものがあります。
      • Open Resolver Project は、オープン DNS リゾルバーのリストを管理し、オープン リゾルバーの IP アドレスの範囲を検索するためのインターフェイスを提供しています。
      • Measurement Factory もオープン DNS リゾルバーのリストを管理しており、特定のサーバーが 再帰問合せ (open recursion) を許可しているかどうかを特定するための無料のツールを提供しています。
    • DNS リゾルバーの管理者は、認可されたクライアントの再帰の制限など、リソースが攻撃に使われないようにするためのいくつかの方法を利用できます。
      • ソース IP の確認: 適切に構成された DNS リゾルバーであっても、ソース IP アドレスを使って DNS クエリの発行を偽装する攻撃者に悪用される可能性があります。Internet Engineering Task Force (インターネット エンジニアリング タスク フォース) では、システム管理者がネットワーク侵入のフィルタリングを実行して、パケットによって実際に取得されたパスを使って検出できないアドレスから送信されたパケットを拒否する手順を説明した 2 つの Best Current Practice (最新のベスト プラクティス) ドキュメント (http://tools.ietf.org/html/bcp38 および http://tools.ietf.org/html/bcp84) をリリースしています。
      • 権威ネーム サーバーでの再帰の無効化: 権威ネーム サーバーは、指定されたドメイン (microsoft.com など) およびオプションで 1 つ以上のサブドメイン (www.microsoft.com など) のパブリック名を解決するサーバーです。権威ネーム サーバーは、パブリックからのアクセスが必要であるため、クライアントからの再帰クエリを拒否する必要があります。Windows Server で再帰を無効にする方法については、「DNS サーバーで再帰を無効にする」をご覧ください。
    • 認可されたクライアントの再帰の制限: 組織やインターネット サービス プロバイダー (ISP) に導入されている DNS サーバーでは、再帰クエリは認可されたクライアントに代わって実行する場合のみ許可し、できれば組織のネットワーク内のクライアントに限定するよう構成する必要があります。

DDoS 攻撃は、あらゆるクラウド サービスや Web サイトが標的になる可能性があります。適切に運用されているクラウド サービスでは、ほとんどの企業 IT インフラストラクチャに比べ、DDoS 攻撃への対策がはるかによく整備されている傾向があります。Web サイトやネットワーク インフラストラクチャの他の重要な部分への DDoS 攻撃の対策に苦慮している組織では、クラウド サービスが提供するセキュリティや運用上の利点を利用するためにも、リソースの一部をクラウドに移すことを検討する必要があります。

Trustworthy Computing (信頼できるコンピューティング) 部門
ディレクター
Tim Rains (ティム・レインズ)

Skip to main content