2026年5月19日

2026年5月19日

Tripwireでファイル改ざんを検知する設定手順(Ubuntu/Debianの導入から日次チェックまで)

Tripwire は、監視対象のファイルのハッシュ値や権限・所有者などを「正しい状態」としてデータベースに記録し、後から照合して変化を報告するツールです。改ざんを防ぐ道具ではなく、「いつの間にか変わった」ことに気づくための道具です。

この記事では、Ubuntu/Debian に Open Source Tripwire を入れ、サーバー全体の重要ファイルを監視する基本の流れを説明します。手順は 2026年11月時点の Ubuntu 24.04(tripwire 2.4.3.7)で動作を確かめています。WordPress のファイルを監視するためのポリシー例は、Tripwireでファイル改ざんを検知する方法(WordPressサーバー向け)で扱っています。

Tripwire の仕組みと主なファイル

Tripwire は鍵で署名したファイルだけを信用します。テキストで書いた設定やポリシーを、鍵で署名した版に変換してから使うのが特徴です。

ファイル 役割
/etc/tripwire/twcfg.txt 設定のテキスト版(編集用)
/etc/tripwire/tw.cfg 署名済みの設定(Tripwire が実際に読む)
/etc/tripwire/twpol.txt 監視ポリシーのテキスト版(編集用)
/etc/tripwire/tw.pol 署名済みのポリシー(Tripwire が実際に読む)
/etc/tripwire/site.key サイト鍵。設定とポリシーの署名に使う
/etc/tripwire/<ホスト名>-local.key ローカル鍵。データベースとレポートの署名に使う
/var/lib/tripwire/<ホスト名>.twd 正しい状態を記録したデータベース
/var/lib/tripwire/report/*.twr チェック結果のレポート

テキスト版を編集しただけでは反映されません。署名し直す手順を忘れて「設定を変えたのに効かない」となるのが、最初によくあるつまずきです。

インストールと鍵の作成

sudo apt update
sudo apt install tripwire

インストール中に、サイト鍵とローカル鍵のパスフレーズを設定するか、設定ファイルとポリシーファイルを作るかを順に尋ねられます。ここで設定すると、上の表の鍵と署名済みファイルがそろいます。

パスフレーズはサーバー上のファイルに保存せず、パスワードマネージャーなど別の場所で管理してください。攻撃者がパスフレーズを知ると、データベースを作り直して変更の痕跡を消せてしまいます。

インストール時に鍵を作らなかった場合や作り直したい場合は、twadmin で作成し、設定とポリシーを署名します。

sudo twadmin --generate-keys --site-keyfile /etc/tripwire/site.key
sudo twadmin --generate-keys --local-keyfile /etc/tripwire/$(hostname)-local.key
sudo twadmin --create-cfgfile -S /etc/tripwire/site.key /etc/tripwire/twcfg.txt
sudo twadmin --create-polfile -S /etc/tripwire/site.key /etc/tripwire/twpol.txt

RHEL 系(AlmaLinux/Rocky Linux 9 など)では、tripwire は EPEL リポジトリから入れられます(2026年11月時点で EPEL 9 に 2.4.3.7 を確認)。twadmin と tripwire のコマンドは同じですが、ファイルの置き場所は rpm -ql tripwire で確かめてから進めてください。

ポリシーを環境に合わせて調整する

既定の twpol.txt は一般的な Linux を想定した内容で、手元の環境には無いファイルが多く含まれています。そのまま初期化やチェックをすると、次のような警告が大量に出ます。

### Warning: File system error.
### Filename: /root/.tcshrc
### No such file or directory

まず元のファイルを残してから編集し、存在しないパスの行を # でコメントアウトします。

sudo cp /etc/tripwire/twpol.txt /etc/tripwire/twpol.txt.orig
sudo nano /etc/tripwire/twpol.txt

ポリシーの冒頭には、監視の厳しさを表す変数が定義されています。

変数 意味
SEC_CRIT 変わってはならない重要ファイル
SEC_BIN 変わらないはずのプログラム($(ReadOnly))
SEC_CONFIG 変更されることがある設定ファイル($(Dynamic))
SEC_LOG 大きくなるが、所有者などは変わらないファイル($(Growing))
SIG_LOW / SIG_MED / SIG_HI 重要度(33/66/100)

自分で監視対象を足すときは、ルールのまとまりを末尾に追加します。次は Web サーバーの設定と公開ディレクトリのプログラムを監視し、変化があればこのルールだけ指定のアドレスへ知らせる例です。パスは環境に合わせて書き換えてください。

(
  rulename = "Web server config",
  severity = $(SIG_HI),
  emailto = admin@example.com
)
{
  /etc/nginx              -> $(SEC_CONFIG) ;
  /etc/php                -> $(SEC_CONFIG) ;
  /var/www/html           -> $(SEC_BIN) ;
  !/var/www/html/wp-content/uploads ;
  !/var/www/html/wp-content/cache ;
}

行頭に ! を付けたパスは監視から外れます。アップロードやキャッシュのように日常的に変わる場所を外しておかないと、通知が多すぎて本当に見るべき変化が埋もれます。

編集が終わったら署名済みポリシーを作り直します。

sudo twadmin --create-polfile -S /etc/tripwire/site.key /etc/tripwire/twpol.txt

データベースを初期化する

初期化は「今のファイルの状態が正しい」と記録する作業です。侵入された後のサーバーで初期化すると、改ざんされた状態を正しいものとして覚えてしまいます。OS を入れた直後や、パッケージの検証を済ませた後に行ってください。Debian 系なら debsums パッケージの sudo debsums -s で、パッケージから入れたファイルが配布時と同じかを確かめられます。

sudo tripwire --init

ローカル鍵のパスフレーズを入力すると、/var/lib/tripwire/<ホスト名>.twd にデータベースが作られ、最後に「The database was successfully generated.」と表示されます。「No such file or directory」が残っていれば、ポリシーの該当行を直して署名と初期化をやり直します。

チェックを実行してレポートを読む

sudo tripwire --check

結果は画面に出るほか、/var/lib/tripwire/report/<ホスト名>-日付-時刻.twr に保存されます。レポートはそのままでは読めないので、twprint で表示します。

sudo ls -t /var/lib/tripwire/report/
sudo twprint --print-report --twrfile /var/lib/tripwire/report/ホスト名-20261110-020001.twr

レポートでは、ルールごとに Added(追加)、Removed(削除)、Modified(変更)の件数が並び、続いて対象のパスと、変わった属性(サイズ、ハッシュ、更新日時など)が表示されます。特定のルールだけ確かめたいときは sudo tripwire --check --rule-name "Web server config"、特定のファイルだけなら sudo tripwire --check /etc/passwd のように指定できます。

変化を見つけたら、次の順で確かめると判断しやすくなります。

  1. パッケージの更新や設定変更など、自分たちの作業で説明できるか(/var/log/apt/history.log や作業記録と照らす)
  2. 説明できない追加ファイル、特に実行ファイルやスクリプトが無いか
  3. /etc/passwd、/etc/shadow、/etc/ssh/sshd_config、cron の設定など、侵入後に書き換えられやすいファイルに変化が無いか

毎日のチェックとメール通知

Debian/Ubuntu のパッケージは /etc/cron.daily/tripwire を置き、毎日次のコマンドを実行します。自分で crontab に追加する必要はありません。

/usr/sbin/tripwire --check --quiet --email-report

--email-report の送信先は、ポリシーのルールに書いた emailto です。すべての結果を1つのアドレスに送りたい場合は、twcfg.txt に GLOBALEMAIL を追加します。既定の送信方法は MAILMETHOD=SMTP、送信先サーバーは SMTPHOST=localhost、SMTPPORT=25 なので、サーバー上でメールを送れる状態(Postfix など)にしておく必要があります。

GLOBALEMAIL   =admin@example.com

twcfg.txt を変えたら署名し直し、テストメールで届くか確かめます。

sudo twadmin --create-cfgfile -S /etc/tripwire/site.key /etc/tripwire/twcfg.txt
sudo tripwire --test --email admin@example.com

既定では MAILNOVIOLATIONS=true のため、変化が無い日も結果が届きます。届かない日があれば、Tripwire かメール送信のどちらかが止まっている合図として使えます。

更新したらデータベースも更新する

apt upgrade などで正当な変更をした後は、次のチェックで大量の変化が報告されます。内容を確かめたうえで、そのレポートを使ってデータベースを更新します。

sudo tripwire --check
sudo tripwire --update --twrfile /var/lib/tripwire/report/最新のファイル名.twr

--update を実行するとエディタでレポートが開き、受け入れる変更の行に [x] が付いています。受け入れたくない変更は x を消して保存し、ローカル鍵のパスフレーズを入力するとデータベースが更新されます。すべてを確認なしで受け入れる --accept-all もありますが、作業と関係ない変化が混ざっていないかを見る機会を失うので、日常の運用ではエディタで確かめる方法をおすすめします。

監視対象を変えたいときは、twpol.txt を編集してから次のコマンドでポリシーを入れ替えます。サイト鍵とローカル鍵の両方のパスフレーズを求められます。

sudo tripwire --update-policy /etc/tripwire/twpol.txt

運用上の注意

  • Tripwire 本体、データベース、鍵が同じサーバーにあるため、root を奪われると書き換えられるおそれがあります。初期化直後のデータベースと署名済みポリシー、鍵を、サーバーの外(読み取り専用の媒体や別のサーバー)にも保管しておくと、照合の基準を守れます。
  • 変化を見つけた後の復旧は、バックアップと再インストールで行います。Tripwire は検知までの道具です。
  • 似た役割の AIDE は、RHEL 系では標準のリポジトリ(AppStream)から入れられます。ディストリビューションの標準に合わせて選ぶのも一つの方法です。
  • ルートキットの検査には別の道具を組み合わせます。rkhunterでルートキットを検出する方法も参考にしてください。

まとめ

  • Tripwire は署名済みの tw.cfg と tw.pol を読むため、テキスト版を編集したら twadmin で署名し直します
  • 既定のポリシーは存在しないパスを含むので、コメントアウトしてから初期化します
  • 初期化は改ざんされていないと確かめた状態で行います
  • Debian/Ubuntu では /etc/cron.daily/tripwire が毎日チェックし、emailto または GLOBALEMAIL の宛先に結果を送ります
  • 正当な変更の後は、レポートを確かめてから tripwire --update でデータベースを更新します

お気軽にご相談ください

お見積りへ お問い合わせへ
▲