はじめに：なぜ、我々のFIMは「プロの侵入者」に簡単にバイパスされるのか
レッドチームのエンゲージメントにおいて、境界防御を突破した後に最初に行う儀式は何だと思うか？それは、Webアプリケーションの公開ディレクトリ、例えば/var/www/htmlやその周辺へのWebシェルのドロップだ。
インフラストラクチャの担当者は、「ファイル整合性監視（FIM: File Integrity Monitoring）」を導入しているから安全だと胸を張る。OSSECのリアルタイム監視が走っている、あるいはauditdでシステムコールの監査を有効化しているから、未許可のファイル作成や改ざんは即座に検知・アラートされると信じ込んでいる。
しかし、攻撃者の視点から言わせてもらえば、素朴なFIMほど簡単に無力化できるものはない。
多くのFIMは、「どのファイルが、いつ、どのように作成・変更されたか」という表面的なメタデータしか見ていない。しかし、現代の高度なペネトレーションテストや実際の標的型攻撃では、ファイルシステムのタイムスタンプ（MACb：Modified, Accessed, Changed, birth）の偽装、インメモリ実行、あるいはファイル監視の盲点を突いたアトミックな置換手法が日常茶飯事に行われている。
本稿では、OSSECやauditdといった標準的なツールを用いたFIMが、なぜ実戦においていとも簡単に突破されるのか、その限界を低レイヤのファイルシステム挙動から暴きつつ、攻撃者のロジックを逆手に取った「真に機能する」FIMのアーキテクチャ設計と実装について、セキュリティアーキテクトやチーフホワイトハッカーの視点から深く掘り下げて解説する。
—
1. 現場で蔓延するFIMの致命的な盲点：なぜ「静的な監視」は死んでいるのか
従来のFIM（OSSECのsyscheckや、単純なAIDE / Tripwireの定期スキャン）は、データベースに保存された既知のハッシュ値（SHA-256など）と、ターゲットファイルのハッシュ値を比較するアプローチをとっている。これがなぜ通用しないのか。
タイムスタンプとハッシュの魔術（Timestomp）
攻撃者はWebシェルを書き込んだ後、一瞬にしてそのファイルのメタデータを書き換える。Linux環境であれば、touchコマンドやC言語のutimes()システムコールを用いることで、ターゲットファイルの変更時刻（mtime）やアクセス時刻（atime）を、親ディレクトリや正当なCMSのコアファイルと完全に一致させることが可能だ。
さらに悪質なケースでは、監視エージェントのポーリング間隔の隙をつき、ファイルを一時的なプレフィックス（例: .swpやランダムな文字列）で書き込んでおき、処理の完了直前にアトミックなrename()システムコールで本来のファイル名に置き換える。この手法をとられた場合、ファイル作成イベントの検知タイミングがずれ、ハッシュ計算の競合状態（Race Condition）を引き起こすか、そもそもスキャン周期から綺麗に逃れることができる。
カーネル空間とユーザー空間のギャップ
auditdを用いることで、システムコールレベル（sys_enter_openやsys_enter_execveなど）でのファイル操作を監視することは可能だが、ここにも罠がある。高負荷なWebアプリケーション環境において、全てのファイルシステムイベントを同期的にカーネルからユーザー空間へ吸い上げようとすると、メッセージキューのオーバーフロー（audit: backlog limit exceeded）が発生する。
バッファがあふれた際、auditdの設定（failure_flag）がデフォルトのまま（通常はログ記録の継続やパニック）であると、攻撃者は意図的に大量のダミーリクエストを送り込んでログシステムを飽和させ、その隙に検知を回避してWebシェルを配置するという古典的かつ極めて有効なDDoS的アプローチをとる。
—
2. 攻防の最前線：auditdによるリアルタイム監視の限界と堅牢化
では、auditdを実戦投入可能なレベルまでチューニングし、妥協のないリアルタイム監視を構築するにはどうすればよいか。単に「公開ディレクトリを監視する」という雑なルールでは、無数の誤検知（False Positive）の嵐に埋もれ、真のアラートが見えなくなる。
以下の設定例は、Webサーバー（Nginx / Apache）のドキュメントルートに対する不正な書き込み、特に「実行権限を伴うファイル作成」に特化させたauditdのルールセットである。
# ==========================================
# Webシェル検知特化型 auditd ルール設定例
# ==========================================
# 1. 既存の監査ルールのクリア（初期化）
-D
# 2. バッファサイズの拡張（ログ溢れによる検知抜けを防ぐ）
-b 8192
# 3. 障害発生時の挙動設定（システムの可用性を保ちつつ監査を厳格化）
-f 1
# 4. /var/www/html/ 以下のファイル作成・属性変更を監視
# 攻撃者がWebシェルを配置する際に必ず通過するシステムコールを捕捉する
-w /var/www/html/ -p wa -k web_shell_deployment
# 5. 特権プロセス（rootやwww-data等）以外による不審なバイナリ実行の監視
# Webサーバーのプロセス（www-data等）からシェル（/bin/sh, /bin/bash）が直接呼び出された場合を検知
-a always,exit -F arch=b64 -S execve -F uid!=0 -F auid>=1000 -k unauthorized_exec
# 6. ルールの不変化（再起動するまでルール変更を不可能にする）
-e 2この設定の肝は、単なるファイルの変更（w属性）だけでなく、プロセスのコンテキストと結びつけて監視している点にある。例えば、www-dataユーザーの権限で動作するPHP-FPMのプロセスから、予期せぬ外部プロセス（shやwgetなど）が起動された瞬間を捉えることが、Webシェル経由のリバースシェルや追加ペイロードのダウンロードを防ぐ最後の砦となる。
—
3. OSSEC / Wazuh を用いた高度なエージェント監視とレスポンス自動化
オープンソースのHIDS（Host-based Intrusion Detection System）であるOSSECや、その後継であるWazuhを活用する場合、エージェント側でのローカルチェックと、サーバー側での相関分析（Correlation）のバランスが鍵となる。
単に「ファイルが追加された」というイベントだけでは、開発者が正規のデプロイ（Git pullやFTPなど）を行った際にもアラートが鳴り響き、運用の現場を疲弊させる「オオカミ少年」現象を引き起こす。そのため、「コンテキストを持った検知ルール」を定義する必要がある。
以下は、Wazuh（OSSEC派生）のカスタムデコーダーおよびルール設定の概念を示すXMLスニペットである。正規のデプロイメントツール経由の変更を除外し、異常なパスや拡張子のファイルを即座に検知・ブロックする。
<!-- ========================================== -->
<!-- Wazuh カスタム検知ルール設定例 -->
<!-- ========================================== -->
<group name="web_integrity, web_shell_detection,">
<!-- 検出ID: 100001 - 公開ディレクトリへの予期せぬスクリプトファイル作成 -->
<rule id="100001" level="12">
<if_sid>554</if_sid> <!-- ファイル変更イベントの基本シグネチャを継承 -->
<match>/var/www/html/</match>
<regex>\.php$|\.phtml$|\.php5$|\.jsp$|\.asp$</regex>
<description>警戒警報: Web公開ディレクトリへのスクリプトファイル（Webシェル）の不正作成を検知しました。</description>
<group>pci_dss_11.5, gpg13_4.13,</group>
</rule>
<!-- 検出ID: 100002 - デプロイメント除外フィルター（正規のCI/CDパイプラインからの書き込みを除外） -->
<rule id="100002" level="0">
<if_sid>100001</if_sid>
<user>deploy_bot</user> <!-- 正規のデプロイ用ユーザー -->
<description>正規のCI/CDパイプラインによるファイル更新のため、アラートを抑制します。</description>
</rule>
</group>自動修復（Active Response）の罠と現実
「Webシェルを検知したら、瞬時にそのファイルを削除し、IPをブロックする」というActive Responseは、理論的には美しく響く。しかし、現場のインシデントハンドラーとして警告しておこう。誤検知によるActive Responseは、自らの手でシステムを停止させるDDoS攻撃そのものになり得る。
高度なペネトレーションテスターは、防御側の自動修復スクリプトのトリガー条件をあらかじめリサーチし、わざと誤検知を引き起こすダミーファイルを大量に投入することで、防御システム側の自動ブロック機能を暴走させ、正当なユーザーのアクセスまで遮断させるという戦術をとることもある。したがって、自動修復を実装する場合は、ファイルの削除だけでなく、即座のプロセスダンプ採取、メモリフォレンジック用イメージの保存、そして隔離（Quarantine）をセットで行う多層的な設計が不可欠である。
—
4. チーフセキュリティアーキテクトが推奨する「次世代FIM」のアーキテクチャ設計
従来のファイルシステム監視の限界を突破するためには、OSのファイルシステムレイヤそのもの、あるいはWebアプリケーションの実行基盤に踏み込んだアプローチが必要となる。
1. 読み取り専用ファイルシステム（Immutable Infrastructure）の徹底
そもそも、本番環境のWeb公開ディレクトリに、アプリケーション稼働プロセス（www-data等）が書き込める権限を与えていること自体がアーキテクチャの欠陥である。
Kubernetesやコンテナベースの環境、あるいは厳格に構築されたオンプレミスサーバーにおいて、Webアプリケーションのルートディレクトリは完全にRead-Only（読み取り専用）であるべきだ。アップロード機能が必要な場合、その保存先はWeb公開ディレクトリから完全に切り離された外部ストレージ（S3互換オブジェクトストレージや、実行権限が厳格に剥奪されたマウントポイント）に限定し、そこに配置されるファイルには一切のスクリプト実行権限（noexecオプション）を付与する。これこそが、FIMに頼る必要すらない最強の構造的防御である。
2. eBPF（Extended Berkeley Packet Filter）を活用した次世代ファイル監視
従来のauditdやユーザースペースのエージェントが抱えるオーバーヘッドとカーネルパニックの問題を解決するのが、現代のオブザーバビリティとセキュリティのデファクトスタンダードとなりつつあるeBPFだ。
eBPFを用いることで、カーネル空間内で直接システムコール（sys_enter_openatやsys_enter_writeなど）を安全にフックし、不審なファイル作成の試みをユーザー空間に負荷をかけることなくミリ秒単位でブロックすることが可能になる。
以下は、将来的な次世代防御の基盤として考慮すべき、eBPFを活用したファイルアクセス監視の概念的なアプローチ（Pythonのbccライブラリ等を用いた実装イメージ）である。
#!/usr/bin/python3
# -*- coding: utf-8 -*-
from bcc import BPF
import time
# eBPFプログラムの記述（カーネル空間で実行されるC言語コード）
bpf_text = """
#include <uapi/linux/ptrace.h>
#include <linux/sched.h>
// ファイルオープンイベントをフックするeBPFトレーサー
int trace_file_open(struct pt_regs *ctx, const char __user *filename, int flags) {
char comm[TASK_COMM_LEN];
bpf_get_current_comm(&comm, sizeof(comm));
// 例: Webサーバープロセス以外からの公開ディレクトリへの書き込みを検知・警告
// 実際のプロダクションコードでは、パスのフィルタリングをカーネル空間で高速に処理する
return 0;
}
"""
# eBPFのコンパイルとアタッチ
b = BPF(text=bpf_text)
# ※実際の運用では sys_enter_openat 等のシステムコールに対してプローブをアタッチします
print("[*] eBPF-based File Integrity Monitor is running. Press Ctrl+C to exit.")
try:
while True:
time.sleep(1)
except KeyboardInterrupt:
print("[*] Detaching and exiting.")このような低レイヤからのアプローチを取り入れることで、攻撃者がどれほど巧妙にタイムスタンプを偽装しようとも、システムコールレベルでの「書き込みの事実」そのものを改ざんすることは不可能であるため、完全な検知網を構築することができる。
—
おわりに：攻撃者の心理を逆手に取った「動的監査」のすすめ
セキュリティの現場において、「完璧な防御」など存在しない。FIMも例外ではない。どれほど高度な監視ツールを導入しようとも、攻撃者は常にその盲点（カーネルの仕様、エージェントのパフォーマンス低下、管理者の設定ミス）を突いてくる。
だからこそ、我々ディフェンダーは単に「ツールを導入して安心する」という思考停止から脱却しなければならない。
公開ディレクトリを完全にイミュータブル（不変）に保つこと。どうしても動的な書き込みが必要な領域は、実行権限を完全に剥奪し、分離すること。そして、システムコールやeBPFといった低レイヤの挙動に目を光らせること。
攻撃者が次に何をするか、その思考の先回りをしてアーキテクチャを磨き続けることこそが、真のセキュリティプロフェッショナルの仕事である。ログのアラート音に怯えるだけの監視体制は、今日で終わりにしよう。
コメント