2026年9月24日

Tripwire でファイルの改ざんを検知する方法｜ポリシーの書き方・WordPress の PHP ファイルを監視する設定・日々の運用

Q: 初期化のたびに File system error が出ます

Debian / Ubuntu の既定ポリシーに、そのサーバーに無いファイルが含まれているためです。twpol.txt の該当行を # でコメントアウトして --create-polfile と --init をやり直すと消えます。

Q: WordPress を更新したら数百件の Modified が出ました

正常です。自分の更新作業による変更だと確認したら、その報告書を指定して tripwire --update で基準に取り込みます。取り込まずに放置すると、次回以降も同じ件数が出続けて、本当の改ざんが見つけにくくなります。

Q: 共用サーバーでも使えますか

root 権限が必要なので、共用のレンタルサーバーでは使えません。WP-CLI が使えるなら wp core verify-checksums で本体の改ざんを確認できます。使えない場合はファイル変更を検知するプラグインを利用してください。

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

Tripwire でファイルの改ざんを検知するには、監視したいディレクトリとチェックする属性をポリシーファイルに書き、基準となるデータベースを作ってから、定期的に現在の状態と比べるという流れになります。WordPress のサーバーなら、コアとテーマ・プラグインの PHP ファイルを「変わらないはずのもの」として登録し、画像の保存先やキャッシュのように日々変わる場所を除外するのが要点です。

結論を先にまとめます。

Tripwire は「正常な状態の記録」と「今の状態」を比べて差分を報告する道具で、マルウェアの検出や駆除をするものではありません。改ざんに気づく時間を短くするために使います。
導入の手順は、インストール → 鍵（site key / local key）の作成 → ポリシーの編集 → tripwire --init で基準データベースの作成 → tripwire --check の定期実行、の 5 段階です。
WordPress の更新やプラグインの更新で正しくファイルが変わったときは、tripwire --update で基準を更新します。これを怠ると報告が「変更あり」で埋まり、本当の改ざんが埋もれます。
ポリシーは /etc/tripwire/twpol.txt を編集し、twadmin --create-polfile で署名付きの tw.pol に変換してから使います。

Tripwire 導入の 5 段階。インストールと鍵の作成、ポリシーの編集、基準データベースの初期化、定期チェック、正しい変更後の更新

Tripwire とは

Tripwire とは、ファイルやディレクトリの属性（ハッシュ値、サイズ、権限、所有者、更新時刻など）を記録しておき、後で同じ属性を取り直して比べることで変更を見つける「ファイル整合性監視（File Integrity Monitoring）」のソフトウェアです。ここで扱うのは、Debian / Ubuntu の tripwire パッケージや RHEL 系の EPEL で配布されている Open Source Tripwire です（商用版の Tripwire Enterprise とは別の製品です）。

同じ目的の道具に AIDE（Advanced Intrusion Detection Environment）があります。AIDE は設定が 1 つの平文ファイルで済み、鍵の管理がない分だけ導入は軽いです。Tripwire は設定ファイル・ポリシー・データベース・報告書を鍵で署名するため、サーバーに入り込んだ側が監視の設定そのものを書き換えることが難しくなります。どちらを選んでも、WordPress の監視に必要な考え方（何を見て、何を除外するか）は同じです。

項目	Open Source Tripwire	AIDE
設定の署名	site key / local key で署名	なし（ファイルの権限で保護）
設定ファイル	`twcfg.txt` と `twpol.txt`（署名して `tw.cfg` / `tw.pol`）	`aide.conf` の 1 つ
基準の更新	`tripwire --update` で報告書を見ながら反映	`aide --update` で新しいデータベースを作って差し替え
向く場面	設定の改ざんも疑う本番サーバー	手早く導入したい、鍵の管理を避けたい

手順 1: インストールと鍵の作成

Debian / Ubuntu では apt で入ります。インストール中に site passphrase と local passphrase を聞かれます。site key は設定ファイルとポリシーの署名に、local key はデータベースと報告書の署名に使います。パスフレーズは後の操作で毎回使うので、パスワード管理ツールに控えてください。

sudo apt update
sudo apt install tripwire

RHEL 系（AlmaLinux / Rocky Linux）では EPEL を有効にしてからインストールし、鍵は twadmin で作ります。

sudo dnf install epel-release
sudo dnf install tripwire
sudo twadmin --generate-keys -S /etc/tripwire/site.key -L /etc/tripwire/local.key

鍵の作成後、平文の設定ファイルを署名付きに変換します（Debian / Ubuntu のパッケージはインストール時に済ませてくれます）。

sudo twadmin --create-cfgfile -S /etc/tripwire/site.key /etc/tripwire/twcfg.txt

手順 2: ポリシーファイルの書き方

