【テクニカル・上級編】 Linux監査システム(auditd)によるログ監視の構築 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

Linux監査の真実：auditdによるシステムコール監視と、ログ改ざんを防ぐ要塞化アーキテクチャ

こんにちは。数々のインシデントレスポンスの現場を渡り歩いてきたが、いつも痛感させられるのは、「侵入を防ぐこと」と同じくらい、いやそれ以上に「侵入された事実を正確に、かつ改ざん不能な形で残すこと」がいかに困難であるかという現実だ。

多くのシステム管理者は、syslogや/var/log/auth.logを眺めて満足している。だが、高度な攻撃者（APTグループや内部不正者）は、足跡を残さないために、あるいは自分に都合の良いようにそれらのログを書き換える術を心得ている。ログファイルそのもののタイムスタンプをいじり、関連するプロセス名を偽装し、痕跡を巧みに消し去るのだ。

そこで必要になるのが、ユーザーランドのロギングではなく、Linuxカーネルの深部（システムコールレベル）で何が起きているかを監視する auditd である。

今回は、単なるコマンドの羅列や教科書的な設定の紹介ではない。攻撃者がどのように特権を奪い、システムを蝕み、そして我々セキュリティアーキテクトがどのレイヤでそれを検知し封じ込めるべきか。その実践的な設計と実装のすべてを語ろう。

—

1. なぜsyslogでは不十分なのか？（カーネルレイヤ監視の必要性）

従来のsyslogは、アプリケーションやデーモンが「自発的に」出力したメッセージを収集する。ここに根本的な脆弱性がある。もし攻撃者がシステム管理権限（root）を奪取した場合、彼らは最初に行うのはログ出力プロセスの無効化、あるいはログファイルの直接的な改ざんだ。

一方、auditd（Linux Audit Subsystem）は、カーネル空間で直接動作する。
プロセスがディスク上のファイルを読み書きした瞬間、特権昇格のために execve システムコールを叩いた瞬間、あるいはネットワークソケットを開いた瞬間——これらすべてを、カーネルが直接フックし、ユーザーランドの監査デーモンへと安全に非同期で引き渡す。

[ ユーザーランド (アプリ/シェル) ]
        │
        ▼ (システムコール発行: sys_execve 等)
[ カーネル空間 (Linux Audit Subsystem) ] ───► 強制的にイベント生成
        │
        ▼ (Netlinkソケット経由で安全に転送)
[ ユーザ空間の auditd デーモン ] ──────────► ローカルディスク / リモート転送

攻撃者がどれほど巧妙に bash の履歴を消去しようとも、プロセスが起動されたその瞬間の sys_execve システムコールの引数（実行バイナリパス、引数、環境変数）は、すでにカーネルによってキャプチャされ、リモートへ飛ばされている。この「不可逆な事実の記録」こそが、フォレンジックにおける最強の武器となる。

—

2. 攻撃者の盲点を突く：実戦的な auditd ルール設計

auditd のデフォルト設定は、いわば「素の状態」だ。そのままではノイズが多いか、あるいは肝心な攻撃の兆候を捉えられない。ここでは、現場のインシデントハンドラーが必ず投入する、高精度な監査ルールを構築しよう。

ルールファイルは通常 /etc/audit/rules.d/audit.rules（または個別の .rules ファイル）に記述する。以下に、特権昇格、重要ファイルの改ざん、および不正なプロセスの実行を監視するための実践的設定を示す。

# ==========================================
# Linux Audit Daemon 実戦向け要塞化ルール
# ==========================================

# 1. 監査ルールの動的な変更を禁止（シングルユーザーモード以外での改ざんを防ぐ）
-e 2

# 2. 特権昇格（SUID/SGID実行）の監視
# システム内のSUID/SGIDファイルが実行された瞬間をキャプチャし、誰が特権を奪おうとしたかを暴く
-a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -k privilege_escalation
-a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -k privilege_escalation

# 3. 重要なシステム設定ファイルへの不審なアクセス監視
# /etc/passwd や /etc/shadow への書き込み試行は、バックドア作成の明白な兆候である
-w /etc/passwd -p wa -k identity_tampering
-w /etc/shadow -p wa -k identity_tampering
-w /etc/group -p wa -k identity_tampering
-w /etc/sudoers -p wa -k sudoers_modification
-w /etc/sudoers.d/ -p wa -k sudoers_modification

# 4. ネットワーク設定およびファイヤーウォールの変更検知
-w /etc/hosts -p wa -k network_modification
-w /etc/resolv.conf -p wa -k network_modification
-w /sbin/iptables -p x -k firewall_tampering
-w /usr/sbin/nft -p x -k firewall_tampering

# 5. セキュリティログ自体の改ざん・削除対策
# 攻撃者は必ず audit のログや設定を消そうとする。そこを逆手に取る
-w /var/log/audit/ -p wa -k audit_log_tampering
-w /etc/audit/ -p wa -k audit_config_tampering
-w /etc/libaudit.conf -p wa -k audit_config_tampering

# 6. 未承認の特権コマンド（useradd, groupadd等）の実行監視
-w /usr/sbin/useradd -p x -k user_account_creation
-w /usr/sbin/groupadd -p x -k user_account_creation
-w /usr/bin/passwd -p x -k password_change

