Linux監査ログ解析による侵入検知

Linux監査ログ解析による侵入検知 は何をしますか？

使用するタイミング

• Linuxホストにおける不正アクセスまたは特権昇格の疑いを調査する場合
• エクスプロイト、バックドアインストール、持続化メカニズムの証拠を探す場合
• システムコール監視を必要とするセキュリティベースライン（CIS、STIG、PCI-DSS）への準拠を監査する場合
• インシデント対応において攻撃者の行動の時系列を再構築する場合
• /etc/passwd、/etc/shadow、SSH鍵などの重要なシステムファイルの改ざんを検出する場合

使用しない場合: ネットワークレベルの侵入検知には使わないでください。ネットワークトラフィック分析にはSuricataやZeekを使用してください。Auditdは個々のホストのカーネルレベルで動作します。

前提条件

• auditdパッケージがインストールされ、監査デーモンが動作しているLinuxシステム（systemctl status auditd）
• 監査ルールの設定とログの照会に必要なrootまたはsudoアクセス権
• /etc/audit/rules.d/*.rules に配置、または auditctl でロードされた監査ルール
• 推奨: 包括的なベースラインカバレッジのための Neo23x0/auditd ルールセット（GitHub）
• Linuxシステムコール（execve、open、connect、ptrace など）に関する知識
• 十分な保持期間を持つログストレージ（デフォルトの場所: /var/log/audit/audit.log）

ワークフロー

ステップ1: 監査デーモンの状態と設定を確認する

監査システムが動作していることを確認し、現在のルールセットを確認します:

# auditdサービスの状態を確認
systemctl status auditd

# 現在カーネルにロードされている監査ルールを表示
auditctl -l

# 監査デーモンの設定を表示
cat /etc/audit/auditd.conf | grep -E "log_file|max_log_file|num_logs|space_left_action"

# 監査バックログが超過していないか確認（ドロップされたイベント）
auditctl -s

バックログ制限に達している場合は、増やします:

auditctl -b 8192

ステップ2: 侵入検知に特化した監査ルールをデプロイする

一般的な侵入兆候を対象とするルールを追加します。/etc/audit/rules.d/intrusion.rules に配置します:

# 認証情報ファイルの不正な読み取りや変更を監視
-w /etc/passwd -p wa -k credential_access
-w /etc/shadow -p rwa -k credential_access
-w /etc/gshadow -p rwa -k credential_access
-w /etc/sudoers -p wa -k privilege_escalation
-w /etc/sudoers.d/ -p wa -k privilege_escalation

# SSH設定と認証鍵を監視
-w /etc/ssh/sshd_config -p wa -k sshd_config_change
-w /root/.ssh/authorized_keys -p wa -k ssh_key_tampering

# ユーザーおよびグループ管理コマンドを監視
-w /usr/sbin/useradd -p x -k user_management
-w /usr/sbin/usermod -p x -k user_management
-w /usr/sbin/groupadd -p x -k user_management

# ptraceによるプロセスインジェクションを検出
-a always,exit -F arch=b64 -S ptrace -F a0=0x4 -k process_injection
-a always,exit -F arch=b64 -S ptrace -F a0=0x5 -k process_injection
-a always,exit -F arch=b64 -S ptrace -F a0=0x6 -k process_injection

# 異常なディレクトリからのプログラム実行を監視
-a always,exit -F arch=b64 -S execve -F exe=/tmp -k exec_from_tmp
-a always,exit -F arch=b64 -S execve -F exe=/dev/shm -k exec_from_shm

# カーネルモジュールのロードを検出（ルートキットのインストール）
-a always,exit -F arch=b64 -S init_module -S finit_module -k kernel_module_load
-a always,exit -F arch=b64 -S delete_module -k kernel_module_remove
-w /sbin/insmod -p x -k kernel_module_tool
-w /sbin/modprobe -p x -k kernel_module_tool

# リバースシェルのためのネットワークソケット作成を監視
-a always,exit -F arch=b64 -S socket -F a0=2 -k network_socket_created
-a always,exit -F arch=b64 -S connect -F a0=2 -k network_connection

# cronジョブの変更を検出（持続化）
-w /etc/crontab -p wa -k cron_persistence
-w /etc/cron.d/ -p wa -k cron_persistence
-w /var/spool/cron/ -p wa -k cron_persistence

# ログの削除や改ざんを監視
-w /var/log/ -p wa -k log_tampering

編集後、ルールを再ロードします:

augenrules --load
auditctl -l | wc -l   # ルール数を確認

ステップ3: ausearch で侵入兆候を検索する

ausearch を使用して監査ログから特定のイベントを検索します:

# 過去24時間のすべての失敗したログイン試行を検索
ausearch -m USER_LOGIN --success no -ts recent

# 特定のユーザーによって実行されたコマンドを検索
ausearch -ua 1001 -m EXECVE -ts today

# /etc/shadow へのすべてのファイルアクセスイベントを検索
ausearch -f /etc/shadow -ts this-week

# sudoによる特権昇格を検索
ausearch -m USER_CMD -ts today

# カーネルモジュールロードイベントを検索
ausearch -k kernel_module_load -ts this-month

# /tmp から実行されたプロセスを検索（一般的な攻撃ステージング）
ausearch -k exec_from_tmp -ts this-week

# SSH鍵の変更を検索
ausearch -k ssh_key_tampering -ts this-month

# 監査イベントIDで特定のイベントを検索
ausearch -a 12345

# 特定の時間範囲のイベントを検索
ausearch -ts 03/15/2026 08:00:00 -te 03/15/2026 18:00:00

# システムコール番号を解釈し、出力を読みやすく整形
ausearch -k credential_access -i -ts today

ステップ4: aureport でサマリレポートを生成する

aureport を使用して、トリアージのための集計サマリを生成します:

# すべての認証イベントのサマリ
aureport -au -ts this-week --summary

# すべての失敗イベントのレポート（ログイン、アクセスなど）
aureport --failed --summary -ts today

# 実行可能ファイルの実行レポート
aureport -x --summary -ts today

# すべての異常イベントのレポート（セグフォルト、プロミスキャスモードなど）
aureport --anomaly -ts this-week

# ファイルアクセスイベントのレポート
aureport -f --summary -ts today

# キー別の全イベントレポート（カスタムルールキーにマッピング）
aureport -k --summary -ts this-month

# すべてのシステムコールのレポート
aureport -s --summary -ts today

# ユーザー別にグループ化されたイベントのレポート
aureport -u --summary -ts this-week

# タイムライン構築のための詳細な時間ベースのイベントレポート
aureport -ts 03/15/2026 08:00:00 -te 03/15/2026 18:00:00 --summary

ステップ5: 攻撃タイムラインを再構築する

ausearchクエリを組み合わせて時系列のストーリーを構築します:

# ステップ5a: 初期アクセスのタイムスタンプを特定
ausearch -m USER_LOGIN -ua 0 --success yes -ts this-week -i | head -50

# ステップ5b: 攻撃者がアクセス後に何をしたかを追跡
# インシデント期間内の侵害アカウントからのすべてのイベントを取得
ausearch -ua <UID> -ts "03/15/2026 14:00:00" -te "03/15/2026 18:00:00" -i \
  | aureport -f -i

# ステップ5c: インシデント期間中に実行されたすべてのコマンドを抽出
ausearch -m EXECVE -ts "03/15/2026 14:00:00" -te "03/15/2026 18:00:00" -i

# ステップ5d: インストールされた持続化メカニズムを確認
ausearch -k cron_persistence -ts "03/15/2026 14:00:00" -i
ausearch -k ssh_key_tampering -ts "03/15/2026 14:00:00" -i

# ステップ5e: 横展開（アウトバウンド接続）を確認
ausearch -k network_connection -ts "03/15/2026 14:00:00" -i

ステップ6: 監査ログをSIEMに転送する

audisp-remote または auditbeat を設定して、ログを集中SIEMに転送し、相関分析を行います:

# オプションA: audisp-remote プラグインを使用
# /etc/audit/plugins.d/au-remote.conf を編集
active = yes
direction = out
path = /sbin/audisp-remote
type = always

# /etc/audit/audisp-remote.conf でリモートターゲットを設定
remote_server = siem.internal.corp
port = 6514
transport = tcp

# オプションB: Elastic Auditbeat を使用
# auditbeat をインストールし、/etc/auditbeat/auditbeat.yml を設定
# Auditbeat はカーネル監査フレームワークから直接読み取ります

主要な概念

用語	定義
auditd	カーネルから監査イベントを受け取り、/var/log/audit/audit.log に書き込むLinux監査デーモン
auditctl	監査システムを制御するコマンドラインユーティリティ: ルールの追加/削除、状態確認、バックログサイズ設定
ausearch	メッセージタイプ、ユーザー、ファイル、キー、時間範囲、イベントIDで監査ログを検索するクエリツール
aureport	トリアージやコンプライアンスのために監査イベントの集計サマリを生成するレポートツール
監査ルールキー (-k)	監査ルールに付与するユーザー定義のラベル。ausearch と aureport で関連イベントを高速フィルタリングできる
システムコール監査	システムコール（execve, open, connect, ptrace）のカーネルレベルでの監視。プロセスとファイルのアクティビティを捕捉する
augenrules	/etc/audit/rules.d/ 内のすべてのファイルを /etc/audit/audit.rules にマージし、カーネルにロードするユーティリティ

確認項目

• auditd が動作しており、ルールがロードされている（auditctl -l で期待されるルール数が返る）
• 監査バックログのオーバーフローがない（auditctl -s で backlog: 0 または低い値、lost: 0）
• ausearch が各カスタムキーに対してイベントを返す（ausearch -k <key> -ts today で結果が返る）
• aureport が認証、実行可能ファイル、ファイルイベントに対して空でないサマリを生成する
• タイムライン再構築により、攻撃者の行動の一貫した時系列が得られる
• 重要なファイル監視がテスト操作（touch /etc/shadow）でアラートをトリガーする
• ログが中央SIEMに転送されている（テストイベントで受信を確認）
• 監査ルールが再起動後も持続する（ルールが /etc/audit/rules.d/ にあり、auditctl 経由のみではない）