uml
Know Your Enemy:
Learning with User-Mode Linux
Building Virutal Honeynets using UML.
Last Modified: 20 December, 2002
Translated by SHIBUYA Yoshihiro (Self-Defence Force)
Original document is here
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
このペーパは５つのパートからなる｡最初のパートはUMLとは何か､どのように機能するか､インストール方法と設定法である｡次のパートは､すべてのネットワーク要素を含む､単独のコンピュータ上で複数のシステムのネットワークを構築する方法である｡３番目には､iptablesを使用したUMLのData Controlの実施方法である｡４つ目にはsnortを使用したData Captureの方法､５番目にはセットアップのテストについて述べてある｡
Part I: User Mode Linux
UMLは仮想マシンを形成するオープンソースのソリューションである｡作成と整備はJeff Dikeで、http://user-mode-linux.sourceforge.netで見つけることができる｡UMLは同一システム上で同時に複数のLinuxシステムを起動させることができる｡この機能は商用の VMwareと似ているが､UMLはLinuxに限定される｡UML はカーネルデバック､アプリケーションのテスト等､多くの目的のために設計された｡我々はこの機能を単独のコンピュータ上で走らせ､単独のゲートウェイの後ろにHoneypotを置くことにする｡このペーパではUMLのインストールと起動をRH7.3で説明する｡VMWareと同じ用法で述べ､特に基盤のOSをHost systemと呼ぶ。その上に構築されたシステムをGuest systemと呼ぶ｡この装備の図は､KYE: Virtual HoneynetsのペーパのFigure 1 を参照のこと｡
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を参照のこと｡
- TTY Logging: UMLはUML Honeypotと交信するSSHのような暗号化を含むすべての攻撃者のキーストロークをキャプチャする能力を持つ｡UMLではHostから出て行くすべてのttyデバイスを記録するttyドライバのパッチを当てることにより可能となる｡これに比較して物理的なHoneypotのロギングメカニズムでは､検知も破壊もできない｡このことにより、Honeypotで検知されたものはネットワークトラフィックでなくなる。このことはまたUMLのカーネルでは侵入者が何も妨げることができないことを示している｡
- hppfs: 仮想Honeypotの不安な点の一つがfingerprintingである。攻撃者が仮想OSにアクセスしてしまえば､Honeypotであると覚られてしまう｡UMLは/procを修正し､実際のOSに見せかけることでこの危険性を軽減している｡
- skas Mode: UMLは最近UMLのカーネルのプロセスがhostアドレスと分離するように再設計された｡このことによりUMLカーネルバイナリとデータはプロセスからは見えなくなり､記録もできなくなる｡これでUMLカーネルのデータはこれらのプロセスに変更されることなくセキュアになる｡
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
/usr/bin/jailtest
/usr/bin/linux <- executable binary that is really the UML kernel, the Guest OS
/usr/bin/tunctl
/usr/bin/uml_mconsole
/usr/bin/uml_moo
/usr/bin/uml_net
/usr/bin/uml_switch
/usr/lib/uml/config
/usr/lib/uml/modules-2.2.tar
/usr/lib/uml/modules-2.4.tar
/usr/lib/uml/port-helper
このとおり､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
host #linux ubd0=root_fs.rh-7.2-server.pristine.20021012 eth0=tuntap,,,192.168.0.254
"linux"コマンドを実行するとき､ターミナル上に新しいOSがブートするのを見るであろう｡そして期待通りログインのプロンプトになる｡"root"でログインし､"root"というパスワードを入力することによってOSにアクセスすることができる｡ついにできた！これからその内容について述べる｡
Part II: Setting up the Network
これで２つのOSが動いている｡次の我々のHoneypotであるGuestOSのステップはゲートウェイ経由インターネットへ出て行くルーティングである。このことにより、もし誰かがGuestOSにアクセスしたい場合､Hostをまず通らなければならなくなる｡あなたには分からないだろうが､もうすでにすべてのセットアップは含まれているのだ｡"linux"コマンドを実行したときの最後のコマンドeth0=tuntap,,,192.168.0.254である。このコマンドは２つのことを実行する｡最初に､tap0と呼ばれる論理インターフェースをHost上に作成する｡tap0及びGuestOSのデフォルトゲートウェイのIPアドレスは､192.168.0.254である。eth0のIPアドレスと唯一異なるところは､あなたの設定次第である｡たとえば我々の場合､192.168.1.1である。セットアップを確認するため､HostOS上で次のコマンドを打つ｡
eth0の部分はGuestOSのeth0を生成し､Host上のtap0を論理的に通ることを示している｡我々が残した唯一のことは､GuestOSのeth0にIPアドレスを与えたことである｡これで我々のファイルシステムは完了した｡我々のRH7.2サーバの場合､eth0のIPアドレスは192.168.0.144である。もしRH7.2サーバの設定を変えたければ､これらの変更をすればよい｡このセットアップを確認するために､GuestOSで以下のコマンドを打つ｡
仮想ネットワークがどのようになっているかは､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
UMLネットワークをセットアップしたら､次の段階はデータコントロールである｡データコントロールの目的はHoneynetへの往来で攻撃者が何を含むことができるかである｡典型的に､我々はHoneynetに入ってくるものはすべて許可し､出て行く接続は制限している｡このペーパでは､オープンソースのLinux用ファイアーウォールソリューションであるiptablesを使用する｡iptablesは高度にフレキシブルで安定したファイアーウォールであり、接続制限を含み､ネットワークアドレスの解釈､ロギングそして多くの機能を備えている｡我々はHost上でiptablesを動かすように設定し､出て行くパケットをカウントするようにした｡出て行くパケットが制限に達したら､すべてがブロックされ､外部への害を防ぐ｡これらの機能の設定と実行は極めて複雑である｡しかし、プロジェクトではrc.firewall なるスクリプトを用意した｡あなたはHoneynet用に単に変更してスクリプトを実行すればよい｡
最初に決定しなければいけないことは､ゲートウェイを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のルーティングモードにする。
# The MODE variable tells the script to #setup a bridge HoneyWall
# or a NATing HoneyWall.
MODE="nat"
#MODE="bridge"
次に､GuestOSのIPアドレスを設定する必要がある｡これはNATの外部IPアドレスとなる｡これはまたハッカーがVirtual Honeypotを攻撃するであろうアドレスとなる｡もしブリッジモードで使用するならば､これらは（そのまま）使えるが､Honeypotの実際のアドレスは設定しなければならない｡ PUBLIC_IP="192.168.1.144"
３番目に､Honeypotの内部IPアドレスを設定する｡これはGuestOSの実際のIPアドレスである。もしブリッジモードならばこれは使ってはいけない｡
HPOT_IP="192.168.0.144"
４つ目に､HostOSの外部用IPアドレスを設定する必要がある｡これはファイアーウォールとゲートウェイの外部IPアドレスである｡我々の場合､
INET_IP="192.168.1.1"
最後に､HostOSの内部インターフェースの名前を設定する｡デフォルトではeth1である。しかし、我々は仮想インターフェースtap0を使っており､この変数を変更する｡
LAN_IFACE="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
Data Controlが完了したら､次の段階はData Captureである。Data Captureの目的は知られることなく攻撃者の行動をすべてキャプチャすることである｡多くの方法があるが､我々はiptables及びSnortの２つに絞ることにする｡iptableのログは接続が出入りするときはいつでもファイアーウォールによってロギングされる｡Snortはネットワーク上のすべてをキャプチャするオープンソースのIDSである。先に述べたように､UMLはカーネルスペースからすべてのTTYをキャプチャする能力を持つ｡
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
５番目の最後のステップとして特にData Control及びData Captureの設定のテストをする｡我々はHoneynetが期待通りの働きをするか確認したい｡Data Controlのテストは比較的簡単である｡我々が確認したいのはOutboundのログとコントロールである。ログによって､/var/log/messagesに記録され、出て行く接続があったことを警告し､Honeypotは侵入されたことを示す｡また、制限回数に至ったら､それ以上の接続はないことを確認したい｡このペーパでは､１時間あたり９回のTCP接続の許可をテストした｡これには２つのターミナルが開いている必要がある｡
最初に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
Trying 192.168.1.105...
Guest #telnet 192.168.1.220 21
Trying 192.168.1.220...
Guest #telnet 192.168.1.5 80
Trying 192.168.1.5...
Guest #telnet 192.168.1.115 6667
Trying 192.168.1.115...
もしログに記録されれば､制限後はブロックされる｡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
このペーパでの目的はオープンソースのツールでVirtual Honeynetを構築することであった｡このソリューションの価値はリサーチと開発のための簡単で安価なHoneynetである。このペーパにより､セキュリティ社会でのHoneynet技術の理解の簡素化に役立てば幸いである｡