設定のポイント

-e 2（Immutableモード）を指定している点に注目してほしい。この設定を有効にすると、一度ルールをロードした後は、システムを再起動するまでルールを動的に変更・削除できなくなっている。万が一、root権限を奪われたとしても、攻撃者は監査ルールを勝手に緩めることができない。

—

3. ログの生存戦略：ローカル書き込みの限界とリモート転送

どれほど堅牢なルールを書いても、そのログが侵害されたサーバーのローカルディスク（例: /var/log/audit/audit.log）に保存されている限り、ルート権限を持った攻撃者には無力だ。彼らは dd コマンドでログを上書きしたり、ディスクそのものを改ざんしたりする。

真の要塞化とは、「生成されたログを、リアルタイムかつセキュアに別系統のログサーバー（SIEM等）へ流し込むこと」である。

ここでは、audisp-syslog プラグインや専用の転送エージェント（FluentbitやLogstashなど、あるいは auditd 標準のリモート転送機能）を用い、TLS暗号化されたチャネル経由でログを隔離された集約サーバーへ飛ばす構成を推奨する。

audisp-remote を用いた暗号化転送の設定（概要）

監視対象サーバー（クライアント）側の設定ファイル /etc/audit/audisp-remote.conf を以下のように調整し、信頼されたログサーバーへイベントをストリーミングする。

# /etc/audit/audisp-remote.conf の主要設定例
remote_server = 192.168.100.50  # ログ集約サーバーのIPアドレス
port = 60                       # 転送先ポート
local_port = 0
transport = tcp                 # 信頼性の高いTCPを使用
queue_depth = 2000
format = managed
network_failure_action = syslog
disk_full_action = warn
overflow_action = syslog

# 商用環境では必ずTLS証明書による相互認証（mTLS）を有効化すること
enable_krb5 = no

さらに、ログ集約サーバー側では、受け取った監査ログに対して書き込み専用（Append-Only）の権限を付与するか、WORM（Write Once, Read Many）特性を持つストレージ、あるいはクラウド上のオブジェクトストレージ（オブジェクトロック有効）へ即座に同期するパイプラインを構築しておくべきだ。

—

4. 運用上の罠：パフォーマンス劣化とノイズの調停

セキュリティアーキテクトとして現場に立つと、開発チームやインフラチームから必ずこういうクレームが飛んでくる。
> 「おい、セキュリティの監査設定を入れたら、DBサーバーのレスポンスが落ちたぞ」

これは事実だ。過剰なシステムコール監視（例: すべてのファイルの読み取り r を監視するような愚かな設定）を行うと、カーネルとユーザーランドの間でコンテキストスイッチが頻発し、I/O性能が著しく低下する。

このトレードオフを解消するための鉄則を挙げておこう。

1. ファイル監視における -p r（読み取り）の原則禁止
confidentialな設定ファイルでない限り、読み取りまで監視してはならない。監視対象は原則として w（書き込み）、a（属性変更）、x（実行）に絞る。
2. バッファサイズの最適化
/etc/audit/auditd.conf 内の backlog_buf_size をシステムの負荷に応じて適切にチューニングする。ビジーなWeb/DBサーバーでは、デフォルト値（例: 8192）では溢れてしまい、カーネル側でパニックやログ落ち（LOST イベント）が発生する。

# /etc/audit/auditd.conf のチューニング例
   backlog_buf_size = 65536
   backlog_wait_time = 60000
   
   # バッファ溢れ時のアクション（高セキュリティ環境ではパニックかシャットダウンを選ぶこともある）
   space_left_action = email
   action_mail_acct = root
   admin_space_left_action = halt

3. ノイズのフィルタリング
特定のバッチ処理や監視エージェントが毎秒発生させる無駄なシステムコール（例えば、高頻度で動く監視スクリプトによる /proc へのアクセスなど）が監査ログを埋め尽くさないよう、-F auid!=4294967295（ログインセッションを持っていないデーモンプロセスの除外など）を適切に活用し、シグナルとノイズを明確に分離する。

—

5. まとめ：セキュリティの終着点は「検知の非対称性」をつくること

攻撃者は常に効率的かつ静かにシステムを侵食しようとする。彼らにとって理想的な環境とは、「誰も見ていない、あるいはログが簡単に改ざんできるシステム」だ。

我々防御側が目指すべきは、その非対称性を破壊することにある。
攻撃者がどれほど巧妙に権限を奪い、痕跡を消そうとも、カーネルの深部で起きた事実がリアルタイムに暗号化されて外部のイミュータブルなストレージに保管されている——この事実を攻撃者が認識した瞬間、そのターゲットの価値は劇的に下がる。

auditd による監視の構築は、単なるコンプライアンス（PCI-DSSやCIS Benchmarkなど）のチェックリストを埋めるための作業ではない。それは、システムが侵害されたその最悪の瞬間においてすら、「真実の証言者」を手元に残すための、極めてロバストな防衛エンジニアリングなのだ。

インフラの要塞化に終わりはない。今日からでも /etc/audit/rules.d/ を見直し、真に価値のあるシステムコールだけを鋭く捕らえる仕組みを組み上げてほしい。