Learning with User-Mode Linux Building Virutal Honeynets using UML. Honeynet Project Honeynetは設定が難しく様々な技術とシステムが必要とされ､リソースを集中的に装備しなければならない｡多くのユーザおよび組織はHoneynetのリサーチにリソースを必要としないことを望んでいる｡たから、このペーパでは､単独のコンピュータとフリーのオープンソースのソフトウェアでHoneynetを構築することに焦点を当てる｡これはOpenSource solutionsのUser-Mode Linux (UML)とIPTablesを用いて仮想Honeynetを構築することにより達成される。このペーパのフォーマットはハウツーものであり､段階的に単独コンピュータへの構築法を述べ､HoneynetのData ControlとData Captureのメソッドについて述べる｡このペーパはすでにKYE:HoneynetsとKYE:Virtual Honeynetsを読んだ人間を対象としている｡Honeynet技術の詳細までは述べない｡基本的なHoneynet技術での環境のテストについて述べる｡もし初めてのHoneynet構築であれば､研究室か､テスト環境での使用を強く勧める｡ Plan of Attack Part I: User Mode Linux VMWareとは異なり､UMLは追加の仮想ソフトウェアを必要としない｡そのかわり、起動させたいGuestOSにカーネルパッチを当てる｡このUMLパッチは"linux"と呼ばれる実行形式のバイナリをカーネルに組み込み、それはシステム上で分離したOSとして起動させるものである｡UMLパッチを当ててしまえば､ファイルシステムが与えるだけで独立したLinuxシステムを得ることができる｡この新しいカーネルはHostOSのユーザスペースにある。UMLカーネルはシステムコールをこのアプリケーションから受け､sends/requestsをHostカーネルから受ける｡さらに追加マネジメントやUMLツールをインストールすることによりさらに快適となる｡ UMLに加えられたHoneypotにとっていくつかのエキサイティングな機能がある。これらの機能はUML Honeynetにとっての重大な改善点である｡３つのハイライトを以下に述べるが､技術的な詳細及びHOWTOは、http://user-mode-linux.sf.net/honeypots.htmlを参照のこと｡
UMLの構築とインストールにはrpmを使用する｡RPMはRedHat Linuxのパッケージマネージャで､簡単にソフトウェアのパッケージをインストールすることができる｡UMLパッケージでは２つのことをしなければならない｡１つ目はUMLカーネルパッチを当てることで､これにより"linux"という実行可能バイナリがインストールされる｡これで分離したLinuxカーネルを起動することができるようになる｡加えて､このパッケージにはすべてのUMLユーティリティが含まれている｡すべてのUMLバイナリとソースコードをUMLダウンロードサイトからダウロードドすることができる｡以下は2.4.19カーネルでのインストールコマンドの実例である｡ここで､どのファイルが必要なのかが分かる｡ host #rpm -ivh user_mode_linux-2.4.19.5um-0.i386.rpm host #rpm -ql user_mode_linux-2.4.19.5um-0.i386 このとおり､RPMをインストールすることにより２つのことを成し遂げたのである｡最初に､GuestOSとしての実行可能カーネル(/usr/bin/linux)がインストールされた｡次に､様々なUMLユーティリティがインストールされた｡もし同時にさらなるカーネルを起動させたければ､UMLカーネルをダウンロードするか､カーネルソースコードのパッチを当てるだけでよい（注：実験では､カーネル2.4.19-5は同時に１つのカーネルしか操作できない｡もし複数のカーネルを動かしたければ､最新のカーネルパッチをダウンロードする必要がある）｡ これで１つ目のGuestカーネルのファイルシステムについては終わった｡攻撃者がインタラクトする他のカーネルがないことの何がよいことなのだろうか？もう一度UMLのダウンロードサイトに戻り､半分構築されたファイルシステムのイメージを探してみよう｡またはもしよければ、既存のファイルシステムでddで独自のイメージを作成してみよう｡このHOWTOの目的は､RH7.2のサーバファイルシステムイメージ(65MBに圧縮したもの)をインストールして使うことである｡我々はこのファイルシステムにtelnet,viとしてpicoバイナリをインクルードした｡ダウンロードしたら準備完了で､コンフィグレーションはない｡新しいGuestOSを起動するのに､ダウンロードしたファイルシステムを単に展開し､使用するファイルシステムでlinuxバイナリをスタートアップするだけである｡そのためのコマンドは､ host #gzip -d root_fs.rh-7.2-server.pristine.20021012.gz "linux"コマンドを実行するとき､ターミナル上に新しいOSがブートするのを見るであろう｡そして期待通りログインのプロンプトになる｡"root"でログインし､"root"というパスワードを入力することによってOSにアクセスすることができる｡ついにできた！これからその内容について述べる｡ Part II: Setting up the Network eth0の部分はGuestOSのeth0を生成し､Host上のtap0を論理的に通ることを示している｡我々が残した唯一のことは､GuestOSのeth0にIPアドレスを与えたことである｡これで我々のファイルシステムは完了した｡我々のRH7.2サーバの場合､eth0のIPアドレスは192.168.0.144である。もしRH7.2サーバの設定を変えたければ､これらの変更をすればよい｡このセットアップを確認するために､GuestOSで以下のコマンドを打つ｡ guest #ifconfig -a 仮想ネットワークがどのようになっているかは､Figure2を参照のこと｡ 次の段階ではGuestOSが会話できるか､そしてゲートウェイを通るようにルーティングされているかどうかの確認である｡このことは、最初にデフォルトゲートウェイにpingを打つ(この場合は192.168.0.254)。これはHost上の実際のtap0である。内部インターフェースにpingが通ることを確認したら､Host上の外部インターフェースにpingを打ってみる(eth0宛のIPアドレスと同様に)。これでルーティングがHostシステムを通過していることが確認できる｡もしpingが機能しなければ､Host上のファイアーウォールが起動していないということであり、Host及びGuestOSの双方のネットワーク設定をチェックする必要がある｡このセットアップを確認するため､次のコマンドを打つ｡ guest #ping (external IP of Host OS, interface eth0) Part III: Data Control 最初に決定しなければいけないことは､ゲートウェイをLayer3モードで実行するか､Layer2のブリッジモードにするかである｡GenⅡのようなLayer2のブリッジモードが好ましい方法である｡ゲートウェイがブリッジとして機能すると､ルーティングやTTLの減少がなく､見えないフィルタリングデバイスとなり､攻撃者にとって覚られにくいものとなる｡しかしiptablesをブリッジモードにすると､あなたのカーネルにパッチを当てなければならなくなる｡デフォルトでは､たいていのカーネルはiptablesのブリッジモードに対応していない｡RHのカーネル2.4.18-3はデフォルトでサポートしている数少ないカーネルである｡もしパッチが必要であれば､http://bridge.sourceforge.net/download.htmlで見つけることができる｡このハウツーでは､サポートしていないものとして考えることにする｡NATを利用したルーティングモードのVirtual Honeynetの構築法について述べる｡ この機能を有効にするrc.firewallの設定法を見てみよう｡この設定には２つのクリティカルなエリアがあり､それはネットワーク問題とコントロール問題である｡ネットワーキングでは､Host及びGuestのIPアドレスとネットワークを定義しなければならない｡もしLayer3ルーティングモードで走らせている場合､このスクリプトはすべてのNATに気をつける｡Layer2のブリッジモードの場合､すべてのブリッジに気をつける｡覚えておいてもらいたいのは､このペーパではLayer3のルーティングを使用していることを考えることである｡コントロールについては、どれだけの出て行く接続を許可するかを決めることである｡ここでは最低５か所はあなたのシステムと異なり､あなたは変更しなければならない｡特に､ 最初にデフォルトのrc.firewallをブリッジモードで走らせる｡あなたはそれをLayer3のルーティングモードにする。 次に､GuestOSのIPアドレスを設定する必要がある｡これはNATの外部IPアドレスとなる｡これはまたハッカーがVirtual Honeypotを攻撃するであろうアドレスとなる｡もしブリッジモードで使用するならば､これらは（そのまま）使えるが､Honeypotの実際のアドレスは設定しなければならない｡ PUBLIC_IP="192.168.1.144" ３番目に､Honeypotの内部IPアドレスを設定する｡これはGuestOSの実際のIPアドレスである。もしブリッジモードならばこれは使ってはいけない｡ ４つ目に､HostOSの外部用IPアドレスを設定する必要がある｡これはファイアーウォールとゲートウェイの外部IPアドレスである｡我々の場合､ 最後に､HostOSの内部インターフェースの名前を設定する｡デフォルトではeth1である。しかし、我々は仮想インターフェースtap0を使っており､この変数を変更する｡ これらは変更しなければならない最低限の変数であり､使用するシステムに依存する｡他にもアップデートできる箇所があり､リモート管理､ファイアーウォールがどの接続を始めることができるか､そしてHoneypotにDNSアクセスを制限させないことなどである｡また､デフォルトではこのスクリプトはどのHoneypotに対しても出て行く接続が１時間あたり9TCP,20UDP,50ICMPその他10となっている。よく理解するためには実験環境でこのスクリプトを実際に動かしてみるとよい｡rc.firewallの設定が終わったら､実行する｡ host #/.rc.firewall このスクリプトの確認には２つのことを実行する｡最初に､アドレス解釈ができているかを確認する｡Hostシステムに新しい､論理インターフェースがあるかどうかを確認する｡次に､iptablesのルールを再確認する。 確認したら､データコントロールはOKということだ。データコントロールにはこのほかにも多くのツールがある。例えば､既知の攻撃をブロックしたり変更したりするようにSnort-Inlineを併せて使用することもできる｡これはiptablesのスクリプトにQUEUEオプションを追加することによりできる｡他には､バンド幅のスロッティングの利用もある｡しかしこれらの応用はこのペーパではふれない｡追加のオプションはHoneynet Tools Sectionを参照のこと｡ Part IV: Data Capture Iptablesに関しては､ログはすでにrc.firewallスクリプトによって設定されている｡すべての新しい出入りする接続は/var/log/messagesに記録するよう設定されている｡すべての入ってくる接続は探索､スキャン､攻撃を示している｡すべての出て行く接続はHoneypotが侵入されたことを示している｡Iptablesのログの価値は警告することである｡このログは攻撃者が何をしたのかは教えてくれない｡Snortでは、Honeynetに出入りするすべてのパケットをキャプチャするよう設定してある｡ここにSnortの設定ファイルのリンクを置く｡あなたはSnortの簡単なスタートアップと設定ファイルを使うことを勧める｡HostOSのtap0インターフェースをモニタするように変更するとよい｡これを毎日cronから実行することになるだろう｡ host #./snort-start.sh ここではふれないSebekのような他の様々なData Captureのツールがある｡追加のオプションは Honeynet Tools Sectionを参照のこと｡ Part V: Testing Your UML Honeynet 最初にHostOSでターミナルを開き､/var/log/messagesでiptablesのログをモニタする｡Hostのゲートウェイと通過してGuestOSからの外部への接続があれば､ログを確認できる｡この情報はクリティカルな警告が目的で､Honeypotが侵入され､攻撃者またはツールが外部への接続を試みていることを表している｡１０回目の接続が始まると､ブロックされ､ロギングされる｡以下に接続開始前のコマンドを示す｡ host #tail -f /var/log/messages 次に､GuestOSのHoneypotでターミナルを開く｡ここから外部宛に様々なTCP接続を試みる｡例えば､GuestOSから外部192.168.0.1/24の異なるシステムにtelnetをしたりする｡これらのシステムが存在しようとなかろうと､接続は試みられる｡パケットはHostOSのtap0を通りiptablesにより/var/log/messagesに記録される。９回の許可された外部宛の接続を見ることができ､それ以上はドロップされる｡それらすべての行動はロギングされる｡ Guest #telnet 192.168.1.105 Guest #telnet 192.168.1.220 21 Guest #telnet 192.168.1.5 80 Guest #telnet 192.168.1.115 6667 もしログに記録されれば､制限後はブロックされる｡Data Controlが成功したことを意味する｡次に､Data Captureがなされているか、特にSnortが出入りするすべてのペイロードをキャプチャしているかを確認したい｡SnortはHostOSの内部インターフェース､特にtap0を監視していなければならない｡これをテストするために192.168.1.0/24ネットワークのいくつかにpingを打つ｡ Guest #ping -c 3 192.168.1.105 SnortはICMPのパケットをキャプチャしている｡これはtcpdumpフォーマットでロギングされている｡ログファイルを見るために例えば次のように打つ｡ これで簡単なData Control及びData Captureのテストが完了した｡この他に､分離したコンピュータから試す方法等があるが､ここでは割愛する｡ Conclusion  |
