Tripwireを利用したファイル改竄のチェック

運用が大変かも....

Tripwireとは

 あなたが運用しているサーバーへの侵入にクラッカーが仮にに成功したとして、そのクラッカーがサーバー上で何をやろうとするのか考えてみてください。

 例えばあなたがECサイトを運用していて、サーバー上に顧客のクレジットカード番号があったり、もしくはあなたの会社の社運をかけた開発プロジェクトの極秘データがあるとすれば、そのようなデータに関心を示すクラッカーもいるかもしれません。しかし、私のようにフレッツISDNで運用されているサーバーにはそんなに客観的に重要な意味を持つデータはありません。それではクラッカーは何をするのでしょうか?

更に他のサーバーにアタックをかけるための踏み台にする

 という可能性が一番高いでしょう。

 そしてそのような目的を持ってサーバーの中で活動を行う場合、クラッカーはかなりの確率で次にもう一度そのサーバーに侵入する時に楽に侵入するための"バックドア"をこっそりと作っておく、という作業を行います。この作業を行う過程において、かなり高い確率で何らかのファイルを書き換えを行うでしょう。

 Tripwireは、ファイルの書き換えを監視することにより、自分の身に覚えがない変更がファイルに加えられた場合にそれを検出し、またある時点での設定状態に書き戻すことが出来る、ファイルの改竄防止を目的とするツールです。

 

Tripwireの入手とインストール

 私には関係はわかりませんが、配布元としてTripwire.comとTripwire.orgの2種類があります。前者は基本的にTripwireを販売しているようで、無料で利用できるLinux版の位置付けは評価目的という位置付けのようです。
 Tripwire.comの方は、 ダウンロードするには自分の個人情報を入れなければなりませんしバージョンも古く、Tripwire.comの法はオープンソースで公開されており、且つバージョンが新しいのですが、Tripwire.comの方はなぜかすでにRedhat Linux Ver. 7.0向けに最適化されています。

 ご存知の方もいらっしゃるかもしれませんが、Redhat Linux Ver. 7.0からファイルシステムに大きな変更があり(FSF準拠になった)、ファイル構成ははっきり言ってそれ以前のRedhat LinuxをベースにしているTurbo Linuxとは全く異なってしまっているので、今回はTripwire.comから入手で出るものを利用します。

 以下のURLから"Download"を選択し、ある程度の個人情報を入力するとダウンロードができるようになります。ついでに同じ場所に置いてあるPDFファイルも落としておきましょう。

http://www.tripwiresecurity.com/

 

Tripwireのインストール

 ダウンロードしたらまず解凍します。tarを解凍する際に専用のディレクトリを掘ってくれないので、自分で適当なディレクトリを作成して、そこに移動してから解凍した方がいいでしょう。

 mkdir Tripwire
 mv Tripwire_221_for_Linux_x86.tar.gz ./Tripwire
 cd Tripwire
 tar -zxvf Tripwire_221_for_Linux_x86.tar.gz

 軽くReadmeやRelease Noteに目を通したら、本番に入ります。インストールはinstall.shというスクリプトファイルが行いますが、そのスクリプトが使用するinstall.cfgというファイルを必要があれば修正します。非常に簡素なファイルで通常は特に修正の必要はないでしょう。

 ./install.sh

 と入力するとインストールが開始されます。インストール前にsuしておきましょう。

 "unameコマンドでよくわからないOS名が返ってきたけどほんとにいいの?"というメッセージが出ますが、ここは気にせず"y"で進みましょう。ライセンスの画面がでるので、一番下までスクロールして"accept"と入力すると、設定ファイルのないよう確認画面が出ます。問題がなければ"y"で進みます。

 ファイルのコピーが終了すると、Site KeyとLocal Keyをプロテクトするパスフレーズの入力を要求されます。指示されている通り、大文字小文字記号数字混在で8文字以上のパスフレーズを利用するように心がけましょう。続いて署名された設定ファイルとポリシーファイルの生成に移り、先ほど決定したパスフレーズの入力が要求されます。そして署名付ファイルの生成が正常に終了したら、インストールは終了です。

 

