Linux Auditdの設定手順：重要ファイルの監視と不正コマンド実行の検知

Table of Contents

現場の課題：午前2時の本番環境改ざんアラート

火曜日の深夜2時14分、枕元のポケットベルが激しく振動しました。毎秒450件のトランザクションを処理する本番決済ノードで、深刻度の高いアラートが発報されたのです。Webデーモンから不正な対話型bashシェルが生成され、直後に/etc/pam.d/common-authのチェックサム不一致が発生。わずか8分後には、決済リクエストが401 Unauthorizedエラーを吐き出し始めました。

WireGuard bastion経由で急いでリモート接続し、目を凝らしてターミナル画面を確認しました。しかし、従来の初動調査は即座に行き詰まりました。侵入者が先頭スペースを使った履歴非表示テクニックを用い、さらにHISTFILEを未設定にしていたため、historyコマンドを実行しても空行しか返ってこなかったのです。ls -laでタイムスタンプを調べると、ファイルが02:11 UTCに変更されたことは分かりましたが、誰が改ざんしたのか、どの親プロセスが書き込みを実行したのか、どのアカウントが権限昇格を行ったのかまでは特定できませんでした。

集約先の/var/log/syslogには、標準的なNginxのアクセスログやマイクロサービスのヘルスチェックによる14GBものノイズが溢れ返っていました。攻撃者はまさにこちらの目の前で認証情報を改ざんしていたにもかかわらず、Linuxの標準ログでは完全に盲点となっていたのです。

根本原因の分析：なぜ標準Linuxログはフォレンジックで役に立たないのか

この失敗の原因はアーキテクチャ設計にあります。標準ログはユーザーランドに配置されています。アプリケーションログ、シェル履歴、syslogファシリティは、すべて「適切な協調動作による通知」に依存しているのです。もし権限のないデーモンがリバースシェルを起動したり、意図的にsyslog()の呼び出しを回避したりした場合、その実行ログはユーザーランドのログに一切記録されません。

さらに、ユーザーランドのツールはシステムコールの境界を監視できません。攻撃者がexecveを実行したり、Pythonスクリプト経由でシェルを展開したり、openatで/etc/shadowを開いたりしても、psやlsofといったツールでは特定時点のスナップショットしか捉えられず、短時間の急激な変化を見逃してしまいます。その上、sudoers設定の不備を突いてroot権限を取得した攻撃者なら、わずか3秒で/var/log/auth.logを消去できてしまいます。

確実な説明責任と証跡を確保するには、カーネルレベルのフックが不可欠です。実行されたシステムコールを正確に捕捉し、元のログイン識別子（auid）を追跡し、不正プロセスが証拠隠滅を図る前に改ざん不可能なログを記録する仕組みが必要になります。

ソリューション比較：ユーザーランドツール vs ファイル整合性チェッカー vs カーネル監査

本番システムの監視において、エンジニアリングチームは通常以下の3つの選択肢を検討します：

プロセスクアカンティング（psacct / acct）：実行コマンドとCPU・メモリ消費量を記録します。しかし、ファイルの読み取りや書き込み操作、ソケット接続は無視されます。実行前にバイナリ名をリネームされるだけで、攻撃者に容易に回避されてしまいます。
ファイル整合性監視（AIDE / Tripwire）：暗号化ハッシュを用いてデータベースとの定期的な比較検証を行います。誰かが/etc/pam.d/common-authに変更を加えたことは検知できますが、cronジョブとして数時間おきに実行されることが多く、リアルタイム性に欠けます。また、実行中のプロセス記述子の特定や、書き込みコマンドを発行したユーザーの特定までは不可能です。
Linux監査デーモン（Auditd）：Linuxカーネルの監査パイプライン内に直接配置されます。すべてのシステムコールは、実行完了前に監査フィルターを通過します。sudo -iやsuなどを実行しても元のログインUID（auid）が保持され、正確なバイナリパス、作業ディレクトリ、親PIDをリアルタイムに記録します。

最適なアプローチ：本番環境仕様のLinux Auditd設定

以下は、フォレンジックの死角を解消するために、私たちが120台の本番ノードに展開した堅牢化済みのAuditd構成です。

1. Auditdのインストールと有効化

Auditdは主要なLinuxディストリビューションの公式パッケージリポジトリに含まれています。DebianおよびUbuntu系システムの場合：

sudo apt update && sudo apt install -y auditd audispd-plugins
sudo systemctl enable auditd
sudo systemctl start auditd

RHEL、Rocky Linux、AlmaLinuxの場合：

sudo dnf install -y audit audit-libs
sudo systemctl enable auditd
sudo systemctl start auditd

2. Auditdサービルルールの堅牢化

システム管理者がカスタムルールファイルを追加する場合は、/etc/audit/rules.d/内に配置します。/etc/audit/audit.rulesを直接編集しないでください。ブートシーケンス内でaugenrulesによって頻繁に再生成されるためです。/etc/audit/rules.d/99-security-hardening.rulesにカスタム設定ファイルを作成します：

