2026年5月27日

Tripwireでファイル改ざんを検知する方法（WordPressサーバー向けのポリシー調整と運用）

サーバーセキュリティ・SSL

Tripwire は、ファイルのハッシュや属性を「正しい状態」としてデータベースに記録し、後から照合して変化を報告するツールです。WordPress サーバーで使うなら、コア・プラグイン・テーマ・wp-config.php のように本来変わらない場所を監視対象にし、アップロードやキャッシュのように日常的に変わる場所を外すことが、通知を読める量に抑える鍵になります。この記事では、Ubuntu／Debian に Open Source Tripwire を入れ、WordPress 向けにポリシーを調整し、更新のたびにデータベースを更新する運用までを説明します。

Tripwire でできること・できないこと

Tripwire は「変わったこと」を見つける道具で、「何が悪意のある変更か」を判断する道具ではありません。プラグインの更新でファイルが変わっても、攻撃者がバックドアを置いても、どちらも同じく「変更あり」と報告されます。そのため、変更を見たときに「自分たちの作業によるものか」を説明できる運用（更新日時の記録、作業ログ）とセットで使うことが前提です。

また、Tripwire は改ざんを防ぐものではなく、検知した後の復旧はバックアップと再インストールで行います。マルウェアの侵入経路を塞ぐ対策（更新の適用、不要なプラグインの削除、ログイン保護）とは役割が違う点を押さえておきましょう。

なお、Tripwire には商用製品と、GitHub で公開されている Open Source Tripwire があります。本記事は後者を対象にしています。オープンソース版の更新頻度は高くないため、導入前にディストリビューションのパッケージが提供されているか確認してください。Debian／Ubuntu では公式リポジトリに tripwire パッケージがあり、RHEL 系では EPEL から入れる形が一般的です（2026年10月現在）。似た用途のツールとして AIDE もあり、こちらを選ぶ運用も広く見られます。

インストールと鍵の作成

Ubuntu／Debian では apt で入れます。

sudo apt update
sudo apt install tripwire

インストール中に、サイト鍵とローカル鍵のパスフレーズを作るか、設定ファイルとポリシーファイルを作り直すかを尋ねられます。ここで鍵を作っておくと、/etc/tripwire/ に次のファイルがそろいます。

site.key：ポリシーと設定ファイルの署名に使う鍵
<ホスト名>-local.key：データベースとレポートの署名に使う鍵
twcfg.txt と tw.cfg：設定（テキスト版と署名済みの版）
twpol.txt と tw.pol：監視ポリシー（テキスト版と署名済みの版）

Tripwire が実際に読むのは署名済みの tw.cfg と tw.pol です。テキスト版を編集しただけでは反映されず、後述の手順で署名し直す必要があります。ここが最初につまずきやすいポイントです。

パスフレーズはサーバー上に保存せず、パスワードマネージャーなど別の場所で管理します。サーバーを乗っ取った攻撃者がパスフレーズを知っていれば、データベースを作り直して痕跡を消せてしまうからです。

インストール時に鍵を作らなかった場合は、twadmin で後から作れます。

sudo twadmin --generate-keys --site-keyfile /etc/tripwire/site.key
sudo twadmin --generate-keys --local-keyfile /etc/tripwire/$(hostname)-local.key

WordPress 向けにポリシーを調整する

既定の twpol.txt は OS 全体の主要ファイルを監視する内容で、環境に存在しないファイルが多く含まれています。そのまま初期化すると「No such file or directory」の警告が大量に出るため、まず不要な行をコメントアウトします。編集前に元のファイルをコピーしておくと、戻したいときに困りません。

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

次に、WordPress 用のルールを末尾に追加します。SEC_BIN や SIG_HI は既定のポリシー冒頭で定義されている変数で、SEC_BIN はハッシュやサイズ、更新日時の変化を検知する設定です。ドキュメントルートは環境に合わせて書き換えてください。

WPROOT = /var/www/html ;

(
  rulename = "WordPress code",
  severity = $(SIG_HI)
)
{
  $(WPROOT)/wp-admin              -> $(SEC_BIN) ;
  $(WPROOT)/wp-includes           -> $(SEC_BIN) ;
  $(WPROOT)/index.php             -> $(SEC_BIN) ;
  $(WPROOT)/wp-config.php         -> $(SEC_BIN) ;
  $(WPROOT)/.htaccess             -> $(SEC_BIN) ;
  $(WPROOT)/wp-content/plugins    -> $(SEC_BIN) ;
  $(WPROOT)/wp-content/themes     -> $(SEC_BIN) ;
  $(WPROOT)/wp-content/mu-plugins -> $(SEC_BIN) ;
}