ポリシーは /etc/tripwire/twpol.txt に平文で書きます。1 つの規則は「対象のパス -> 調べる属性のマスク;」の形で、ディレクトリを書くとその下すべてが対象になります。属性は 1 文字ずつの記号で、+ が「調べる」、- が「調べない」です。よく使うものを挙げます。

記号	意味
`p` / `u` / `g`	権限 / 所有ユーザー / 所有グループ
`s` / `t` / `n`	サイズ / ファイル種別 / リンク数
`m` / `c` / `a`	更新時刻 / inode 変更時刻 / アクセス時刻
`i` / `d` / `b`	inode 番号 / デバイス番号 / 使用ブロック数
`C` / `M` / `S` / `H`	CRC-32 / MD5 / SHA / Haval のハッシュ

毎回記号を並べる代わりに、あらかじめ定義された変数が使えます。

変数	用途
`$(ReadOnly)`	変わらないはずのファイル。ほぼすべての属性を調べる
`$(Dynamic)`	内容が変わることが前提のファイル。サイズや時刻の変化は無視
`$(Growing)`	ログのように増え続けるファイル。サイズの増加は許す
`$(IgnoreAll)`	存在するかどうかだけを見る
`$(IgnoreNone)`	すべてを調べる。`$(IgnoreNone) -ar` のように引いて使う

規則の後ろの括弧には、報告書で見分けるための名前（rulename）、重大度（severity、0〜1,000,000）、通知先（emailto）、深さ（recurse）を付けられます。先頭に ! を付けたパスは監視から外れます（stop point）。

WordPress 向けの例

WordPress のディレクトリが /var/www/html だとして、コアとテーマ・プラグインの PHP を $(ReadOnly) で監視し、アップロード先とキャッシュを除外する規則を追加します。既定のポリシーに付け足す形で書きます。

# WordPress（/var/www/html）
WPROOT = /var/www/html ;

(
  rulename = "WordPress core and code",
  severity = 100,
  emailto  = "admin@example.com"
)
{
  $(WPROOT)/wp-admin            -> $(ReadOnly) ;
  $(WPROOT)/wp-includes         -> $(ReadOnly) ;
  $(WPROOT)/wp-content/themes   -> $(ReadOnly) ;
  $(WPROOT)/wp-content/plugins  -> $(ReadOnly) ;
  $(WPROOT)/wp-config.php       -> $(ReadOnly) ;
  $(WPROOT)/index.php           -> $(ReadOnly) ;
  $(WPROOT)/.htaccess           -> $(ReadOnly) ;

  # 日々変わる場所は除外（ここに PHP が現れたら別の手段で見る）
  !$(WPROOT)/wp-content/uploads ;
  !$(WPROOT)/wp-content/cache ;
  !$(WPROOT)/wp-content/upgrade ;
  !$(WPROOT)/wp-content/debug.log ;
}

wp-content/uploads を除外するのは、画像の追加で毎日報告が出てしまうためです。ただし改ざんでは uploads に PHP が置かれることが多いので、こちらは「uploads で PHP の実行を禁止する」Web サーバー側の設定で守ります（ファイルパーミッションとセキュリティの記事を参照）。

Debian / Ubuntu の既定ポリシーには、そのサーバーに存在しないファイル（別の起動方式のものなど）が含まれていて、初期化のたびに「File system error」が並びます。最初の --init の出力を見て、無いファイルの行は # でコメントアウトしてください。

平文のポリシーを書き終えたら、署名付きの tw.pol に変換します。

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

手順 3: 基準データベースの初期化

ポリシーに従って、現在の状態を基準としてデータベースに記録します。local passphrase を聞かれます。

sudo tripwire --init

データベースは /var/lib/tripwire/<ホスト名>.twd にできます。この時点のファイルが「正しい状態」として記録されるので、初期化は WordPress を最新に更新し、不要なファイルを片付けた直後に行ってください。すでに改ざんされているファイルを基準にしてしまうと、その改ざんは検知されません。導入前に一度、マルウェアの検出と除去の手順で確認しておくと安全です。

手順 4: 定期チェックと報告書の読み方

チェックは次のコマンドです。

sudo tripwire --check

報告書は画面に出るほか、/var/lib/tripwire/report/<ホスト名>-<日時>.twr に保存されます。保存した報告書を読み直すには twprint を使います。

sudo twprint --print-report --twrfile /var/lib/tripwire/report/<ホスト名>-<日時>.twr

報告書の見方は次のとおりです。

Added: 基準に無かったファイルが増えた。テーマやプラグインの中に見覚えのない PHP が増えていたら要確認です。
Removed: 基準にあったファイルが消えた。
Modified: 内容や属性が変わった。更新作業をしていないのに wp-includes や wp-config.php が Modified なら、改ざんの可能性があります。

