Posted inLinux

Linuxにおけるauditd設定ガイド：重要ファイルの監視、ユーザーコマンドの記録、不正侵入の追跡

Linux tutorial - IT technology blog
Linux tutorial - IT technology blog

背景とbash_historyだけでは不十分な理由

多くのシステム管理者は、ユーザー操作の追跡に依然として~/.bash_historyを頼りにしています。しかし、このアプローチは極めて高リスクです。シェルにアクセスできる人物であれば、unset HISTFILEの実行、コマンド先頭へのスペース挿入、または履歴ファイルの/dev/nullへのシンボリックリンク作成といった簡単な操作で、容易に履歴記録を無効化できます。設定ファイルが不正に改ざんされたりデータが流出したりした際、監査証跡がほとんど残らない事態に陥りかねません。

Linux Audit Framework（デーモンauditd）は、この課題をカーネルレイヤーで根本から解決します。ファイルのオープン（openat）、変更（write）、削除（unlinkat）、バイナリ実行（execve）など、あらゆる重要なシステムコールをカーネルが直接捕捉します。攻撃者がユーザースペースのコマンド履歴を消去したとしても、カーネルレベルで記録されたログに手を加えることはできません。

リソース消費についても過度な心配は不要です。約1,200 req/sの負荷でNginxおよびNode.jsが稼働するUbuntu 22.04サーバー群（2 vCPU、4GB RAM）環境において、auditdデーモンの消費量はRAM 35MB未満、CPU使用率1.5%以下に収まっています。

サービスのインストール

Red Hat系ディストリビューション（RHEL、Rocky Linux、AlmaLinux）では、SELinuxの監査ログ収集などにも利用されるため、通常auditdが標準で組み込まれています。一方、Ubuntu/Debian環境（AppArmor採用環境など）では、APT経由で追加インストールします。

sudo apt update
sudo apt install -y auditd audispd-plugins

CentOS StreamまたはRocky Linux（Minimal構成等で未導入の場合）は以下の通りです。

sudo dnf install -y audit

OS起動時に自動起動するようサービスを有効化します。

sudo systemctl enable auditd
sudo systemctl start auditd

重要なお知らせ：systemctl restart auditdの実行は意図的にブロックされる設計となっています。これは、不正なプロセスがデーモンを勝手に再起動してログ収集を中断させるのを防ぐためのセキュリティ機構です。サービスを停止させずにルールを再読み込みするには、以下のコマンドを使用してください。

sudo augenrules --load
# プロセス全体の再起動がどうしても必要な場合：
sudo service auditd restart

詳細な設定手順

標準的なauditdシステムは、デーモン設定ファイル/etc/audit/auditd.confと、監視ルールを格納するディレクトリ/etc/audit/rules.d/の2つで構成されます。

1. ディスク容量枯渇を防ぐauditd.confの最適化

デフォルトのログファイル/var/log/audit/audit.logは急速に肥大化する可能性があります。ncduやdufなどでディスク容量を分析・把握したうえで、/etc/audit/auditd.confを開き、ストレージ制御パラメータを調整します。

# 各ログファイルの最大サイズを50MBに制限
max_log_file = 50

# ローテーション保持数を最大10世代に設定（総容量を約500MBに固定）
num_logs = 10

# 容量上限到達時に自動ローテーション
max_log_file_action = ROTATE

# I/O負荷のボトルネックを避ける非同期ディスク書き込み設定
flush = INCREMENTAL_ASYNC
freq = 50

2. 監査ルール（Audit Rules）の定義

/etc/audit/audit.rulesを直接編集しないでください。システム再起動時に上書きされてしまいます。独自のルールは/etc/audit/rules.d/custom.rulesに新規作成します。

sudo nano /etc/audit/rules.d/custom.rules

以下は、本番サーバーに適した実戦的な設定サンプルです。

# 読み込み前に古いルールを全消去
-D

# バッファサイズを8192イベントに設定（突発的なバースト負荷時のログ取りこぼしを防止）
-b 8192

# 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/sudoers -p wa -k sudoers_changes
-w /etc/sudoers.d/ -p wa -k sudoers_changes

# 2. SSH設定の監視
-w /etc/ssh/sshd_config -p wa -k sshd_config

# 3. 実ユーザー（UID >= 1000）が実行したすべてのコマンドを記録
-a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=unset -k user_commands
-a always,exit -F arch=b32 -S execve -F auid>=1000 -F auid!=unset -k user_commands

# 4. システム時刻の変更操作を監視
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time_change
-a always,exit -F arch=b64 -S clock_settime -k time_change

# 5. ルールをイミュータブル（変更不可）状態にロック（必ず末尾に記述）
-e 2

覚えておくべき中核パラメータ：

  • -w <path>：監視対象のファイルまたはディレクトリのパス。
  • -p wa：書き込み（w – write）およびファイル属性変更（a – attribute change）イベントを捕捉。
  • -k <key>：ausearchによる迅速なログ照会用の識別識別タグ（キー）。
  • -F auid>=1000：ログインした実ユーザーによるイベントのみを捕捉。cron、nginx、prometheusなどのバックグラウンドデーモンを除外してログの氾濫を防ぎます。
  • -e 2：全ルールを変更不可（Immutable）状態に固定。この設定を有効にすると、root権限であってもサーバーを再起動しない限りルールの変更や無効化ができなくなります。

ファイルを保存後、新しい設定をカーネルに反映させます。

sudo augenrules --load

インシデントログの照会と分析

生のログファイルには16進エンコード文字列や生のUNIXタイムスタンプが含まれているため、目視での直接確認は困難です。標準ユーティリティであるausearchとaureportを活用して分析します。

1. カーネルにロードされているルールの確認

sudo auditctl -l

2. 重要ファイルの改ざん痕跡を追跡

システムアカウントの不正操作が疑われる場合、キーidentity_changesでイベントをフィルタリングします。

sudo ausearch -k identity_changes -i

オプション-i（interpret）を指定すると、タイムスタンプをローカル日時に自動デコードし、UID/GIDを対応するユーザー名に変換して分かりやすく出力します。

type=SYSCALL msg=audit(21/10/2026 14:22:05.312:108) : arch=x86_64 syscall=openat success=yes exit=3 comm="vim" exe="/usr/bin/vim" auid=kien.nguyen uid=root gid=root key="identity_changes"

上記のログから、ユーザーkien.nguyen（ログイン時の元auid）がroot権限昇格の上、vimエディタを使用してファイルを操作した事実が正確に判明します。

3. 当日実行されたユーザーコマンドの抽出

本日の開始時点から現在までにユーザーが入力したコマンドを全件監査する場合：

sudo ausearch -ts today -k user_commands -i

実行されたコマンドライン引数の全容と、それを呼び出した親プロセスの情報が出力されます。

4. aureportによるサマリーレポートの出力

セキュリティ監査チームへの報告や定期点検時には、aureportを用いることで主要指標を素早く集計できます。

  • ログイン試行の統計（成功および失敗）：
sudo aureport --auth -i
  • アクセス頻度の高いファイル上位の集計：
sudo aureport -f -i --summary
  • 権限昇格セッション（sudo / su）の監査：
sudo aureport -u -i

重要な認証ファイルとユーザーコマンドを正しく監視下に置くことで、ユーザースペースからの証跡消去に惑わされることなく、障害やインシデント発生時に確固たる照合データを確保できる独立した監査基盤が完成します。さらに監査ログを安全に退避・保全したい場合は、systemd-journal-remote等によるログの集約管理と併用するのも効果的です。

Share:
Tags: