TripwireとAIDEの併用は危険？Linux改ざん検知の落とし穴と最適な選び方

備忘録

はじめに

Linux環境における改ざん検知は、セキュリティの要とも言える存在だ。
特にTripwireとAIDE、この2つのツールは定番中の定番。

だが、そこに潜む“二重監視”の罠について、誰もがきちんと語ってきただろうか。

この記事では、「Tripwireだけで足りるのか？」という問いに向き合いながら、AIDEを併用した際に起きがちな運用トラブルや誤検知の嵐について掘り下げていく。

スポンサーリンク
スポンサーリンク

Tripwireの“監視力”は本物か？

Tripwireは、ファイルの改ざんや不正な変更をハッシュ値によって検出する堅牢なツールだ。
導入後にポリシーファイルを整え、データベースを初期化すれば、次回からの差分チェックで異常を知らせてくれる。

しかし、Tripwireの弱点は更新作業の煩雑さにある。
OSのアップデートが発生するたびにデータベースの再生成が求められ、意図的な変更と不正な変更の区別がつきにくくなる。

設定ファイル例

設定ファイルはシステム構成に強く依存するため、これらをベースに自環境に最適化したルール構築が肝となる。
また、Tripwireは「ポリシーファイルの変更＝全再構成」になるため、AIDEよりも慎重な設計が求められる点にも注意が必要。

Tripwireの設定ファイル例（twpol.txt の一部）

(
  rulename = "Critical system binaries",
  severity = 100
)
{
  /bin         -> $(SEC_CRIT);
  /sbin        -> $(SEC_CRIT);
  /usr/bin     -> $(SEC_CRIT);
  /usr/sbin    -> $(SEC_CRIT);
}

(
  rulename = "Configuration files",
  severity = 66
)
{
  /etc         -> $(SEC_CONFIG);
}

補足ポイント：

  • $(SEC_CRIT) は twcfg.txt 内のルールプリセット。通常はパーミッション・オーナー・MD5/SHAなどを全て監視。
  • severity はイベント発生時の重要度で、ログ出力時に影響。
  • /var や /tmp のように頻繁に変更されるディレクトリは除外か、別ルールで緩めの監視を行うのが現実的。

Tripwireのログ解析例（tripwire --check 後）

ログ抜粋：

### Warning: File system error.
### Filename: /etc/shadow
### No such file or directory

Modified object name:  /usr/bin/ssh
  Property:            c (inode)
  Expected value:      123456
  Observed value:      987654

解説：

  • /etc/shadow
    → 「存在しない」というエラー。削除された可能性があるが、OS更新や設定変更に伴う一時的な挙動かもしれない。要確認。
  • /usr/bin/ssh
    → inodeが変更されている。ファイルの再インストールまたはバージョン更新時にありがちな変更で、改ざんではなく正規アップデートの可能性が高い。

AIDEを加えれば“完璧”になるのか？

AIDE（Advanced Intrusion Detection Environment）は、Tripwireと同様にファイル改ざん検出を担うが、より軽量かつ柔軟な設定が可能とされる。
特にログファイルのパス除外やタイムスタンプだけの変更に強く、使いやすさの点で評価されている。

だが、AIDEもまた万能ではない。
ディレクトリ単位での監視粒度がTripwireほど細かく設定できない場面もあり、用途次第では「見落とし」が発生することもある。

AIDEの設定ファイル例（aide.conf）

# 定義済みルール
NORMAL = p+i+n+u+g+s+m+c+md5+sha512

# 監視対象のディレクトリとルール
/bin    NORMAL
/sbin   NORMAL
/usr/bin NORMAL
/usr/sbin NORMAL
/etc    NORMAL

# 除外対象（例）
!/var/log/.*  
!/tmp/.*

補足ポイント：

  • NORMAL は定義済みの属性チェックルール（パーミッション、UID/GID、チェックサムなど）。
  • ! は除外対象の指定。ログやキャッシュ、動的に変わるファイルをここに設定することで誤検知を大幅に削減可能。
  • AIDEでは--updateで新しいスナップショットを作成、--checkで整合性を検査。

AIDEのログ解析例（aide --check 後）

ログ抜粋：

AIDE found differences between database and filesystem!!

Summary:
  Total number of files:        25439
  Added files:                  0
  Removed files:                0
  Changed files:                3

Detailed information about changed files:
  Changed: /etc/hostname
  Changed: /etc/machine-id
  Changed: /var/log/syslog

解説：

  • /etc/hostname と /etc/machine-id
    → 仮想マシンの再起動や複製時に書き換わる。これは無視可能なケースが多い。
  • /var/log/syslog
    → ログファイルのタイムスタンプ変更。AIDEでは、mtime だけの変化なら除外するよう設定するのが定石。

併用で強化？それとも監視の衝突？

多くのユーザーが陥るのが、TripwireとAIDEの併用で安心感を得ようとするパターンだ。
確かにツールが複数あれば、片方の見落としをもう片方がカバーできる──理屈としては正しい。

しかし、現実はもっと複雑だ。

  • 両者でハッシュアルゴリズムが異なるため、同じ変更に対して異なる警告が出る
  • 同じファイルに対して重複チェックが走り、無駄なログが肥大化
  • 定期実行のタイミングがずれることで、片方にだけ通知が出る“幽霊アラート”が発生

このような事象は、運用担当者の判断を曇らせる。
特にログの解釈において「どちらが正しいのか？」という判断停止が起きやすく、最終的には両ツールの存在意義が薄れてしまう。

真に必要なのは“信頼できる設計”

改ざん検知ツールの本質は、検出力そのものよりも“信頼性のある運用体制”にある。
その点で言えば、TripwireまたはAIDE、どちらかを自分のシステム設計と運用体制に合わせて最適化するほうが、併用よりも遥かに成果につながりやすい。

無差別な併用は、安心ではなく“混乱”を生むだけ。

ツールに頼るより、運用方針を定めるほうが先だ。

併用するなら：ログ出力先を分離せよ

もしどうしてもTripwireとAIDEを併用したいなら、ログファイルを完全に分離し、cronによる実行タイミングも調整することを強く推奨する。

# /etc/cron.daily/tripwire_check.sh
/usr/sbin/tripwire --check > /var/log/tripwire/check.log 2>&1

# /etc/cron.daily/aide_check.sh（時間をずらす）
/usr/bin/aide --check > /var/log/aide/check.log 2>&1

このように運用レイヤーでの制御を明確にすることで、ツール同士の“衝突”を最低限に抑えることができる。

まとめ

TripwireとAIDEを両方使えば完璧――そう思い込んでいるなら、少し立ち止まって考えてほしい。
冗長な監視体制は、むしろ盲点を増やす温床となる。
単独運用でも十分な成果を上げるためには、ツールの特性と限界を理解し、検出ポリシーと更新プロセスを最適化する工夫が必要になる。

最終的に頼れるのは、設定ファイルの一行と、それを運用する人間の判断力だ。
セキュリティの現場に、万能な正解など存在しない。

コメント