vmware

Know Your Enemy:

Learning with VMware

Building Virutal Honeynets using VMware.

Honeynet Project

http://www.honeynet.org

Last Modified: 27 January, 2003

translated by OHNUKI Takehito

Virtual Honeynets は同一のコンピュータ上に複数の OS を用いてHoneynet を実行することができる手法である。以前に Know Your Enemy: Virtual Honeynets について触れたが、これらの方法はシステムの配置や管理をより簡単にすることができるという利点がある。Honeynet プロジェクトは VMware を使った Honeynet テクノロジーの優れた開発環境にも着目してきた。この章では、その方法を商用ソフトウェアである VMware を使ってどのように構築していくかについて順を追ってに説明していくことにする。今回、5種類の異なる Honeypots を用い GenⅡ (2nd Gengeration) Virtual Honeynet を構築することにする。この章では、すでに KYE: Virtual HoneynetsKYE: Honeynets で話したコンセプトを理解していると言う前提で説明を進めるものとする。また、今回初めて Honeynet テクノロジーに関わる者は、研究施設 (環境) で行うことを強く勧める。最後に、全てのバーチャルソフトウェアについて言えることだが、利用の際には攻撃者の発見に意識を向け、同時に、彼らによってそれら仮想環境でも破られる可能性があることを承知しておいてもらいたい。これは警告である。

Plan of Attack

この章の構成は KYE: User-Mode Linux と同じ仕様で、5部構成になっている。最初のパートでは、VMware と何か、どのように機能するのかとそのインストール方法について説明する。2番目のパートでは、VMware の設定方法と Honeypot のインストール方法について。3番目のパートでは、VMware Honeynet での IP Table を用いた Data Controll の実行方法について。4番目のパートでは、Snort を用いた Data Capture 方法について。最後のパートでは、セットアップのテスト方法について説明する。

Part I: VMware

VMware とは、同時に複数の OS を動かすことができる仮想化ソフトウェアである。User-Mode Linuxと違い、Intel X86 アーキテクチャ上で動くものであれば、種類の異なる OS を VMware では同時に走らせことが出来る。VMware Inc から開発されている製品には実際、Workstation、GSX または ESX の3つの中から選ぶことになる。この3つの中で、我々はGSX を使うことになる。GSX は Workstation より強力で、2つの OS を同時に動かせるように設計されており、またリモート管理も可能となっている。しかしながら、この章で述べるほとんどの説明はWorkstation にも適応できるものである。では、これから本章の目的である Virtual Honeynet を IBM Thinkpad T23 (Pentium III、1Ghz プロセッサ、768MB RAM) のラップトップ PC を使って構築してみることにする。根幹の OS は Red Hat 7.3 となっている。

VMware は仮想化ソフトウェアをインストールすることで使用できる。そして、この仮想化ソフトによって、複数の OS を同時に起動することが可能となる。一番最初にインストールした OS が HostOS となる。これは、VMware をインストールした時に使用していた OS にがこれに当たる。HostOS と VMware をインストールすれば、他の追加 OS を仮想環境の中にインストールすることが出来る。この追加 OS は HostOS に対する Guest に対応し、GuestOS と呼ばれる。詳細な説明は Figure 1 を参照。Linux OS 上での VMware のインストールはいたって容易であり、単に RPM パッケージを一つインストールすればよい。コマンドは以下の様になる:

host #rpm -vi VMware-gsx-2.0.1-2129.i386.rpm

Preparing packages for installation...

VMware-gsx-2.0.1-2129

更に、リモート管理パッケージといった追加でインストールできるソフトウェアパッケージがある。しかし、我々のラップトップシステムでは全てローカルで管理されるのでこのパッケージは必要ない。この様な付属パッケージについての詳細情報は VMwareドキュメントを参照のこと。

Part II: Configuring VMware and Installing your Honeypots

インストール後の作業はVMwareの設定である。configrationは'vmware-config.pl'で実行される。configration の途中で、いくつかのカーネルモジュールのリコンパイルが必要となることが多々ある。これには、そのカーネル用のコンパイラーとソースコードが必要となる。我々のラップトップでは、カーネル 2.4.18-19.7.x を使用している。そして、そのソースコードがあることを確認する。