Debian / Ubuntu のパッケージは /etc/cron.daily/tripwire を入れるので、日次のチェックは自動で動きます。メールで受け取るには、ポリシーの emailto に加えて --email-report を付けて実行します。

# 送信の試験（ポリシーの emailto の文法は検査しない）
sudo tripwire --test --email admin@example.com
# 定期実行の例（systemd timer か cron に登録）
sudo tripwire --check --email-report

メールの送信元として、サーバーに sendmail 互換のコマンド（Postfix など）か、twcfg.txt の SMTPHOST / SMTPPORT の設定が必要です。

手順 5: 正しい変更の後にデータベースを更新する

WordPress 本体やプラグインを更新すると、大量の Modified が報告されます。自分が行った変更だと確認できたら、その報告書を元にデータベースを更新します。

sudo tripwire --update --twrfile /var/lib/tripwire/report/<ホスト名>-<日時>.twr

エディターが開き、各項目の先頭に [x] が付いた一覧が出ます。基準に取り込む項目は [x] のまま、取り込まない（調べ直したい）項目は [ ] にして保存します。すべて取り込むなら --accept-all を付けます。

ポリシー自体を変えたときは、--update-policy で新しいポリシーを反映します。

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

運用のこつは、「更新作業 → すぐ --check → 報告を確認して --update」を 1 セットにすることです。これを守ると、日次の報告が普段は空に近くなり、何か出たときにすぐ目に付くようになります。

WordPress の運用での位置づけ

Tripwire が向くのは、VPS や専用サーバーで root 権限があり、OS 側の変更も含めて見たい場合です。共用のレンタルサーバーでは Tripwire を入れられないので、同じ目的は WordPress 側のプラグイン（Wordfence のファイル変更検知など）や、wp core verify-checksums と wp plugin verify-checksums を定期実行する方法で代用します。

Tripwire が検知できるのは「ファイルが変わった」ことまでです。データベースに書き込まれた不正なリンクや、管理者アカウントの追加は見えません。改ざんの疑いが出たときの全体の手順はサーバーがハッキングされたときの初動対応とWordPress のハッキング復旧手順にまとめています。

よくある質問

Tripwire と AIDE はどちらを選べばよいですか

鍵の管理まで含めて設定を守りたい本番サーバーなら Tripwire、手早く入れて日次の差分だけ見たいなら AIDE が合います。どちらも「正しい状態を基準にする」「更新後に基準を更新する」という運用は同じなので、使い慣れた方で問題ありません。

初期化のたびに File system error が出ます

Debian / Ubuntu の既定ポリシーに、そのサーバーに無いファイルが含まれているためです。twpol.txt の該当行を # でコメントアウトして --create-polfile と --init をやり直すと消えます。

WordPress を更新したら数百件の Modified が出ました

正常です。自分の更新作業による変更だと確認したら、その報告書を指定して tripwire --update で基準に取り込みます。取り込まずに放置すると、次回以降も同じ件数が出続けて、本当の改ざんが見つけにくくなります。

uploads を除外すると、そこに置かれた不正な PHP は見逃しますか

Tripwire では見逃します。uploads は Web サーバー側で PHP の実行を禁止し、ファイルの追加は WordPress 側のスキャンで補うのが現実的です。find /var/www/html/wp-content/uploads -name "*.php" を日次で実行して、1 件でも出たら通知する方法も有効です。

共用サーバーでも使えますか

root 権限が必要なので、共用のレンタルサーバーでは使えません。WP-CLI が使えるなら wp core verify-checksums で本体の改ざんを確認できます。使えない場合はファイル変更を検知するプラグインを利用してください。

まとめ

Tripwire は「正しい状態」を鍵で署名して記録し、定期チェックで差分を報告する道具です。WordPress では wp-admin・wp-includes・テーマ・プラグイン・wp-config.php を $(ReadOnly) で監視し、uploads と cache を除外します。
手順は、インストールと鍵の作成 → twpol.txt の編集と --create-polfile → --init → 日次の --check → 正しい変更の後の --update です。
初期化は WordPress を更新して不要なファイルを片付けた直後に行い、更新作業のたびに基準を更新する運用を守ると、報告が読みやすくなります。

参考: tripwire(8) マニュアル（Debian）、twpolicy(4) ポリシーファイルの文法、twadmin(8)、Open Source Tripwire（GitHub）

更新履歴: 2026-11-09 全面改訂（定型文の本文を、ポリシーの文法と WordPress 向けの監視規則、初期化・定期チェック・基準更新の運用手順に置き換え）。この記事はワードプレス博士（ライトセンド株式会社）が運営しています。