auditdでシステム監査ログを設定する方法（ルール設計・検索・ログ保存の実務）

auditd は Linux カーネルの監査機能を使って「誰が、いつ、どのファイルに触れ、どのコマンドを実行したか」を記録するデーモンです。この記事では、auditd のインストールから、WordPress サーバーで役に立つ監査ルールの書き方、ausearch と aureport での検索、ログの保存量の調整までを順に設定します。読み終えると、設定ファイルの書き換えや管理者権限の操作を後から追跡できる状態になります。

auditd で何が記録できるのか

通常のアプリケーションログは、そのアプリケーションが書こうとしたことしか残りません。auditd はカーネルの段階で記録するため、たとえば wp-config.php を vi で開いて保存した操作も、PHP から書き換えた操作も、同じように記録できます。

記録の単位は大きく2種類です。

• ファイル監視：特定のファイルやディレクトリへの書き込み・属性変更・実行などを記録する
• システムコール監視：execve（コマンド実行）などのシステムコールを条件付きで記録する

さらに auditd は、ログインした元のユーザーを示す auid（監査ユーザー ID）を記録します。sudo で root になって作業しても、auid には元のユーザーが残るため「root が変更した」ではなく「どの担当者が root 権限で変更した」まで追えます。これが auditd を使う大きな理由です。

一方で、記録対象を広げすぎるとログが急増し、ディスクを圧迫したり性能に影響したりします。「何を後から確認したいか」を先に決めてからルールを書くのが基本です。

1. インストールと起動

# Ubuntu/Debian
sudo apt install auditd audispd-plugins
sudo systemctl enable --now auditd

# RHEL 系（多くの場合は標準で入っている）
sudo dnf install audit
sudo systemctl enable --now auditd

動作の確認は次のとおりです。

sudo auditctl -s     # 状態の表示（enabled 1 なら有効）
sudo auditctl -l     # 読み込まれているルールの一覧

RHEL 系では、auditd のサービスユニットが手動での停止を拒否する設定になっていることがあり、systemctl restart auditd が失敗する場合があります。その場合は sudo service auditd restart を使います。これは監査記録を途切れさせないための意図的な仕様です。

2. ルールの置き場所と読み込み方

ルールには一時的なものと永続的なものがあります。

• auditctl コマンドで追加したルールは、再起動や auditd の再起動で消えます。動作確認に向いています。
• 永続化するルールは /etc/audit/rules.d/ に .rules ファイルとして置き、augenrules --load で読み込みます。augenrules は rules.d 内のファイルを名前順に結合して /etc/audit/audit.rules を生成します。

まず一時ルールで試してから、ファイルに書く流れが安全です。

# 一時的に wp-config.php の書き込みと属性変更を監視
sudo auditctl -w /var/www/example/wp-config.php -p wa -k wp_config

-p の値は r（読み取り）、w（書き込み）、x（実行）、a（属性変更）の組み合わせです。読み取りの監視は PHP が毎回 wp-config.php を読み込むため大量のログになります。改ざんの追跡が目的なら wa で十分です。

3. WordPress サーバー向けのルール例

次のファイルを /etc/audit/rules.d/50-wordpress.rules として作成します。パスは自分の環境に置き換えてください。

## WordPress の重要ファイル
-w /var/www/example/wp-config.php -p wa -k wp_config
-w /var/www/example/.htaccess -p wa -k wp_htaccess
-w /var/www/example/wp-content/mu-plugins/ -p wa -k wp_mu_plugins

## アカウントと権限の設定
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers

## SSH とスケジュール実行の設定
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /etc/crontab -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /var/spool/cron/ -p wa -k cron

## ログインユーザーが root 権限で実行したコマンド（64bit 環境）
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=4294967295 -k root_cmd

ポイントは次のとおりです。

• -k のキー名は、後で ausearch で絞り込むためのラベルです。用途ごとに分けておくと調査が楽になります。
• auid!=4294967295 は「ログインを経由していないプロセス（auid が未設定）」を除く条件です。新しいバージョンの audit では auid!=unset とも書けます。
• auid>=1000 は一般ユーザーの UID の範囲を前提にしています。ディストリビューションによって範囲が違う場合があるので、/etc/login.defs の UID_MIN で確認します。
• wp-content/uploads やキャッシュディレクトリは監視しません。正規の書き込みが多く、ログが埋もれます。

