auditdでLinuxの操作ログを記録する方法（ルール設定・ausearch・aureportの使い方）

Linuxで「誰が・いつ・どのファイルを変更したか」「どのコマンドがroot権限で実行されたか」を後から追えるようにするには、カーネルの監査機能とその記録デーモンである auditd を使います。この記事では、auditd の導入、/etc/audit/rules.d/ への恒久ルールの書き方、auditctl と augenrules の使い分け、ausearch と aureport での調べ方までを、WordPressサーバーの運用を例に説明します。

auditdの仕組みとできること

監査の本体はLinuxカーネルの中にあり、auditd はカーネルが生成した監査イベントを受け取ってファイルに書き出す役割を持っています。どのイベントを記録するかは「監査ルール」で指定し、ルールに一致したシステムコールやファイル操作だけがログに残ります。

通常のアプリケーションログや syslog との違いは、記録がカーネルのレベルで行われる点です。たとえば wp-config.php を書き換えたのが vim でも sed でも PHP のプロセスでも、ルールに一致すれば同じ形式で記録されます。さらに auid（ログインUID）という値が残るため、sudo で root になってから操作しても「最初にログインしたのは誰か」をたどれます。

一方で、ルールを広く取りすぎるとログが急増し、ディスクとCPUを圧迫します。auditd は「全部を記録する」道具ではなく、「重要なファイルと操作を絞って監視する」道具だと考えるのが運用のこつです。

インストールと起動

RHEL系（Rocky Linux、AlmaLinux など）では多くの場合最初から入っています。Debian/Ubuntu では auditd パッケージを追加します。

# RHEL / Rocky Linux / AlmaLinux
sudo dnf install -y audit
sudo systemctl enable --now auditd

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

# 動作確認
sudo auditctl -s

auditctl -s の出力で enabled 1 になっていれば監査が有効です。同じ出力にある lost はカーネル側で取りこぼしたイベント数、backlog は処理待ちの件数です。lost が増え続ける場合はバッファ（後述の -b）が足りていません。

注意点として、RHEL系の auditd のユニットは手動停止を受け付けない設定になっており、systemctl restart auditd はエラーになります。再起動が必要なときは sudo service auditd restart を使います。これは不具合ではなく、監査を勝手に止められないようにするための仕様です。

ログは標準で /var/log/audit/audit.log に出力されます。保存量は /etc/audit/auditd.conf の max_log_file（1ファイルの上限MB）と num_logs（世代数）、max_log_file_action（上限到達時の動作、通常は ROTATE）で決まります。監査ログは logrotate ではなく auditd 自身がローテーションする点も覚えておくと、ログが消えた・増えすぎたときの調査が早くなります。

auditctlでルールを試す

auditctl は実行中のカーネルにルールを直接追加するコマンドです。即座に効きますが、再起動すると消えます。そのため「まず auditctl で試し、問題なければファイルに書いて恒久化する」という順番で進めます。

# 現在のルールを一覧表示
sudo auditctl -l

# wp-config.php への書き込みと属性変更を監視（キー名 wp-config）
sudo auditctl -w /var/www/html/wp-config.php -p wa -k wp-config

# 試しに触ってみる
sudo touch /var/www/html/wp-config.php

# 記録されたか確認
sudo ausearch -k wp-config -i --start recent

-w は監視するパス、-p は監視する操作で、r（読み取り）、w（書き込み）、x（実行）、a（属性変更）を組み合わせます。-k は検索用のキー名で、後から ausearch -k で絞り込むための目印です。キー名は用途ごとに分けておくと、調査時に目的のイベントだけを取り出せます。

r を付けると読み取りのたびに記録されるため、PHPが毎リクエスト読み込む wp-config.php に付けるとログがすぐに膨らみます。変更の検知が目的なら wa で十分です。

/etc/audit/rules.d/ に恒久ルールを書く

再起動後もルールを残すには、/etc/audit/rules.d/ に .rules ファイルを置きます。起動時に augenrules がこのディレクトリのファイルを名前順に連結して /etc/audit/audit.rules を生成し、カーネルに読み込ませます。audit.rules は生成物なので直接編集しません。

sudo vi /etc/audit/rules.d/50-wordpress.rules

## 認証・アカウント情報の変更
-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/shadow -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/ssh/sshd_config.d/ -p wa -k sshd-config

## WordPressの重要ファイル
-w /var/www/html/wp-config.php -p wa -k wp-config
-w /var/www/html/.htaccess -p wa -k wp-htaccess

## ログインしたユーザーがroot権限で実行したコマンド
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=unset -k root-cmd
-a always,exit -F arch=b32 -S execve -F euid=0 -F auid>=1000 -F auid!=unset -k root-cmd

最後の2行はシステムコールルールです。execve（プログラムの実行）のうち、実効ユーザーが root で、かつ人間がログインして始めたセッション（auid が1000以上で、未設定ではないもの）に絞っています。この絞り込みがないと、cron やデーモンの動作まで大量に記録されます。64ビット環境でも32ビットのシステムコール経路があるため、arch=b64 と arch=b32 の両方を書くのが定石です。古い audit パッケージでは auid!=unset の代わりに auid!=4294967295 と書きます。

