前回は、Tripwireの導入からレポートの出力までを解説しました。今回は、導入後の運用について説明します。
レポートファイルは、整合性チェックを行うことで作成されます。まず、このファイルの内容を見ていきましょう。ここでは、テスト用のポリシーファイルで整合性チェックを行って生成されたレポートファイルを例に説明します。
まずは、前回の復習を兼ねて簡単なポリシーファイルを作成してみましょう。内容は簡単な方がいいと思いますので、次のようなものにします。
/var/tmp/atmarkitというファイルに何らかの変更が発生した場合に通知
早速、作成してみましょう。以下の内容のテキストファイルを用意します。
(
rulename = Test Policy
)
{
/var/tmp/atmarkit -> $(ReadOnly);
} |
ファイルの作成が終わったら、暗号署名してデータベースを作成後、整合性のチェックを行います(編注)。
では、作成されたレポートファイルの内容を確認してみましょう。
Note: Report is not encrypted.
Tripwire(R) 2.3.0 Integrity Check Report
Report generated by: root
Report created on: Tue Apr 9 12:37:12 2002
Database last updated on: Mon Apr 8 20:26:07 2002
======================================================================
Report Summary:
======================================================================
Host name: atmarkit
Host IP address: 192.168.1.1
Host ID: None
Policy file used: /etc/tripwire/tw.pol
Configuration file used: /etc/tripwire/tw.cfg
Database file used: /var/lib/tripwire/atmarkit.twd
Command line used: tripwire -m c
======================================================================
Rule Summary:
======================================================================
----------------------------------------------------------------------
Section: Unix File System
----------------------------------------------------------------------
Rule Name Severity Level Added Removed Modified
--------- -------------- ----- ------- --------
* TestPolicy 0 0 0 1
(/var/tmp/atmarkit)
Total objects scanned: 1
Total violations found: 1
======================================================================
Object Summary:
======================================================================
----------------------------------------------------------------------
# Section: Unix File System
----------------------------------------------------------------------
----------------------------------------------------------------------
Rule Name: TestPolicy (/var/tmp/atmarkit)
Severity Level: 0
----------------------------------------------------------------------
Modified:
"/var/tmp/atmarkit"
======================================================================
Object Detail:
======================================================================
----------------------------------------------------------------------
Section: Unix File System
----------------------------------------------------------------------
----------------------------------------------------------------------
Rule Name: TestPolicy (/var/tmp/atmarkit)
Severity Level: 0
----------------------------------------------------------------------
----------------------------------------
Modified Objects: 1
----------------------------------------
Modified object name: /var/tmp/atmarkit
Property: Expected Observed
------------- ----------- -----------
Object Type Regular File Regular File
Device Number 770 770
Inode Number 1186733 1186733
Mode -rw-r--r-- -rw-r--r--
Num Links 1 1
UID root (0) root (0)
GID root (0) root (0)
* Size 931 1083
* Modify Time Mon Apr 8 20:25:41 2002 Tue Apr 9 12:37:03 2002
Blocks 8 8
* CRC32 AsdXgr B9BiOR
* MD5 AnFGlQAa6uTviRVQJIie0V BU+dY6h5Vez7cunb9L7hA4
======================================================================
Error Report:
====================================================================== |
①Modifiedの「1」は、変更されたファイルが1つあることを表す。Addedが「1」の場合は、ファイルなどが1つ追加されたことを意味する
②チェックを行ったファイルの総数
③違反が見つかったファイルの数
④変更されたファイル名。その下に詳細が記載されている。サイズやHASH値から、ファイルが明らかに変更されていることが分かる
レポートの内容を確認しても、それからどのようなことが想定されるのか、どのような対応をすべきなのかは分かりにくいでしょう。通常、意図しない変更が行われてもよいと考えられるファイルなど存在しないものです。設定変更など、何らかの意図があり、その事実を把握しているのであれば問題はないでしょう。
まず、何らかの変更が報告されたのであれば、それが正当なものなのか不当なものなのかを判断しなければなりません。不当なものであれば対応が必要になります。最善の対応は、そのホストをネットワークから切り離してしまうことです。その後、どのようなことが原因でファイルが変更されたのかを判断します。
すなわち、プログラムの不具合などを突かれ、不正な侵入・変更が行われてしまったのか、それともFTPでのanonymousログインに対してもPUTを許してしまうような設定ミスによるものなのかということになります。前者はある意味致命的であるため、ホストの再構築を考えなければならないでしょう。後者であれば、本当にFTPに関する設定ミスのみであれば、適切に設定変更するだけで済むかもしれません。いずれにしても、現状の正確な把握をしなければなりません。
判断が難しい面もあります。例えば複数の管理者が存在し、意思の疎通ができていなければ、ある管理者にとっては正当な変更であり、別の管理者にとっては不当な変更と判断されてしまうかもしれません。これは絶対に避けたいものです。このような事態を回避するためにも、IDSのポリシーを考えるだけでなく、運用に関するポリシーもきちんと作成することを強く推奨します。
次に、どのようなファイルが狙われやすく、そのファイルの変更からどのような事態が発生し得るかを考えてみましょう。
Tripwireで用意されているポリシーファイルの中には、コマンドも含まれています。このようなコマンドに関する変更も注意が必要です。トロイの木馬が仕掛けられている可能性があるのです。狙われやすいのが、通常のオペレーションで頻繁に使われるコマンドです。ディレクトリの一覧を表示するlsコマンドなどがそれに当たります。何げない操作によって悪意のあるプログラムを実行してしまい、システムを破壊してしまうといったことが十分に考えられます。
また、先にも挙げたアプリケーションなどの設定ファイルにも注意が必要です。FTPのほかに、分かりやすいところではメールの設定ファイルなどが考えられます。不正中継を許可しない設定であったにもかかわらず、設定が変更されて踏み台になってしまう可能性もあります。単純にメールの送受信ができるからといって「被害はない」などと考えてはいけません。
当然、/etc/passwdファイルなどは要注意です。通常、/etc/passwdファイルは一般ユーザー権限での書き込みを許可しません。/etc/passwdが書き換えられたということは、root権限によるコマンド実行を許してしまっていると考えられるからです。もちろん、一般ユーザー権限での任意のコマンド実行を許してはいけませんが、想定される被害の度合いから考えても、事の重要性は変わってきます。また、起動スクリプトなども狙われることがあります。OSの起動時に実行されるスクリプトで、意図しないプログラムが起動されてしまうかもしれません。
Tripwireは不正アクセスに対してのみ利用するというものではなく、ほかの使い方も考えられます。例えば、アプリケーションの設定変更を行うときにも役立つことがあります。複数の設定ファイルを変更した後、正常に動作しなくなったとします。どのファイルを編集したか忘れてしまったときなど、Tripwireのレポートが役立ちます。ただし、残念ながらどの部分が変更されたのかまでは分かりません(注)。
注:どの部分を変更したのかを把握するには、diffコマンドなどを利用するといいでしょう。
さらに、データベースファイルをテキスト化し、siggenコマンドで変更前のファイルのHASH値と現在のファイルのHASH値とを比較することで、元の状態へ戻すことへの手助けとなるでしょう。
ほかにも、アプリケーションを新たにインストールしたりバージョンアップしたときなどに、どのファイルが追加・変更されたのかを把握できます。