ハイパーバイザーを狙うエクスプロイト

　仮想マシン（以下、VM）のハッキングは概念でしかないという人には、VMware環境の脆弱性を狙った2009年に登場したエクスプロイト（CVE-2009-1244）について見ていただきたい。このエクスプロイトにより、VM（ゲストマシン）の攻撃者は、仮想インスタンスからホストマシンを乗っ取ることができた。このエクスプロイトで狙われた脆弱性のパッチは迅速に公開されたが、このエクスプロイトが使用可能なものであったことに変わりはない。

　もう1つの有名なハッキングとして、VMから未パッチのWindows Server 2008またはWindows Server 2008 R2のHyper-Vホストに、仮想バスを介してサービス妨害攻撃を行うというものがあった。米Microsoftは、この攻撃で狙われたHyper-Vの脆弱性のパッチを、セキュリティ情報「MS10-102」とともに公開した。

Hyper-Vの構成上の重要な考慮点

　IT部門の多くは、サーバへのパッチの適用を着実に行っているが、仮想ホストにパッチを適用するのは厄介だ。全てのVMをオフラインにしたり、別のHyper-Vクラスタメンバーに移動したりするのは時間がかかる。また、私はしばしば経験しているが、リソースがオーバーコミットされていると、これらの操作は不可能だ。ハイパーバイザーをハードウェアの一部として扱うと、短期的には安定運用ができるかもしれない。だが実際には、潜在的なセキュリティホールを作ってしまうことになる。このため、このレイヤーでのパッチ適用が重要になる。

　仮想環境でエクスプロイト対策として最新パッチを適用するのは、管理者にとって当然のことだ。しかし今のところ、この作業はなおざりになっているかもしれない。エクスプロイトを利用したハイパーバイザーへの攻撃は、まだ比較的珍しいからだ。そのため、管理者は仮想化によって一定のセキュリティや保護が確保されると想定することが多いが、それは思い込みにすぎないかもしれない。また管理者は、日々のVM管理の手間を軽減するために、警告やベストプラクティスを無視するかもしれない。しかし、これらのまずい選択は行われたとたんに忘れられがちだ。管理者はシステムが攻撃されるまで、選択を誤ったことに気付かないだろう。

　Hyper-Vに焦点を絞ると、最初のセットアップの際に行うべき重要なことが幾つかある。これらを行うことで攻撃ベクトルを減らせる。その1つが仮想ネットワークの設定だ。ハイパーバイザーがホストする仮想イーサネットスイッチは、親ホストのネットワークカードを使って物理レイヤーに接続する目的でさまざまな方法で利用され、接続される。構成を誤ると、これらの仮想接続がいろいろな問題を引き起こす恐れがある。

　管理ネットワークをゲストVMと共有する設定にすると、攻撃ベクトルが発生し、VMがHyper-Vの管理OSにアクセスし、正当な資格情報でHyper-Vのホストと設定や、他のVMにアクセスすることが可能になる。この設定オプションは、デフォルトではオフになっているが、非常に多くの管理者がオンに切り替える。多くのマシンから管理ができ、管理が容易になることや、使えるネットワークインタフェースカード（NIC）が限られていることが理由だ。だが、このオプションをオンにすると、セキュリティ上の脅威を招く。管理OSがホストするどのVMからも管理OSを攻撃できてしまうからだ。このため、管理専用ネットワークには、常に物理ネットワークアダプターを専用に割り当てなければならず、これらのアダプターを通常のVMトラフィックと共有するのは絶対に禁物だ。

　また、さまざまなマシンからのトラフィックを論理的に分離するために、VLANを認識するようにHyper-Vを構成することもできる。これは、物理レイヤーを意識せずにさまざまなサブネットを1台のマシンに集約し、クラスタ化されたホストをサポートする良い方法だが、実のところセキュリティの向上にはつながらない。一見するとセキュリティ向上につながると思えるかもしれない。異なるVLAN上のVMにはアクセス権が与えられていて、ネットワークレイヤーでルーティングが適切に行われる場合を除けば、お互いのトラフィックを見ることができないからだ。しかし実際には、これらのトラフィックは全て同じ仮想および物理ネットワークを流れており、そのせいでVLANがハッキングされる恐れがある。これは、物理環境で守るべきルールを仮想環境にも応用しなければならないということだ。

　このことから、セキュリティ要件が異なるサーバを同一の仮想ホストに混在させないこともポイントになる。個々のサーバは、管理者やIT部門によって何らかの基本的なセキュリティレベルを設定されているはずだ。例えば、DMZ（DeMilitarized Zone）内のWebサーバは、社内ファイルサーバとはセキュリティレベルが異なる。インターネットに公開するDMZ Webサーバは、エクスプロイト攻撃を受ける危険が社内ファイルサーバよりも高いと判断したら、両サーバを同じ仮想ホストに混在させてはならない。また、その2つのネットワークを同じ仮想ホストに接続してはならない。これは、物理環境におけるセキュリティルールを仮想環境に応用したものだ。

　Hyper-Vを実行するときは、そのホストではHyper-V以外は実行してはならない。管理者は多くの場合、既存サーバにHyper-Vロールをインストールする。その物理サーバをより有効に活用するためだ。サーバの有効活用という考え方自体は良いが、そのホストでは、他のサーバ機能を存続させてはならない。ホスト上のアプリケーションはVMに移行する必要がある。ほとんどの環境では、アプリケーションコードの脆弱性を追跡し、パッチを当てるのは大抵厄介だ。アプリケーションをホストで稼働させ続けた場合、アプリケーションコードの脆弱性を突くエクスプロイトにより、攻撃者がホストマシンにアクセスできてしまう恐れがある。そうなれば、全てのゲストVMへのアクセスも可能になってしまうだろう。

　もう1つのアドバイスは、VM管理のためのアカウントやグループを、仮想ホストを管理するためのものとは別個に用意することだ。そうすれば、VMへのエクスプロイト攻撃が発生しても、仮想ホストは簡単には乗っ取られない。また、できるだけ的確な監査が行われるように、全てのVMにIntegration Servicesがインストールされるようにするとよい。

　Hyper-Vは、システムを保護する機能を多数備えている。例えば、ASLR（Address Space Layout Randomization）、仮想プロセッサをユーザーモードで動作させるプロセス、VMごとに仮想デバイスとVMバスを持たせる機能などだ。仮想環境では多くの場合、セキュリティ上の最大の問題はハイパーバイザー自体ではなく、構成の操作による過大な権限の取得や、アプリケーションへのエクスプロイト攻撃だ。常に最新のパッチを適用し、ネットワークを分離しておくというベストプラクティスを実行し、仮想環境に対する重大な脅威を回避しよう。

本稿筆者のエリック・ビーラー氏は、90年代半ばからIT業界に携わっており、そのはるか前からコンピュータ技術に親しんでいた。現在、共同所有するConsortio Servicesを通じてコンサルティングとトレーニングを提供している。