セキュリティ

Linux Auditd – セキュリティイベントを適切に記録する

Linux Auditd カーネルから直接セキュリティ関連のイベントを記録し、ログイン、ファイルの変更、コマンドの実行、システム呼び出しに関する完全な監査証跡を提供してくれます。. 正しい 設定を行うことで、攻撃を早期に検知し、ISO 27001やPCI DSSなどのコンプライアンス要件を満たし、インシデントをフォレンジック的に信頼性の高い方法で分析します。.

中心点

此れ概要については、監査ルールの定義方法、ログの保護方法、そして知見の導き出し方をすぐに理解できるよう、あえて簡潔かつ実践的に、決まり文句を排してまとめています。. I 主要な構成要素、代表的な使用例、有用なルール、および多くの環境において見落とされがちな問題点を挙げなさい。. 然れば auditd.conf のどの設定が有効か、また分析に利用できるツールがどれか、一目で確認できます。. その後 各テーマについて、具体例や明確な推奨事項、そして重要なパラメータをまとめた表を用いて詳しく解説しています。. だから 「Auditdが動作している」状態から、「Auditdが実用的なセキュリティシグナルを提供している」状態へと移行できるようになります。.

監査証跡: セキュリティに関連するアクションの完全な追跡可能性
ルール: 特定の重要なファイル、execve、権限、および設定
ログ保護: ローテーション、メモリトリガー、ボトルネック時の対応
リモート: TCP/TLS による一元的な収集および SIEM との連携
分析: ausearch、aureport、明確なキー、そして整然としたドキュメント

セキュリティ対策におけるLinux Auditd

Auditd セキュリティに関連するアクションに的を絞り、カーネルインターフェースを介してイベントを記録することで、従来のシステムログを補完します。. 仝 Daemonはデフォルトでこれらのイベントを以下の場所に書き込みます /var/log/audit/audit.log また、どのユーザーが、どの操作を、いつ実行したかを記録します。. その結果、 疑わしい点を素早く確認できます。例えば、意図しない変更が /etc/ssh/sshd_config あるいは、次のような機密性の高いファイルなど /etc/shadow. 時点では 規制対象の環境において、これによりポリシー違反の証拠を確保し、信頼性の高いログ記録に関する要件を満たしています。. 向かい側 従来のジャーナルやSyslogデータとは異なり、Auditdは、攻撃の分析において重要な、セキュリティに重点を置いた詳細な視点を提供します。.

アーキテクチャ：カーネル、デーモン、ツール