sudo nano /etc/audit/rules.d/99-security-hardening.rules

以下のディレクティブを追記します：

# メモリ上の既存ルールをすべてクリア
-D

# カーネル監査バッファサイズを設定（高トラフィックノードでは8192から32768の値を指定）
-b 8192

# バッファ溢れ時の動作：1 = syslog警告、2 = カーネルパニック
-f 1

# アカウント識別ファイルおよび認証データベースの変更を監視
-w /etc/passwd -p wa -k identity_changes
-w /etc/shadow -p wa -k identity_changes
-w /etc/group -p wa -k identity_changes
-w /etc/gshadow -p wa -k identity_changes
-w /etc/security/ -p wa -k pam_security
-w /etc/pam.d/ -p wa -k pam_security
-w /etc/sudoers -p wa -k sudoers_tampering
-w /etc/sudoers.d/ -p wa -k sudoers_tampering

# SSHサーバー設定およびauthorized_keysの配置場所を監視
-w /etc/ssh/sshd_config -p wa -k ssh_config_tampering
-w /root/.ssh/ -p wa -k root_ssh_keys

# 対話型ユーザー（UID >= 1000）による非デーモンバイナリの実行を追跡
-a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=4294967295 -k command_execution
-a always,exit -F arch=b32 -S execve -F auid>=1000 -F auid!=4294967295 -k command_execution

# 権限昇格ツールの呼び出しを追跡
-w /bin/su -p x -k priv_escalation
-w /usr/bin/sudo -p x -k priv_escalation
-w /usr/bin/passwd -p x -k password_mod

# 再起動するまでカーネルメモリ内の監査設定をロック（不変フラグ）
-e 2

各フラグの役割は次のとおりです。-wフラグで特定のパスを指定し、-p waで書き込み操作とファイル属性の変更を監視します。-kフラグは、一致したイベントに検索用の識別キーをタグ付けします。プロセス監視における-S execveは、UIDが1000以上のアカウントによるコマンド実行をログに記録し、未設定のカーネルセッション（UID 4294967295）は除外します。最後に-e 2で設定をメモリ上にロックします。これを設定すると、rootユーザーであってもホストを再起動しない限り、ルールの消去やデーモンの停止ができなくなります。

作成した新しいルールファイルをビルドしてロードします：

sudo augenrules --load

3. 運用セキュリティとアクセス制御

カーネル監査は「何が起きたか」を克明に記録しますが、強固な認証ポリシーは攻撃自体を未然に防ぎます。管理者の認証情報が漏洩したり総当たり攻撃で突破されたりした場合、標準的なアクセス防御壁は完全に無力化されてしまいます。

踏み台サーバー（jump box）や本番用bastionアカウントをセットアップする際は、toolcraft.app/ja/tools/security/password-generator のパスワードジェネレーターを使用して、長大でランダムなシークレットを生成してください。クライアント側のWeb Cryptography APIで実行されるため、ネットワーク上にパスワードが平文送信される心配がありません。堅牢なパスフレーズと不変のカーネル監査ルールを組み合わせることで、初歩的な初期アクセス経路を確実に排除できます。

4. ausearchとaureportを用いたインシデント調査

grepを使って/var/log/audit/audit.logの生ログを行単位で検索するのは避けてください。ログエントリは高密度であり、パラメータが16進数文字列でエンコードされているためです。代わりに、定義したタグをausearchやaureportで照会します。

pam_securityキーで登録された全イベントを検索するには：

sudo ausearch -k pam_security -i

-iオプションを付与すると、生のシステムコールIDや数値のUIDが人間が読めるテキスト名に変換されます。侵害イベントからは明瞭なメタデータが確認できます：

type=PROCTITLE msg=audit(10/22/2026 02:14:18.102:491) : proctitle=nano /etc/pam.d/common-auth
type=SYSCALL msg=audit(10/22/2026 02:14:18.102:491) : arch=x86_64 syscall=openat success=yes exit=3 a0=0x7ffd9b8 ... exe=/usr/bin/nano key="pam_security" auid=deployer uid=root

各IDに注目してください。現在のUIDはuid=rootとなっていますが、不変の監査IDはauid=deployerを示しています。攻撃者が完全なroot権限に昇格していたとしても、このセッションの起点がdeployerアカウントであったことをカーネルが記憶しているのです。このわずか1行の情報が、攻撃経路を確定づける決定打となります。

直近1日間に発生したログイン失敗やコマンド実行の集約サマリーを確認するには、以下を実行します：

sudo aureport --start yesterday --executable --summary
sudo aureport --auth --failed

Auditdの設定にかかる時間は、ホスト1台あたりおよそ10分程度です。このわずかな手間で、混乱を極める深夜のインシデント対応を、確たる証拠に基づいた整然たるポストモーテム（事後検証）へと変えることができます。