泥沼のインシデント現場から学ぶ：Auditdによる「事後」ではなく「リアルタイム」の防衛線
現場でインシデント対応をしていると、決まって遭遇するのが「犯人は何を盗み、どこへ消えたのか」という証拠の欠如だ。攻撃者が侵入後に最初に行うのは、自身の痕跡を消すこと（ログの削除や改ざん）。これに対抗するための最後の砦が、OSカーネルレベルでの監査、すなわち auditd だ。
多くのエンジニアは auditd を「ログを取るツール」と勘違いしているが、本質は「カーネルが発行するシステムコールを監視し、不正な挙動を即座にシグナル化するセンサー」である。これを使いこなせば、攻撃者の小さな指先すら逃さない。
—
1. 攻撃者が狙う盲点：なぜ「ファイル監視」だけではダメなのか
多くの脆弱性診断やセキュリティガイドラインでは「重要ファイルの変更検知」を推奨する。確かに /etc/passwd や /etc/shadow の監視は基本だが、プロの攻撃者は「ファイルそのもの」ではなく、そのファイルを「誰が、どのようなシステムコールで触ったか」というプロセス実行の文脈を狙う。
例えば、Webサーバーの脆弱性（RCE等）を突いた際、攻撃者はまず /tmp や /var/tmp にスクリプトを置き、実行権限を付与してバックドアを起動する。この「実行」という行為を、ファイル属性の変更だけではなく、execve システムコールレベルでキャッチしなければ、侵入の初期段階を見逃すことになる。
—
2. 実践：Auditdによる鉄壁の設定
ただログを垂れ流す設定は、ディスクを圧迫するだけのゴミ箱だ。必要なのは「インシデント発生時に即座にアラートを飛ばせる」ピンポイントな監視ルールだ。
/etc/audit/rules.d/audit.rules に以下の設定を追加し、再起動または augenrules --load で適用してほしい。
# 1. 権限変更の監視 (chmod, chown, fchmodat等)
-a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod
# 2. 重要なシステム設定ファイルの書き込み監視
-w /etc/passwd -p wa -k identity_changes
-w /etc/shadow -p wa -k identity_changes
# 3. プロセスの実行監視 (バックドア検知の要)
# 攻撃者がよく使う execve を監視し、実行されたコマンドを記録する
-a always,exit -F arch=b64 -S execve -k process_execution
# 4. 一時ディレクトリへの不正な書き込み禁止と監視
-w /tmp -p wa -k suspicious_activity設定のポイント：
-F auid>=1000: システムユーザーのログは除外している。攻撃者は大抵、ハックした一般ユーザーやWebサーバーの実行権限で動くからだ。-k: これが「鍵」だ。SIEM（ELKやSplunkなど）で検索する際、このタグ名でフィルタリングをかけることで、ノイズの中から攻撃の足跡だけを抽出できる。
—
3. SIEM連携：ログを「情報」から「知見」に変えるPythonスクリプト
auditd が吐き出したログをそのまま眺めるのは苦行だ。以下は、ログを監視し、特定のタグ（ここでは process_execution）が検知された瞬間に Slack や SIEM に飛ばすためのシンプルなリスナーの雛形だ。
import subprocess
import re
# auditdのログをリアルタイムで追跡するジェネレーター
def watch_audit_log(file_path="/var/log/audit/audit.log"):
with open(file_path, "r") as f:
f.seek(0, 2) # ファイルの末尾へ移動
while True:
line = f.readline()
if not line:
continue
# 'process_execution'タグが含まれる行だけを抽出
if "key=\"process_execution\"" in line:
yield line
def notify_security_team(log_entry):
# ここにSlack WebhookやSIEMへのAPI送信処理を記述
print(f"[ALERT] 不審なプロセス実行を検知: {log_entry.strip()}")
if __name__ == "__main__":
print("Security Monitoring Started...")
for entry in watch_audit_log():
notify_security_team(entry)—
4. 最後に：エンジニアへの提言
セキュリティは「設定して終わり」の静的なものではない。攻撃者も日々、新しいバイパス手法を開発している。
もし君たちがWebアプリ開発者なら、auditd を設定するだけでなく、アプリケーション側でも操作ログ（誰が、いつ、どのリソースにアクセスしたか）をDBに残す癖をつけてほしい。「OSの監査ログ」と「アプリの操作ログ」を突合させること。これができた時、君たちは初めて攻撃者の全貌を論理的に追跡できる「プロの守護者」になれる。
設定に迷ったら、まずはこの audit.rules をテスト環境に入れて、自分の操作がどう記録されるかを確認することから始めてみてくれ。それが、最強の防御への第一歩だ。
コメント