40 Linux 監査システムの概要 #Edit source
概要#
本バージョンの openSUSE Leap に同梱されている Linux 監査フレームワークは、 CAPP (Controlled Access Protection Profiles) 互換の監査システムとして提供され、セキュリティに関連するイベントを確実に収集します。監査記録からは、セキュリティポリシーへの違反有無と、それが誰によって行われたものであるのかを調べることができます。
監査フレームワークは CC-CAPP/EAL (Common Criteria-Controlled Access Protection Profiles/Evaluation Assurance Level) の認証を受ける際に重要な要件となるものです。また、 Common Criteria (CC) for Information Technology Security Information は、独立したセキュリティ評価に対する国際標準です。 Common Criteria の仕組みにより、顧客が任意の IT 製品に対するセキュリティレベルを判断し、ミッションクリティカルな環境への導入を支援することができます。
Common Criteria でのセキュリティ評価には、 2 種類の評価要件セット (機能要件／保証要件) があります。機能要件は評価対象の製品のセキュリティ属性を記述するもので、 Controlled Access Protection Profiles (CAPP) のもとまとめられるものです。一方の保証要件は、 Evaluation Assurance Level (EAL) に従ってまとめられるものです。 EAL は、評価者がセキュリティ属性を判断するにあたって、それが存在し、効果があって、実装されていることを確認するためのすべての作業を記述するものです。この種類の作業には、たとえば開発者によるセキュリティの脆弱性の検索、修正処理、テストなどの文書化が含まれます。
このガイドでは、監査システムの動作概要と、設定方法について説明しています。 Common Criteria に関する一般的な情報については、 コモンクライテリア (Wikipedia) などの情報をお読みください。
Linux 監査システムでは、お使いのシステム内で発生している内容を非常に細かく分析することによって、セキュリティをより強固にする支援を行います。ただし、それ自身でセキュリティが強化されるわけではありません。つまり、コードの誤動作や様々な脆弱性からシステムを保護するわけではありません。その代わり、監査システムではそれらの問題を追跡し、 AppArmor などのそれらを保護するための様々な仕組みを使用するよう促すためのものです。
監査システムは複数のコンポーネントから構成される仕組みですが、それぞれがフレームワーク全体に重要な機能を提供しています。監査システムのカーネルモジュールは、システムコールを中継し、その際に関連するイベントを記録します。また auditd デーモンは、監査レポートをディスクに記録します。このほか、様々なコマンドラインユーティリティを利用することで、監査証跡の表示や問い合わせ、書庫保存などを行うことができます。
監査システムは下記の機能を提供します:
- ユーザとプロセスとの関連づけ
監査システムはプロセスとそれを起動したユーザ ID との間の関連づけを行います。これにより、管理者やセキュリティ責任者が、プロセスを所有しているユーザを正確に追跡することができるほか、システム内での不審な動作を検出することができるようになります。
重要: ユーザ ID の名前変更について
監査デーモンは UID の変更を処理しません。そのため、たとえばユーザ名
tuxの UID をuid=1001からuid=2000に変更したり、廃止したりすることは避けてください。このような作業を行ってしまった場合は、auditctlデータ (監査ルール) を変更する必要が発生してしまうほか、古いデータを正しく取得できなくなってしまうことがあります。- 監査証跡の確認
Linux 監査システムでは、監査レポートのディスクへの書き込みだけでなく、レポートを人間にとって読みやすい形式に変換する処理も行います。
- 特定の監査イベントの確認
監査システムでは、監査レポート内の特定のイベントのみを抽出するためのユーティリティを提供しています。下記の検索条件を指定することができます:
ユーザ
グループ
監査 ID
リモートホスト名
リモートホストアドレス
システムコール
システムコールのパラメータ
ファイル
ファイル操作
成功もしくは失敗
- 選択的監査の適用
監査システムにはフィルタリング機能が用意され、注目対象のイベントに対して監査レポートを作成することができるほか、特定のイベントのみを記録するよう監査システムを構成することもできます。このほか、独自のルールセットを作成して、これらの記録のみを実施するよう監査デーモンを構成することもできます。
- レポートデータの可用性の保証
監査レポートは
rootが所有するもので、rootのみが削除できます。それ以外のユーザは監査ログを削除できません。- 監査データの喪失保護
カーネルのメモリが不足した場合や監査デーモンのバックログが超過した場合、もしくは監査デーモンの流量制限を超過した場合、監査デーモンはシステムのシャットダウンを実施して、監査システムの監視から外れないように設定することができます。このシャットダウンは、監査システムの中枢部からシステムの即時停止を求めるもので、この場合は直近のログがディスクに書き込まれることはありません。既定の設定では、システムの停止ではなく、 syslog への警告記録のみを行うように設定されています。
ログの記録に必要なディスク領域が不足した場合、監査システムに対してクリーンなシャットダウンを求めるように設定することもできます。既定の設定では、ディスク領域が不足した場合、ログを停止するように設定されています。
40.1 Linux 監査システムのコンポーネント紹介 #Edit source
重要: audispd の auditd への併合について
openSUSE Leap 15.4 およびそれ以降のバージョンでは、 audispd のソースコードが auditd に併合されています。また、 audispd の全ての設定は /etc/audit/auditd.conf および /etc/audit/plugins.d 内に移動しています。
下記の図には、監査システムでの様々なコンポーネントと、相互作用の関係を示しています:
図 40.1: Linux 監査システムのコンポーネント紹介 #
実線の矢印はコンポーネント間でのデータの流れを、点線の矢印はコンポーネント間の制御を表しています。
- auditd
監査デーモンは、アプリケーションやシステムの動作によって生成され、監査カーネルインターフェイスを介して提供された監査メッセージを、ディスクに書き込むデーモンです。監査デーモンは
systemdによって起動されます。監査システムの (起動時の) 設定は、/etc/audit/auditd.confで制御します。auditdに関する詳細情報と設定方法について、詳しくは 40.2項 「監査デーモンの設定」 をお読みください。auditctlauditctlユーティリティは、監査システムを制御するためのユーティリティです。ログ生成に関わるパラメータのほか、監査インターフェイスのカーネル設定や、どのイベントを追跡するかのルールなどを設定することができます。auditctlに関する詳細は、 40.3項 「auditctlによる監査システムの制御」 をお読みください。- 監査ルール
/etc/audit/audit.rulesファイルには、auditctlコマンドのシーケンスが含まれていて、監査デーモンの起動直後のシステム起動時に読み込まれる内容が記述されています。監査ルールに関する詳細は、 40.4項 「監査システムに対するパラメータ指定」 をお読みください。- aureport
aureportユーティリティは、監査イベントログから独自のレポートを作成することができるユーティリティです。このレポート生成は簡単にスクリプトに組み込むことができますし、出力は他のアプリケーションから使用することができる (たとえば結果のグラフ化など) ようになっています。aureportに関する詳細は、40.5項 「監査ログの仕組みとレポートの生成」 をお読みください。- ausearch
ausearchユーティリティは監査ログ内を検索するためのユーティリティで、様々なキーを指定してイベントを検索したり、様々なログ形式の属性を指定して検索したりすることができるようになっています。ausearchに関する詳細は、40.6項 「ausearchによる監査デーモンログへの問い合わせ」 をお読みください。- autrace
autraceはstraceのように、特定のプロセスを追跡するためのユーティリティです。autraceの出力についても、監査ログに記録されるようになっています。autraceに関する詳細は、 40.7項 「autraceによるプロセスの解析」 をお読みください。- aulast
lastコマンドのように、ユーザが直近にログインした日時を一覧表示します。aulastは過去の監査ログ (もしくは指定した監査ログファイル) を読み込んで、指定した日時範囲におけるユーザのログインおよびログアウトを一覧で表示します。- aulastlog
lastlogコマンドのように、マシンに対する最新のログイン日時を一覧表示します。ログイン名のほか、ポートと最終ログイン日時が表示されます。
40.2 監査デーモンの設定 #Edit source
監査ログの生成やそのログの処理を行う前に、まずは監査デーモン自身の設定を行います。 設定ファイル /etc/audit/auditd.conf では、デーモンの起動時にどのようにして監査システムを動作させるのかを設定します。ほとんどの用途では、 openSUSE Leap に同梱されている既定の設定のままでかまいません。 CAPP 環境向けに使用する場合は、ほとんどのパラメータに調整が必要です。下記は既定の設定です:
例 40.1: /etc/audit/auditd.conf の既定値 #
local_events = yes write_logs = yes log_file = /var/log/audit/audit.log log_group = audit log_format = RAW flush = INCREMENTAL_ASYNC freq = 50 max_log_file = 8 num_logs = 5 priority_boost = 4 name_format = NONE ##name = mydomain max_log_file_action = ROTATE space_left = 75 space_left_action = SYSLOG verify_email = yes action_mail_acct = root admin_space_left = 50 admin_space_left_action = SUSPEND disk_full_action = SUSPEND disk_error_action = SUSPEND use_libwrap = yes ##tcp_listen_port = 60 tcp_listen_queue = 5 tcp_max_per_addr = 1 ##tcp_client_ports = 1024-65535 tcp_client_max_idle = 0 transport = TCP distribute_network = no q_depth = 1200 overflow_action = SYSLOG max_restarts = 10 plugin_dir = /etc/audit/plugins.d end_of_event_timeout = 2
これらの設定値に関する詳細は、 man 5 auditd.conf で表示されるマニュアルページをお読みください。
CAPP の要件を満たすよう環境を設定する必要があるかどうかによって異なりますが、必要である場合は監査デーモンの設定をより厳密に行う必要があります。 CAPP の要件を満たす場合は、 「CAPP 環境について」 と書かれた注記に従って設定を行ってください。
/etc/audit/auditd.conf でのデーモン設定が完了したら、次は監査デーモンが監査する範囲の制御と、デーモンが適切に動作するために必要な十分なリソースの割り当てと制限を行います。
40.3 auditctl による監査システムの制御 #Edit source
auditctl は監査デーモンの状態の制御のほか、基本的なシステムパラメータを設定することができます。このほか、システム内で実施される監査範囲の制御を行うこともできます。監査ルールを使用することで、 auditctl はお使いのシステム内のどのコンポーネントを監査するのか、およびどの範囲までを監査するのかを制御することができます。監査ルールは auditctl コマンドを使用してコマンドラインから渡すことができるほか、ルールセットを作成して監査デーモン側で処理させることもできます。既定では、 auditd は /etc/audit/audit.rules にある監査ルールを使用するようになっています。監査ルールに関する詳細は、 40.4項 「監査システムに対するパラメータ指定」 をお読みください。
基本的な監査システムパラメータを制御するための主な auditctl コマンドは下記のとおりです:
auditctl-e: 監査の有効化と無効化auditctl-f: 失敗フラグの制御auditctl-r: 監査メッセージの流量制限の制御auditctl-b: バックログ制限の制御auditctl-s: 監査デーモンに関する現在の状態の表示auditctl-Sでは監査対象とするシステムコールを指定します。なお、お使いのシステムでauditctl -Sを実行する際は、-F arch=b64を指定して、アーキテクチャの間違いに関する警告が発生しないようにしてください。
-e , -f , -r , -b オプションは audit.rules ファイル内でも指定することができます。これにより、監査デーモンの起動時に毎回入力するような手間を省くことができます。
auditctl -s で監査デーモンの状態を問い合わせる場合や、 auditctl -eフラグ で状態フラグを変更する場合は、状態メッセージ (上述のパラメータに関する情報を含む) が出力されます。下記は、一般的な監査状態のメッセージ例を示しています。
例 40.2: auditctl -s の出力例 #
enabled 1 failure 1 pid 790 rate_limit 0 backlog_limit 64 lost 0 backlog 0 backlog_wait_time 15000 loginuid_immutable 0 unlocked
表 40.1: 監査状態フラグ #
|
フラグ |
意味 [取り得る値] |
コマンド |
|---|---|---|
|
|
有効化フラグを設定します。 [0..2] 0=無効, 1=有効, 2=有効にして設定をロックダウンします。なお、この有効化フラグはシステムコールのログにのみ適用されるものであり、その他のイベントについては効果がありません (詳しくはaudit-devel パッケージ内の |
|
|
|
失敗フラグを設定します。 [0..2] 0=何もしない, 1=printk, 2=panic (ディスクへの書き込み待ちのデータを書き込むことなく、即時に停止する) |
|
|
|
|
— |
|
|
メッセージの流量制限 (毎秒メッセージ数) を設定します。この値にゼロより大きい値が設定され、その値を超過した場合は、失敗フラグ内で設定した動作を実行します。 |
|
|
|
未処理の監査バッファの最大サイズを指定します。すべてのバッファが使用中になると、失敗フラグ内で設定した動作を実行します。 |
|
|
|
現時点までに喪失した監査メッセージの数を表します。 |
— |
|
|
現時点での未処理の監査バッファ数を表します。 |
— |
40.4 監査システムに対するパラメータ指定 #Edit source
監査システムに対するコマンドは auditctl コマンドを利用してシェルから個別に実行することもできますし、 auditctl - R のように指定して、ファイルから読み込んで一括処理することもできます。後者のやり方は起動時のスクリプトでも使用していて、監査デーモンの起動後に、 /etc/audit/audit.rules ファイルからルールを読み込む目的で使用しています。ルールは上から順に実行されます。それぞれのルールは、それぞれが auditctl のコマンドに展開されます。ルールファイル内で使用する書式は、 auditctl コマンドと同じです。
動作中の監査システムを auditctl で設定変更しても、その変更点はシステムの再起動で失われてしまいます。恒久的に変更したい場合は、 /etc/audit/audit.rules ファイルに追加するとともに、現時点で監査デーモン内に読み込まれていない場合は、 systemctl restart auditd を実行して、監査システムを再起動してください。
例 40.3: 監査ルール例: 監査システムのパラメータ #
-b 10001 -f 12 -r 103 -e 14
未処理の監査バッファの最大数を指定しています。ログの発生頻度にも依存しますが、監査の負荷がシステムにとって重すぎない程度の値に設定してください。 | |
使用する失敗フラグを指定しています。指定可能な値は 表40.1「監査状態フラグ」 をご覧ください。 | |
カーネル側で発信される最大流量のメッセージ数を指定しています。詳しくは 表40.1「監査状態フラグ」 をご覧ください。 | |
監査サブシステムの有効化／無効化を設定しています。 |
監査の仕組みを使用することで、重要なファイルや設定、リソースなどのファイルシステムアクセスを追跡することができるようになります。また、これらに対して監視を設定してキーを割り当てることで、ログ内でより見つけやすくすることができます。
例 40.4: 監査ルール例: ファイルシステムの監査 #
-w /etc/shadow1 -w /etc -p rx2 -w /etc/passwd -k fk_passwd -p rwxa3
| |
このルールは | |
このルールは、 |
システムコールの監査では、アプリケーションよりも下のレベルで、システムの動作を追跡することができます。これらのルールを設計する際は、多数のシステムコールに対して監査を行うと、システムの負荷が上昇するだけでなく、ディスク領域も不足する危険性があることに注意してください。追跡対象のイベントと、それらのフィルタリング方法については、より具体的に設定するようにしてください。
例 40.5: 監査ルール例: システムコールの監査 #
-a exit,always -S mkdir1 -a exit,always -S access -F a1=42 -a exit,always -S ipc -F a0=23 -a exit,always -S open -F success!=04 -a task,always -F auid=05 -a task,always -F uid=0 -F auid=501 -F gid=wheel6
このルールは | |
このルールは access システムコールに対する監査を設定していますが、システムコールの 2 番目のパラメータ ( | |
このルールは IPC 多重化システムコールに対して監査コンテキストを設定しています。特定の | |
このルールは open システムコールが失敗した場合に対する監査を設定しています。 | |
このルールはタスクルール (キーワード: | |
最後のルールはフィルタを複雑に設定した場合の例です。すべてのフィルタオプションが組み合わせられていて、それらを論理積 (AND) で結んでいます。つまり、このルールは監査 ID が |
監査システムにはルールを追加するだけでなく、ルールを削除することもできます。ルール全体を一括で削除することができるほか、個別のシステムコールルールやファイル／ディレクトリの監視ルールを削除することができます:
例 40.6: 監査ルールとイベントの削除 #
-D1 -d exit,always -S mkdir2 -W /etc3
監査ルールのキューを消去して、既存のルールをすべて削除します。このルールは | |
このルールでは、システムコールのルールを削除しています。ルールキューから削除する必要のあるシステムコールを指定する場合は、その前に | |
このルールでは、監査システムのルールキューから |
現時点での監査設定で使用しているルールの概要を知りたい場合は、 auditctl -l と入力して実行します。このコマンドは、 1 ルールあたり 1 行で表示します。
例 40.7: auditctl -l によるルール一覧の表示 #
exit,always watch=/etc perm=rx exit,always watch=/etc/passwd perm=rwxa key=fk_passwd exit,always watch=/etc/shadow perm=rwxa exit,always syscall=mkdir exit,always a1=4 (0x4) syscall=access exit,always a0=2 (0x2) syscall=ipc exit,always success!=0 syscall=open
注記: フィルタルールの作成について
様々なフィルタオプションを組み合わせることで、より洗練された監査ルールを構築することができます。監査フィルタルールを構築する際に利用可能なオプションのほか、監査ルールに関する詳細については、 auditctl(8) のマニュアルページをお読みください。
40.5 監査ログの仕組みとレポートの生成 #Edit source
aureport ユーティリティが何をするものなのかを知るには、まず監査デーモンが生成するログの構造について知っておく必要があるほか、イベント内にどのような情報が存在するのかを知っておく必要があります。これにより、要件に対応できる最適なレポートタイプを判断することができるようになります。
40.5.1 監査ログの仕組み #Edit source
下記の例には、監査デーモンが記録した 2 種類の典型的なイベントと、それらの証跡が示されています。監査ログは、ローテーションしたものを含め、 /var/log/audit 内に保存されます。
ログには 2 種類の情報が記録されます。それぞれレコードタイプとイベントフィールドと呼びます。レコードタイプはそれぞれの記録内の type= 以下に書かれています。イベントフィールドはそれ以外の項目で、イコール記号の前に書かれたものを指します。下記の例では type=SYSCALL や type=CWD がレコードタイプ、 arch=c000003e や syscall=2 がイベントフィールド (値付きのもの) となります。
レコードタイプの全ての一覧とそれらの意味について、詳しくは /usr/include/libaudit.h ファイル (audit-devel パッケージに含まれています) をお読みください。
また、 ausyscall --dump コマンドを実行することで、システムコールの番号と対応する関数名を出力することができます:
> ausyscall --dump
Using x86_64 syscall table:
0 read
1 write
2 open
3 close
4 stat
5 fstat
[...]最初の例は単純な less コマンドを実行した場合の例、 2 番目の例は、監査を実施しているマシン内にユーザがリモートからログインしようとした場合、ログ内に PAM の動作に関わる大量のログが出力されている場合の例を示しています。
例 40.8: シンプルな監査イベント例: 監査ログの表示 #
type=SYSCALL msg=audit(1234874638.599:5207): arch=c000003e syscall=2 success=yes exit=4 a0=62fb60 a1=0 a2=31 a3=0 items=1 ppid=25400 pid =25616 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1164 comm="less" exe="/usr/bin/less" key="doc_log" type=CWD msg=audit(1234874638.599:5207): cwd="/root" type=PATH msg=audit(1234874638.599:5207): item=0 name="/var/log/audit/ audit.log" inode=1219041 dev=08:06 mode=0100644 ouid=0 ogid=0 rdev=00:00
上記のイベントは less /var/log/audit/audit.log を実行した場合のログで、 3 種類のメッセージが記録されています。これらのすべては密接にリンクしているため、その他の情報が無ければ意味を理解するのが難しいものと思います。最初のメッセージには下記の情報が記録されています:
type記録されたイベントの種類を示しています。この場合は
SYSCALLという種類で、システムコールによる記録であることを示しています。それ以外にはCWDという種類のイベントもあり、これはシステムコール時点でのカレントディレクトリを示しています。次のPATHという種類のイベントは、システムコールに渡されたパスに関する情報が示されています。 open システムコールは 1 つのパラメータを取るシステムコールであることから、PATHイベントも 1 つだけ生成されます。ここで重要となるのが、PATHイベントはパス名の文字列パラメータを報告するだけで、それ以外の解釈については何も行わないものである点です。そのため、相対パスを指定した場合は、CWDのイベントで示されたカレントディレクトリの情報とあわせて、手作業で絶対パスに戻さなければならないことになります。msg括弧内にはメッセージ ID が書かれています。メッセージ ID は 2 種類のパーツから構成されていて、
:の前は Unix エポックタイムを、後ろは実際のイベント ID を表しています。同じシステムコール内であれば、同じイベント ID が割り当てられます。アプリケーションがさらに別のシステムコールを行うと、イベント ID が新たに割り当てられます。archシステムコールに対応する CPU アーキテクチャを示しています。この情報は
ausearchコマンドでログを検索する際、-iオプションを指定するとデコードすることができます。syscallこのシステムコールに対して
straceで表示することのできる、システムコールの種類を表しています。このデータは/usr/include/asm/unistd.hファイル内に示されていて、アーキテクチャによって番号体系が異なります。このアーキテクチャでは、syscall=2は open システムコール (詳しくはman open(2)をお読みください) を表しています。successシステムコールが成功したか、失敗したかを示しています。
exitシステムコールの返り値を表しています。この例では
openシステムコールに対する返り値ですが、これは作成されたファイルディスクリプタ番号を表しています。返り値の意味はシステムコールによって異なります。a0からa3数値形式で表現された、システムコールの最初の 4 つのパラメータです。これらはシステムコールによって異なる解釈になります。この例 (
openシステムコール) では、下記のように解釈します:a0=62fb60 a1=8000 a2=31 a3=0
a0はパス名の開始アドレスを表しています。a1はフラグを表していて、 16 進数の8000は 8 進数でいうと100000にあたることから、O_LARGEFILEというフラグを指定していることになります。またa2はモード指定で、O_CREATを指定していないことから、使用していないパラメータであることがわかります。a3はopenシステムコールでは使用していないパラメータです。それぞれのパラメータの意味については、マニュアルページをお読みください。itemsアプリケーションに渡された文字列の数を表しています。
ppidこのプロセスの親のプロセス ID を表しています。
pidこのプロセスのプロセス ID を表しています。
auid監査 ID を表しています。監査 ID はユーザのログイン時にプロセスに対して設定されます。この ID は、そのユーザの初期プロセスから起動されたすべての子プロセスに渡されます。ユーザが自身の識別情報を変更した場合 (たとえば
rootになった場合) でも、監査 ID は変わらずそのままであり続けるため、元のユーザの動きをそのまま追跡できることになります。uidプロセスを起動したユーザの実ユーザ ID を表しています。この場合は
0であることから、rootであることになります。gidプロセスを起動したユーザの実グループ ID を表しています。この場合は
0であることから、rootであることになります。euid,suid,fsuidプロセスを起動したユーザの実効ユーザ ID, Set User ID, ファイルシステムユーザ ID をそれぞれ表しています。
egid,sgid,fsgidプロセスを起動したユーザの実効グループ ID, Set Group ID, ファイルシステムグループ ID をそれぞれ表しています。
ttyアプリケーションを起動した端末を表しています。この場合は、 SSH セッション内で疑似端末 (pts) を使用していることを表しています。
sesログインセッション ID を表しています。このプロセス属性はユーザのログイン時に設定されるほか、どのプロセスも特定のユーザログインに結びつけることができます。
commタスクリストに表示されるアプリケーション名を表しています。
exeバイナリプログラムに対する解決済みパスを表しています。
subjauditdは、プロセスに対して AppArmor などのセキュリティコンテキストが割り当てられている場合、その内容を記録することができます。この場合はunconstrainedになっていますが、これは AppArmor でプロセスが保護されていないことを表しています。プロセスが何らかの制限を受けた場合、バイナリパスと AppArmor のプロファイルモードも記録されます。key多数のディレクトリやファイルに対して監査を行っている際、監視対象の判別用にキー文字列を指定することができます。これらのキーを
ausearchに指定すると、そのキーに合致するもののみを表示することができます。
less コマンドが生成した 2 つ目のメッセージには、 less コマンドを実行した時点でのカレントディレクトリを表しています。
3 つ目のメッセージの意味は下記のとおりです (type と message のフラグは既に説明しているとおりです):
itemこの例では、
itemはa0パラメータを表しています。ここには元々のSYSCALLメッセージ内に対応する、パス名が書かれています。cpやmvなどのように、複数のパスパラメータを指定する場合は、さらにPATHイベントが生成されて記録されることになります。nameopen システムコールのパラメータとして渡されたパスを表しています。
inodenameに対応する inode 番号を表しています。devファイルが保存されているデバイスを表しています。この場合、
08:06と書かれていますので、/dev/sda1もしくは 「最初の IDE デバイス上の最初のパーティション」 であることを示しています。modeファイルのアクセス許可を数値で表現したものです。この場合は
rootが読み書きの権限を持ち、グループ (root) は読み込みのみ、その他のユーザはファイルへのアクセス権を持たない設定になっています。ouidとogidinode が指し示すものに対する UID と GID を表しています。
rdevこの例では意味を持たないものです。
rdevはブロックデバイスやキャラクタデバイスの場合にのみ意味を持つもので、ファイルでは意味を持ちません。
例40.9「複雑な監査イベント例: SSH でのログイン」 には、 SSH 接続を受け付けた際の監査イベントを示しています。ほとんどのメッセージは PAM スタックに関連するもので、 SSH PAM の処理における様々なステージを表しています。また、いくつかの監査メッセージは入れ子になっていて、それぞれの PAM の処理段階を示しています。監査システムでは PAM の処理についても記録を行いますが、独自のメッセージタイプが割り当てられます:
例 40.9: 複雑な監査イベント例: SSH でのログイン #
type=USER_AUTH msg=audit(1234877011.791:7731): user pid=26127 uid=0 1 auid=4294967295 ses=4294967295 msg='op=PAM:authentication acct="root" exe="/usr/sbin/sshd" (hostname=jupiter.example.com, addr=192.168.2.100, terminal=ssh res=success)' type=USER_ACCT msg=audit(1234877011.795:7732): user pid=26127 uid=0 2 auid=4294967295 ses=4294967295 msg='op=PAM:accounting acct="root" exe="/usr/sbin/sshd" (hostname=jupiter.example.com, addr=192.168.2.100, terminal=ssh res=success)' type=CRED_ACQ msg=audit(1234877011.799:7733): user pid=26125 uid=0 3 auid=4294967295 ses=4294967295 msg='op=PAM:setcred acct="root" exe="/usr/sbin/sshd" (hostname=jupiter.example.com, addr=192.168.2.100, terminal=/dev/pts/0 res=success)' type=LOGIN msg=audit(1234877011.799:7734): login pid=26125 uid=0 old auid=4294967295 new auid=0 old ses=4294967295 new ses=1172 type=USER_START msg=audit(1234877011.799:7735): user pid=26125 uid=0 4 auid=0 ses=1172 msg='op=PAM:session_open acct="root" exe="/usr/sbin/sshd" (hostname=jupiter.example.com, addr=192.168.2.100, terminal=/dev/pts/0 res=success)' type=USER_LOGIN msg=audit(1234877011.823:7736): user pid=26128 uid=0 5 auid=0 ses=1172 msg='uid=0: exe="/usr/sbin/sshd" (hostname=jupiter.example.com, addr=192.168.2.100, terminal=/dev/pts/0 res=success)' type=CRED_REFR msg=audit(1234877011.828:7737): user pid=26128 uid=0 6 auid=0 ses=1172 msg='op=PAM:setcred acct="root" exe="/usr/sbin/sshd" (hostname=jupiter.example.com, addr=192.168.2.100, terminal=/dev/pts/0 res=success)'
リモートのホスト (jupiter.example.com, 192.168.2.100) から | |
PAM は、ユーザにログイン権限があることを確認した、と報告しています。 | |
PAM はログインにあたって適切な資格情報が必要である旨を報告するとともに、端末が通常の端末 ( | |
PAM は、 | |
ユーザのログインが成功したことを示しています。このイベントは | |
PAM は資格情報を再取得したことを報告しています。 |
40.5.2 独自の監査レポートの生成 #Edit source
/var/log/audit ディレクトリ内にある未加工の監査レポートは、かさばって理解しにくいものになってしまっています。必要なメッセージを簡単に取得できるようにするには、 aureport ユーティリティを利用して、独自にレポートを作成してください。
下記の利用例では、 aureport で生成することのできる、いくつかのレポートタイプについて説明しています:
- 他のファイルからの監査ログ読み込み
監査ログを他のマシンに移動させた場合や、それぞれのマシンに接続することなく、ローカルのマシン内で複数のマシンの監査ログを分析したりしたい場合は、対象となるログファイルをローカルに移動したあと、
aureportを利用してローカルで分析してください:>sudoaureport -if myfileSummary Report ====================== Range of time in logs: 2009年02月03日 14:13:38.225 - 2009年02月17日 14:52:27.971 Selected time for report: 2009年02月03日 14:13:38 - 2009年02月17日 14:52:27.971 Number of changes in configuration: 13 Number of changes to accounts, groups, or roles: 0 Number of logins: 6 Number of failed logins: 13 Number of authentications: 7 Number of failed authentications: 573 Number of users: 1 Number of terminals: 9 Number of host names: 4 Number of executables: 17 Number of files: 279 Number of AVC's: 0 Number of MAC events: 0 Number of failed syscalls: 994 Number of anomaly events: 0 Number of responses to anomaly events: 0 Number of crypto events: 0 Number of keys: 2 Number of process IDs: 1211 Number of events: 5320上記のコマンドでは
aureportに何もパラメータを指定しておらず、myfile内に含まれているログ情報から、標準的で一般的な概要レポートのみを生成するように指定しています。より詳しいレポートを作成したい場合は、-ifオプションに加えて、必要なオプションを指定してください。たとえば特定の時間帯のログインレポートのみを生成したい場合は、下記のように入力して実行します:>sudoaureport -l -ts 14:00 -te 15:00 -if myfileLogin Report ============================================ # date time auid host term exe success event ============================================ 1. 2017年02月09日 14:21:09 root: 192.168.2.100 sshd /usr/sbin/sshd no 7718 2. 2017年02月09日 14:21:15 0 jupiter /dev/pts/3 /usr/sbin/sshd yes 7724- 数値表現の文字列変換
ユーザ ID などの情報は数値で出力されます。これらを読みやすいテキスト形式に変換するには、
aureportコマンドに-iオプションを追加してください。- 大まかな概要レポートの作成
現在の監査統計情報 (イベント数, ログイン数, プロセス数など) のみを知りたい場合は、
aureportに何もパラメータを指定せずに実行してください。- 失敗イベントの概要レポートの作成
純粋な
aureportの概要統計情報を失敗イベントのみの統計情報に変更したい場合は、aureport--failedのように入力して実行します:>sudoaureport --failedFailed Summary Report ====================== Range of time in logs: 2009年02月03日 14:13:38.225 - 2009年02月17日 14:57:35.183 Selected time for report: 2009年02月03日 14:13:38 - 2009年02月17日 14:57:35.183 Number of changes in configuration: 0 Number of changes to accounts, groups, or roles: 0 Number of logins: 0 Number of failed logins: 13 Number of authentications: 0 Number of failed authentications: 574 Number of users: 1 Number of terminals: 5 Number of host names: 4 Number of executables: 11 Number of files: 77 Number of AVC's: 0 Number of MAC events: 0 Number of failed syscalls: 994 Number of anomaly events: 0 Number of responses to anomaly events: 0 Number of crypto events: 0 Number of keys: 2 Number of process IDs: 708 Number of events: 1583- 成功イベントの概要レポートの作成
純粋な
aureportの概要統計情報を成功イベントのみの統計情報に変更したい場合は、aureport--successのように入力して実行します:>sudoaureport --successSuccess Summary Report ====================== Range of time in logs: 2009年02月03日 14:13:38.225 - 2009年02月17日 15:00:01.535 Selected time for report: 2009年02月03日 14:13:38 - 2009年02月17日 15:00:01.535 Number of changes in configuration: 13 Number of changes to accounts, groups, or roles: 0 Number of logins: 6 Number of failed logins: 0 Number of authentications: 7 Number of failed authentications: 0 Number of users: 1 Number of terminals: 7 Number of host names: 3 Number of executables: 16 Number of files: 215 Number of AVC's: 0 Number of MAC events: 0 Number of failed syscalls: 0 Number of anomaly events: 0 Number of responses to anomaly events: 0 Number of crypto events: 0 Number of keys: 2 Number of process IDs: 558 Number of events: 3739- 概要レポートの作成
専用の概要レポート (全体概要／失敗概要／成功概要) に加えて、
--summaryオプションと他のオプションを併用することで、指定した分野のみの概要レポートを作成することもできます。ただし、すべてのオプションがレポートに対応しているわけではありません。この例では、ユーザのログインイベントに関する概要レポートを作成しています:>sudoaureport -u -i --summaryUser Summary Report =========================== total auid =========================== 5640 root 13 tux 3 wilber- イベント一覧レポートの作成
監査デーモンが記録したイベントの概要を取得するには、
aureport-eコマンドを使用します。このコマンドは順序番号付きのリストで、すべてのイベントに対する日付と時刻、イベント番号と種類、そして監査 ID を出力します。>sudoaureport -e -ts 14:00 -te 14:21 Event Report =================================== # date time event type auid success =================================== 1. 2009年02月17日 14:20:27 7462 DAEMON_START 0 yes 2. 2009年02月17日 14:20:27 7715 CONFIG_CHANGE 0 yes 3. 2009年02月17日 14:20:57 7716 USER_END 0 yes 4. 2009年02月17日 14:20:57 7717 CRED_DISP 0 yes 5. 2009年02月17日 14:21:09 7718 USER_LOGIN -1 no 6. 2009年02月17日 14:21:15 7719 USER_AUTH -1 yes 7. 2009年02月17日 14:21:15 7720 USER_ACCT -1 yes 8. 2009年02月17日 14:21:15 7721 CRED_ACQ -1 yes 9. 2009年02月17日 14:21:15 7722 LOGIN 0 yes 10. 2009年02月17日 14:21:15 7723 USER_START 0 yes 11. 2009年02月17日 14:21:15 7724 USER_LOGIN 0 yes 12. 2009年02月17日 14:21:15 7725 CRED_REFR 0 yes- すべてのプロセスイベントからのレポート作成
プロセスの観点からログを分析したい場合は、
aureport-pコマンドを使用します。このコマンドは順序番号付きのリストで、プロセス関連のイベントを列挙します。これには日付と時刻、プロセス ID と実行ファイルの名前、システムコールと監査 ID 、イベント番号が含まれます。aureport -pProcess ID Report ====================================== # date time pid exe syscall auid event ====================================== 1. 2009年02月13日 15:30:01 32742 /usr/sbin/cron 0 0 35 2. 2009年02月13日 15:30:01 32742 /usr/sbin/cron 0 0 36 3. 2009年02月13日 15:38:34 32734 /usr/lib/gdm/gdm-session-worker 0 -1 37- すべてのシステムコールイベントからのレポート作成
システムコールの観点からログを分析したい場合は、
aureport-sコマンドを使用します。このコマンドは順序番号付きのリストで、システムコール関連のイベントを列挙します。これには日付と時刻、システムコールの回数とそのコールを使用したコマンドの名前、監査 ID とイベント番号が含まれます。>sudoaureport -sSyscall Report ======================================= # date time syscall pid comm auid event ======================================= 1. 2009年02月16日 17:45:01 2 20343 cron -1 2279 2. 2009年02月16日 17:45:02 83 20350 mktemp 0 2284 3. 2009年02月16日 17:45:02 83 20351 mkdir 0 2285- すべての実行ファイルイベントからのレポート作成
実行ファイルの観点からログを分析したい場合は、
aureport-xコマンドを使用します。このコマンドは順序番号付きのリストで、実行ファイル関連のイベントを列挙します。これには日付と時刻、実行ファイルの名前と実行していた端末、実行していたホストと監査 ID 、イベント番号が含まれます。aureport -xExecutable Report ==================================== # date time exe term host auid event ==================================== 1. 2009年02月13日 15:08:26 /usr/sbin/sshd sshd 192.168.2.100 -1 12 2. 2009年02月13日 15:08:28 /usr/lib/gdm/gdm-session-worker :0 ? -1 13 3. 2009年02月13日 15:08:28 /usr/sbin/sshd ssh 192.168.2.100 -1 14- ファイルに関するレポート作成
ファイルアクセスの観点からログを分析したい場合は、
aureport-fコマンドを使用します。このコマンドは順序番号付きのリストで、アクセスしているファイル、アクセスに使用したシステムコールの数と成功可否、実行ファイルと監査 ID 、イベント番号が含まれます。>sudoaureport -fFile Report =============================================== # date time file syscall success exe auid event =============================================== 1. 2009年02月16日 17:45:01 /etc/shadow 2 yes /usr/sbin/cron -1 2279 2. 2009年02月16日 17:45:02 /tmp/ 83 yes /bin/mktemp 0 2284 3. 2009年02月16日 17:45:02 /var 83 no /bin/mkdir 0 2285- ユーザに関するレポートの作成
システム内で、どのユーザが何の実行ファイルを実行させたのかを監査ログから調べ、レポートとしてまとめたい場合は、
aureport-uコマンドを使用します。このコマンドは順序番号付きのリストで、日付や時刻、監査 ID や使用した端末とホスト、実行ファイルの名前とイベント ID がそれぞれ示されます。aureport -uUser ID Report ==================================== # date time auid term host exe event ==================================== 1. 2009年02月13日 15:08:26 -1 sshd 192.168.2.100 /usr/sbin/sshd 12 2. 2009年02月13日 15:08:28 -1 :0 ? /usr/lib/gdm/gdm-session-worker 13 3. 2009年02月13日 08:25:39 -1 ssh 192.168.2.101 /usr/sbin/sshd 14- ログインに関するレポートの作成
マシンに対するログイン試行に着目してレポートを作成するには、
aureport-lコマンドを使用します。このコマンドは順序番号付きのリストで、日付や時刻、監査 ID や使用したホストおよび端末、実行ファイルの名前と試行の成功可否、イベント ID がそれぞれ含まれる、ログイン関連のレポートを生成します。>sudoaureport -l -iLogin Report ============================================ # date time auid host term exe success event ============================================ 1. 2009年02月13日 15:08:31 tux: 192.168.2.100 sshd /usr/sbin/sshd no 19 2. 2009年02月16日 12:39:05 root: 192.168.2.101 sshd /usr/sbin/sshd no 2108 3. 2009年02月17日 15:29:07 geeko: ? tty3 /bin/login yes 7809- 特定の時刻範囲に限定したレポート作成
特定の時刻範囲に限定してログを分析したい場合、たとえば 2009 年 2 月 16 日の日中時間帯のみを調べたい場合は、まず対象のデータが現在の
audit.log内に含まれているか、それとも既にローテーションされてしまったものかどうかを確認します。これはaureport-tを実行することで判別することができます。aureport -tLog Time Range Report ===================== /var/log/audit/audit.log: 2009年02月03日 14:13:38.225 - 2009年02月17日 15:30:01.636現在の
audit.logファイル内に必要な時間帯のデータがすべて含まれていれば、通常通りにレポートを作成します。そうでない場合は、aureportコマンドに-ifオプションを指定し、必要なデータを含むログファイルを指定します。あとは開始日時と終了日時を指定して、作成するレポートの種類を選ぶオプションを加えます。下記の例では、ログイン試行に着目してレポートを作成しています:
>sudoaureport -ts 02/16/09 8:00 -te 02/16/09 18:00 -lLogin Report ============================================ # date time auid host term exe success event ============================================ 1. 2009年02月16日 12:39:05 root: 192.168.2.100 sshd /usr/sbin/sshd no 2108 2. 2009年02月16日 12:39:12 0 192.168.2.100 /dev/pts/1 /usr/sbin/sshd yes 2114 3. 2009年02月16日 13:09:28 root: 192.168.2.100 sshd /usr/sbin/sshd no 2131 4. 2009年02月16日 13:09:32 root: 192.168.2.100 sshd /usr/sbin/sshd no 2133 5. 2009年02月16日 13:09:37 0 192.168.2.100 /dev/pts/2 /usr/sbin/sshd yes 2139開始日時は
-tsで指定します。指定した日時と同じか、それより後のイベントがレポート内に出力されます。日付部分を省略した場合、aureportは 今日 を指定したものとして扱います。時刻部分を省略した場合は、日付の切り替わった深夜を開始時刻として指定したものとして扱います。 なお、日付は 月/日/年 の形式で指定することに注意してください。終了日時は
-teで指定します。指定した日時と同じか、それより前のイベントがレポート内に出力されます。日付を省略した場合、aureportは 今日 を指定したものとして扱います。また、時刻部分を省略した場合、aureportは 現在時刻 を指定したものとして扱います。指定可能な書式は-tsと同じです。
概要を除き、レポートは表形式で標準出力に出力されます。つまり、出力された情報を他のコマンドに取り込むことが容易であることになります。たとえば 40.8項 「監査データの可視化」 で紹介されている可視化スクリプトを使用すると、監査デーモンが生成したデータをさらに詳しく処理することができます。
40.6 ausearch による監査デーモンログへの問い合わせ #Edit source
aureport では、システム内で何が起こっているのかを概要レベルで表示することができますが、特定のイベントの詳細までは追うことができません。特定のイベントを追跡したい場合は、 ausearch ツールを使用します。
ausearch コマンドは /var/log/audit/audit.log にある監査ログ内を検索するためのツールで、キーや語句などを条件に指定して検索することができます。ただし、すべてのレコードタイプに同じ項目が含まれているわけではないことに注意してください。たとえば PATH レコードの場合、 hostname や uid の項目はありません。
検索を行う場合、必要なレコードをすべて抽出できるような適切な検索条件を指定してください。その一方、特定のレコードタイプを抽出したり、それに付随するその他の関連レコードを抽出したりすることもできます。これは、カーネル内の様々な箇所で、イベントに関連する複数のレコードを出力する仕組みであるためです。たとえば open システムコールの場合、 SYSCALL レコードだけでなく PATH レコードも同時に出力されます。
ヒント: 複数の検索オプションの使用について
複数のコマンドラインオプションを指定すると、それらは論理積 (AND) 演算子で結びつけられ、検索を絞り込む用途として使用することができます。
- 他のファイルからの監査ログ読み込み
監査ログを他のマシンに移動させた場合や、それぞれのマシンに接続することなく、ローカルのマシン内で複数のマシンの監査ログを分析したりしたい場合は、対象となるログファイルをローカルに移動したあと、
ausearchを利用してローカルで分析してください:>sudoausearch -オプション -if ファイル名- 数値表現の文字列変換
ユーザ ID などの情報は数値で出力されます。これらを読みやすいテキスト形式に変換するには、
ausearchコマンドに-iオプションを追加してください。- 監査イベント ID での検索
既に監査レポートを作成している場合や、
autraceを実行している場合は、ログ内の特定のイベントに対して、証跡を分析する必要があります。 40.5項 「監査ログの仕組みとレポートの生成」 で説明しているほとんどの種類のレポートには、出力内に監査イベント ID が含まれます。監査イベント ID は監査メッセージ ID の第 2 パートの部分ですが、ここには Unix エポックのタイムスタンプと監査イベント ID がコロン区切りで書かれています。また、同じシステムコール内であれば、同じイベント ID が割り当てられます。ausearchでこのイベント ID を使用することで、ログ内のイベント証跡を取得することができます。下記のようにしてコマンドを使用してください:
>sudoausearch -a 5207---- time->Tue Feb 17 13:43:58 2009 type=PATH msg=audit(1234874638.599:5207): item=0 name="/var/log/audit/audit.log" inode=1219041 dev=08:06 mode=0100644 ouid=0 ogid=0 rdev=00:00 type=CWD msg=audit(1234874638.599:5207): cwd="/root" type=SYSCALL msg=audit(1234874638.599:5207): arch=c000003e syscall=2 success=yes exit=4 a0=62fb60 a1=0 a2=31 a3=0 items=1 ppid=25400 pid=25616 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1164 comm="less" exe="/usr/bin/less" key="doc_log"ausearch-aコマンドを使用すると、指定したイベント ID に関連するログ内のすべてのレコードを検索して、表示します。このオプションは、他のオプションと組み合わせて指定することもできます。- メッセージタイプによる検索
特定のメッセージタイプの監査レコードを検索するには、
ausearch-m メッセージタイプコマンドを実行します。指定できるメッセージタイプには、PATH,SYSCALL,USER_LOGINなどがあります。メッセージタイプを指定せずにausearch-mを実行すると、すべてのメッセージタイプの一覧を表示することができます。- ログイン ID による検索
特定のログインユーザ ID に関連するレコードを表示するには、
ausearch-ulコマンドを使用します。このコマンドは、指定したログインユーザ ID に関連し、ログインに成功したすべてのレコードを取得します。- ユーザ ID による検索
特定の実ユーザ ID および実効ユーザ ID の両方に関連するレコードを表示するには、
ausearch-uaコマンドを使用します。特定の実ユーザ ID に関連するレコードを表示するには、ausearch-ui UIDのように入力して実行します。特定の実効ユーザ ID に関連するレコードを表示するには、ausearch-ue EUIDのように入力して実行します。実ユーザ ID での検索はプロセスを作成したユーザの ID を、実効ユーザ ID での検索は、そのプロセスを実行するのに必要なユーザ ID と権限の ID を意味しています。- グループ ID による検索
特定の実グループ ID および実効グループ ID の両方に関連するレコードを表示するには、
ausearch-gaコマンドを使用します。特定の実グループ ID に関連するレコードを表示するには、ausearch-gi GIDのように入力して実行します。特定の実効グループ ID に関連するレコードを表示するには、ausearch-ge EGIDのように入力して実行します。- コマンドライン名による検索
特定のコマンドに関連するレコードを表示するには、
ausearch-c コマンド名コマンドを使用します。たとえばausearch-c lessのように入力して実行すると、lessコマンドに関連するすべてのレコードを表示することができます。- 実行ファイル名による検索
特定の実行ファイルに関連するレコードを表示するには、
ausearch-x 実行ファイルのパスコマンドを使用します。たとえばausearch-x /usr/bin/lessのように入力して実行すると、/usr/bin/lessの実行ファイルに関連するすべてのレコードを表示することができます。- システムコール名による検索
特定のシステムコールに関連するレコードを表示するには、
ausearch-sc システムコール名コマンドを使用します。たとえばausearch -sc openのように入力して実行すると、openシステムコールに関連するすべてのレコードを表示することができます。- プロセス ID による検索
特定のプロセス ID に関連するレコードを表示するには、
ausearch-p プロセス_IDコマンドを使用します。たとえばausearch-p 13368のように入力して実行すると、指定したプロセス ID に関連するすべてのレコードを表示することができます。- イベントもしくはシステムコールの成功可否による検索
システムコールの成功可否を指定してレコードを表示するには、
ausearch-sv 成功可否コマンドを使用します。たとえばausearch-sv yesのように入力して実行すると、成功したシステムコールに関連するすべてのレコードを表示することができます。- ファイル名による検索
ファイル名を指定してレコードを表示するには、
ausearch-f ファイル名コマンドを使用します。たとえばausearch-f /foo/barのように入力して実行すると、/foo/barファイルに関連するすべてのレコードを表示することができます。なお、ファイル名だけの指定でも問題なく動作しますが、相対パスでの指定はできません。- 端末による検索
特定の端末に関連するレコードを表示するには、
ausearch-tm 端末名コマンドを使用します。たとえばausearch-tm sshのように入力して実行すると、 SSH 端末に関連するすべてのレコードを表示することができますし、ausearch-tm ttyのように入力して実行すると、コンソールに関連するすべてのレコードを表示することができます。- ホスト名による検索
特定のホストに関連するレコードを表示するには、
ausearch-hn ホスト名コマンドを使用します。たとえばausearch-hn jupiter.example.comのように入力して実行します。ホスト名や完全修飾ホスト名、ネットワークアドレスのいずれかを指定することができます。- キー項目による検索
あらかじめ特定の種類のイベントを識別するために設定して記録しておいたキー項目を指定してレコードを表示するには、
ausearch-k キー項目コマンドを使用します。たとえばausearch-k CFG_etcのように入力して実行すると、CFG_etcというキーを含むレコードのみを表示します。- 単語による検索
監査ルールセット内に含まれる、さまざまなイベントの情報に対して、文字列での検索を行うこともできます。文字列はファイル名やホスト名のほか、端末名に対しても検索することができます。具体的には
ausearch-w 文字列のように入力して実行してください。- 特定の時刻範囲に限定した検索
-tsと-teの各オプションを指定することで、特定の時間帯範囲のものを検索することができるようになります。-tsオプションでは開始日時を、-teオプションでは終了日時をそれぞれ指定します。これらのオプションは、上述の任意のオプションと組み合わせて使用することができます。また、使用方法はaureportと同じです。
40.7 autrace によるプロセスの解析 #Edit source
監査システムでは、設定したルールを利用してシステムを監視するだけでなく、 autrace コマンドを使用することで、特定のプロセス専用の監査を実施することもできます。 autrace は strace コマンドのように動作するコマンドですが、少し異なる情報を採取します。また、 autrace の出力は /var/log/audit/audit.log に書き込まれ、標準的な監査ログ項目と同様の書式で出力されます。
プロセスに対して autrace を実行する前に、まずはキュー内から監査ルールすべてを削除して、 autrace 自身の監査と衝突しないようにしておいてください。監査ルールの削除は auditctl -D で行います。これにより、すべての通常監査が停止します。
>sudoauditctl -DNo rulesautrace /usr/bin/lessWaiting to execute: /usr/bin/less Cleaning up... No rules Trace complete. You can locate the records with 'ausearch -i -p 7642'
autrace で実行ファイルを指定する際には、必ずフルパスで指定してください。追跡が完了すると、 autrace はトレースのイベント ID を通知しますので、証跡を ausearch で検索できるようになります。作業後は監査ルールを元に戻すため、 systemctl restart auditd と入力して実行してください。
40.8 監査データの可視化 #Edit source
/var/log/audit/audit.log にある監査証跡も、 40.5.2項 「独自の監査レポートの生成」 で説明している様々な種類の aureport のレポートも、ユーザが読む場合にはある程度の経験が必要となります。 aureport の出力は表形式であるため、 sed, Perl, awk などのスクリプトを使用することで、容易に監査データを可視化することができます。
可視化に対応するスクリプト (詳しくは 41.6項 「ログの可視化の設定」 をお読みください) は、 openSUSE Leap やその他の Linux ディストリビューションで、読みやすい監査出力を作成するための標準的な Linux ツールの使い方の例となっているものです。下記の例では、純粋なテキスト形式の監査レポートを、グラフに変換する作業を行っています。
最初の例では、プログラムとシステムコールの対応付けを可視化しているものです。この種類のデータを取得するには、最終的なグラフを生成するための元となるデータを aureport で作成する必要があります:
>sudoaureport -s -iSyscall Report ======================================= # date time syscall pid comm auid event ======================================= 1. 2009年02月16日 17:45:01 open 20343 cron unset 2279 2. 2009年02月16日 17:45:02 mkdir 20350 mktemp root 2284 3. 2009年02月16日 17:45:02 mkdir 20351 mkdir root 2285 ...
このレポートに対して可視化スクリプトが行うべき最初の処理は、必要な列の情報のみを抽出することです。この例では、 syscall と comm の列になります。出力は並べ替えられたあと重複を排除し、グラフ作成プログラム自身に渡すことになります:
LC_ALL=C aureport -s -i | awk '/^[0-9]/ { print $6" "$4 }' | sort | uniq | mkgraph
図 40.2: フローグラフ: プログラムとシステムコールの関係性 #
2 つ目の例では、様々な種類のイベントとそのログ記録数をまとめたグラフを示しています。この種類のグラフを作成するにあたって、 aureport で対応するコマンドは aureport -e です:
>sudoaureport -e -i --summary Event Summary Report ====================== total type ====================== 2434 SYSCALL 816 USER_START 816 USER_ACCT 814 CRED_ACQ 810 LOGIN 806 CRED_DISP 779 USER_END 99 CONFIG_CHANGE 52 USER_LOGIN
この種類のレポートは既に 2 列のみの出力になっていることから、単純にグラフ作成プログラムに渡して棒グラフにするだけです。
>sudoaureport -e -i --summary | mkbar events
図 40.3: 棒グラフ: 一般的なイベントの種類 #
監査データの可視化の背景となる情報について、詳しくは https://people.redhat.com/sgrubb/audit/visualize/index.html (英語) をお読みください。
40.9 監査イベント通知の中継 #Edit source
監査システムでは、リアルタイムに外部プログラムを呼び出して、 auditd にアクセスしたり、使用したりすることができます。この機能は 監査ディスパッチャ と呼ばれる仕組みで、たとえば侵入検知システムなどが auditd を使用し、より詳しい検知情報を取得したりすることができます。
auditd の設定ファイルは /etc/audit/auditd.conf に保存されています。このファイルには下記のようなオプションを記述することができます:
q_depth監査ディスパッチャの内部キューのサイズを指定します。 syslog 内に監査イベントの喪失を表すメッセージが現れた場合は、この値を増やしてください。既定値は 250 です。
overflow_action監査ディスパッチャの内部キューが溢れてしまった場合、監査デーモンがどのように対応するのかを指定します。指定可能な値は
ignore(何もしない),syslog(syslog に警告を発する),suspend(イベントの処理を停止させる),single(コンピュータシステムをシングルユーザモードに移行させる),halt(システムをシャットダウンする) のいずれかです。priority_boost監査イベントディスパッチャに対する優先度設定を指定します (監査デーモン自身の優先度からの相対指定です) 。既定値は 4 で、優先度を変更しません。
name_format監査イベント内へ挿入するコンピュータノード名の設定方法を指定します。指定可能な値は
none(コンピュータ名を挿入しない),hostname(gethostnameシステムコールで取得した名前),fqd(マシンの完全修飾ホスト名),numeric(マシンの IP アドレス),user(nameオプションで指定する任意の値) のいずれかです。既定値はnoneです。nameマシンを識別するためのユーザ定義の文字列です。このオプションを動作させるには、
name_formatオプションがuserでなければなりません。それ以外の場合、このオプションは無視されます。max_restarts非負の整数を入れる項目で、監査イベントディスパッチャに対して、何回までクラッシュしたプラグインを再起動しようとするかを指定します。既定値は 10 です。
例 40.10: /etc/audit/auditd.conf の例 #
q_depth = 250 overflow_action = SYSLOG priority_boost = 4 name_format = HOSTNAME #name = mydomain
プラグインプログラムでは、自身の設定ファイルを専用のディレクトリである /etc/audit/plugins.d にインストールします。プラグインの設定ファイルには、下記のようなオプションがあります:
activeプログラムが
auditdを使用するかどうかを指定します。指定可能な値はyes(はい),no(いいえ) のいずれかです。directionプラグインと監査システムの通信方法を指定します。これはイベントディスパッチャに対して、イベントの流れる方向を示すことになります。指定可能な値は
in(入力),out(出力) のいずれかです。pathプラグインの実行ファイルに対する絶対パスを指定します。内部プラグインの場合、ここにはプラグイン名を指定します。
typeプラグインの動作方法を指定します。指定可能な値は
builtin,alwaysのいずれかです。builtinは内部プラグイン (af_unixおよびsyslog) であることを示すもので、alwaysはほとんどすべて (ただし全てではありません) のプラグイン向けの値です。既定値はalwaysです。argsプラグインプログラムに渡すパラメータを指定します。通常、プラグインプログラムは自身の設定ファイルからパラメータを読み込む仕組みであるため、何もパラメータを指定する必要はありません。また、 2 個までのパラメータに対応しています。
format監査ディスパッチャがプラグインプログラムに渡すデータの形式を指定します。指定可能な値は
binary,stringのいずれかです。binaryはイベントディスパッチャが監査デーモンから受信したデータをそのまま渡す指定で、stringはディスパッチャに対して、イベントデータを監査処理ライブラリで処理できる文字列に変換する指定です。既定値はstringです。
例 40.11: /etc/audit/plugins.d/syslog.conf の例 #
active = no direction = out path = /sbin/audisp-syslog type = builtin args = LOG_INFO format = string