auditdログから侵入痕跡を見抜く実践ガイド｜不審操作の検知ルールと解析手順

「サーバーに不審なアクセスがあった気がする」「ログは取っているけれど、どれを見ればいいかわからない」――情シス担当者やインフラエンジニアの方であれば、一度は感じたことがあるのではないでしょうか。

侵入の痕跡は、必ずどこかに残ります。問題は「どのログを、どう読み解くか」です。Linuxには標準で auditd というカーネルレベルの監査機構が用意されており、ファイルアクセス・コマンド実行・権限変更まで追跡できます。

ただし、auditdは「設定すれば全部見える」ものではありません。適切な監査ルールを設計し、ログを読み解くノウハウがなければ、膨大なログの山から侵入痕跡を見つけることはできません。

この記事では、auditdの仕組みから始めて、「侵入の痕跡を見抜くための監査ルール設計」「ausearch・aureportでの実践的な解析手順」「中小企業の情シス1人体制でも今日から始められる運用パターン」までを、現場で使えるレベルで解説します。

auditdとは？syslog・journaldとの違い

auditd（Linux Audit Daemon）は、Linuxカーネルが発生させた監査イベントを収集・記録するデーモンです。SELinuxやファイアウォールが「ポリシーで操作を制御する」のに対し、auditdは「操作の記録を残す」役割を担います。

監視対象はカーネル内部の動作までおよびます。具体的には、システムコール（ファイルオープン、execveなど）・ファイルアクセス・ユーザー認証・SELinuxイベント・ネットワーク接続といった粒度で記録できます。

syslog・journaldとの違いを整理すると次の通りです。

auditdの特長は「アプリケーションが何を出力したか」ではなく「カーネルが何を許可したか」を記録できる点にあります。攻撃者がアプリケーションのログ機能を回避しても、カーネルの動作は隠せません。だからこそ、侵入痕跡の追跡に向いているのです。

侵入痕跡を見抜くための監査ルール設計

auditdを単に起動しただけでは、Linuxディストリビューションが用意したデフォルトルールしか動きません。RHEL系では /etc/audit/rules.d/audit.rules、Ubuntu系では同じパスもしくは /etc/audit/rules.d/ 以下の個別ファイルにルールを記述します。

侵入の痕跡を捉えるには、以下の観点でルールを設計するのが定石です。

・権限関連の変更を全て記録する: /etc/passwd・/etc/shadow・/etc/sudoersの読み書き
・認証情報の操作を追跡する: /var/log/auth.log・/var/log/secureへのアクセス
・不審なコマンド実行を記録する: wget・curl・nc（netcat）・python -cなどの実行
・権限昇格の試みを検知する: sudo・su・setuid系システムコール
・カーネルモジュールの変更を監視する: insmod・rmmod・modprobeの呼び出し
・SELinuxポリシーの違反を捕捉する: AVCイベントの常時記録

1. 必須レベルの監査ルール例

以下は中小企業のサーバーでも導入しやすい、必須レベルのルール集です。/etc/audit/rules.d/99-security.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 identity
-w /etc/sudoers.d/ -p wa -k identity

# =========================================
# 認証ログへのアクセスを記録（改ざん検知）
# =========================================
-w /var/log/auth.log -p wa -k auth_log
-w /var/log/secure -p wa -k auth_log
-w /var/log/wtmp -p wa -k login_log
-w /var/log/btmp -p wa -k login_log

# =========================================
# 権限昇格の追跡（setuid系システムコール）
# =========================================
-a always,exit -F arch=b64 -S setuid -S setgid -S setreuid -S setregid -k privilege_escalation
-a always,exit -F arch=b32 -S setuid -S setgid -S setreuid -S setregid -k privilege_escalation

# =========================================
# カーネルモジュール操作の追跡
# =========================================
-w /sbin/insmod -p x -k kernel_module
-w /sbin/rmmod -p x -k kernel_module
-w /sbin/modprobe -p x -k kernel_module
-a always,exit -F arch=b64 -S init_module -S delete_module -k kernel_module