host #uname -r 2.4.18-19.7.x host # host #rpm -qa | grep source kernel-source-2.4.18-19.7.x marge $ls -l /usr/src total 8 lrwxrwxrwx 1 root root 19 Dec 26 13:53 linux-2.4 -> linux-2.4.18-19.7.x drwxr-xr-x 17 root root 4096 Dec 26 13:53 linux-2.4.18-19.7.x drwxr-xr-x 7 root root 4096 Jul 12 11:52 redhat

ソースコードをインストールさせれば、設定作業を開始することができる。設定作業において、ネットワーク設定だけが本当に必要な機能となる。目的は全ての GuestOS のネットワークルートがゲートウェイである HostOS を通過させることにあるということを忘れないで欲しい。インストール作業の途中でHostOnly のネットワークかどうか訪ねられる。その時、10.10.10.1 のゲートウェイ用 IP アドレスを与える。以下のコマンドが設定で実行されたものである:

vmware-config.pl

設定作業が完了したら、VMware は稼働し始める。しかし、まだ一つ問題が生じる。デフォルトの設定では、VMware は vmnet0、vmnet1、vmnet8 のインターフェースが利用可の状態になっている。我々が使用したいものは vmnet1 のみである。vmnet0 は GuestOS が HostOS をバイパスしネットワークに直接つなげる為のブリッジに使用し、vmnet8 は NAT Networks に使用する。vmnet1 のみがGuestOS から HostOS への接続の制御を行えるものとなる。従って、再び vmware-config.pl を実行し、エディタを用いて vmnet0 と vmnet8 のインターフェースを取り除く。

vmware-config.pl (being ran for the second time)

VMwareの設定が完了したら、次は個々のHoneypotsの設定作業となる。Honeynetには5種類のHoneypotをインストールし稼働させることになる。要求される作業は、それほど込み入った作業ではない。というのは、そのシステム自体を利用するのは攻撃者以外にいないわけで、最低限のシステム設定で済ませるからである。また、UnixベースのシステムではGUIは必要なく、全てコマンドラインからシステム管理を行う。従って、X-Windowsは必要ない。メモリー条件も最低限の要求となる。また、それぞれのOSも2GB以下のHDD容量でよい。

  • Red Hat Linux 8.0 (64 MB RAM, do not run X-Windows)
  • Solaris8 X86 (64 MB RAM, do not run X-Windows)
  • OpenBSD 3.1 (64 MB RAM, do not run X-Windows)
  • Windows2000 (128 MB RAM)
  • WindowsXP (128 MB RAM)

各々のHoneypotの設定は簡単である。まず、"ps aef | grep vmnet" で VMware システムが稼働していることを確認し、"ifconfig -a" で vmnet1 が利用可能かを確認する。確認が済んだら、新たに VMwareのウィンドウを開き Honeypot をインストールする。コマンドは以下の通りである:

host #vmware -G &

このウィンドウを開くときに、「既存の GuestOS を起動させる」か「新しい GuestOS をインストールする」という選択肢が表れる。"Run the Configuration Wizard" を選択する。そこで、どの GuestOS をインストールし、どこに仮想ディスクを作成するかを指示する。また、CDROM (フロッピーディスクが付いている場合は、使用不可にする) と HostOnly のネットワーク利用を使用可にする。GuestOS の設定をした後は、GuestOS の CDROM を挿入し、そのシステムを Power Onにする。それ以降は起動とインストール作業は通常の OS のインストール作業と同じである。他の GuestOS の Honeypot についても同様の手順である。インストールが終了したら、VMware tools を GuestOS の Honeypot にインストールするという選択がある。これは GUI インターフェースの解像度を高めてくれるものである。Unix システムでは、コマンドラインによる管理の為この VMware tools は必要ない。Window ベースの Honeypot では解像度を上げる為にこのツールが必要になるかもしれないが、VMware 仮想システムに対する fingerprint 攻撃を受けやすくなってしまう。VMware の configuration や GuestOS のインストールに関する詳細は VMwareドキュメントを参照。

