テクノロジーガイド

Ubuntu 16.04でTripwireをインストール・設定

3 min read システム管理 更新されました 21 Oct 2025
Ubuntu 16.04でTripwireをインストール・設定
Ubuntu 16.04でTripwireをインストール・設定

この記事で行うこと

  • Tripwireのインストール
  • Ubuntu向けTripwireポリシーの設定と再生成
  • Tripwire動作の検証(手動チェック)
  • 新しいルール(例:WordPress用)の追加
  • 通知設定(メール)とcronによる自動実行の設定

前提条件

  • Ubuntu 16.04 サーバ
  • root 権限またはsudoが使えるアカウント

重要: Ubuntu 16.04は公式サポートが終了しています。可能であればサポート版(例: Ubuntu LTSの最新)への移行を検討してください。移行時はTripwireのパッケージ互換性と設定ファイルの差分を確認してください。

Tripwireとは(ワンライン定義)

Tripwireはファイルシステムの整合性を監視するホスト型IDSです。重要ファイルの変更、追加、削除を検出して報告します。


ステップ 1 — Tripwire のインストール

公式リポジトリからインストールします。パッケージ更新とインストールは以下の通りです。

sudo apt update  
sudo apt install -y tripwire

インストール中にPostfixのSMTP設定画面が表示されます。通常は「Internet Site」を選択してOKを押し、メール送信に必要な基本設定を行います。

Postfix SMTP 設定画面(Internet Site を選択)

メールシステム名(system mail name)はデフォルトのままで進めることが一般的です。

システムのメール名を設定する画面

次にTripwireの初期設定ウィザードが実行されます。まずsite-key(サイト鍵)を作成するか聞かれるので「Yes」を選択します。

Tripwire の site-key 作成を確認する画面

続けてlocal-key(ローカル鍵)についても「Yes」を選択します。

Tripwire の local-key 作成を確認する画面

Rebuild Tripwire Configuration と Rebuild Tripwire Policy も通常「Yes」で進めます。

Tripwire 構成の再作成確認画面

Tripwire ポリシーの再作成確認画面

site-key と local-key のパスフレーズをそれぞれ入力します(確認入力有り)。

site-key のパスフレーズ入力画面

site-key のパスフレーズ再入力画面

local-key のパスフレーズ入力画面

local-key のパスフレーズ再入力画面

これでTripwireのインストールは完了です。


ステップ 2 — Tripwire ポリシーをUbuntu向けに調整

Tripwire関連の設定は /etc/tripwire に格納されています。インストール後、最初にデータベースを初期化します。

sudo tripwire --init

local-key のパスフレーズを入力してください。存在しないディレクトリがあると「No such directory」といったエラーが出ることがあります。

初期化時のディレクトリが無い旨のエラー表示

存在しないファイル/ディレクトリの特定

エラーを解決するには、まずどのパスが無いかを確認します。

sudo sh -c "tripwire --check | grep Filename > no-directory.txt"
cat no-directory.txt

存在しないパス一覧を表示した例

ポリシーテキストの編集

/etc/tripwire/twpol.txt を編集して存在しないパスをコメントアウトまたは調整します。

cd /etc/tripwire/
vim twpol.txt

以下はよく調整する箇所の例です。

  • Boot Scripts ルールでは /etc/rc.boot のように環境依存で存在しないエントリをコメントアウトする。