-w によるファイル監視は古くからの書式で、公式マニュアルでは -F path= や -F dir= を使った書式も案内されています。どちらも使えますが、環境のバージョンで挙動を確認してください。

sudo augenrules --load
sudo auditctl -l

auditctl -l に追加したルールが表示されれば読み込み完了です。ルールの書式に誤りがあると augenrules が該当行を報告するので、出力を読み飛ばさないようにします。

ルールを固定する -e 2 の注意

ルールファイルの末尾に -e 2 を書くと、以降はルールの変更ができなくなります（変更には再起動が必要）。侵入者が監査を止めることを防げますが、設定ミスに気づいても再起動するまで直せません。導入直後は使わず、ルールが安定してから検討してください。

4. ausearch と aureport でログを読む

ログは /var/log/audit/audit.log に記録されます。そのままでも読めますが、ausearch を使うと条件で絞り込めます。

# キーで絞り込み、-i で UID などを名前に変換して表示
sudo ausearch -k wp_config -i

# 今日の分だけ
sudo ausearch -k sudoers --start today -i

# 特定のユーザーが関わる操作（uid・euid・auid のいずれかが一致するもの）
sudo ausearch -ua 1001 -i

1件の出来事は複数の行（type=SYSCALL、type=PATH など）に分かれて記録されます。-i を付けると、auid=deploy のように名前で表示され、comm（実行したコマンド名）や exe（実行ファイル）と組み合わせて「誰がどのプログラムで書き換えたか」が読み取れます。

集計には aureport を使います。

sudo aureport --summary      # 全体の概要
sudo aureport -au            # 認証の試行
sudo aureport -k --summary   # キーごとの件数
sudo aureport -x --summary   # 実行ファイルごとの件数

普段から aureport -k --summary の件数を見ておくと、急に増えたキーに気づけます。たとえば wp_config の件数が普段ゼロなのに増えていれば、誰かが設定ファイルを触ったということです。

5. ログの保存量とディスク対策

auditd のログ設定は /etc/audit/auditd.conf にあります。主な項目は次のとおりです。

# 1ファイルの上限（MB）
max_log_file = 50
# 上限に達したときの動作
max_log_file_action = ROTATE
# 保持するファイル数
num_logs = 10
# ディスク残量が少なくなったときの動作
space_left_action = SYSLOG

既定値はディストリビューションによって異なるため、変更前に現在の値を確認し、ファイルをバックアップしてから編集します。変更後は auditd を再起動します。

auditd のログは logrotate ではなく auditd 自身がローテーションするのが標準です。logrotate の設定を別に加えると二重管理になるので注意してください。

サーバーが侵入された場合、そのサーバー上のログは改ざんされる可能性があります。重要なサーバーでは、audispd-plugins に含まれる syslog 連携や remote 送信のプラグインを使い、別のログサーバーへ転送する構成も検討します。プラグインの設定ファイルの場所や名前は audit のバージョンで変わっているため、インストールされたパッケージの説明を確認してください（2026年10月現在）。

運用で気をつけること

• ルールを足す前に目的を書く：「wp-config.php の変更者を追いたい」のように目的があれば、不要なルールを足さずに済みます。
• 性能を確認する：execve の監視は、アクセスの多いサーバーでは負荷が増える場合があります。条件（euid=0 など）で絞り込み、導入後に負荷を観察します。
• 定期的に読む：週に1回 aureport の概要を見るだけでも、記録しっぱなしよりはるかに役立ちます。
• 検証環境で試す：ルールを本番に入れる前に、ステージング環境でログの量を確かめておくと安心です。

まとめ

• auditd はカーネルの段階で記録し、sudo 後も元のユーザー（auid）を追える
• 一時ルールは auditctl、永続ルールは /etc/audit/rules.d/ に書いて augenrules --load
• WordPress では wp-config.php・.htaccess・mu-plugins、OS では passwd・sudoers・sshd_config・cron を監視する
• uploads やキャッシュは監視対象から外し、ログの量を抑える
• ausearch -k でキー検索、aureport で集計し、件数の変化に気づける状態にする
• -e 2 はルールが安定してから。ログは auditd.conf でローテーションし、重要なら別サーバーへ転送する

• sudoの設定でコマンド実行を制限する方法
• journalctlでLinuxのログを確認する方法