Learning with VMware Building Virutal Honeynets using VMware. Honeynet Project Virtual Honeynets は同一のコンピュータ上に複数の OS を用いてHoneynet を実行することができる手法である。以前に Know Your Enemy: Virtual Honeynets について触れたが、これらの方法はシステムの配置や管理をより簡単にすることができるという利点がある。Honeynet プロジェクトは VMware を使った Honeynet テクノロジーの優れた開発環境にも着目してきた。この章では、その方法を商用ソフトウェアである VMware を使ってどのように構築していくかについて順を追ってに説明していくことにする。今回、５種類の異なる Honeypots を用い GenⅡ (2nd Gengeration) Virtual Honeynet を構築することにする。この章では、すでに KYE: Virtual Honeynets と KYE: Honeynets で話したコンセプトを理解していると言う前提で説明を進めるものとする。また、今回初めて Honeynet テクノロジーに関わる者は、研究施設 (環境) で行うことを強く勧める。最後に、全てのバーチャルソフトウェアについて言えることだが、利用の際には攻撃者の発見に意識を向け、同時に、彼らによってそれら仮想環境でも破られる可能性があることを承知しておいてもらいたい。これは警告である。 Plan of Attack Part I: VMware 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 更に、リモート管理パッケージといった追加でインストールできるソフトウェアパッケージがある。しかし、我々のラップトップシステムでは全てローカルで管理されるのでこのパッケージは必要ない。この様な付属パッケージについての詳細情報は VMwareドキュメントを参照のこと。 Part II: Configuring VMware and Installing your Honeypots 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 は稼働し始める。しかし、まだ一つ問題が生じる。デフォルトの設定では、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には５種類のHoneypotをインストールし稼働させることになる。要求される作業は、それほど込み入った作業ではない。というのは、そのシステム自体を利用するのは攻撃者以外にいないわけで、最低限のシステム設定で済ませるからである。また、UnixベースのシステムではGUIは必要なく、全てコマンドラインからシステム管理を行う。従って、X-Windowsは必要ない。メモリー条件も最低限の要求となる。また、それぞれのOSも2GB以下のHDD容量でよい。
各々のHoneypotの設定は簡単である。まず、"ps aef | grep vmnet" で VMware システムが稼働していることを確認し、"ifconfig -a" で vmnet1 が利用可能かを確認する。確認が済んだら、新たに VMwareのウィンドウを開き Honeypot をインストールする。コマンドは以下の通りである： このウィンドウを開くときに、「既存の 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 まず 最初に決めなければならないことは、ゲートウェイがレイヤー３のルーティングモードで機能させるか、もしくはレイヤー２のブリッジモードで機能させるかである。レイヤー２のブリッジモード(GenII、または 2nd generation として知られている) がより好ましい。ゲートウェイがブリッジとして機能している時は、ルーティングや TTL のパケット減少は無い。不可視なフィルタリング装置として機能し、攻撃者による発見をより一層困難にさせることが出来る。しかし、IPTables がブリッジモードで機能する為には、システムのカーネルにそのパッチが当てられていなければならない。デフォルトでは、ほとんどのカーネルはブリッジモードにおいてIPTablesをサポートしていない。Red Hat カーネル 2.4.18-3 はこの中でも希有にデフォルトでこれをサポートしている。もし、パッチを当てたいならば、http://bridge.sourceforge.net/download.html から見つけることが出来る。この章の目的通り、我々はカーネル DOES が IPTables をブリッジモードでサポートしていると仮定する。もし、自分のカーネルがブリッジモードをサポートしていない場合は、KYE: UML でレイヤー３でのルーティングを行う為の rc.firewall スクリプトの詳細設定を参考にされたい。 GenII の実装を行うために rc.firewall スクリプトの設定方法について取り上げてみよう。設定では、ネットワーク問題と制御問題の２つの重要な領域がある。実際、ネットワークはルートモードよりもブリッジモードにおける方が遥かに単純である。ブリッジモードでは、ルーティング問題やネットワークアドレス変換問題などは一切無い。我々は単純に 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 この他、自身のシステムの仕様により若干の設定変更を要するかもしれない。さらに追加機能として、リモート管理やファイアウォールが制御する接続の種類、Honeypot に自由な DNS アクセス権を与えるなどといったものがある。またデフォルトのスクリプトでは、Honeypot から outbound への接続を１時間当たり 9 TCP、20 UDP、50 ICMP、50 IP に制限している。この詳細については、ここでは範囲外として扱わないが、より理解を深める為には研究環境においてスクリプトの詳細を見直し様々な値を変えて試してみることを勧める。rc.firewall スクリプトを設定したら、そのスクリプトを実行することで実装を行う。この時、HostOS をブリッジモードに設定することを忘れないでほしい。その為には、自身の HostOS がブリッジユーティリティを備えていなければならない。Red Hat システムでは "bridge-utils-0.9.3-4"がこれにあたる。 ブリッジを使用する時には２つの gotcha がある。一つ目はまず、ブリッジを開始する前に、全てのGuestOS を起動させなければならない。GuestOS は起動時に vmnet1 を探し出し使用する。もし、すでにこの vmnet1 がブリッジモードとして設定されていた場合は、GuestOS はそのインタフェースを探し出すことが出来ず、ネットワークと通信を行うことが出来なくなってしまう。従って、rc.firewall スクリプトを実行する前に、全ての Honeypot を起動させなければならない。２つ目の gotcha は時間である。ブリッジを開始する為には 10~30 秒程の時間が必要になる。ブリッジパケットが開始される前に、MAC の場所を認識させる為にブリッジ時間を設けてやらなければならない。 host #/.rc.firewall スクリプトが正常に動作しているかを確認する為に、いくつかのチェック事項がある。第一に、ブリッジが確立されているか確かめる。これは、/var/log/messages file にカーネルがブリッジモードに入るというログを書き込むので、そのログから確認することが出来る。第二に、'br0' と呼ばれる新たなインターフェースを用意する。これは自分自身のブリッジである。第三に、'brctl' コマンドでどのインターフェースがブリッジと接続しているかを調べる。第四に、ブリッジモードに入っている為、もはや内部にも外部にも IP アドレスを持っていない状態であることを確認する。最後に、接続に対してフィルタリングが行われているかを確かめる為に IPTables のルールを見直す。 問題が無ければ、Data Control は行われていることになる。さらに他には、bandwidth throttling といった Data Control の実装も存在する。 Part IV: Data Capture 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 outbound への TCP 接続をテストする。これはデフォルトでは一時間に９回までの接続と制限されている。これを調べる為には、まず２つターミナルを立ち上げる。１つ目のウィンドウでは、/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 もし、これに対するログが確認され、接続が遮断された場合は Data Control の実装は成功している。その次は、Data Capture が行われているかどうか、特に Snort プロセスが全パケットを捕らえているか、またそのペイロードが Honeynet に残されているかを確認する。Snort プロセスは HostOS の内部インターフェース、特に vmnet1 を監視しているはずである。これを確かめる為に、10.10.10.100 で外部システムへ ping を行う。 guest #ping -c 3 10.10.10.100 Snort プロセスは３つの ICMP Echo Request パケットとそのペイロードをキャプチャし、tcpdump binary log format に記録されているはずである。これを確かめるには、その例として以下の様にログファイルを見直すことである。何が重要なのかといえば、我々は全てのパケットやそのヘッダーをキャプチャーしているだけではなく、全パケットに対する全てのペイロードもキャプチャしているということである。 これが全ての手続きである。これで Data Control と Data Capture 機能における一番初歩的な部分を習得したことになる。より高度な手法として、さらに別のシステムを用意してインターネット上の実システムとして振舞うことや Honeypot との対話的振舞いを行うといった方法もある。しかし、今回はそれは範囲外として扱わない。 Note: この記事について最終検討に入る段階で、我々のプロジェクトは VMware の別の機能である advance forensic analysis を用いて進められている。特に、VMware での一時停止機能についてである。「一時停止」は文字通り GuestOS (もしくは Honeypot) イメージを一時停止にすることであり、稼働状態のプロセスを凍らせ、メモリイメージをファイルに保存させることである。つまり、これは Honeypot を一時停止させ、電源を off にし、また一週間後に電源を入れ、一時停止を解除することで前回の状態からそのまま Honeypot をまた稼働させることが出来るということを意味する。これには、いくつかの信じ難いフォレンシックなアプリケーションを用いている。プロジェクトでは、ハッキングされたコンピュータを一時停止しそのイメージを保存することを進めている。そして、そのイメージ情報を解析する為に他のシステムに送信している。この技術により、システムがまだ稼働中の段階でハッキングされた Honeypot の解析が可能となる。問題点としては、一時停止されたイメージの解析時に、自分自身がネットワークから遮断された環境でその解析を行っているということが保証できる場合、もしくはハッキングされた Honeypot が一時停止される以前に通信を行っていた何らかのシステムと再度接続を行うことが確信できる場合でなければならないことがあげられる。 Conclusion  |
