VMwareの実験



この投稿では、VMware vSphere 4.1での不適切で非体系的な実験の結果を司法コミュニティに提示します



仕事について



この研究は、卒業プロジェクトの特別セクションの一部として実施しました。

研究部分は、NIST SP 800-125規格の翻訳に基づいています( 投稿を参照)。

特別なセクションでは、最も可能性の高い脅威を調査するタスクが与えられたため、内部侵入者のモデルが選択されました。



スタンドについて



スタンドは、4つのVM(Ubuntu 12.10用に2つ、WinServer 2008 R2用に2つ)を実行する3つのESX 4.1サーバーのクラスターであり、それぞれ2つのvNIC:ローカルセグメントにルーティングされる共有ラボVLANと分離VLANを備えています。

使用したアプリケーションソフトウェアから:



体験



スニッフィング

最初に検討し始めたのは、無差別仮想スイッチモードです。 すでにその過程で、VMwareコミュニティに関する総合的な記事を見つけました。 なぜなら オリジナルは常に改ざんするよりも優れています。 直接リンクを使用することをお勧めします。



MACスプーフィング

物理的に十分な「スマート」スイッチには、MACアドレススプーフィングなどの攻撃を防ぐメカニズムがあります。 たとえば、これらはCisco Systemsスイッチのポートセキュリティ設定であり、その助けを借りて各デバイスポートの許可アドレスをハードコーディングできます。

仮想環境には独自の特性があります。 MACアドレスを含むすべてのVM設定はVMファイルに保存され、仮想インフラストラクチャの管理者のみが変更を許可されます。 また、VMを作成し、それらを仮想ポートのグループおよびVLANに接続することもできます。 さらに、MACアドレスの変更-Accept / Rejectの設定があり、ゲストOSがVMファイルに記録されたアドレスとは異なるアドレスでネットワークにアクセスすることを許可または禁止します(ただし、デフォルトで置換が許可されます)。

アドレスの変更を禁止するのは論理的ですが、IaaS(サービスとしてのインフラストラクチャ)サービスの顧客がこの機会を必要とする状況(たとえば、ソフトウェアをテストするため)を想像することは難しくありません。

1つのオプション:前の脅威と同じことを行う-VLANを異なる設定の部分に分割します。

2番目のオプションを検討してください。VVIの管理者が無能であるか、VMware開発者の摂理のためにデフォルト設定のままにする場合(ポートのグループの無差別モードは有効になりません)。

単純な攻撃スキーム






Windows VMの1つと外部ホスト(ローカルネットワークから)との間のICMP交換をターゲット情報フローにします。

攻撃者が持つべきすべて:被害者のMACアドレスとVMのゲストOSのローカル管理者の権限。

攻撃:

sudo su-

ifconfig eth0 down

ifconfig eth0 hw ether NEW_MAC

ifconfig eth0 up

tcpdump –n src host 10.106.30.104



結果:攻撃者は交換全体を傍受します。 さらに、攻撃の検出は非常に困難です。 攻撃されたVMに到着するリクエストの頻度は変化せず、攻撃者で傍受されたメッセージの頻度と同じです。これは、仮想スイッチがパケットを単純に複製することを意味します。 機械の相互作用も侵害されません。 これらのVM間の直接交換のみが不可能になります。



MACフラッド

最も「汚れた」実験は、軽率に行われましたが、興味深い結果をもたらし、もちろん、より詳細な調査が必要です。



各物理スイッチは、CAM(Content Addressable Memory)データ、または単にスイッチングテーブルで動作します。 異なるモデルのボリュームは異なります。 例(花嫁が科学的な真実を装っていない場合にグーグルで調べたデータ):



CAMテーブルがいっぱいになると、新しいエントリを追加できなくなり、すべてのトラフィックがすべてのポートに送られます(ただし、一般的な場合、スイッチの動作は異なります)。 攻撃者は、すべてのネットワークトラフィックを「リッスン」し、機密情報を受信できます。

このような攻撃を抑制するには、ユーザーが接続されているスイッチポートに、たとえば、MACアドレスが1つだけ存在し、複数のMACアドレスが表示される場合、ポートを無効状態にして、セキュリティ違反に関するメッセージを管理者に送信することを示す必要があります(たとえば、Ciscoのポートセキュリティ設定)。

VMwareにはForged Transmits設定-Accept / Rejectがありますが、上で説明したように、それを適用できない場合があります。 したがって、リスクを管理するために、このような攻撃の結果を明確にする必要があります。

攻撃を実装するために、dsniffパッケージのmacofプログラムが使用されました。

攻撃パターン






私は実験の欠点について言わなければなりません:

  1. まず、それが主なものです。攻撃者はルーティング可能なVLANに属し、攻撃者は隔離されたVLANに属していました。 逆を行う方がはるかに正しいでしょう。
  2. 2つ目は、回路の欠如です。 クラスターの使用により、結果を判断することは困難です
しかし、まず最初に。



攻撃が開始されると、パケットジッターがすぐに増加し、
(pingを参照)




しかし、これまでのところ何も重要ではありません。

数分後、VMコンソールは著しく「スローダウン」し始め、個々のパッケージが失われ始めました。

(ダンプを参照)




最後に、開始から5〜7分後、すべてが崩壊しました。vCenterへのクライアントの接続が切断される前に、一部のVMが使用できず、VMコンソールが開かず、Top of Rackが失敗したことがわかりました。

実際には、これは公共サービスのDoSだけでなく、プロバイダーの一部の内部サービスを意味する可能性があり、これは許容可能なリスクではないため、対策が必要です。



仮想スイッチのハブモードへの移行を記録しなかった(少なくともVLANが最後に分割された)と言う必要があります。



上記の欠点のため、何が起こったのか、本当の理由は何であったのかを正確に言うことは困難です(少なくとも私にとって)。 コメント(またはhp)の誰かが結果を整理できるなら、私はとても幸せです。



これは私の仕事の中で最も興味深いものです。

提案、ヒント、訂正など、フィードバックをお待ちしています。 =)ご清聴ありがとうございました。



All Articles