# =========================================
# 危険コマンドの実行追跡
# =========================================
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/wget -k suspicious_cmd
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/curl -k suspicious_cmd
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/nc -k suspicious_cmd
-a always,exit -F arch=b64 -S execve -F path=/bin/nc -k suspicious_cmd

# =========================================
# crontab・cron設定の変更を記録
# =========================================
-w /etc/crontab -p wa -k cron_change
-w /etc/cron.d/ -p wa -k cron_change
-w /etc/cron.daily/ -p wa -k cron_change
-w /etc/cron.hourly/ -p wa -k cron_change
-w /var/spool/cron/ -p wa -k cron_change

ルールに付ける -k（キーワード） は、後で ausearch で絞り込むための識別子です。「identity」「privilege_escalation」「suspicious_cmd」のように、用途別に統一しておくと解析時に大きく時短できます。

2. ルールの反映と確認

ルールファイルを編集したら、auditdを再起動するか augenrules を使ってルールを反映します。

# rules.d/ 以下の全ファイルから audit.rules を生成
sudo augenrules --load

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

# auditd の再起動が必要な場合
sudo systemctl restart auditd

RHEL系ではsystemdからauditdを再起動できないため、service auditd restart を使う必要がある場合があります。auditctl -l でルールが反映されているか必ず確認してください。

ausearch・aureportによる実践的な解析手順

auditdのログは /var/log/audit/audit.log に書き込まれますが、生のログは難読です。専用の解析ツール ausearch と aureport を使うのが基本です。

1. キーワード単位で絞り込む

監査ルールに付けたキーワード（-k）で絞り込むのが最速の解析方法です。

# 認証ファイル関連の変更履歴を抽出
sudo ausearch -k identity

# 権限昇格の試みを抽出
sudo ausearch -k privilege_escalation

# 過去24時間の不審コマンド実行
sudo ausearch -k suspicious_cmd -ts recent

# 特定の日時範囲を指定
sudo ausearch -k identity -ts 04/30/2026 00:00:00 -te 05/03/2026 23:59:59

2. 失敗した認証を抽出する

ブルートフォース攻撃や不正ログイン試行は、認証失敗の連続として現れます。

# 認証失敗のサマリー
sudo aureport -au --failed --summary

# 特定ユーザーの認証履歴
sudo aureport -au -i | grep username

# 最近のログイン失敗を時系列で表示
sudo ausearch -m USER_LOGIN -sv no -ts today

3. プロセス実行の追跡

「いつ・誰が・何のコマンドを実行したか」を時系列で見るには、execveシステムコールを追います。

# 全プロセス実行の集計（実行回数の多い順）
sudo aureport -x --summary

# 特定ユーザーが実行したコマンドの一覧
sudo aureport -x | grep -E "username"

# 特定の時間帯にroot権限で実行されたコマンド
sudo ausearch -m EXECVE -ui 0 -ts 02:00:00 -te 04:00:00

4. ファイルアクセスの追跡

機密ファイルが「いつ・誰に・どう触られたか」を追えるのもauditdの強みです。

# /etc/shadow へのアクセス履歴
sudo ausearch -f /etc/shadow

# /var/log 配下への書き込み試行
sudo ausearch -f /var/log -p w

# 特定UIDのファイルアクセス（uid=1001の例）
sudo ausearch -ui 1001 -ts today

侵入痕跡として注目すべきパターン

監査ログには大量のイベントが記録されます。侵入痕跡として優先的にチェックすべきパターンを把握しておくことで、解析の効率が上がります。

1. 不自然な時間帯の権限昇格

業務時間外（深夜・休日）の su / sudo 実行は、第一に疑うべきイベントです。正規の運用作業であれば、変更管理ログや作業申請が必ず残っているはずです。

# 深夜帯のsudo実行を抽出
sudo ausearch -k privilege_escalation -ts 23:00:00 -te 06:00:00

2. /etc/passwd・/etc/shadow への書き込み

正規の運用で /etc/shadow を直接編集することはほぼありません。useradd・passwd コマンドを使うはずです。直接書き込みのイベントが記録されていれば、攻撃者がバックドアアカウントを仕込んだ可能性があります。