書いたら構文を確かめてから読み込みます。

# 変更があるか確認
sudo augenrules --check

# ルールを生成してカーネルに読み込む
sudo augenrules --load

# 反映されたか確認
sudo auditctl -l

ディストリビューションには 10-base-config.rules（既存ルールの削除 -D、バッファサイズ -b、失敗時の動作 -f）のような基本ファイルが用意されていることが多く、自作のファイルは番号を 50- などにしてその後ろに読ませます。CISベンチマーク向けなどのサンプルルールが /usr/share/audit/sample-rules/（バージョンにより /usr/share/doc/ 配下）に入っているので、参考にするとよいでしょう。

ルールをロックする -e 2 は最後に

-e 2 をルールの最後に置くと、それ以降は再起動するまでルールの変更ができなくなります。攻撃者に監査を無効化されにくくなる反面、自分でもルールを直せなくなります。運用に慣れるまでは付けず、ルールが固まってから 99-finalize.rules のような最後に読まれるファイルに追加するのが安全です。

ausearchでイベントを探す

ausearch はログから条件に合うイベントを取り出すコマンドです。-i を付けると UID がユーザー名に、システムコール番号が名前に変換され、読みやすくなります。

# キーで検索（今日の分）
sudo ausearch -k wp-config -i --start today

# 特定のファイルに関するイベント
sudo ausearch -f /etc/sudoers -i

# ログインUIDで絞る（例: UID 1001 のユーザーが関わった操作）
sudo ausearch -ua 1001 -i --start this-week

# 失敗したログインを探す
sudo ausearch -m USER_LOGIN --success no -i

1件のイベントは複数行のレコードで構成されます。type=SYSCALL の行に、実行したプログラム（exe）、ログインUID（auid）、実効UID（euid）、成功・失敗（success）、キー（key）が入っています。type=PATH の行には対象ファイルのパス、type=PROCTITLE には実行時のコマンドラインが記録されます。PROCTITLE は16進数で保存されていますが、-i を付ければ元の文字列に戻して表示されます。

調査では、まず -k でキー単位に絞り、気になるイベントの auid を確認し、そのユーザーの同じ時間帯の操作を -ua と --start、--end で追う、という流れにすると効率的です。

aureportで全体を把握する

aureport は監査ログを集計してレポートにします。個別のイベントを見る前に「何が起きているか」を俯瞰するのに向いています。

# 全体のサマリー
sudo aureport --summary

# キーごとの件数
sudo aureport -k --summary

# 認証（ログイン試行）の一覧
sudo aureport -au -i

# 失敗したイベントだけ
sudo aureport --failed --summary

# 実行ファイル別の件数（今日の分）
sudo aureport -x --summary --start today

aureport -k --summary でキーごとの件数を定期的に見ておくと、急に件数が増えたキーに気付けます。普段は数件しかない identity が一晩で数十件になっていれば、アカウントの追加や変更が行われた可能性があるので、その時間帯を ausearch で詳しく確認します。

運用でつまずきやすい点

• ログ量の増えすぎ: ルールを追加したら数日は /var/log/audit/ の容量と auditctl -s の lost を見て、多すぎるルールを絞ります。ディスクの空きが少なくなったときの動作は auditd.conf の space_left_action と disk_full_action で決まります。
• バッファ不足: 起動直後やバッチ処理中にイベントが集中すると取りこぼしが起きます。-b 8192 などでバッファを増やします。auditd が起動する前のプロセスも監査したい場合は、カーネルの起動パラメータに audit=1 を加えます。
• ログの保全: 侵入されたサーバー上のログは改ざんされる可能性があります。重要なサーバーでは、auditd のプラグイン（syslog 連携や audisp-remote）を使って別サーバーへ転送しておくと証跡として信頼性が上がります。
• WordPressの設置場所: 例の /var/www/html/ はサーバーによって異なります。親ディレクトリが存在しないパスを -w に書くとそのルールは読み込めず、監視されないままになるため、実際のドキュメントルートに合わせて書き換え、auditctl -l に表示されることを確認します。

パッケージのバージョンやサンプルルールの配置はディストリビューションによって異なります（2026年10月現在、RHEL系・Debian系とも audit 3系以降が主流です）。手順を本番に適用する前に、検証用のサーバーで auditctl -l と実際のログ出力を確かめてください。

まとめ

• auditd はカーネルの監査イベントを記録するデーモンで、auid によって sudo 後の操作も元のログインユーザーにひも付けられます。
• ルールはまず auditctl で試し、/etc/audit/rules.d/ に書いて augenrules --load で恒久化します。audit.rules は直接編集しません。
• ファイル監視は -w パス -p wa -k キー名、コマンド実行の監視は execve のシステムコールルールを auid で絞って使います。
• 調査は aureport で全体を見て、ausearch -k ... -i で個別のイベントを確認する流れが効率的です。
• ログ量・lost の値・ディスク容量を定期的に確認し、-e 2 によるロックはルールが固まってから使います。

• SSHのログイン履歴を確認する方法
• サーバー侵入時の初動対応