(  
  rulename = "Boot Scripts",  
  severity = $(SIG_HI)  
)  
{  
        /etc/init.d             -> $(SEC_BIN) ;  
        #/etc/rc.boot           -> $(SEC_BIN) ;  
        /etc/rcS.d              -> $(SEC_BIN) ;
  • System Boot Changes で /var/run や /var/lock などが存在しない環境ではコメント化。
(  
  rulename = "System boot changes",  
  severity = $(SIG_HI)  
)  
{  
        #/var/lock               -> $(SEC_CONFIG) ;  
        #/var/run                -> $(SEC_CONFIG) ; # daemon PIDs  
        /var/log                -> $(SEC_CONFIG) ;
  • Root config files ではユーザ固有のファイルを必要に応じて有効化/無効化します。
(  
  rulename = "Root config files",  
  severity = 100  
)  
{  
        /root                           -> $(SEC_CRIT) ; # Catch all additions to /root  
        #/root/mail                     -> $(SEC_CONFIG) ;  
        /root/.bashrc                   -> $(SEC_CONFIG) ;  
        /root/.bash_history             -> $(SEC_CONFIG) ;
  • デバイスおよび/proc の監視では動的に変化するエントリを除外します。
(  
  rulename = "Devices & Kernel information",  
  severity = $(SIG_HI),  
)  
{  
        /dev            -> $(Device) ;  
        /dev/pts        -> $(Device);  
        /dev/shm        -> $(Device);  
        /dev/hugepages  -> $(Device);  
        /dev/mqueue     -> $(Device);  
        #/proc          -> $(Device) ;  
        /proc/devices           -> $(Device) ;
        /proc/net               -> $(Device) ;
        /proc/tty               -> $(Device) ;
        /proc/cpuinfo           -> $(Device) ;
        /proc/modules           -> $(Device) ;
        /proc/mounts            -> $(Device) ;
        /proc/dma               -> $(Device) ;
        /proc/filesystems       -> $(Device) ;
        /proc/interrupts        -> $(Device) ;
        /proc/ioports           -> $(Device) ;
        /proc/scsi              -> $(Device) ;
        /proc/kcore             -> $(Device) ;
        /proc/self              -> $(Device) ;
        /proc/kmsg              -> $(Device) ;
        /proc/stat              -> $(Device) ;
        /proc/loadavg           -> $(Device) ;
        /proc/uptime            -> $(Device) ;
        /proc/locks             -> $(Device) ;
        /proc/meminfo           -> $(Device) ;
        /proc/misc              -> $(Device) ;
}

編集後は、暗号化されたポリシーファイルを再生成します。

sudo twadmin -m P /etc/tripwire/twpol.txt

site-key のパスフレーズを入力してください。続けてデータベースを再初期化します。

sudo tripwire --init

local-key のパスフレーズを入力し、エラーが出ないことを確認します。

トリプワイヤのデータベース再初期化完了の例

これでUbuntu向けのTripwireポリシーの基本設定は完了です。


ステップ 3 — システムファイルの整合性をチェック

ポリシー更新後、手動でシステムをチェックして結果を確認します。

sudo tripwire --check

正常ならば出力に “No Violation” と “No Error” が表示されます。

tripwire スキャン実行例(違反なし)

試験としてルートディレクトリにファイルを作成し、変更が検出されるか確かめます。

cd ~/  
touch hakase-labs.txt

もう一度チェックを実行します。

sudo tripwire --check

追加ファイルと、ファイルが置かれたディレクトリの変更が検出され、Violationが報告されます。

Tripwire スキャン結果(ファイル追加の検出例)


ステップ 4 — 新しいルールを追加する

本節では、/var/www 下(例:WordPressファイル)を厳格に監視するルールを追加します。

cd /etc/tripwire/  
vim twpol.txt

ファイル末尾などに以下のルールを追加します。

# Ruleset for Wordpress  
(  
  rulename = "Wordpress Ruleset",  
  severity= $(SIG_HI)  
)  
{  
        /var/www        -> $(SEC_CRIT);  
}

保存して終了後、ポリシーを再生成します。

sudo twadmin -m P /etc/tripwire/twpol.txt

site-key のパスフレーズを入力し、続けてデータベース再初期化を行います。

sudo tripwire --init

local-key のパスフレーズを入力してください。

Tripwire に新ルールを追加した例

ルール追加後、/var/www/ 下にファイルを作成・変更して検出されるか確認します。

cd /var/www/  
touch hakase-labs.txt  
echo "

Hakase-labs Tutorial

" > html/index.nginx-debian.html sudo tripwire --check

Severity 100 の違反が報告されるはずです。

Tripwire 違反検出の例(/var/www)


ステップ 5 — 通知とcronの設定

Tripwireはポリシー内で emailto を指定すると、違反検出時に通知先へメールを送信できます。Postfixはインストール時に基本的なセットアップを行っている想定です。

まず手動テストで通知が機能するかを確認します。

tripwire --test --email [email protected]

サーバーから受信トレイにメールが届くか確認してください。

Tripwire の通知メールを受け取った例

ポリシー内での emailto の設定例

cd /etc/tripwire/  
vim twpol.txt

Wordpressルール内に emailto 指定を追加します。

# Rules for Web-app  
(  
  rulename = "Wordpress Rule",  
  severity = $(SIG_HI),  
  emailto = [email protected]  
)

保存後、ポリシー再生成とデータベース再初期化を行います。

sudo twadmin -m P /etc/tripwire/twpol.txt  
sudo tripwire --init

site-key と local-key のパスフレーズを順に入力します。

手動で検出とメール送信を試すには以下を実行します。

sudo tripwire --check --email-report

受信トレイにレポートが届くはずです。

Tripwire のメールレポート例

cron による自動実行

日次でチェックしてメール送信する例です。

sudo crontab -e -u root

以下を追加します。

0 0 * * * tripwire --check --email-report

保存後、cron を再読み込みします。

systemctl restart cron

crontab 編集画面の例

これで毎日0時にTripwireが実行され、検出があればメールで通知されます。

crontab 保存後の確認画面


運用上の注意(重要)

  • site-key と local-key のパスフレーズは安全に保管してください。紛失するとポリシー再生成やデータベースの復旧に支障が出ます。
  • 初期ポリシーは監視対象が広範なので、誤検知(False Positive)を減らすために環境に合わせて調整してください。
  • 動的ファイル(/proc、/dev、/var/run など)は基本的に除外または低シグニチャとして扱います。

トラブルシューティングとよくある問題

  1. “No such directory” エラー

    • 原因: twpol.txt に指定されたパスが存在しない。
    • 対応: 該当エントリをコメントアウトするか、ディレクトリを作成してから twadmin/twinit を再実行する。
  2. メールが届かない

    • 原因: Postfix の設定不備、ファイアウォール、SPF/DKIM、宛先メールサーバの受信拒否。
    • 対応: /var/log/mail.log を確認し、Postfix のキューや送信エラーを調査する。ローカル送信であればまず /var/log/mail.log を確認。
  3. ルール追加後に検出が出ない

    • 原因: ポリシー再生成(twadmin)や tripwire –init を忘れている可能性。
    • 対応: twadmin -m P と tripwire –init を順に実行し、パスフレーズを正しく入力する。
  4. 権限関連でチェックが不完全

    • 原因: tripwire が必要なファイルを読み取れない。
    • 対応: tripwire はrootでの実行を前提にしているため、cronや手動実行はrootで行う。ファイルシステムの権限を確認する。

運用ガイド(SOP)

目的: Tripwireでファイル改変を継続監視し、違反発生時に速やかに対応する。

手順(短縮版):

  1. 週次でポリシー差分を確認する。
  2. 重大な違反(SEC_CRIT, severity >= SIG_HI)が通知されたら直ちに調査チケットを作成する。
  3. 調査ではまず最近の変更ログ、誰が、いつ、どのプロセスで変更したかを特定する。
  4. 正当な変更ならポリシーを更新してホワイトリスト化する。
  5. 不正な変更ならバックアップから復旧し、侵入経路の調査(ログ、ネットワーク接続、ユーザ権限)を行う。

受け入れ基準(Критерии приёмки):

  • 毎日の自動チェックが正常に動作しており、メールレポートが送信されること。
  • 既知の変更(意図的なデプロイ等)が検出された場合、手順に従いポリシーを更新できること。

インシデント対応ランブック(簡易)

  1. 通知受領: メールの件名と対象パスを確認。
  2. 初期確認: tripwire –check のログを取得し、変更内容(追加/削除/変更)を把握する。
  3. 影響範囲特定: 変更されたバイナリや設定ファイルの依存関係を確認する。
  4. 取り急ぎ対応: 変更をそのまま放置せず、必要ならサービス停止とロールバックを実施。
  5. 根本原因分析: 誰がどの鍵でアクセスしたか、CRON/スクリプト/管理者操作などをログから調査。
  6. 再発防止: アクセス制御の見直し、パッチ適用、ポリシーの調整。
  7. 文書化: 事象、対応、教訓を記録し次回に備える。

テストケース(受け入れ試験例)

  • ケースA: 新規ファイル作成(/var/www/test.txt)→ Tripwireが追加を検出し、メール送信が行われる。
  • ケースB: 既存ファイルの内容変更(index.htmlの書き換え)→ Tripwireが変更を検出する。
  • ケースC: 動的ファイルを作成(/proc系)→ 誤検出が発生しない(ポリシーで除外されていること)。
  • ケースD: twpol.txt を変更して twadmin/twinit を忘れる → 変更が反映されないことを確認。

役割別チェックリスト(運用時)

管理者:

  • site-key/local-key を安全に保管する。
  • ポリシー変更時は必ず twadmin と tripwire –init を実行する。

オペレーター:

  • 日次のメールを確認し、未解決のアラートがある場合はエスカレーションする。
  • 定期的にno-directoryリストをチェックして環境差異を吸収する。

セキュリティチーム:

  • 高重大度の違反に対してはすぐにインシデントレスポンスを開始する。
  • ログと検出証拠を保全する。

セキュリティ強化のヒント

  • Tripwire構成ファイル(/etc/tripwire/)自体の監視を検討してください。設定ファイルの改変は重大です。
  • Tripwireの実行はrootで行いますが、鍵ファイルへのアクセスは最小権限に制限してください。
  • OSのセキュリティ強化(最新パッチ適用、不要サービス停止、ファイアウォール設定)を併用してください。
  • ログ集約(syslog/nginxログ/Tripwireレポート)をSIEMに送ると相関分析で強化できます。

互換性と移行メモ

  • Ubuntu 16.04 のサポート終了を踏まえ、可能であればUbuntu LTSの最新版へ移行してください。
  • 移行時はTwpol.txtの差分、twcfgの鍵管理、パッケージバージョン(tripwire-open-source等)を比較・検証すること。
  • Snapや新しいパッケージ管理の影響、AppArmor/SELinux設定の違いに注意してください。

よく使うコマンド一覧(チートシート)

  • パッケージインストール: sudo apt install -y tripwire
  • ポリシー生成: sudo twadmin -m P /etc/tripwire/twpol.txt
  • データベース初期化: sudo tripwire –init
  • 手動チェック: sudo tripwire –check
  • メール付きチェック: sudo tripwire –check –email-report
  • テストメール: tripwire –test –email [email protected]

用語集(1行ずつ)

  • site-key: Tripwireポリシーを暗号化するための共通鍵。
  • local-key: 各ホストで使われるローカル鍵。
  • twpol.txt: Tripwireのテキスト形式ポリシー定義ファイル。
  • twadmin: ポリシーを暗号化してバイナリ形式に変換するユーティリティ。

まとめ

  • Tripwireはファイルシステムの改変を検知する強力なホスト型IDSです。
  • Ubuntu 16.04にインストールし、twpol.txtを環境に合わせて編集すれば、重要ディレクトリを監視できます。
  • 通知やcronを設定することで定常運用が可能です。

重要: 16.04はEOLのため、長期運用ならOSのアップグレードを強く推奨します。


参考

共有する: X/Twitter Facebook LinkedIn Telegram
著者
編集

類似の素材

Debian 11 に Podman をインストールして使う
コンテナ

Debian 11 に Podman をインストールして使う

Apt-pinning入門:Debianで複数リポジトリを管理
Linux

Apt-pinning入門:Debianで複数リポジトリを管理

OptiScalerでFSR 4を全対応ゲームに導入する方法
ゲーム

OptiScalerでFSR 4を全対応ゲームに導入する方法

Dansguardian と Squid(NTLM)を Debian Etch に導入する方法
ネットワーク

Dansguardian と Squid(NTLM)を Debian Etch に導入する方法

AndroidでSDカードのインストールエラーを修正する方法
トラブルシューティング

AndroidでSDカードのインストールエラーを修正する方法

KNetAttach と KDE の remote:/ でネットワークフォルダーを設定
Linux ネットワーク

KNetAttach と KDE の remote:/ でネットワークフォルダーを設定