3. 短時間に集中した認証失敗

1分間に数十回の認証失敗は、ブルートフォース攻撃の典型パターンです。fail2banを併用すると自動でブロックできますが、auditdログを見ることで「攻撃者が何を試したか」まで分析できます。

4. wget・curlで外部から実行ファイルを取得

侵入後の典型的な動きとして、攻撃者は外部サーバーから追加のマルウェアやrootkitをダウンロードします。Webサーバーのapacheユーザーがwgetを実行していた場合、ほぼ確実に異常事態です。

# Webサーバーユーザーが外部通信コマンドを実行した形跡
sudo ausearch -k suspicious_cmd -ui apache
sudo ausearch -k suspicious_cmd -ui www-data
sudo ausearch -k suspicious_cmd -ui nginx

5. 不審なカーネルモジュールのロード

rootkitの一部はカーネルモジュールとして動作します。出所不明のモジュールがロードされた形跡は重大なシグナルです。

# カーネルモジュール操作の履歴
sudo ausearch -k kernel_module

中小企業・情シス1人体制でも今日からできること

auditdは強力ですが、設定を間違えるとログ量が爆発し、ディスク容量を圧迫することがあります。中小企業で導入する場合、次の手順を踏むのが現実的です。

・第一段階: 認証・権限関連のみ監査: /etc/passwd・/etc/shadow・sudo・suだけを記録対象にする
・第二段階: 重要サーバーで本格適用: Webサーバー・DBサーバーで全ルールを有効化
・第三段階: ログ集約と通知連携: rsyslog経由で集約サーバーへ転送、不審パターンを検知したらメール通知

ディスク容量への影響を抑えたい場合は、/etc/audit/auditd.conf でログローテートを適切に設定します。

# /etc/audit/auditd.conf の主要設定例
max_log_file = 50               # 1ファイル最大50MB
num_logs = 10                   # ローテートで保持するファイル数
max_log_file_action = ROTATE    # サイズ上限でローテート
disk_full_action = SUSPEND      # 容量逼迫時の動作（HALTは過激）
disk_error_action = SUSPEND
space_left = 200                # 残り200MBで警告
admin_space_left = 50           # 残り50MBで管理者通知

監視を始めたら、最低週1回はログのチェック時間を業務に組み込んでください。「設定したけれど見ていない」状態が一番危険です。aureportのサマリー機能を使えば、5分程度で「異常がないか」のざっくり確認はできます。

# 過去1日のサマリーレポート
sudo aureport --summary --start yesterday

# 認証イベントのサマリー
sudo aureport -au --start yesterday

# 異常終了したプロセスのサマリー
sudo aureport -p --start yesterday

よくある誤解と注意点

【注意1】auditdはリアルタイム検知ツールではない

auditdはあくまで「記録する」仕組みであり、不審な操作を即座にブロックするものではありません。リアルタイム検知が必要な場合は、auditd + auditbeat（Elastic）+ SIEM（Wazuh、Graylogなど）の組み合わせを検討してください。fail2banのような自動ブロック機構とは別物です。

【注意2】ログ改ざん対策は別途必要

攻撃者がroot権限を取った後、auditdのログ自体を消去する可能性があります。auditd単体ではログ改ざんを防げません。重要サーバーでは、リモートのログ集約サーバー（rsyslog over TLS、Wazuhマネージャ等）へ転送する設計を組み合わせてください。

【注意3】コンテナ・Kubernetes環境では設計が異なる

auditdはホストOSのカーネルレベルで動作するため、Dockerコンテナ内のプロセスもホストのauditログに記録されます。一方、コンテナ単位での監査ルール分離はできません。Kubernetes環境では、Falcoなどのコンテナ向け監査ツールとの併用を検討する必要があります。

【注意4】performance impactを軽視しない

execveを全て監査するルールは、ログ量と性能影響が大きくなります。CPU使用率の高いサーバーや、頻繁にプロセスをfork/execする処理（CIサーバーなど）では、対象を絞り込む設計が必須です。最初は識別キーワードを限定し、必要に応じて拡張するアプローチが現実的です。