さらに先の手順に移る前に、Honeypot のバックアップをとって置きたくなるであろう。VMware は各Honeypot の状態をそれぞれ別々のディレクトリに保存する。バックアップを行うには、それらのディレクトリにあるファイルをコピーすればよい。これによってリカバリーや再構築がごく簡単に行えるようになる。従来の Honeypot では、Honeypot が侵されその攻撃に対する解析が終了した後、オンラインに戻す前に再び Honeypot を再構築し直さなければならかった。これは時間の浪費であったが、VMware ではバックアップファイルをコピーするだけで再構築が可能となった。数秒で Honeypot を元の状態に戻すことができるのである。例えば、デフォルトの VMware では/root/vmwareディレクトリにそれぞれの Honeypot のイメージが保存されている。このディレクトリをコピーすることで全てのHoneypot のバックアップがとれるのである。Honeypot を再構築したい時はいつでも、このディレクトリごとコピーすれば良い。

host #ls -l /root/vmware total 28 drwxr-xr-x 2 root root 4096 Oct 10 01:10 linux-6.2 drwxr-xr-x 2 root root 4096 Jan 14 19:00 linux-7.2 drwxr-xr-x 2 root root 4096 Jan 14 22:14 linux-7.3 drwxr-xr-x 2 root root 4096 Jan 25 15:15 openbsd drwxr-xr-x 2 root root 4096 Jan 25 15:15 solaris drwxr-xr-x 2 root root 4096 Dec 16 08:47 win2000Serv drwxr-xr-x 2 root root 4096 Jan 25 15:15 winXPPro host # host #cp -a /root/vmware /root/vmware-backup

Part III: Data Control

VMware のセットアップが完了したら、次のステップは Data Control である。Data Control の目的はHoneynet の内外へ向けて攻撃者が行う行動情報を封じ込めることである。基本的に Honeynet システム内部 (inbound) へ向けられた行動は全て許可しているが、外側 (outbound) への接続は許可していない。この章の目的として、我々は IPTables という Linux に付属の OpenSource ファイアウォールを用いる。IPTables は、接続制限だけでなく、ネットワークアドレス変換、ロギング、その他多くの機能がありとても柔軟性のあるファイアウォールである。我々は IPTables を用いて、outbound に向かって流れるパケットをカウントするという、HostOS 上でフィルタリングとして機能させる設定を行うことにする。outbound への接続があるしきい値を満たすと、それ以降の攻撃がロックされ、破られたHoneypot が他のシステムへ被害を出すのを阻止ことができる。これらの設定と実装は極めて複雑な作業である。しかし、Honeynet プロジェクトでは、rc.firewall と呼ばれる IPTables 用のスクリプトを作成した。単に自分の Honeynet に適した変数の値を修正しさえすれば、このスクリプトを実行することが出来る。

まず 最初に決めなければならないことは、ゲートウェイがレイヤー3のルーティングモードで機能させるか、もしくはレイヤー2のブリッジモードで機能させるかである。レイヤー2のブリッジモード(GenII、または 2nd generation として知られている) がより好ましい。ゲートウェイがブリッジとして機能している時は、ルーティングや TTL のパケット減少は無い。不可視なフィルタリング装置として機能し、攻撃者による発見をより一層困難にさせることが出来る。しかし、IPTables がブリッジモードで機能する為には、システムのカーネルにそのパッチが当てられていなければならない。デフォルトでは、ほとんどのカーネルはブリッジモードにおいてIPTablesをサポートしていない。Red Hat カーネル 2.4.18-3 はこの中でも希有にデフォルトでこれをサポートしている。もし、パッチを当てたいならば、http://bridge.sourceforge.net/download.html から見つけることが出来る。この章の目的通り、我々はカーネル DOES が IPTables をブリッジモードでサポートしていると仮定する。もし、自分のカーネルがブリッジモードをサポートしていない場合は、KYE: UML でレイヤー3でのルーティングを行う為の rc.firewall スクリプトの詳細設定を参考にされたい。