Tripwireの利用

 Tripwireはインストールディレクトリ(デフォルトでは/usr/TSS)の下の/policyの中にあるポリシーファイルで監視するファイルの設定をします。そして商用版ですとこのファイルがインストールされるOSとディストリビューションに合わせて細かく設定した物が添付されるようですが、今回は評価目的なのでTripwire本体と同じページからダウンロードできる評価版ポリシーファイルevalpol.tar.gzを利用します。

 tar -zxvf evalpol.tar.gz
 cp evalpol.txt /usr/TSS/policy (デフォルトインストール時)

 ちなみに評価用ポリシーファイルは、/etc以下のみを監視するようになっています。自分でまじめにポリシーファイルを書けば、他のディレクトリも監視できると思いますが、今回はそのまま利用します。

 次は今コピーしたポリシーファイルを、Tripwireが理解できる暗号形式のファイルに変換します。以下コマンド入力時のカレントディレクトリは、全て/usr/TSS/binと考えてください。

 ./twadmin --create-polfile ../policy/evalpol.txt

 サイトパスフレーズを入力しすると、/policy以下にtw.polという名前のファイルが出来ます。次はTripwireが利用するデータベースを初期化します。

 ./tripwire --init

 今度はローカルパスフレーズを要求されるので入力します。その後処理が開始され、データベースファイルが生成されます。ファイル名は($HOSTNAME).twdになるようです。

 これでこの時点での/etc以下の状態は保存されました。つまり、この瞬間から監視が始まったということになります。今後何らかの形で変更があった場合、その変更についてTripwireで検出することが可能になります。実際に変更があったかどうかを確認するには、コマンドラインから

 ./tripwire --check --interactive

 と入力します。そうするとレポートが表示され、ファイルの内容に変更があればそれがわかります。

 

改竄が本当にあったらどう見える?

 データベースを作成してからチェックをするまでの間に監視対象のファイルに対して何らかの変更があった場合のレポートの見え方を例として示しておきます。本当はレポート全体を載せたいのですが、結構大きくなるのでそれとわかる部分だけに留めておきます。

----------------------------------------------------------------
Section: Unix File System
----------------------------------------------------------------

----------------------------------------------------------------
Rule Name: Configuration Files (/etc)
Severity Level: 0
----------------------------------------------------------------
 ----------------------------------------
 Modified Objects: 1
 ----------------------------------------

Modified object name: /etc/hosts

Property:
-------------
Object Type
Device Number
Inode Number
Mode
Num Links
UID
GID
* Size
* Modify Time
Blocks
* CRC32
* MD5

Expected
-----------
Regular File
774
97464
-rw-r--r--
1
root (0)
root (0)
80
Sat Sep 16 03:54:11 2000
8
DkTvgX
A7bpu6IkuqGp9pX/kO9Qbr
Observed
-----------
Regular File
774
97464
-rw-r--r--
1
root (0)
root (0)
110
Sat Dec 9 21:52:29 2000
8
CQA4aa
DV4Z34yg0VmmykzDhP1HCS


 こんな感じに見えるはずです。
 "Expected"の部分が、元々のそのファイルのデータです。先頭に"*"がついている項目が変更があった部分で、今回はサイズ、最終修正日時、CRCとMD5の値がデータベース作成時から変更があったということが検出されています。

 管理者などが何らかの設定を加えて変更があった場合、その変更をデータベース自体に反映する必要があります。実際に変更が検出された後、レポートの画面から抜けるときにその変更をデータベースに反映するためにローカルパスフレーズの入力を求められます。ここで正式なパスフレーズを入力できない場合は、データベースは更新されません。つまり、不正侵入者がデータベースの更新を行うことは出来ないわけです。

 おそらく実際の運用としては、定期的にcronで走らせるような形になるでしょう。また、監視対象もrootkit対策などを考えると/sbinや/binなども合わせて監視する必要があるでしょう。ここらへんは各々のセキュリティポリシーによる部分だと思います。