Tripwireによるホスト型IDSの構築
第8回 Tripwireによるホスト型IDSの構築前回紹介したように、Tripwireはファイルの監査を行うホスト型IDSです。監査対象となるディレクトリやファイル属性のHASH値をデータベースに保存しておき、データベースと現在の属性を比較することで監査を行います。Tripwireでは、この監査を「整合性チェック」と呼びます。違反があった場合は、管理者に対してメールで通知する機能などもあります。
Tripwireの導入には、大きく分けて以下のような作業が発生します。
ネットワーク型IDSと違い、ホスト型IDSはポリシーファイルが一度決まってしまえば、ホスト上で大きな変更がない限り、ポリシーファイルを変更する必要はそれほどありません。そこで、導入初期段階が非常に重要になってきます。大切なことは、Tripwireを導入する意味や目的をきちんと考えたうえで作業することです。
Tripwireのインストール
オープンソース版(無償)のTripwireはhttp://www.tripwire.org/にあります。ここには、
が用意されているので、適当なディレクトリにダウンロードして展開、インストールします。
$ tar -zxvf tripwire-2.3-47.i386.tar.gz |
RPM 4.0版の場合 |
/usr/sbin以下に実行ファイルなどがインストールされ、/etc/tripwireディレクトリが作成されます。ここで、/etc/tripwireにサンプルとなる設定ファイルやポリシーファイルがあることを確認してください。
しかし、rpmコマンドだけでインストール作業が完了したわけではありません。Tripwireでは、設定ファイルやポリシーファイルで利用されるサイトキーファイルを暗号化するための「サイトパスフレーズ」、データベースファイルなどで利用されるローカルキーファイルを暗号化するための「ローカルパスフレーズ」が必要になります。各パスフレーズを設定するために、/etc/tripwireディレクトリにあるtwinstall.shというスクリプトを実行します。
# /etc/tripwire/twinstall.sh |
スクリプトを実行したら、表示される指示に従って設定を進めます。初めにサイトキーファイルのパスフレーズ、次にローカルキーファイルを入力します。それぞれ確認用の入力も求められるので2回ずつ入力することになります。これが終わると、先に設定したサイトパスフレーズの入力が2回必要になります。画面の指示をよく見れば特に難しくありません。
設定が終わったら、/etc/tripwireディレクトリに以下の2つのキーファイルが作成されていることを確認しましょう。
設定ファイルの作成
Tripwireのデフォルトの設定ファイルはtw.cfgで、暗号署名されたファイルです。実際の設定変更には、クリアテキストのtwcfg.txtを使います。つまり、設定ファイルの作成には、次のような段階があります。
■クリアテキストの設定ファイルの作成
設定ファイルには、利用するポリシーファイル名やレポートファイルの出力先、メールで通知するときに利用するSMTPホストの指定などを記述します。
キーワード = 値 |
という形式で記述し、キーワードは大文字でなければなりません。また、値は「$()」という形式の変数が使えます。
以下に、設定ファイルの例を示します。
# Tripwireの保存場所 |
$(HOSTNAME)、$(DATE)はすでに定義されており、変更できません |
■設定ファイルの暗号署名
クリアテキスト(twcfg.txt)による設定を行ったら、このファイルを基に暗号署名したファイル(tw.cfg)を生成しなければなりません。暗号署名を行うには、twadminコマンドを使います。
# /usr/sbin/twadmin
-m F -c tw.cfg -S site.key /etc/tripwire/twcfg.txt |
これで、設定ファイルの暗号署名は完了です。twadminコマンドのオプションを以下に示します。
なお、暗号署名された設定ファイルの確認方法は以下のとおりです。
# /usr/sbin/tripwire
-m f -c tw.cfg |
ポリシーファイルの作成
設定ファイルと同様に、ポリシーファイルもクリアテキストのファイルを作成し、これを基に暗号署名したファイルを生成します。
■クリアテキストのポリシーファイルの作成
ポリシーファイルを作成するには、まずどのファイルを監査対象とするのか、Tripwire導入の目的と照らし合わせて検討する必要があります。Webサーバのコンテンツ改ざんを検知するなら、コンテンツに関するファイルが監査対象となるでしょう。さらにlsなど、よく使うコマンドも監査対象とした方がよいでしょう。コマンドにトロイの木馬を仕掛けられてしまうことがあるからです。ほかにも、OS起動時にセットされる環境変数の変化にも注意すべきです。/etc/profileや~/.bash_profileといったファイルも重要です。
/etc/tripwireディレクトリに、twpol.txtというファイルがあります。これは、Red Hat Linuxをベースに作成されたサンプルポリシーファイルです。これを参考に作成するとよいでしょう。twpol.txtを見ると、さまざまな記述があって分かりにくいかもしれません。そこで、簡単なポリシーファイルを例に説明します。
@@section GLOBAL |
●命令
Tripwireでは、ポリシーファイルに条件分岐などの命令を記述できます。
@@section
ポリシーファイルのセクションを指定します。「GLOBAL」はすべてに当てはまります。「FS」はUNIX(およびUNIX系OS)の場合に利用されるもので、Windows用ポリシーと区別するために用意されています。デフォルトでは、UNIXルールとして読み取られます。
ほかにも命令はありますが、あまり使うことはないので省略します。
●属性
「()」でくくられている部分を「属性」と呼び、以下の4種類があります。
rulename
ルールブロックの名前を指定します。名前にスペースを入れるときは必ずダブルクオーテーションでくくる必要があります。rulenameで指定した名前で整合性チェックやレポートの作成が行われるので、分かりやすい名前にしておきましょう。
severity
重要度を0〜1,000,000の範囲の値で設定します(デフォルトは0)。サンプルポリシーでは次のように定義されています。
SEC_LOW = 33;
SEC_MED = 66;
SEC_HI = 100;
例として挙げたポリシーの場合、Sample Policy1は「0」、Sample Policy2は「100」ということになります。
emailto
違反が発見されたときに通知するメールアドレスを指定します。
recurse
「true」「false」あるいは-1〜1,000,000の範囲の数値でディレクトリに対する再帰の階層を指定します。「true」(-1)であれば、サブディレクトリやその中のファイルまですべてが監査対象となります(注)。「false」(0)にすると、サブディレクトリ内のファイルは監査しません。
注:/usr、/usr/localというディレクトリが存在するとします。両者のマウントポイントが異なると「true」としても再帰的な監査は行われません。
●オブジェクト
監査対象となるファイルやディレクトリを指定します。
●プロパティ
オブジェクトに対してどのようなチェックを行うかを指定します。指定可能なプロパティは18種類あり、チェックを行う場合は「+」、行わない場合は「-」で示します。
a | アクセスのタイムスタンプ | |
b | 割り当てられているブロック数 | |
c | iノード作成/変更タイムスタンプ | |
d | iノードが保存されているディスクのデバイス番号 | |
g | 所有者のグループID | |
i | iノード番号 | |
l | ファイルサイズの増加。最後に記録されたサイズよりもファイルが小さい場合に違反として検知される(注) | |
m | 変更タイムスタンプ | |
n | リンク数(iノードリファレンス数) | |
p | ファイルアクセス権 | |
r | iノードが指し示しているデバイスのデバイス番号 | |
s | ファイルのサイズ | |
t | ファイルの種類 | |
u | 所有者のユーザーID | |
C | CRC-32ハッシュ値 | |
H | Havalハッシュ値 | |
M | MD5ハッシュ値 | |
S | SHAハッシュ値 | |
プロパティ一覧 注:ファイルがAからBになり、A<Bのときは違反とならず、データベースも更新されない。よって、BからCになりA<C<Bの場合も違反とならない |
例えば、ファイルのアクセス権をチェックする場合は、
/tmp/test
-> +p; |
とします。複数のプロパティを指定する場合(注)は、
/tmp/test
-> +pinugt; |
のように記述します。
注:ポリシーファイル内で、同じオブジェクトに対して異なるプロパティを定義することはできません。 |
各オブジェクトに対していちいち18種類のプロパティを指定するのは困難です。そこで、目的に応じたプロパティの組み合わせを分かりやすい名前で指定できる方法が用意されています。多くのオブジェクトについては、この方法で十分です。
前述したように、あらかじめ用意されているtwpol.txtをベースにして設定するのがよいでしょう。ただし、これはあくまでもサンプルポリシーなので必ずしも自分の環境に適しているわけではありません。導入初期段階は、このポリシーファイルの調整に追われることが予想されます。一度で環境に適したポリシーファイルを作成するのは非常に困難です。徐々にで構わないので、自分の環境に適したものへと根気よく調整していきましょう。
■ポリシーファイルの暗号署名
次に、クリアテキストで作成したポリシーファイルを暗号署名します。設定ファイルと同じく、twadminコマンドを利用します。ここでは、あらかじめ用意されているサンプルポリシー(twpol.txt)を利用します。
# /usr/sbin/twadmin
-m P -S site.key twpol.txt |
これで、twpol.txtを基に暗号署名を施したtw.polが生成されます。つまり、Tripwireが解釈可能なポリシーファイルが作成されたということです。
twadminコマンドのオプションのうち、ポリシーファイルの作成に使用するものを以下に示します。なお、設定ファイル作成時に紹介したものは省略しています。
暗号署名されたポリシーファイルの確認方法は以下のとおりです。
# /usr/sbin/tripwire
-m p -c tw.cfg -p tw.pol |
ベースラインデータベースの作成
ポリシーファイルを生成したら、ポリシーファイルを基にベースラインデータベースを作成します。整合性チェックでは、このデータベースと比較されるのです。
ベースラインデータベースは、tripwireコマンドで作成します。
# /usr/sbin/tripwire
-m i |
tripwireコマンドのオプションを以下に示します。
ここで、多くのWarningが出るかもしれません。それらのほとんどは、指定されたファイルが存在しないという内容でしょう。そこでポリシーファイルの調整が必要になるのです。存在しないファイルやディレクトリを監査対象としても意味がありません。そこで、クリアテキストで作成されたファイルを再度確認してみましょう。
ベースラインデータベース作成時に「存在しない」とされたファイルやディレクトリが監査対象として指定されていないか確認します。記述があるようであれば、行頭に「#」を挿入してコメントアウトするか、その行を削除しましょう。ただし、パスが異なるだけで、実はファイルが存在する可能性もあることに注意してください。
これで、整合性チェックを行うための「一応の」準備は完了です。
Tripwireの基本的な運用方法
■整合性チェック
実際に整合性チェックを実行してみましょう。ベースラインデータベース作成後、特に変更を行わなければ何も違反は警告されないでしょう。
# /usr/sbin/tripwire -m c |
これで、整合性チェックは完了です。整合性チェックでのtripwireコマンドのオプションを以下に示します(既出コマンドは省略)。
■レポートチェック
整合性チェックの結果は標準出力およびレポートファイルに出力されます。この内容を確認するには、次のコマンドを実行します。
# /usr/sbin/twprint
-m r -c tw.cfg -r "レポートファイル名" -L local.key -t 4 |
twprintコマンドのオプションを以下に示します。
レポートファイル名は整合性チェックを行ったときに表示されます。デフォルトでは/var/lib/tripwire/report/{ホスト名}-{日付}-{時間}.twrとなります。また、出力先は設定ファイルで変更できます。