Azure の DNS セキュリティ アプライアンス


執筆者: Gareth Bradshaw (Senior Program Manager, Microsoft Azure Networking)

このポストは、6 月 21 日に投稿された DNS security appliances in Azure の翻訳です。

 

概要

マルウェアやボットネット (ZeroAccess、Conficker、Storm など) の活動には増殖と通信が不可欠です。これらのプログラムは、DNS や IRC、ピアツーピア ネットワークといった複数の通信手段を使用します。通常 DNS プロトコルは、人間が扱いやすい形式のドメイン名を機械が使用しやすい IP アドレスに対応付けます。しかし、ほとんどの企業では DNS クエリをフィルタリングしていないため、DNS クエリが密かに通信チャネルとして使用されることがあります。マルウェアに感染したシステムから送信されるデータは DNS クエリでエンコードされ、疑惑を持たれることなく DNS 応答としてマルウェアに命令が返信されるのです。

この記事では、この種の脅威に関する説明とネットワークの保護方法をご紹介します。

DNS のしくみ

DNS は高度に分散化されたシステムであり、サーバーや組織が単体ですべての DNS クエリに応答することは不可能です。“.com” という DNS サーバーは “microsoft.com” の DNS データがマイクロソフトのどのサーバーに存在しているかを把握していますが、DNS レコードそのものは保持していません。権威 DNS サーバーは自身のドメインのデータのみを保持しているため、特定の DNS レコードを発見するには多数の権威 DNS サーバーを順にたどる必要があります。

アプリケーションが DNS レコードを参照する場合、ローカルの再帰リゾルバーにクエリが送信されます。クエリを受信したサーバーは権威 DNS サーバーの階層を移動して、必要な DNS レコードを検索します。この処理は再帰解決と呼ばれ、通常は社内インフラストラクチャ (下図の場合は Azure インフラストラクチャ) のリゾルバー群により処理されます。再帰リゾルバーの IP アドレスは、(ネットワーク管理者により) オペレーティング システムで静的に設定されているか、または DHCP などのシステムにより動的に設定されます。Azure では DHCP を使用しています。

 

ほとんどの場合、再帰リゾルバーは、解決時にクエリをフィルタリングしません。ネットワーク管理者が外部リソースに対してユーザーが http 接続を開くことを許可していなくても、システム管理者が任意の DNS 要求の解決を許可するときに隙ができます。それでは、DNS クエリによってどのような損害が生じるおそれがあるのでしょうか?

DNS を悪用した脅威

DNS システムは、ドメイン名を IP アドレスに対応付けるだけではありません。DNS レコードにはさまざまな種類があり、たとえば MX レコードはドメインのメール サーバーの特定に使用され、TXT レコードは任意のテキストの格納に使用されます。TXT レコードなどのレコードは、命令やペイロードなどのデータがマルウェアによって受信されやすくなる原因となっています。

攻撃者は、マルウェア内で DNS クエリを使用して指揮統制 (C&C) サーバーと通信します。マルウェアは DNS クエリを実行し、その応答を「このターゲットは興味深いのでキー ロガーをインストールしなさい」というような命令として解釈します。また、DNS クエリを使用してマルウェアの更新や追加モジュールをダウンロードさせます。さらに、DNS クエリをブロックされにくくするために、マルウェアはドメイン生成アルゴリズム (英語) を使用して新しいドメインを毎日いくつも生成することが少なくありません。攻撃者は少数のドメインを登録するだけでも通信チャネルを開いたままにすることができますが、一方で通信をブロックするには、法執行機関によってほぼすべてのドメインをブロックしてもらう必要があります。このため、攻撃者にとっては有利な状況となっています。

ここまでは受信側の通信について説明しましたが、感染したサーバーからのデータのエクスポートについてはどうでしょうか。DNS プロトコルでは最大 253 文字の長さまでのドメイン名を使用でき、“<任意のアドレス>.mydomain.com” に対するクエリは “mydomain.com” の DNS サーバーに送信されます。感染したホストに対する DNS クエリを作成 (例: “the_password_for_joeblogs_gmail_com_is_letMeIn.mydomain.com”) し、カスタム DNS サーバー ソフトウェアを使用して他の終端でメッセージを解釈すると、データをエクスポートすることができます。この手法は TCP-over-DNS プロトコル (DNS-over-TCP と混同しないようにご注意ください) に汎用化されており、DNS インフラストラクチャをトンネルして TCP トラフィックを伝送します。

ここで重要となるのが、マルウェアはこうした通信チャネルの使用を開始する前にサーバーに感染しておく必要があるという点です。したがって、DNS のフィルタリングはそもそも多層型防御機構の一部であり、他の手法で初期感染を防ぎきれなかった場合に影響を緩和するための手段です。デスクトップ環境では、DNS フィルタリングはメールや Web サイトの悪意のあるリンクから感染プロセスが開始されることを防ぐ効果もあります。

ベスト プラクティス

セキュリティの状態を良好に保つことが不可欠ですが、そのためには多層型の手法が欠かせません。まずはマルウェアの感染と繁殖を防ぐことに主眼を置くべきであり、それに加えて DNS トラフィックの監視やフィルタリングを行い、感染したマシンでマルウェアを検出したり、その通信をブロックしたりします。バランスの取れた防御戦略とするためには、以下のような項目について考慮する必要があります。

 

 

  • Network Security Groups (ネットワーク ACL) を使用して、ネットワーク外部との送受信とネットワーク内部での通信を制限すること。たとえば、DNS トラフィック (ポート 53) から他のサーバーへの通信は、信頼できる再帰リゾルバーへの通信のみに制限します。

 

  • ファイアウォール (DNS、アプリケーション、IP ベース) を使用して不審なトラフィックの検出やフィルタリングを行うこと。詳細については、Azure Marketplace で入手可能なサードパーティ製アプライアンス (英語) をご参照ください。

 

  • 危険性の高いワークロードを分離すること (データベース サーバーからインターネットにアクセスしないなど)。

 

 

  • DNS トラフィックをスキャンしてマルウェアの活動を検出するスマート DNS リゾルバー (DNS ファイアウォール) を実行すること。詳細については、Azure Marketplace で入手可能なサードパーティ製 DNS ファイアウォールをご参照ください。

 

Azure のインフラストラクチャでは主要なセキュリティ機能セットを利用できますが、それ以外にもサードパーティ製セキュリティ製品の大規模なエコシステムの構築が進んでいます。これらの製品 (ファイアウォールWAFウイルス対策DNS ファイアウォールなど) は、Azure Marketplace からわずか数クリックで簡単にデプロイすることが可能です。多くの製品には無料試用版が用意されており、試用期間終了後はサプライヤーから直接請求されるか、または Azure サブスクリプションを通じて時間単位で料金が請求されます。

現在、多くの企業で社内インフラストラクチャに DNS ファイアウォールをデプロイする流れが広がっており、マイクロソフトでは Azure Marketplace でサードパーティ製 DNS ファイアウォールを拡充する取り組みを始めています。これら特殊な DNS サーバーでは、DNS クエリを調べてマルウェアの活動の兆候を検出し、アラートを通知したりトラフィックをブロックしたりします。たとえば、C&C サーバーへのクエリは、クエリ先のドメインまたは DNS サーバーの IP アドレスで識別できます。DNS ファイアウォールは DNS サーバーとして仮想ネットワーク内にデプロイされ、その多くは、常に変化する脅威の状況に対応するために脅威インテリジェンス フィードを使用して最新状態を維持します。この場合の仮想ネットワークを図で表すと次のようになります。

 

Comments (0)

Skip to main content