「サーバーに不審なアクセスがあった気がする」「ログは取っているけれど、どれを見ればいいかわからない」――情シス担当者やインフラエンジニアの方であれば、一度は感じたことがあるのではないでしょうか。
侵入の痕跡は、必ずどこかに残ります。問題は「どのログを、どう読み解くか」です。Linuxには標準で auditd というカーネルレベルの監査機構が用意されており、ファイルアクセス・コマンド実行・権限変更まで追跡できます。
ただし、auditdは「設定すれば全部見える」ものではありません。適切な監査ルールを設計し、ログを読み解くノウハウがなければ、膨大なログの山から侵入痕跡を見つけることはできません。
この記事では、auditdの仕組みから始めて、「侵入の痕跡を見抜くための監査ルール設計」「ausearch・aureportでの実践的な解析手順」「中小企業の情シス1人体制でも今日から始められる運用パターン」までを、現場で使えるレベルで解説します。
auditdとは？syslog・journaldとの違い
auditd（Linux Audit Daemon）は、Linuxカーネルが発生させた監査イベントを収集・記録するデーモンです。SELinuxやファイアウォールが「ポリシーで操作を制御する」のに対し、auditdは「操作の記録を残す」役割を担います。
監視対象はカーネル内部の動作までおよびます。具体的には、システムコール（ファイルオープン、execveなど）・ファイルアクセス・ユーザー認証・SELinuxイベント・ネットワーク接続といった粒度で記録できます。
syslog・journaldとの違いを整理すると次の通りです。
| 仕組み | 記録対象 | 主な用途 | 侵入検知への適性 |
|---|---|---|---|
| syslog（rsyslog） | アプリケーションのログ（任意） | サービスログの集約・転送 | 中（アプリ任せ） |
| journald | systemdサービスの起動・停止・stdout/stderr | サービス状態の追跡 | 中（systemd配下のみ） |
| auditd | カーネルの監査イベント（システムコール単位） | セキュリティ監査・コンプライアンス対応 | 高（操作レベルで追跡可能） |
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 インストール・systemd で有効化 | 10分 |
| ルール設計 | 認証・権限関連の監査ルールを /etc/audit/rules.d/ に配置 | 30分 |
| 反映確認 | augenrules –load → auditctl -l で動作確認 | 5分 |
| 解析手順整備 | ausearch・aureportのコマンドをチートシート化 | 30分 |
| 運用定着 | 週1回 aureport –summary で異常チェック | 5分／回 |
| 応用 | ログ集約サーバー連携・SIEM導入 | 数日（中規模以上向け） |
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の無料版から試すのがコストパフォーマンスに優れています。
「Linuxセキュリティ」の記事を読む
このテーマに関連する解説記事を一覧でまとめています。あわせてご覧ください。