【注意5】監査ルールの順番が結果に影響する

auditdのルールは記述順に評価されます。除外ルール（-A exit,never）を先に書くか、対象を限定するルールを先に書くかで挙動が変わります。複雑なルールセットを組む場合は、テスト環境で auditctl -l の出力順序を必ず確認してください。

本記事のまとめ

auditdは、Linuxサーバーへの侵入痕跡を追跡するうえで最も強力なツールの一つです。設定の難しさを理由に避けられがちですが、認証・権限・コマンド実行に絞った監査ルールであれば、中小企業の情シス1人体制でも十分運用できます。

侵入痕跡を見抜くための要点を整理すると、次のチェックリストになります。

auditdの設定は「Set and Forget（設定して放置）」が許される仕組みではありません。導入したら「週1回ログを見る」という習慣を作ることが、侵入の早期発見につながります。

Linuxのログ監視全般については、姉妹サイトLinuxMaster.JPでもsyslog・journalctl・logrotateの実践的な解説を扱っています。auditdと組み合わせて、サーバーのログ管理を体系化していただければ幸いです。

よくある質問（FAQ）

Q1. auditdとSELinuxの関係は？

SELinuxは「ポリシー違反の操作をブロックする」、auditdは「ポリシー違反のログを記録する」役割を担います。SELinuxが拒否したアクセス（AVC denial）はauditdに記録されるため、両者は密接に連携しています。SELinuxを有効にする場合は、auditdも必ず有効化しておくことを推奨します。

Q2. auditdログのディスク使用量はどれくらい？

監査ルールの内容によって大きく変わります。認証・権限関連のみであれば数MB／日、execve全監査では数百MB／日になることもあります。本記事の必須ルール例では、一般的な業務サーバーで10〜50MB／日が目安です。max_log_fileとnum_logsの設定で上限を制御してください。

Q3. auditd と OSSEC・Wazuhはどう使い分ける？

auditdは「記録に特化」、OSSEC/Wazuhは「記録 + 検知 + アラート」の統合HIDS（ホスト型侵入検知）です。中小企業で1〜数台のサーバー監査ならauditd単体でも十分ですが、複数サーバーの集約監視や自動アラートが必要ならWazuhの導入を検討してください。Wazuhは内部でauditdを利用しているため、両者は競合せず補完関係にあります。

Q4. ログを暗号化して転送できる？

auditd標準のリモート転送機構（audisp-remote）はTCP接続ですが、暗号化はサポートしていません。暗号化転送が必要な場合は、stunnelやrsyslog over TLSと組み合わせて、別経路で集約サーバーへ送る構成を取ってください。Wazuhやauditbeatを使えば、エージェント経由でTLS通信も可能です。

Q5. 古いログを自動で削除すると証拠が消えてしまうのでは？

その通りで、ローカルのみでログローテートを設定すると古い証跡は消えます。インシデント対応や監査要件があるなら、ログを集約サーバーや長期保存ストレージへ転送し、ローカルとは別に最低1年以上保管する設計が望ましいです。コンプライアンス要件（PCI DSSなら1年、ISO27001なら組織ポリシー次第）に合わせて保管期間を決めてください。

Q6. auditdが起動しない場合の対処は？

典型的な原因は3つです。1つ目は /etc/audit/audit.rules の構文エラー（auditctl -R /etc/audit/audit.rules でテスト）、2つ目はディスク容量不足（df -h で確認）、3つ目はSELinuxによるブロック（setenforce 0 一時的に確認）です。systemctl statusとjournalctl -u auditdで詳細を追ってください。

Q7. 過去のログをまとめて分析したい場合のおすすめツールは？

ローカル分析なら ausearch + aureport で十分ですが、大量ログを横断検索したい場合は Elastic Stack（Elasticsearch + Kibana + auditbeat）か Wazuh が定番です。商用ではSplunk、無料ではGraylogも選択肢になります。中小企業ならまずWazuhの無料版から試すのがコストパフォーマンスに優れています。