GenII の実装を行うために rc.firewall スクリプトの設定方法について取り上げてみよう。設定では、ネットワーク問題と制御問題の2つの重要な領域がある。実際、ネットワークはルートモードよりもブリッジモードにおける方が遥かに単純である。ブリッジモードでは、ルーティング問題やネットワークアドレス変換問題などは一切無い。我々は単純に HostOS をブリッジに変換し、GuestOS を他のネットワークと直接対話させるようにすればよい。接続の問題に対して、我々はどれだけの外向けの接続を許可するかを設定しなければならない。その設定しなければならない機能は以下の通りである:第一に、GuestOS の public IP アドレスの設定。これらのアドレスはハッカーが攻撃してくるもの、つまり Honeypot で有効となる IPアドレスとなる。ファイアウォールフィルタはそれらがなんであるかを知る必要がある。

PUBLIC_IP="10.10.10.201 10.10.10.202 10.10.10.203 10.10.10.204 10.10.10.205"

第二に、HostOS の内部インターフェースの名前を確認する必要がある。デフォルトでは eth1 となるが、我々は仮想インタフェース vmnet1 を利用しており、この変数値を修正する必要がある。

LAN_IFACE="vmnet1"

第三に、今回 GenⅡ Honeynet を構築しているので既知の外向けアタックをドロップするための Snort-Inline の機能を試してみたくなるかもしれない。その Snort-Inline について詳細を述べるのはこの章の目的とする領域から外れているが、それについては、今後の章、Know Your Enemy: GenII Honeynet で説明されることになるであろう。しかしながら、Honeynet Snort-Inline Toolkit には、固定されプリコンパイルされたバイナリーと設定ファイル、ルールベースやドキュメントが含まれており、Toolkit の使用を考えている人は、それを Honeynet Tools section で見つけることができる。もし、この機能を試す必要が無いと思う者は、QUEUE 機能を使用可能にする必要がある。注意:この機能を有効にした場合、Snort-Inline を動かさなければならない、さもなければ outbound へのパケットを全てドロップすることになるであろう。もし、この機能について定かでない場合は、決してこの機能を有効にしてはならない。

#QUEUE="yes" # Use experimental QUEUE support

QUEUE="no" # Do not use experimental QUEUE support

この他、自身のシステムの仕様により若干の設定変更を要するかもしれない。さらに追加機能として、リモート管理やファイアウォールが制御する接続の種類、Honeypot に自由な DNS アクセス権を与えるなどといったものがある。またデフォルトのスクリプトでは、Honeypot から outbound への接続を1時間当たり 9 TCP、20 UDP、50 ICMP、50 IP に制限している。この詳細については、ここでは範囲外として扱わないが、より理解を深める為には研究環境においてスクリプトの詳細を見直し様々な値を変えて試してみることを勧める。rc.firewall スクリプトを設定したら、そのスクリプトを実行することで実装を行う。この時、HostOS をブリッジモードに設定することを忘れないでほしい。その為には、自身の HostOS がブリッジユーティリティを備えていなければならない。Red Hat システムでは "bridge-utils-0.9.3-4"がこれにあたる。

ブリッジを使用する時には2つの gotcha がある。一つ目はまず、ブリッジを開始する前に、全てのGuestOS を起動させなければならない。GuestOS は起動時に vmnet1 を探し出し使用する。もし、すでにこの vmnet1 がブリッジモードとして設定されていた場合は、GuestOS はそのインタフェースを探し出すことが出来ず、ネットワークと通信を行うことが出来なくなってしまう。従って、rc.firewall スクリプトを実行する前に、全ての Honeypot を起動させなければならない。2つ目の gotcha は時間である。ブリッジを開始する為には 10~30 秒程の時間が必要になる。ブリッジパケットが開始される前に、MAC の場所を認識させる為にブリッジ時間を設けてやらなければならない。

host #/.rc.firewall

スクリプトが正常に動作しているかを確認する為に、いくつかのチェック事項がある。第一に、ブリッジが確立されているか確かめる。これは、/var/log/messages file にカーネルがブリッジモードに入るというログを書き込むので、そのログから確認することが出来る。第二に、'br0' と呼ばれる新たなインターフェースを用意する。これは自分自身のブリッジである。第三に、'brctl' コマンドでどのインターフェースがブリッジと接続しているかを調べる。第四に、ブリッジモードに入っている為、もはや内部にも外部にも IP アドレスを持っていない状態であることを確認する。最後に、接続に対してフィルタリングが行われているかを確かめる為に IPTables のルールを見直す。