仝監査システムは、記録を行うカーネルサブシステムと、ユーザースペースサービスに分けられる 監査役 保存機能、および管理・分析のためのツール。. について auditctl 実行時にルールを設定するか、起動時に永続的なルールを読み込むか /etc/audit/rules.d/*.rules. と一緒に ausearch イベントを時間、ユーザー、キー、またはファイルでフィルタリングする一方で、 aureport 簡潔なレポートを生成します。. 然れば きめ細かなデータ収集と迅速な分析を組み合わせ、監査証跡を一貫して追跡可能にしています。. 重要は、一貫した命名法であり、 -k キーを設定することで、後のクエリが正しく機能するようになります。.

インストールと有効化

時点では RHEL/CentOSをインストールします 監査 via dnf install audit 或いは yum install audit, Debian/Ubuntuでは、私は apt install auditd audispd-plugins. によると インストールが完了したら、以下のコマンドでサービスを起動・有効化します。 systemctl start auditd そして systemctl enable auditd, ステータスは以下で確認します systemctl status auditd. すぐに 監査サブシステムとサービスが実行されている場合、ルールに従ってイベントは /var/log/audit/audit.log. I 監視対象のファイルに意図的にアクセスして正常に動作することを確認し、その後、以下のコマンドでそのイベントを検索します。 ausearch -k keyname. のために 起動のたびに一貫した動作を確保するため、永続的なルールが設定され、正しく読み込まれるようにしています。.

早期開始、バックログ、およびルールによる保護

宛先起動直後のイベントを見逃さないように、カーネルの起動時に監査サブシステムを有効にしています。. これについて 起動段階においてイベントが失われないよう、カーネルパラメータを設定し、十分なバックログサイズを確保します。. さらに 読み込み後、ルールベースが改ざんされないようロックします。.

カーネルパラメータ: audit=1 audit_backlog_limit=8192 に於いて /etc/default/grub 追加し、その後 アップデート・グラブ (Debian/Ubuntu)または grub2-mkconfig -o /boot/grub2/grub.cfg (RHEL/CentOS) を実行する。.
ルールにおけるバックログ: 開始ルールでは、次のように設定しています -b 8192, カーネルキューのサイズを適切に設定するため。.
ルールを非表示にする: 最終的なルールベースの読み込みが完了したら、次のようにしてImmutableモードを有効にします。 -e 2. 変更は再起動後のみ可能となり、稼働中の改ざんに対する効果的な保護策となります。.
オーバーフローの挙動: 『In』 /etc/audit/auditd.conf 私は定義する overflow_action (例 SYSLOG 或いは シングル)、バッファが満杯の状態でも明確に定義された反応が得られるようにするためです。.

監査ルールを適切に定義する

仝監査証跡の品質は、重要な操作を網羅しつつ、不要なノイズを排除する、明確かつ的を絞ったルールにかかっている。. のために 機密性の高いファイルについては、例えば -w /etc/passwd -p warx -k passwd_changes そして、以下の項目について適切なルールを追加してください /etc/shadow, /etc/sudoers 或いは /etc/ssh/. 宛先コマンドの実行状況を記録するために、私は -a always,exit -F arch=b64 -S execve また、32ビット版も用意されており、これにより、以下の方法でもすべてのバージョンが確認できるようになっています。 根元. のために Apache などのユーティリティについては、バイナリのパスを指定してフィルタリングしています。例えば、 -a always,exit -F arch=b64 -S all -F exe=/usr/sbin/apache2 -k apache_activity. I 各ルールには簡潔なコメントと明確なキーを付けて記録し、分析結果が再現可能であり、同僚がその意図を理解できるようにしてください。.

高度なルール例とチューニング

のために さらに踏み込んで、特権の切り替え、カーネルへの介入、時間やネットワークの設定変更、そして永続的なメカニズムを可視化する、焦点を絞ったセットを構築します。パッケージやバックアップによるノイズは排除します。.

インタラクティブなユーザーのみ: -F auid>=1000 -F auid!=4294967295 に追加して execve-システムサービスを除外するためのルール。.
特権の切り替え: -a always,exit -F arch=b64 -S setuid,setreuid,setresuid -k priv_change および32ビット版。オプション： -C uid!=euid, 、フィールド比較がサポートされている場合。.
カーネルモジュール: -a always,exit -F arch=b64 -S init_module,finit_module,delete_module -k kmod_change; さらに： -w /sbin/insmod -p x -k kmod_exec, -w /sbin/modprobe -p x -k kmod_exec.
時間の変更: -a always,exit -F arch=b64 -S adjtimex,settimeofday,clock_settime -k time_change そして -w /etc/localtime -p wa -k time_change.
マウントとファイルシステム: -a always,exit -F arch=b64 -S mount,umount2 -k fs_mount; -w /etc/fstab -p wa -k fs_mount.
ネットワーク基盤: -a always,exit -F arch=b64 -S sethostname,setdomainname -k net_conf; -w /etc/hosts -p wa -k net_conf, -w /etc/hostname -p wa -k net_conf, -w /etc/resolv.conf -p wa -k net_conf.
Cronとタイマー: -w /etc/crontab -p wa -k sched, -w /etc/cron.d/ -p wa -k sched, -w /var/spool/cron/ -p wa -k sched, -w /etc/systemd/system/ -p wa -k sched, -w /usr/lib/systemd/system/ -p wa -k sched.
SSH 経由での永続化: -w /root/.ssh/ -p wa -k ssh_keys, -w /home/ -p wa -k ssh_keys (狭い小道で authorized_keys（ノイズを防ぐため、ユーザーごとにファイル数を制限しています）。.
SUID／SGIDの悪用を抑制する: 実行可能ファイルが格納されているディレクトリに焦点を当てる： -w /usr/bin/ -p wa -k bin_change, -w /usr/sbin/ -p wa -k bin_change, -w /bin/ -p wa -k bin_change, -w /sbin/ -p wa -k bin_change.
失敗のみを記録する （大音量のシステムコールの場合）： -a always,exit -F arch=b64 -S open,openat -F success=0 -k file_denied.
ノイズを低減する: パッケージマネージャーやバックアップを除外する。例：. -a never,exit -F exe=/usr/bin/dpkg, -a never,exit -F exe=/usr/bin/apt, -a never,exit -F exe=/usr/bin/yum, -a never,exit -F exe=/usr/bin/rpm, -a never,exit -F exe=/usr/bin/rsync （ディストリビューションごとにパスを確認してください）。.

ログ管理とログ損失の防止

なし適切なローテーションと明確なしきい値が設定されていない場合、監査ログは貴重なデータを失ったり、ファイルシステムを埋め尽くしたりするリスクがあります。. 時点では /etc/audit/auditd.conf 私が定義するものは、とりわけ以下の通りである max_log_file, max_log_file_action, num_logs, space_left そして、次のような反応や space_left_action, disk_full_action 或いは disk_error_action. I 次のようなキャンペーンを好む ROTATE また、Syslogへの早期通知を行い、ボトルネックが発生した際に迅速に対応できるようにします。. さらに 影響を受けたシステムでの改ざんを困難にし、証拠を保全するために、監査ログを別のホストに保存しています。. 仝以下の表では、主要なパラメータを分類し、実用的な標準的な設定を示しています。.

パラメータ	目的	例	ヒント
`log_file`	監査ログの保存場所	`/var/log/audit/audit.log`	標準パスを維持し、権限を明確に確保する
`log_format`	イベントの形式	`RAW`	RAWは、情報の損失なくフォレンジック解析を容易にする
`max_log_file`	最大ファイルサイズ（MB）	`100` まで `500`	イベントの発生量とストレージ容量に合わせて調整する
`max_log_file_action`	指定サイズに達した際のキャンペーン	`ROTATE`	ローテーションにより、データが失われたり上書きされたりするのを防ぎます
`num_logs`	保持されているファイルの数	`5` まで `10`	分析に必要なだけの履歴データを保持しつつ、ストレージを圧迫しない
`space_left`	空きメモリのしきい値 (MB)	`1024` 以上	早期のアラートにより、対応時間を確保できる
`space_left_action`	基準値を下回った場合の対応	`SYSLOG`	さらに、メールやSIEMアラートの導入も検討する
`disk_full_action`	ストレージ容量がいっぱいになった場合の対処法	`SUSPEND` 或いは `STOP`	リスク許容度に応じた明確な判断

リモートロギングと一元的な分析

のために 多くのホストについては、次のようなパラメータによって制御される、TCP/TLS による集中管理を採用しています。 tcp_listen_port および対応する端末。. について audispdプラグインやrsyslogを使用して、イベントをSIEMやセキュリティプラットフォームに転送し、ログインエラー、設定変更、不審なプロセスの起動を相関分析します。. 然れば 単一のサーバー上では目立たないようなパターンでも、それらを組み合わせると即座にアラートが発信されることに気づきます。. 誰がすでにダッシュボードを導入している企業は、以下のメリットを享受できます。ホスティングにおけるログ集約, 、なぜなら、そこでは監査イベントが他のテレメトリデータと統合されるからです。. I また、安全な転送経路を確保し、本番システムと集約インスタンスを明確に分離するようにしてください。.

分析：ausearchとareportを効果的に活用する

生データ すぐにフィルタリングできなければ意味がないので、まずは明確なキーから始め、 ausearch 的を絞った検索のために。. と一緒に ausearch -k passwd_changes -ts today 例えば、以下の点に関する最近の変更を評価しています /etc/passwd 以上です。必要に応じて、時間枠やユーザーフィルターを微調整します。. のために 概要レポートを提供します aureport --summary 目立つログイン、ファイルの変更、システムコールの頻度を可視化するコンパクトな表。. さらに プロセス起動とリソース使用状況に関する見解に、以下を追加します。プロセス会計, 、実行内容と負荷のピークを関連付けるために。. オン結局のところ、重要なのは、「誰が、何を、いつ、どこで、どのような方法で」という質問に数秒で答えられるかどうかだ。.

分析をさらに深める：イベントフィールドの正しい読み方

だから 分析結果が正確であるためには、主要なフィールドとイベントの種類を把握しておく必要があります。. SYSCALL- 項目には、とりわけ以下のものが含まれる。. auid (登録UID)、, uid/euid/suid (実UID/有効UID/保存UID)、, ses (セッションID) および exe （実行ファイル）。. PATH-ブロックは影響を受けるパスを示し、, EXECVE その論拠を列挙し、, CWD 作業ディレクトリを指定します。. と一緒に ausearch -m SYSCALL -sc execve -ua 1000 -ts recent ここでは、インタラクティブな実装に焦点を当てています；; aureport -x --summary -i 頻度や特異な点を一目で把握できる。. 重要: auid 残るのは スド あるいは、setuidジャンプは一定であるため、「誰が引き金となったのか」という観点では、より堅牢なフィルタリング基準となる。.

典型的なミスを避ける

へ広範なルールはログを肥大化させ、本当に重要な手がかりを隠してしまうため、私は重要なファイル、execve、権限の切り替え、およびセキュリティに関連する設定に焦点を当てています。. 欠落適切なローテーションが行われないと、システムにリスクが生じるため、規模や数、そしてボトルネック時の対応について明確な基準を設けています。. I 監査の設定とディレクトリも監視する /var/log/audit/, 、攻撃者は痕跡を消そうとするからです。. そして 分析結果の一貫性を保つため、各ルールについてキー、目標、および簡単な理由を記録しています。. 誰がパフォーマンスに懸念がある場合は、的確にフィルタリングを行い、不要なパスを削除し、新しいルールの影響をまずテストで確認すべきである。.

性能、安定性、品質チェック

監査業務の妨げになってはならない。. I 定期的に確認してください auditctl -s, 、かどうか lost-イベントが発生するかどうかを確認し、ルール変更後のバックログ値を監視する。. 時点では イベント負荷が高い場合は、ディスパッチャキューの容量を増やします（q_depth) audispdプラグインを有効にし、 overflow_action 意識的に。. どこで execve-ルールによってボリュームが過剰になる場合は、以下で制限します auid または以下のリンクから exe=- ホワイトリスト／ブラックリストを設定し、ノイズの多いシステムコールについては失敗のみをログに記録する。. 前本格的な展開に先立ち、ステージング環境で新しいルールを検証し、イベント発生率とCPU負荷を測定して比較します aureport --summary 変更前／変更後を比較し、その効果を定量化する。.

コンテナおよび仮想化環境

時点では カーネルはコンテナホストと同様にコンテナプロセスもログに記録します。これは意図された動作ですが、ログの出力が多くなる可能性があります。. I ホスト保護を基準とする（例：. dockerd またはPodman）、安全なバイナリパスと設定、およびユーザービューのフィルタリングを auid. 例: -w /usr/bin/dockerd -p x -k container_runtime, -w /etc/docker/ -p wa -k container_conf, 、さらに次のような汎用的なホストルールなど execve をもって auid-フィルター 時点では VMに関しては、監査ログを一時的なデータとして扱っています。リモート転送を有効にし、ローテーション間隔を短く設定し、スナップショットでは時間的一貫性に注意を払っています。. 重要タイムライン分析の信頼性を確保するためには、NTP/Chronyによる正確な時刻同期が不可欠です。.

コンプライアンスと記録管理

のために ISO 27001（A.12.4 ロギング／モニタリング、A.16 インシデント管理など）およびPCI DSS（第10章）に基づき、検証可能な証拠を策定します：何どのくらいの期間記録されるのか、誰がアクセスできるのか、整合性はどのように確保されるのか？ I ルールベースにバージョン管理を行い、キーと目的を文書化し、アーカイブログにハッシュ値で署名し、改ざん防止対策を施して保存する。. 時点では 個人データについては、データ最小化（対象を絞ったルール、短い保存期間）を適用し、明確な削除プロセスを定めています。. 然れば 監査人を納得させ、インシデント発生時に実際に答えを提供できるレポートが作成されます。.

運用、監視、およびプレイブック

時点では 常時稼働には、決まったルーチンが必要です。毎日の抜き取り検査で aureport, アラームが発生した際 lost > 0, 、空き監査パーティションおよびリモート転送の確認。. I プレイブックを作成：「目立つ幹部」（フィルター： exe= そして auid), 「重要なファイルが変更されました」（以下の項目との相関関係： PATH, SYSCALL, EXECVE), 「カーネルへの介入」（に関する規則） init_module そして マウント). 既知次のようなイベントの種類 ANOM_PROMISCUOUS （プロミスクモードのインターフェース）または MAC_POLICY_LOAD （MACポリシーが読み込まれた）ことを確認し、優先順位に基づいて評価を行い、対応手順を実行します。.

トラブルシューティングと再起動

いつイベントの通知が届かない場合は、まず確認します ausearch -m DAEMON -ts today そして auditctl -s (ステータス／バックログ)。. 欠席ルールについては、以下に載せておきます augenrules --load 新しくして、以下で確認してください auditctl -l. でしょうか？ Immutableモードが有効（-e 2)、起動ルールを調整して再起動するしかありません。. 時点では 権限に関する問題について /var/log/audit/ 所有者とモードを復元します。SELinuxが有効な場合は、コンテキストを修正します。. そして 私は以下を確認します。 log_format = RAW 設定されている――フォレンジックやパーサーが読み取り可能な入力。.

ホスティング環境における監査

ストレート ワークロードの多いホスティング環境において、Auditdはテナント分離の状態を可視化し、不正利用を早期に検知するのに役立っています。. I 段階的なルールセットを用いてWebサーバー、データベースサーバー、アプリケーションサーバーを監視し、そのイベントを既存の監視およびインシデント対応システムに統合します。. のために 一元的な保存、役割の分離、およびログディレクトリへのアクセス権の厳格な制限により、明確な分離を確保しています。. 宛先必要に応じて、システム診断の補足として以下を追加しますトラブルシューティングのための journalctl, 、ただし、セキュリティ上重要な分析は主に監査チャネルで行う。. 然れば これにより、顧客の利益、コンプライアンス要件、および業務効率を両立させる、信頼性の高い監査証跡が構築されます。.

手短に：私の進め方

I 明確な目標像を掲げて開始し、重要なファイル、execve、および権限変更に関する明確なルールを策定し、データ損失を防ぐためにローテーションを確実に実施してください。. それから TLS を使用したリモート転送を有効にし、鍵を記録し、各ルールの効果を、本格的に展開する前にテストします。. のために 日々の仕事では、私は以下を重視しています ausearch そして aureport, 、運用およびセキュリティ向けに、目的を絞った検索を実施し、分かりやすいレポートを作成します。. 時点では 異常が検出された場合、監査イベントをプロセスデータやネットワークデータなどの他のシグナルと照合し、原因を迅速に特定します。. 然れば LinuxのAuditdは、大量のログを吐き出すのではなく、本番環境におけるセキュリティ関連の疑問に対して明確な答えを与えてくれます。.