wp-content/uploads、wp-content/cache、wp-content/upgrade はあえて含めていません。これらは通常の運用で毎日のように変わるため、監視すると本当に見るべき変更が通知に埋もれてしまいます。プラグインが自分のディレクトリ内にログやキャッシュを書き込む場合は、!$(WPROOT)/wp-content/plugins/プラグイン名/cache ; のように先頭に ! を付けた行で除外できます。また、キャッシュ系やセキュリティ系のプラグインは .htaccess を書き換えることがあるので、その場合の通知は想定内として扱います。

アップロードディレクトリを監視から外す代わりに、そこに PHP ファイルが置かれていないかを別に確認すると、よくある手口を拾えます。

sudo find /var/www/html/wp-content/uploads -type f -name "*.php"

通常、uploads に PHP ファイルが置かれることはほぼありません。見つかった場合は内容を確認し、心当たりがなければ調査対象にします。

ポリシーを署名してデータベースを初期化する

編集したポリシーを署名済みファイルに変換し、現在の状態をデータベースに記録します。初期化は「この時点のファイルが正しい」と宣言する作業なので、WordPress のコアやプラグインが改ざんされていないことを先に確認してから行ってください。WP-CLI が使えるなら、wp core verify-checksums と wp plugin verify-checksums --all で公式配布物と照合できます（公式ディレクトリ外の有料プラグインなどは照合できません）。

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

途中でサイト鍵とローカル鍵のパスフレーズを求められます。初期化後、データベースは /var/lib/tripwire/ に作られます。警告が残る場合は、該当するパスをポリシーから外すか修正し、署名と初期化をやり直します。

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

手動でチェックするには次のコマンドを使います。

sudo tripwire --check

結果は画面に表示されるほか、/var/lib/tripwire/report/ に .twr ファイルとして保存されます。後から読み直すときは twprint を使います。

sudo twprint --print-report --twrfile /var/lib/tripwire/report/ファイル名.twr

レポートでは、ルールごとに「Added（追加）」「Removed（削除）」「Modified（変更）」の件数と対象パスが並びます。読むときは次の順で確認すると判断しやすくなります。

変更があったのは、最近更新したプラグインやテーマか
追加されたファイルに、見覚えのない PHP ファイルや不自然な名前のファイルがないか
wp-config.php、index.php、.htaccess の変更が自分たちの作業で説明できるか

説明できない変更が見つかったら、そのファイルの内容とサーバーのアクセスログを確認し、必要に応じてバックアップから復旧します。

定期実行と通知

Debian／Ubuntu のパッケージでは、日次のチェックを行う cron スクリプトが用意されていることが多いです（/etc/cron.daily/ を確認してください）。結果をメールで受け取るには、twcfg.txt のメール送信設定（MAILMETHOD など）がサーバーの環境に合っているか確認し、テストメールを送ります。

sudo tripwire --test --email admin@example.com

twcfg.txt を編集した場合は、twadmin --create-cfgfile -S /etc/tripwire/site.key /etc/tripwire/twcfg.txt で署名し直すまで反映されません。通知が届かない場合は、メールの送信自体ができているか（MTA の設定や送信制限）を先に疑います。

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

WordPress の運用で手間がかかるのはこの部分です。コアやプラグインを更新すると次回のチェックで大量の変更が報告されるので、変更を確認したうえで「これが新しい正しい状態」としてデータベースを更新します。

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

--update を実行するとエディタでレポートが開き、受け入れる変更に印が付いた状態で表示されます。内容を確認して保存すると、ローカル鍵のパスフレーズを求められ、データベースが更新されます。すべてを機械的に受け入れるのではなく、更新したプラグイン以外の変更が混ざっていないかをこの時点で見るのが大切です。

自動更新を有効にしているサイトでは、更新のたびに通知が来ることになります。運用負荷が大きい場合は、自動更新の時間帯を決めて直後にチェックと更新を行う、あるいはプラグインの自動更新を手動に切り替えるなど、更新とデータベース更新の手順をそろえると管理しやすくなります。ポリシー自体を変えたいときは sudo tripwire --update-policy /etc/tripwire/twpol.txt を使います。

まとめ

Tripwire は「変わったこと」を記録・報告するツールで、変更が正当かどうかは作業記録と照らして人が判断します
WordPress ではコア、プラグイン、テーマ、wp-config.php を監視し、uploads やキャッシュは外して、uploads 内の PHP ファイルは別の方法で確認します
テキスト版のポリシーや設定は、twadmin で署名し直すまで反映されません
初期化の前にチェックサム照合で正しい状態を確認し、更新後はレポートを確認してからデータベースを更新します
パスフレーズはサーバーの外で管理し、検知後の復旧に備えてバックアップを用意しておきます