host #tail /var/log/messages

host #ifconfig -a

host #brctl show

host #iptables -L -n

問題が無ければ、Data Control は行われていることになる。さらに他には、bandwidth throttling といった Data Control の実装も存在する。

Part IV: Data Capture

Data Control の次は Data Capture である。Data Capture の目的は攻撃者自身に知られることなく、彼らの行動内容を押さえることである。これに関しては様々な手段があげられる。しかし、今回我々は2つの手段に焦点を当ててみた。IPTable ログと Snort である。IPTable ログは inbound と outbound のどちらへ接続が生じても必ず生成されるファイアウォールのログである。Snort は OpenSource IDS ソリューションで、ネットワークのアクティビティ情報を収集するために使われ、さらに既知の攻撃に対してはアラートを発してくれるものである。

IPTables については、rc.firewall スクリプトによって既にロギングの為の設定がなされている。/var/log/messages に inbound と outbound の接続ログが書き出されるようになっている。inbound への接続があれば、それは詮索やスキャン、もしくは攻撃への暗示と受け止めることが出来る。一方、outbound への接続があれば、それは Honeypot が破られたということを意味している。IPTable ログとは、本来アラートの為に存在するものである。そのログ自体は攻撃者がどのようなことをしたかを判断できる十分な情報は含んでいない。Snort については、全パケットをキャプチャし、また Honeynet に貸されたペイロード情報も全て記録するように設定されている。ここにリンクされている Snort config file には攻撃者の行動情報が全てキャプチャされ記録されるようになっている。simple Snort startup script には Snort の起動スクリプトや推薦される Snort config file が載っている。vmnet1 を監視する為に HostOS の startup script をアップデートすることを忘れずに。おそらく、このスクリプトを cron から毎日起動したくなるであろう。

host #./snort-start.sh

GenII Honeynet ということで、Sebek といったより高機能な Data Capture 技術を使いたくなるかもしれない。Sebek とはカーネル領域を使用して攻撃者の情報を得るものである。ここで紹介する以外にも様々な Data Capture 手法が存在する。そのような手法についての詳細は Honeynet Tools Section を参照のこと。

Part V: Testing Your VMware Honeynet

第五部、最終段階として、我々の Honeynet システムが期待通りの動作を行っているか、特に Data Control と Data Capture に重点をおいて VMware Honeynet の動作確認を行う。Data Control の動作確認は比較的シンプルである。outbound への接続要求が Honeypot によって制御され、またそのログが記録されているかを調べればよいのである。全ての接続要求が /var/log/messages に記録されいるか、outbound への接続が開始されていることを告げているか、また Honeypot が破られていそうな情報があるかどうかを確かめるのである。また、outbound への接続要求が一定のしきい値を満たした場合は、それ以降の outbound 接続を許可しないという機能が動作しているかも確かめる必要がある。これを確かめる方法として1つ裏技がある。我々はシステムでブリッジを使用しているので、もう1台分攻撃用の PC が必要となってくる。宛先 IP が MAC アドレスと一致しない限り、ブリッジがパケットを転送するということはない。もし、パケットが全く転送されないならば、IPTables の動作確認も出来なくなってしまう。コンピュータを2台もっていない人や、はたまた変わり者には、UML システムを起動することで仮想的な PC を動かすという方法がある。VMware 上の Honeypot が vmnet1 の仮想インターフェースと接続しているのに対し、UML システムは tap0 の仮想インターフェースと結びつけることが出来る。この様にすると、HostOS は2種類の仮想ネットワークをブリッジしていることになる。tap0 が外部インターフェースとして認識するように rc.firewall スクリプトの修正を忘れずに。UML の実行などについての詳細は、KYE: UML を参照のこと。この UML は攻撃者とみなし VMware Honeypot を詮索することが可能となる。我々の目的は、この手法を攻撃デモンストレーションという概念として利用することである。UML による攻撃者の IP アドレスは 10.10.10.100 となる。ほら、実際に機能している! :)

