Tripwire運用の勘所

第9回 Tripwire運用の勘所

IDSは、導入したからといってセキュリティが向上するわけではないし、日々の運用を怠ればまったく無意味だ。では、どのように運用すればよいのか? 前回導入したTripwireの運用方法を解説する。

 前回は、Tripwireの導入からレポートの出力までを解説しました。今回は、導入後の運用について説明します。

レポートファイルの確認

 レポートファイルは、整合性チェックを行うことで作成されます。まず、このファイルの内容を見ていきましょう。ここでは、テスト用のポリシーファイルで整合性チェックを行って生成されたレポートファイルを例に説明します。

レポートファイルのどこを見るか?

 まずは、前回の復習を兼ねて簡単なポリシーファイルを作成してみましょう。内容は簡単な方がいいと思いますので、次のようなものにします。

/var/tmp/nandemoariというファイルに何らかの変更が発生した場合に通知

 早速、作成してみましょう。以下の内容のテキストファイルを用意します。

(
    rulename = Test Policy
)
{
    /var/tmp/nandemoari  ->  $(ReadOnly);
}

 ファイルの作成が終わったら、暗号署名してデータベースを作成後、整合性のチェックを行います(編注)。

編注:暗号署名、データベースの作成、整合性チェックの方法については、前回のTripwireによるホスト型IDSの構築参照。

 では、作成されたレポートファイルの内容を確認してみましょう。

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:                    nandemoari
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/nandemoari.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/nandemoari)

Total objects scanned:  1 
Total violations found:  1 

======================================================================
Object Summary:
======================================================================

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

----------------------------------------------------------------------
Rule Name: TestPolicy (/var/tmp/nandemoari)
Severity Level: 0
----------------------------------------------------------------------

Modified:
"/var/tmp/nandemoari"

======================================================================
Object Detail:
======================================================================

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

----------------------------------------------------------------------
Rule Name: TestPolicy (/var/tmp/nandemoari)
Severity Level: 0
----------------------------------------------------------------------
  ----------------------------------------
  Modified Objects: 1
  ----------------------------------------

Modified object name:  /var/tmp/nandemoari 

  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値とを比較することで、元の状態へ戻すことへの手助けとなるでしょう。

 ほかにも、アプリケーションを新たにインストールしたりバージョンアップしたときなどに、どのファイルが追加・変更されたのかを把握できます。
データベースのアップデート

 整合性チェックで監査対象のファイルに変更が発見されたからといって、必ずしも不正な変更というわけではありません。Web関連のコンテンツファイルであれば、定期的に変更されることもあります。

 再度整合性チェックを行うと、また違反が発見されるでしょう。これは当然の結果なのです。これまで説明してきたように、Tripwireは「ある時期に作成された」データベースファイルと、「整合性チェック時」のファイルの内容を比較するのです。つまり、データベースファイルを更新しない限り、何度でも違反として検出され続けるというわけです。

 意図的なファイル変更を行った場合は、Tripwireの「データベースアップデートモード」を利用したデータベースのアップデートが必要になります。データベースのアップデートは、作成されたレポートファイルを基に行います。

 実際に作業を進めながら説明しましょう。まずは、再度/var/tmp/nandemoariファイルに対する監査を行い、違反が報告されることを確認します。確認したら、tripwireコマンドを以下のように実行します。

# /usr/sbin/tripwire -m u -c 設定ファイル -p ポリシーファイル -r レポートファイル

 すると、レポートファイルがvi()で開かれた状態で表示されます。

注:レポートファイルを開くエディタは、設定ファイルの「EDITOR」で定義されています。

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:                    nandemoari
(中略)
----------------------------------------------------------------------
Rule Name: TestPolicy (/var/tmp/nandemoari)
Severity Level: 0
----------------------------------------------------------------------

Remove the "x" from the adjacent box to prevent updating the database
with the new values for this object.

Modified:
[x] "/var/tmp/nandemoari" 

======================================================================
Object Detail:
======================================================================
(中略)
   Modified object name:  /var/tmp/nandemoari

  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
(以下略)

 レポートファイルには、のような部分があります。これが変更されたファイルです。ファイル名の前にあるチェックをオン(「x」が入力された状態)にしたまま保存・終了するとデータベースがアップデートされます。なお、保存後にローカルパスフレーズの入力を求められます。

 データベースのアップデートが終わったら再度整合性チェックを行い、違反が報告されないことを確認してください。

効率的な整合性チェック

電子メールを利用した通知

 Tripwireでは、整合性チェックの結果を電子メールで通知することも可能です。

 前回、電子メールで通知するための設定ファイルやポリシーファイルの記述については説明しました。しかし、これだけでは電子メールで通知されません。整合性チェックの際に、次のようにオプションを指定する必要があります。

# /usr/sbin/tripwire -m c -M

 電子メールでの通知では、レポートレベルは高くなくてもいいでしょう。違反の有無を確認できるだけでいいからです。違反が検出された際はきちんとレポートの内容を確認し、しかるべき対応を取りましょう。

定期的なチェック

 cronに登録することで、定期的に整合性チェックを行うことができます。しかし、ファイルによっては頻繁に監査()したいものや1日1回程度でいいものがあるでしょう。

注:頻度(チェック間隔)には注意が必要です。1分ごとに実行するようにcronへ登録しても、チェックに1分以上かかるようではチェックをしている最中に次のチェックが開始されることになってしまいます。筆者は、このようなチェックを試したことがないのでどのような結果になるか分かりせんが……。

 前回も説明したとおり、Tripwireではポリシーファイル内のルールブロックごとに整合性のチェックを行うことができます。この機能を利用するといいでしょう。

 ルール名「htmlfiles」は10分に1回。それを含めた全ルールは1日1回、午前1時に実施する場合は次のように登録します。

*/5 * * * *         /usr/sbin/tripwire -m c -R htmlfiles -M
0 1 * * *           /usr/sbin/tripwire -m c -M