outbound への TCP 接続をテストする。これはデフォルトでは一時間に9回までの接続と制限されている。これを調べる為には、まず2つターミナルを立ち上げる。1つ目のウィンドウでは、/var/log/messges にある HostOS の IPTable ログを監視する。我々が GuestOS から Host ゲートウェイを通じて outbound 接続を開始した時、その接続要求を示したログが表示されるはずである。このログ情報は、Honeypot がハッキングされ、さらに攻撃者 (もしくは自動化ツール) が外部に接続しようとしていることを意味するアラートとして非常に重要な情報となる。10回目の outbound への接続要求で、(しきい値を満たし) その TCP 接続は遮断され、ログが記録される。以下は outbound 接続を要求する前に実行したいコマンドである。

host #tail -f /var/log/messages

次は、GuestOS である Honeypot システム上でターミナルを開く。様々な TCP 接続を外部の IP (この場合では、10.10.10.10 という自身の UML システム) に向かって開始する。この作業は何回か繰り返し行う必要があるだろう。

guest #telnet 10.10.10.100

Trying 10.10.10.100...

telnet: connect to address 10.10.10.100: Connection refused

もし、これに対するログが確認され、接続が遮断された場合は Data Control の実装は成功している。その次は、Data Capture が行われているかどうか、特に Snort プロセスが全パケットを捕らえているか、またそのペイロードが Honeynet に残されているかを確認する。Snort プロセスは HostOS の内部インターフェース、特に vmnet1 を監視しているはずである。これを確かめる為に、10.10.10.100 で外部システムへ ping を行う。

guest #ping -c 3 10.10.10.100

Snort プロセスは3つの ICMP Echo Request パケットとそのペイロードをキャプチャし、tcpdump binary log format に記録されているはずである。これを確かめるには、その例として以下の様にログファイルを見直すことである。何が重要なのかといえば、我々は全てのパケットやそのヘッダーをキャプチャーしているだけではなく、全パケットに対する全てのペイロードもキャプチャしているということである。

host #snort -vdr *snort.log

これが全ての手続きである。これで Data Control と Data Capture 機能における一番初歩的な部分を習得したことになる。より高度な手法として、さらに別のシステムを用意してインターネット上の実システムとして振舞うことや Honeypot との対話的振舞いを行うといった方法もある。しかし、今回はそれは範囲外として扱わない。

Note: この記事について最終検討に入る段階で、我々のプロジェクトは VMware の別の機能である advance forensic analysis を用いて進められている。特に、VMware での一時停止機能についてである。「一時停止」は文字通り GuestOS (もしくは Honeypot) イメージを一時停止にすることであり、稼働状態のプロセスを凍らせ、メモリイメージをファイルに保存させることである。つまり、これは Honeypot を一時停止させ、電源を off にし、また一週間後に電源を入れ、一時停止を解除することで前回の状態からそのまま Honeypot をまた稼働させることが出来るということを意味する。これには、いくつかの信じ難いフォレンシックなアプリケーションを用いている。プロジェクトでは、ハッキングされたコンピュータを一時停止しそのイメージを保存することを進めている。そして、そのイメージ情報を解析する為に他のシステムに送信している。この技術により、システムがまだ稼働中の段階でハッキングされた Honeypot の解析が可能となる。問題点としては、一時停止されたイメージの解析時に、自分自身がネットワークから遮断された環境でその解析を行っているということが保証できる場合、もしくはハッキングされた Honeypot が一時停止される以前に通信を行っていた何らかのシステムと再度接続を行うことが確信できる場合でなければならないことがあげられる。

Conclusion

この章の目的は、Virtual Honeynet を VMware ソフトを用いて構築する方法を段階的に説明することをねらいとした。一つのコンピュータ上で完全な Honeynet の構築を目的としたのである。VMware を用いることの利点はいくつもの異なる OS を同時に稼働させることが可能な点にある。もし自身でVMware Honeynet を構築したいと思う方は http://www.vmware.com/download/#eval から参照のこと。