3    システムの監査

Tru64 UNIX オペレーティング・システム・ソフトウェアには,監査サブシステムが含まれています。監査サブシステムは,各ファイルのオープン,ファイルの作成,ログイン,およびプリント・ジョブの送信など,システムで発生するイベントを記録します。各イベントは作成したユーザの監査 ID (AUID) が関連付けられるため,どのアクションも特定のユーザまでたどることができます。ユーザは,監査サブシステムと直接やり取りすることはありません。

この章では,以下について説明しています。

3.1    監査の概要

監査は,システム上で実行されたアクションを記録するための手段を提供します。ユーザのログイン時に,システムはユーザのプロセスと監査 ID (AUID) を対応付ける ID レコードを作成します。 AUID は,どのようなプログラムを実行しているときでも,プロセスに関連付けられたままです。ユーザが実ユーザ ID または実効ユーザ ID を変更しても (su コマンドを使って,root または別のユーザになるなど),システムは監査 ID に基づいて,どの認証ユーザが特定のアクションを行ったかを依然として認識できます。ただし,ユーザ ID の信頼性は,ユーザ ID の検証に使われる認証メカニズムに依存することを忘れないでください。

システムは,各ユーザの特性や承認された権限を記述する詳細な認証プロファイルを管理します (特定のユーザに対するログイン制限など)。

簡単に言うと,監査は次の内容から構成されます。

  1. システムのイベントに伴って監査レコードが生成されます。この監査レコードには,イベント内容,発生日時,およびイベントの原因となったユーザの ID などの情報が含まれます。

  2. 監査レコードは,他の監査レコードとともに監査ログ・ファイルと呼ばれるファイルに保存されます。

  3. ユーティリティを使用して,監査ログ・ファイルに情報を表示し,その情報からレポートを作成します。

図 3-1 に監査サブシステムの概要を示します。

図 3-1:  監査サブシステム

監査は,システム上のイベントを監視する強力なツールとして使用できます。監査を通じて,次のようなことが実現できます。

ユーザに対して,システム上で実行される監査の目的および性質を,一般的な言葉で説明することが大切です。ユーザのファイルおよびシステム・リソースへのアクセスを保護するツールとして,監査を肯定的に説明してください。これにより不平不満を緩和することができます。つまり,システムが常に監査されていることを公にすることで,ユーザが偵察されていると感じることが少なくなります。セキュリティ違反を犯す可能性のあるユーザには,動作が監視されていることを知ることで強力な抑止力となります。

3.1.1    監査ファイル

次のリストでは,監査サブシステムで使用するファイルについて説明します。

/sbin/init.d/audit

監査サブシステムの起動およびシャットダウン・スクリプト。

/var/audit/auditlog.hostname.nnn

省略時のログ・ファイル。Tru64 UNIX 監査サブシステムは指定された任意の場所の任意のファイルにイベントを記録できます。

hostname は監査ログを生成したシステムの名前です。

nnn は世代番号で,000 〜 999 の番号です。

/var/adm/syslog.dated/current/daemon.log

監査サブシステムからのステータス・メッセージ用の省略時のログ・ファイルです。

/etc/rc.config.common

監査サブシステムの現在のシステム省略時設定を含みます。

/etc/sec/audit_events

セキュリティに関係するシステム・イベントをすべて記載するリストを含みます。

このファイルは,システム上のどのイベントを監査するかを制御する,auditmask コマンドへの入力として使用されます。

/etc/sec/site_events

サイト固有の監査イベントを定義するファイル。これはアプリケーション固有の監査を監査サブシステムに統合するのに使用します。

/etc/sec/event_aliases

監査可能なイベント・セットを表す,エイリアス (別名) のリストを含むファイル。

/etc/sec/auditmask_style

プロファイル用の監査のスタイル・フラグを定義するファイル。

/etc/sec/file_objects/*

プロファイル用に監視するファイル名のリストを含むディレクトリ。

/etc/sec/rc_audit_events

監視する監査イベントのリストを含むファイル。このリストはシステムのスタートアップ時にロードされ,ファイルは,/etc/rc.config または /etc/rc.config.common にある実行時構成変数 AUDITMASK_FLAG に指定されます。

/etc/sec/fs_objects

監査を選択 (または選択解除) するファイルのリスト。

/etc/sec/auditd_loc

現在の監査ログが使用不能または一杯になったときに,監査ログを保存する代替パスおよびホストのリスト。

/etc/sec/auditd_clients

ローカル・システムに保存するために,監査データを送信できるリモート・ホストのリスト。

/cluster/members/{memb}/dev/audit

クラスタ・システムでの監査に必要な CDSL。監査サブシステムに関連付けられるデバイスを指定します。

/cluster/members/{memb}/dev/.audit/audS

クラスタ・システムでの監査に必要な CDSL。監査サブシステムに関連付けられるデバイスを指定します。

3.1.2    監査ツール

次のインタフェースを使って,監査サブシステムを管理できます。

3.1.2.1    コマンド行インタフェース

次のコマンドは監査サブシステムのコマンドです。これらのコマンドを使うには,root ユーザである必要があります。コマンドの詳細については,関連するリファレンス・ページを参照してください。

sysman auditconfig

監査ログの格納場所,容量不足になったときに監査サブシステムが取る措置,システムのディスク領域を解放するためにログを削除するまでに監査ログを取っておく期間 (指定によっては無期限) ,ネットワークをまたいで監査を行うかどうかなどを含め,システムの監査環境を対話的に設定します。

auditmask

監査ログに含めるイベントを選択します。また監査ログに現在記録されているイベントのリストを表示します。

auditmask コマンドを使って行った監査サブシステムへの変更は一時的であり,システムをリブートするとリセットされます。

audgen(2) と audgen(8)

特権プログラムまたは選択したメッセージを含むスクリプトから監査イベントのレコードを生成します。

auditd

監査デーモンの起動 (監査の開始),監査ログ・ストレージの管理,および監査デーモンの構成を行います。

auditd コマンドを使って行った監査サブシステムへの変更は一時的であり,システムをリブートするとリセットされます。

audit_tool

監査ログから情報を抜粋し,その情報を読みやすい形式で表示します。

audit_tool.ultrix

ULTRIX システム上で作成した監査ログから情報を抜粋し,その情報を読みやすい形式で表示します。

3.1.2.2    グラフィック・インタフェース

監査サブシステムのグラフィック・インタフェースには,CDE のアプリケーション・マネージャを使って次のようにアクセスします。

「システム管理」-->「日常管理」-->「監査マネージャ」

グラフィック・インタフェースを使って,監査ログの管理パラメータを監査したり,設定したりするためのカーネルを構成することはできません。このようなカーネルを構成するには,sysman auditconfig コマンドを使う必要があります。

3.1.3    監査マスク

監査マスクは監査対象イベントを指定し,そのイベントが成功を示す場合,失敗を示す場合,またはその両方の場合を監査するのかを指定します。監査マスクには,次の 2 種類があります。

3.1.3.1    システム・コール

セキュリティ関連のすべてのシステム・コールでは,監査データが生成されますが,セキュリティに関係しない一部のシステム・コールでは,監査データが生成されないことがあります。システム・コールで監査データが生成されない状況について,表 3-1 に示します。

表 3-1:  監査されない可能性があるシステム・コール

システム・コール 監査レコードが生成されない原因
close() 無効なファイル記述子が渡されたため,システム・コールの実行が失敗に終りました。
dup2() 無効なファイル記述子が渡されたため,システム・コールの実行が失敗に終りました。
execv()execve()exec_with_loader() namei() 検索の失敗,スレッドの終了の失敗,ハンドラの呼び出しの強制終了による失敗。
fcntl()* 無効なファイル記述子が渡されたため,システム・コールの実行が失敗に終りました。
ioctl()* 無効なファイル記述子が渡されたため,システム・コールの実行が失敗に終りました。
msfs_syscall() システム・コールのあらゆる失敗。
priocntlse() 無効なプロセスを指定した (ESRCH) か,このシステム・コールで他のプロセスが変更されていません。
proplist_syscall() システム・コール引数の copyin() での失敗。
reboot() 正常リブートは監査されません。reboot() システム・コールは,正常にリブートできたときには戻りません。
security() getluid オプションについては監査レコードはありません。このオプションはセキュリティに関係がなく,監査を行っても,無用の監査レコードが大量に生成されます。
swapctl() SC_ADD 形式のシステム・コールのみ監査されます。他の形式はセキュリティに関係しません。
uadmin() 障害の発生した A_REBOOT または A_SHUTDOWN のみ監査されます。その他の場合,システムがリブートされ,システム・コールは戻りません。

アスタリスク (*) の印が付いているシステム・コールでは,通常,セキュリティ関連オプションの場合にのみ監査データが生成されます。ただし,-e または -E フラグを指定した auditmask でプロセスを実行すると,すべてのオプションで監査データが生成されます。

システム・コール監査の次の側面に注意してください。

3.1.3.2    トラステッド・イベント

トラステッド・イベントとは,セキュリティ保護メカニズムに関連するイベントのことです。このイベントは,システム・コールに直接対応するとは限りません。トラステッド・イベントの一覧を以下に示します。

audit_daemon_exit

監査デーモンが異常終了したことを示します。これは,監査デーモンの初期化中にメモリが不足した場合にのみ発生します。終了は新しい監査ログに記録され,指定した監査コンソールにメッセージが表示されます。

audit_log_change

監査デーモンが現在の監査ログをクローズし,新しいログに書き込みを開始した (たとえば auditd -x コマンドの結果として) ことを示します。ログの変更は現在の監査ログに記録され,指定した監査コンソールにメッセージが表示されます。

audit_log_create

現在のログ・ファイルが削除されたために,新しい監査ログが作成されたことを示します。新しいファイルには,削除されたログ・ファイルより 1 大きい世代番号が与えられます。新規ログの作成は新しい監査ログの先頭に記録され,指定した監査コンソールにメッセージが表示されます。

audit_log_overwrite

auditd-o overwrite オプションを指定したため,監査デーモンが現在の監査ログに上書きを開始したことを示します。上書きは,上書きが開始された監査ログの先頭に記録され,指定した監査コンソールにメッセージが表示されます。

audit_reboot

auditd-o halt オプションを指定したため (ログがオーバフローした結果),監査デーモンによりシステムのリブートが開始されたことを示します。リブートは現在の監査ログの末尾に記録され,リブートの前に,指定した監査コンソールにメッセージが表示されます。

auditconfig

auditd コマンドに -o changeloc オプションを指定したため,オーバフロー・アクションが変更されたことを示します。監査の設定変更は現在の監査ログに記録されます。

audit_start

監査デーモンが起動されたことを示します。

audit_stop

監査デーモンが正常に終了したことを示す (通常,auditd-k オプションを指定)。シャットダウンは現在の監査ログの末尾に記録され,シャットダウン時に,指定した監査コンソールにメッセージが表示されます。

audit_suspend

auditd-o suspend オプションを指定したため (ログがオーバフローした結果),監査デーモンが監査を一時停止したことを示します。一時停止は現在の監査ログに記録され,指定した監査コンソールにメッセージが表示されます。

audit_xmit_fail

監査デーモンが監査レコードをネットワーク上で送信し,転送に失敗したことを示します。転送の失敗は,/etc/sec/auditd_loc (auditd -r を使用) に次のパスとして指定したローカルのログ,または省略時のローカル・パス (/var/adm) に記録されます。

audgen8

audgen8 コマンド (audgen() ルーチンのコマンド行インタフェース) を使って監査レコードが生成されました。

auth_event

ユーザ認証およびユーザ・アカウントの管理に関するイベントが発生しました。トラステッド・イベント auth_events には,passwdsursh,および login が含まれます。イベントは現在の監査ログに記録されます。

login

ユーザがシステムにログインしようとしました。

logout

ユーザがシステムからログアウトしました。

3.1.3.3    サイト定義イベント

独自の監査イベントを定義することができます (これをサイト定義イベントと言います)。これは,アプリケーションの特定の動作に対してレコードを生成したい場合に役立ちます。

トラステッド・アプリケーション・ソフトウェアでは,サイト定義のイベントおよびサブイベントに対してデータを生成できます。このデータは,システムの監査データとともに監査ログに記録したり,アプリケーション固有のログに格納することができます。

サイト・イベントを定義するには,/etc/sec/site_events ファイルを作成し,システムのサイト・イベントにイベント名とイベント番号を付与する必要があります。site_events ファイルには,サイト・イベントごとに 1 つのエントリがあり,サブイベント番号を格納できます。

サイト・イベント番号に許される最小値は MIN_SITE_EVENT で,<sys/audit.h> に定義されています。通常,この値は 2048 です。省略時では 最大 64 のサイト・イベントを定義できます。ただし,上限値を最大 1,048,576 まで増やすこともできます。

サイト・イベントの許容数の上限を変更するには,/etc/sysconfigtab ファイルにエントリを 1 つ追加した後,システムをリブートします。たとえば,最大 5000 個のサイト定義イベントを使用できるようにするには,sysconfigdb コマンドを使用して,次の行を /etc/sysconfigtab ファイルに追加した後,システムをリブートします。

 sec:
     audit-site-events=5000

/etc/sec/site_events ファイルを作成すると,アプリケーションでは audgenl() ライブラリ・ルーチンを使ってアプリケーション固有の監査データを生成できます。詳細については, audgenl(3) を参照してください。

3.1.3.4    イベント・エイリアス

イベント・エイリアスにより,複数の監査イベントを,選択した単一の名前にグループ化できます。イベント・エイリアスには,システム・コール,トラステッド・イベント,または別のエイリアスを含めることができます。次の形式を使って,/etc/sec/event_aliases ファイルの省略時の Tru64 UNIX イベント・エイリアスの後にイベント・エイリアスを定義します。

[alias: event[:success:failure] [event[:success:failure] ...]]

行の継続も可能です。詳細については,/etc/sec/event_aliases ファイルを参照してください。

3.1.4    監査レコード

監査レコードの出力には,少なくとも,次のデータが含まれます。唯一の例外は,ログインが完了しなかった場合,または監査 ID がプロセスに対して設定されなかった (特定のシステム・プロセスでは通常の状態) 場合,audit_id: は現れません。

audit_id:                  ruid/euid:
pid:                       ppid:                cttydev:
event: 
result: 
ip address: 
timestamp:

audit_id:

監査 ID (AUID)。AUID はログイン時にユーザに対応付けられ,ログイン・セッション中は変更されません。ユーザが起動したプロセスには,そのユーザに対応する AUID が付与されます。su コマンドを使用してユーザ ID を変更しても,AUID には影響がありません。

AUID と LUID (ログイン UID) は同義です。

root アクセス権を得た悪意を持ったプロセスでは,システム・コールを使用して自分の監査 ID を変更できることに注意してください。このような特権プロセスを監視するには,セキュリティ・システム・コールの監視を有効にします。監査 uid の変更は,security() システム・コールに関する監査レコード内で,最初の引数が 0x3 であることから識別できます。監査レコードには元の監査 ID と新しい監査 ID の両方が格納されています。元の監査 ID は結果コード (リターン値) として保存され,新しい監査 ID は引数として保存されています。

ruid/euid:

実ユーザ ID (RUID) と実効ユーザ ID (EUID)。

pid:

プロセス ID。

ppid:

親プロセス ID (PPID)。プロセスのリストを逆にたどって,そのプロセスが生成されたときのイベントと,それに対応する RUID および AUID を調べるのに役立ちます。

cttydev:

イベントが発生したデバイス。このレコードには主デバイス番号と副デバイス番号が含まれています。

event:

イベント名 (通常はシステム・コールの名前またはトラステッド・イベントの名前のいずれか)。

result:または error:

イベントが成功の場合は,その結果。多くの場合,結果は 0 ですが,一部のシステム・コールでは別の値を返します。たとえば,write( ) は書き込まれたバイト数を返します。

エラーの場合,システム・コールの監査レコードにはエラー・メッセージとエラー番号が返されます。たとえば,次のとおりです。

error:     Not owner (1)
 

トラステッド・イベントの監査レコードには,追加のエラー・メッセージがある場合があります。

ip address:

イベントが発生したシステムの IP アドレス。

timestamp:

イベントの日時。

3.1.4.1    監査レコードの追加エントリ

システム・コールの監査レコード内の大部分のエントリは,そのシステム・コールへの引数です。次のリストでは,監査レコードに関連付けられるエントリのラベルを説明します。

ラベルはコンテキスト依存です。つまり,ラベルの意味は,そのラベルが現れる監査レコードの種類に依存します。たとえば,mmap( ) の監査レコードでは,flag:はマップ領域の属性を示します。しかし,audcntl( ) の監査レコードでは,flag:は HABITAT 要求とともに渡される数値です。

ユーザがコマンド行に入力したコマンドは,監査レポートでは char param:への引数として表示されます。たとえば,ユーザが august_report ファイルを sept_report という名前のファイルにコピーすると,監査レコードには次の内容が含まれます。

event:  execve
char param:  /usr/bin/cp
char param:  cp august_report sept_report

個々の監査レコードのコンテキストでは,エントリの意味は直感的に分かります。疑問点がある場合,監査対象のシステム・コールのリファレンス・ページを参照すると,レポートの理解に役立ちます。

監査レコードの各フィールドの名前と説明を以下のリストに示します。

address:

メモリ・アドレス。たとえば,mmap( ) への引数です。

char param:

文字列。文字列はイベントへの引数またはイベント関連のその他の情報です。たとえば次のとおりです。

event:       open
char param:  /etc/zoneinfo/localtime

cmd name:

このイベントを生成したプロセスの名前 (プロセスを開始した exec コマンドの arg 0)。

cntl flag:

制御フラグ。たとえば,audcntl( ) 要求へのフラグの 1 つです。

descriptor:

ファイル記述子。状態依存情報が使用できる場合は,実際のファイル名と記述子です。

devname:

デバイス名。

directory:

現在のディレクトリの名前。

flag:

システム・コールへの flag 引数。たとえば,mmap( ) のコンテキストでは,マップ領域の属性を示します。audcntl( ) のコンテキストの場合は,システム・コールの番号であり,HABITAT 要求の 1 つとともに渡されます。

flags:

フラグとしてシステム・コールに渡される引数。たとえば,open( ) では oflag 引数として渡される値です。

gid:

グループ ID。

home dir:

ホーム・ディレクトリ。

hostname:

ホスト名。

inode id:

i ノード番号。inode dev とともに,ファイル動作の監査レコードとして記録される記述子情報の一部です。

inode dev:

i ノードの主デバイス番号と副デバイス番号。

int param:

整数値。たとえば,setpgid( ) では process_id 引数です。

len:

mmap( ) への引数。メモリ領域の長さです。

login name:

ログイン・ユーザ名

long param:

long 型の値。

mask:

マスク引数。たとえば,audcntl( ) では SET_SYS_AMASK 要求とともに渡される値です。

object mode:

オブジェクトの保護モード。たとえば,open( ) ではオープンするファイルのモードです。

operation:

SET_SITEMASK など,audcntl( ) への要求。

pgrp:

プロセス・グループ ID。たとえば,setpgrp( ) への process_group_id 引数です。

procname:

PID に対応するプロセス名。

prot:

mmap( ) への引数。メモリ領域の保護情報です。

req mode:

要求モード。たとえば,open( ) O_CREAT では新しいファイルの保護モードです。

request:

security( ) の呼び出しで要求されたセキュリティ・アクション。

shell:

ユーザのシェル・プログラム。通常,このレコード要素は login イベント・レコードに現れます。

username;

イベントに関連するユーザ名。

監査レポートの生成に,audit_tool -w オプションを使用するか監査マネージャの「UID/GID をローカルの名前に変換する」を選択すると,カッコ内にユーザ名が表示されます。このカッコは,/etc/passwd 内でユーザ名を検索するために,監査縮小ツールで getpw() ルーチンを使用する必要があったことを示します。これは,ログイン時に RUID にユーザ名が対応付けられなかった場合 (たとえば,ログインが監査イベントに含まれていないなどの場合) に発生します。監査イベント間の依存関係については,3.5.3 項を参照してください。

3.2    監査サブシステムの構成

監査はカーネル内に組み込む必要があります。使用しているシステムのカーネルに監査サブシステムが構成されていない場合,監査構成手順のガイダンスに従うとカーネルを再構築して,監査サブシステムを含めることができます。

システム単位の監査に加え,エンハンスト・セキュリティ・サブセット OSFC2SECnnn を含めることで,ユーザごとのイベント監査を指定することができます。監査用の dxaudit グラフィック・インタフェースには,ソフトウェア・サブセット OSFXC2SECnnn が必要です。nnn は,Tru64 UNIX のバージョン番号です。現在のバージョン番号は,『リリース・ノート』 を参照してください。これらのサブセットがインストールされているかどうかを調べるには,次のコマンドを実行します。

# setld -i | grep C2SEC*
OSFC2SECnnn  installed  Enhanced Security (System Administration)
OSFXC2SECnnn installed  Enhanced Security GUI (System Administration)
 

サブセットのインストールの詳細については,『インストレーション・ガイド』 および setld(8) を参照してください。

監査サブシステムを構成する作業には次のフェーズがあります。

  1. 監査用のカーネルを構成し,監査ログの管理パラメータを設定します。この部分では,監査ログの格納場所,容量不足になった場合の措置,システムのディスク領域を解放するためにログを削除するまでに監査ログを取っておく期間 (指定によっては無期限),監査データの格納場所を集中化するかどうかを選択します。

    監査データの格納場所を集中化するかどうかは任意です。TCP/IP ネットワークで接続されたコンピュータがある場合,より高度のセキュリティ・レベルが設定されているリモート・ホスト (監査ハブ) のシステムに監査データを集中化する場合に行います。監査データの格納場所の集中化は,ローカル・システムの監査データを格納する方法に代わる選択肢です。3.2.1 項で説明されているように,構成プロセス時またはそれ以降に,監査データの格納場所の集中化を構成できます。

  2. 監査対象イベントを選択します。

次の手順は,監査サブシステムを構成する方法を説明しています。

  1. 監査サブシステムの構成のフェーズ 1 では,sysman auditconfig コマンドを入力して監査の構成を開始します。使用しているシステムのカーネルに監査サブシステムが構成されていない場合,sysman auditconfig のガイダンスに従うとカーネルを再構築できます。

    1. 「ようこそ」画面で [はい] をクリックし,監査の構成を開始します。

    2. 「情報」画面で [OK] をクリックします。

    3. 監査ログの保存場所を指定します。次のいずれかの場所を指定できます。

      • 省略時の保存場所 (/var/audit/auditlog.hostname.nnn)

      • システム上のその他の保存場所。

      • 監査ハブにシステムの監査データを格納する場合,その監査ハブのホスト名を入力して,その後ろにコロンを付けます。

      「ログのパス名」画面で [次へ>] をクリックします。

    4. 「ログ・ファイル・スペース不足時のアクション」画面で [次へ>] をクリックし,ログのスペースがなくなった場合の動作の省略時の動作を採用します (ファイル・スペースができるまで監査を停止する)。

    5. 「ログ・ファイルの存在期間」画面で,月数で表される監査ログの省略時の期限を採用します。省略時の期限は無期限 (削除しない) で,削除を実行する時刻は 3 時です。

    6. このシステムを監査ハブにして,他のネットワーク・システムが監査データを格納するようにしたい場合は,「リモート・クライアントがこのシステムに監査情報を記録できる」オプションを有効にした後,[リモート・クライアントの設定] ボタンをクリックします。「監査の設定:リモート・クライアント」ウィンドウが表示されます。このウィンドウに,監査データを記録する各クライアントの完全修飾子付きドメイン名を入力します。

      「拡張監査オプション」画面の [フェーズ 1 の完了] をクリックして,監査コンソール・メッセージの省略時の格納先 (syslog-/var/adm/syslog.dated/current/daemon.log) を受け入れます。

    7. 「監査イベント情報」画面の「フェーズ 2 へ処理を進めますか?」という質問に対し,[はい] をクリックしてパート 2 に進みます。

  2. 監査サブシステムの構成のフェーズ 2 では,次の表で説明されている 6 つのプロファイル・リストから選択する必要があります。監査プロファイルでは,監査サブシステムでの監査内容を定義するパラメータを統合し,プロファイル内でその情報をグループ化する手段を提供します。

    プロファイル 説明
    Desktop シングルユーザ・システムに適した最小監査
    NIS_server NIS サーバとして使用するシステムに適した監査
    Networked_system ネットワーク上のシステムに適した監査
    Server ネットワーク・ベースのアプリケーション用のサーバとして使用するシステムに適した監査
    Timesharing 複数の対話型ユーザをサポートするシステムに適した最小監査
    Timesharing_extended_audit 複数の対話型ユーザをサポートするシステムに適した拡張監査

    プロファイルは,次の 3 つのパートで構成されています。

    監査スタイル情報

    /etc/sec/auditmask_style 内の Profile: ラベルの下にあります。有効な監査スタイルの特性については, auditmask(8)-c オプションを参照してください。

    監視対象監査イベント

    /etc/sec/event_aliases 内の Profile:ラベルの下にあります。

    監視対象ファイル

    このファイルの一覧は,/etc/sec/file_objects/Profile ファイルにあります。監視を実行するには,オブジェクト選択フラグおよびオブジェクト選択解除フラグを適切に設定します。/etc/sec/auditmask_style 内の情報で,どのフラグが設定されているか分かります。このファイルはオプションであり,/etc/sec/auditmask_style 内で定義されている監査スタイルに obj_selobj_desel のどちらも含まれていない場合は,このファイルは不要です。

    1. 「監査イベントのカテゴリ選択」画面で,システム構成に最も近いプロファイルを選択し,[次へ>] をクリックします。

      CTRL キーを使用すると,ネットワーク上のデスクトップ・システムに対して,DesktopNetworked_system というように,複数のカテゴリを選択できます。複数のカテゴリを選択できますが,ニーズに合った最小限のプロファイルを使用するようにしてください。

      監査するイベントの省略時のリストを採用することとして,「上級ユーザ向け監査イベントの修正/削除」画面で [次へ>] をクリックします。

    2. 一部のプロファイルにはこの手順が必要ですが,それ以外は次の手順に進んでください。監査するファイルの省略時のリストを採用することとして,「UNIX ファイル・システム・オブジェクト」画面で [次へ>] をクリックします。このメニュー項目は,すべてのプロファイルで表示されるわけではありません。

    3. 「拡張オプション」画面で [完了] をクリックし,プロファイルを選択した結果として設定された監査イベントのオプションを採用します。

  3. 「監査設定の完了」画面で [了解] をクリックし,監査設定を完了します。

    選択が完了すると,auditconfig は次の処理を実行します。

  4. auditd -w コマンドを入力して,監査デーモンの構成をチェックします。省略時の指定を使用した場合,構成が次のように表示されます。

    # auditd -w
     
    Audit data and msgs:
    -l) audit data destination                 = /var/audit/auditlog.hostname.001  [1]
    -c) audit console messages                 = syslog  [2]
     
    Network:
    -s) network audit server status (toggle)   = off  [3]
    -t) connection timeout value (sec)         = 4
     
    Overflow control:
    -f) % free space before overflow condition = 10  [4]
    -o) action to take on overflow             = suspend audit  [5]
     
    

    1. 監査ログの名前。 [例に戻る]

    2. 監査サブシステムのメッセージの格納場所。監査サブシステムの状態が変化すると,ここに記録されます。 [例に戻る]

    3. ネットワークを介した監査は有効になっていません (リモート・クライアントはこのシステムに記録されません)。 [例に戻る]

    4. 監査でオーバフロー状態として検出するファイル・システムの空きスペースの量 (パーセント)。この場合,10 パーセントです。

      監査ログが置かれているファイル・システムが 90 パーセント以上使用された状態になると,監査サブシステムはオーバフロー・アクションを実行します。 [例に戻る]

    5. オーバフロー・アクションでは,格納スペースができるまで監査を一時停止します。

      alternate file systems の部分には,/etc/sec/auditd_loc で指定したディレクトリ名が表示されます。 [例に戻る]

3.2.1    監査データ格納場所の集中化

TCP/IP ネットワークで接続された複数のコンピュータがある場合,ローカル・システムに監査データを格納する方法の代わりに,複数のシステムで監査デーモンを実行し,リモート・システム (監査ハブ) の監査デーモンに監査データを送信し,より高度なセキュリティ・レベルが設定されている単一のシステムに情報を格納することができます。

監査データの破損を防ぐために,リモート・システムの監査データは,監査ハブにある専用の監査ログ・ファイルに格納されます。

監査ツールを使用して,リモート・システムから監査データのログを取り出すと,監査ログの最初と最後のエントリは,完全なエントリにならずに途中で切れている可能性があります。これは,通信チャネルが正しく切断されなかったり,auditd デーモンがリモートでデータを受信しているときにログ・ファイルが強制的に切り替えられた場合に発生します。原因は,監査ハブへ送られるリモートの監査情報が,監査エントリごとではなく連続したストリームとして送られるためです。

エントリが途中で切れている場合は,監査ツールによって通知されます。監査ログからの他のレコードの取り出しには影響はありません。

監査データの格納場所の集中化には,監査ハブの構成と,この監査ハブに監査データを送信するリモート・システムの構成が必要です。監査サブシステムを構成する時点で,監査データの格納場所を集中化するように構成していない場合は,次の項で説明されているコマンドを使って構成します。

3.2.1.1    監査ハブへの監査データ格納場所の集中化の構成

監査データの格納場所を集中化するように監査ハブを構成するには,次の手順を実行します。

  1. 監査情報の収集拠点となるホスト (監査ハブ) で,/etc/sec/auditd_clients ファイルを作成します。このファイルの各行に,監査ハブに監査データを送信するリモート・ホストの名前をそれぞれ入力します。

  2. 次のコマンドを入力して監査ハブを使用可能にし,/etc/sec/auditd_clients ファイルに指定したリモート・ホストの監査デーモンからの監査データを受信できるようにします。

    # /usr/sbin/auditd -s
    

  3. リモート監査デーモンのオプションを次のように設定します。

    auditd [-p ID_of_daemon_serving_remote_host options_for_remote_daemon]

    たとえば,ID 6 の監査デーモンが稼働しているリモート・ホストに対し,監査ログの格納場所を /var/audit/NYC_Sys1 に設定するには,次のように入力します。

    # /usr/sbin/auditd -p 6 -l /var/audit/NYC_Sys1
    

    リモート・ホストの監査デーモン ID は整数です。監査デーモン ID を表示するには,次のように入力します。

    # /usr/sbin/auditd -w
     
     
    

    このコマンドは,現在のオプションを表示します。少なくとも 1 つの子監査デーモンが存在しなければ,監査 ID は表示されません。1 つ以上の監査デーモンを実行している場合に,-p オプションが指定されないと,マスタ・デーモン (ローカル・システムの監査データを受信) が要求を処理します。

監査ツールを使用して,リモート・システムから監査データのログを受信すると,監査ログの最初と最後のエントリは,完全なエントリにならずに途中で切れている可能性があります。これは,通信チャネルが正しく切断されなかったり,auditd がリモートでデータを受信しているときにログ・ファイルが強制的に切り替えられた場合に発生します。原因は,監査ハブへ送られるリモートの監査情報が,監査エントリごとではなく連続したストリームとして送られるためです。

エントリが途中で切れている場合は,監査ツールによって通知されます。監査ログからの他のレコードの取り出しには影響はありません。

3.2.1.2    監査ハブでのリモート・システムの監査データ記憶域の構成

それぞれのリモート・ホストで次のコマンドを入力し,監査ハブへ監査データを送信するようにします。

# /usr/sbin/auditd -l audit_hub_name:

リモート・システムが監査ハブに接続できない場合,auditd-o および -r フラグの指定に従って,リモート・ホストの監査デーモンは監査データをローカルに保存します。

3.3    監査サブシステムの管理

次の項で,以下を説明します。

3.3.1    監査サブシステムの起動時の省略時設定の変更

監査サブシステムに対するシステム起動時の省略時設定は,/etc/rc.config.common ファイル内の AUDITMASK_FLAG 変数に保存されます。このフィールドを使用して,システムの起動時にコマンド行引数を auditmask に渡すことができます。AUDITMASK_FLAG 変数により,監査スタイル・フラグが設定され,/etc/sec/rc_audit_events ファイルから監査用に選択されたイベントを auditmask が読み込むように設定されます。/etc/sec/fs_objects ファイルには,監査サブシステムの構成時に,オブジェクトの選択および選択解除を監視するようにプロパティ・リストが変更されたファイルのリストが含まれます。

/etc/rc.config.common ファイルの AUDITMASK_FLAG 変数は,rcmgr コマンド,sysman auditconfig コマンド,または CDE のダッシュボードから「監査マネージャ」を使用して変更できます。

/etc/sec/rc_audit_events ファイルは,テキスト・エディタ,sysman auditconfig コマンド,または CDE のダッシュボードから「監査マネージャ」を使って変更できます。

3.3.2    監査デーモンの起動,停止,一時停止

監査デーモンを起動するには,次のように入力します。

# auditd [-l log_pathname]

監査デーモンを停止するには,次のように入力します。

# auditd -dk

TruCluser Server 環境で監査デーモンを停止するには,次のコマンドを入力します。

# auditmask [-cluster] -n
# auditd [-cluster] -dk

監査デーモンを一時停止するには,次のように入力します。

# auditd -o suspend | halt

3.3.3    監査ログのアーカイブ

監査ログ・データを収集した後,監査ログ・ファイルを体系的にアーカイブする手順が必要です。監査ログ・データを使用する多くのアプリケーションでは,数ヶ月前のデータを検索して分析できる必要があります。

sysman auditconfig ユーティリティでは,root の cron ジョブを使用して,バイナリ監査ログを定期的に削除することができます。この機能は省略時の設定では無効になっています。この機能を有効にするときには,cron ジョブを実行する前に,監査ログ・ファイルのバックアップを定期的に取るようにする必要があります。

ログ・ファイルの存在期間」ダイアログ・ボックスには,削除を実行する月単位の周期や削除の基準が表示されます。削除は指定した月の 1 日 (初日) に実行されます。時間は設定可能ですが,分は 0 分に設定されています。バイナリ監査ログは,バイナリ監査ログに含まれるすべての監査イベントが,削除実行日から「ログ・ファイルの存在期間」を差し引いた日付よりも古くなると削除されます。

たとえば,2 カ月目,4 カ月目,6 カ月目の 1 日午前 3 時に実行する cron ジョブを作成するには,次のように入力します。

"ログ・ファイルの存在期間" = "2 カ月間隔"
"削除する時間 (0-23)" = "3"

バイナリ・ログ・ファイルは含まれているエントリがすべて 2 カ月以上古くなると,cron 実行時に削除されます。

3.3.4    監査データの回復

システムでパニック状態が発生した場合,crashdc ユーティリティを使って,パニック時にシステムに残されたすべての監査データを抽出し,crash ディレクトリ内の audit-data.n ファイルに格納します。

n はクラッシュ番号です。監査データがない場合,このファイルは作成されません。audit_tool コマンドを使って,audit-data.n ファイルの内容を表示できます。

一部の監査レコードは,auditlog ファイルと audit-data.n ファイルの両方に記録されることがあります。audit-data.n ファイル内の最初の監査レコードは完全でない可能性があります。audit_tool コマンドでは,これを破損レコードとして印を付けます。この場合,監査レコードは通常の auditlog ファイルに書き込まれています。

3.4    監査イベントの管理

次の項で,以下の作業の方法を説明します。

3.4.1    監査マスクの表示

現在の監査マスクを表示し,成功イベント,失敗イベントの一方または両方について監査されているかどうか確認するには,次のコマンドを使います。

succeed というキーワードを入力すると,成功イベントが監査の対象となります。fail というキーワードを入力すると,失敗イベントが監査の対象となります。両方のキーワードを入力すると,成功と失敗の両方のイベントが監査の対象となります。

3.4.2    システムで監査できるイベントの特定

次の手順を実行して,監査可能なすべてのイベントのリストを含む all_auditable_events ファイルを作成します。

  1. 現在の監査マスクを original_audit_mask ファイルに保存します。

    # auditmask > original_audit_mask

  2. すべてのイベントを監査するように監査マスクを設定します。

    # auditmask -f

    auditmask -f コマンドを実行すると,システムの速度が低下することがあります。

  3. all_auditable_events ファイルに監査マスクを保存します。

    # auditmask > all_auditable_events

  4. どのイベントも監査しないように監査マスクを設定します。

    # auditmask -n

  5. 監査マスクを元の状態 (イベント) に戻します。

    # auditmask < original_audit_mask

3.4.3    監査イベントの有効化

監査サブシステムでは大量のデータを生成し収集できます。このため,監査サブシステムが生成するデータの上限を適切に設定し,監査ログの増加を監視する必要があります。この監視によって,監査ログでファイル・システムが一杯になり,サービス不能の状態にならないようにします。

監査サブシステムを構成し,プロファイルを選択する際に,監査対象のイベントを選択しますが,イベントの選択や選択解除を行えば,いつでも監査マスクを変更できます。

監査対象のイベントを選択するには,次のコマンドを使います。

3.4.4    監査イベントの無効化

それぞれのイベントに対して監査を無効にするには,次のコマンドを実行します。

3.4.5    プロセスのトレース

auditmask ユーティリティを使って,システム,単一のプロセス,あるいはユーザの監査 ID (AUID) に関連付けられているすべてのプロセスの監査特性を調整できます。監査レコードの生成は,システム監査マスク,プロセス監査マスク,およびプロセス audcntl フラグに基づきます。それぞれの監査マスクは,すべてのイベントのビットマップです。

プロセス audcntl フラグは,以下を指定します。

or

システムまたはプロセス監査マスクのどちらかに指定イベントがあれば監査対象とします。省略時の audcntl フラグ設定は or です。

and

システムおよびプロセス監査マスクの両方に指定イベントがあれば監査対象とします。

off

プロセスに対して監査を行いません。

usr

プロセス監査マスクに指定イベントがあれば監査対象とします。

システム・コールのセットやエイリアス名を指定することで,監査対象のイベントを指定できます。エイリアスは /etc/sec/event_aliases ファイルで定義されており,そこに追加もできます。このファイルを編集して,システム・コールを追加または削除できます。オプションの拡張を使って,あらゆる成功イベントと失敗イベントを識別できます。たとえば次のとおりです。

open:1:0

open( ) コールの成功を監査するよう指定します。

open:0:1

open( ) コールの失敗を監査するよう指定します。

次の例は,さまざまな目的に即した auditmask ユーティリティの使用方法を示します。これらの例では,プロセス管理マスクを変更します。特に指定しない限り,プロセス audcntl フラグは省略時の設定 or のままです

3.4.5.1    トレース・プロセス・データの表示

トレース・プロセスに関する情報を表示するには,次のコマンドを実行します。

# audit_tool `auditd -dq` -B
 
 

auditd -d オプションは,カーネルのデータを監査ログに書き出します。auditd -q オプションは,現在の監査ログの名前を提供します。

次のような情報が表示されます。

AUID:RUID:EUID    PID    RES/(ERR)   EVENT
-------------- ---   ---------      -----
1123:0:0       6691  0x14           audcntl ( 0x7 0x0 0x14 0x0 )
1123:0:0       6691  0x0            execve ( /sbin/date date )
1123:0:0       6691  0x2000         getpagesize ( )
1123:0:0       6691  0x2000         getpagesize ( )
1123:0:0       6691  0x0            getrlimit ( )
1123:0:0       6691  0x3ffc0004000  mmap ( -1 0x7 0x3ffc0004000 0x12 0x2000 )
1123:0:0       6691  0x0            getrlimit ( )
1123:0:0       6691  0x3ffc0006000  mmap ( -1 0x7 0x3ffc0006000 0x12 0x4000 )
1123:0:0       6691  0x0            getuid ( )
1123:0:0       6691  0x1            getgid ( )
1123:0:0       6691  0xa68          read ( 3 )
1123:0:0       6691  0x120000000    mmap ( 3 0x5 0x120000000 0x102 0x4000 )
1123:0:0       6691  0x140000000    mmap ( 3 0x7 0x140000000 0x2 0x2000 )
1123:0:0       6691  0x4            open ( /shlib/libc.so 0x0 )
1123:0:0       6691  0xa68          read ( /shlib/libc.so )
1123:0:0       6691  0x3ff80080000  mmap ( /shlib/libc.so 0x5 0x3ff80080000 0x2 0x10e000 )
1123:0:0       6691  0x3ffc0080000  mmap ( /shlib/libc.so 0x7 0x3ffc0080000 0x2 0x10000 )
1123:0:0       6691  0x3ffc0090000  mmap ( -1 0x7 0x3ffc0090000 0x12 0x9bf0 )
1123:0:0       6691  0x0            close ( 4 )
1123:0:0       6691  0x0            stat ( /shlib/libc.so )
1123:0:0       6691  0x0            set_program_attributes ( )
1123:0:0       6691  0x0            close ( 3 )
1123:0:0       6691  0x2000         getpagesize ( )
1123:0:0       6691  0x0            obreak ( 0x14000ea10 )
1123:0:0       6691  0x0            gettimeofday ( )
1123:0:0       6691  0x3            open ( /etc/zoneinfo/localtime 0x0 )
1123:0:0       6691  0x32e          read ( /etc/zoneinfo/localtime )
1123:0:0       6691  0x0            close ( 3 )
1123:0:0       6691  0x1d           write ( 1 )
1123:0:0       6691  0x0            close ( 0 )
1123:0:0       6691  0x0            close ( 1 )
1123:0:0       6691  0x0            close ( 2 )
1123:0:0       6691  0x0            exit ( )

3.4.5.2    アクティブ・プロセスの監査

例 3-1 は,guest としてログインしたユーザによって起動されたプロセスを調べるために使用できるコマンドを示します。

例 3-1:  アクティブ監査セッションの例

# ps -uguest -o user,pid,uid,comm  [1]
USER       PID   UID COMMAND
guest    23561  1123 csh
guest    23563  1123 ed
 
# auditmask -p 23563 open exec -c or  [2]
# auditmask -p 23563  [3]
!  Audited system calls:
execv                      succeed  fail
exec_with_loader           succeed  fail
open                       succeed  fail
execve                     succeed  fail
 
!  Audited trusted events:
 
!  Audcntl flag: または
 
# auditd -d 5s -w   [4]
Audit data and msgs:
-l) audit data destination   = /var/audit/auditlog.hostname.001
-c) audit console messages           = /var/audit/auditd_cons
-d) audit data dump frequency        = 5s
 
Network:
-s) network audit server status (toggle)   = off
-t) connection timeout value (sec)         = 4
 
Overflow control:
-f) % free space before overflow condition = 10
-o) action to take on overflow    = overwrite current auditlog
 
# audit_tool /var/audit/auditlog.hostname.001 -Bfw  [5]
USERNAME    PID    RES/(ERR)   EVENT
--------    ---    ---------   -----
jdoe        23563  0x4         open ( /etc/motd 0x0 )
jdoe        23563  0x4         open ( /etc/passwd 0x0 )
jdoe        23563  0x4         open ( /etc/ftpusers 0x0 )
jdoe        23563  0x4         open ( /etc/hosts 0x0 )
jdoe        23583  0x0         execve ( /usr/bin/sh sh -c ps )
jdoe        23583  0x5         open ( /usr/shlib/libc.so 0x0 )
jdoe      * 23592  0x0         execve ( /sbin/ps ps gax ) [6]
jdoe        23599  0x0         execve ( /usr/bin/sh sh -c w )
jdoe        23599  0x5         open ( /usr/shlib/libc.so 0x0 )
jdoe      * 24253  0x0         execve ( /usr/ucb/w w )
jdoe        23563  0x4         open ( savethis 0x602 0640 )
 
[Ctrl/C]  [7]
--interrupt:  exit (y/[n])?  y
 
 

  1. ユーザ guest が実行しているプロセスを見つけ出し,プロセス ID と監査 ID も取得します。 [例に戻る]

  2. PID 23563 に対して,auditmask を open および exec に設定し,システム・マスクで OR 操作を実行します。execexecvexec_with_loader および execve のエイリアスであることに注意してください。 [例に戻る]

  3. 23563 プロセス の auditmask を取得します。 [例に戻る]

  4. 監査ログを 5 秒ごとにダンプ出力し,auditd の構成も表示します。 [例に戻る]

  5. 連続した (-f) 簡略型の (-B) 監査レポートを表示します。AUID を対応するユーザ名に変換します (-w)。

    監査ログの名前は,auditd -w コマンドの結果として取得されたことに注意してください。 [例に戻る]

  6. アスタリスク (*) は setuid を伴う操作を示します。 [例に戻る]

  7. Ctrl/C で audit_tool プログラムを終了します (監査は継続します)。 [例に戻る]

詳細については, auditmask(8) を参照してください。

3.4.5.3    追加のシステム・コール引数の動的な監査

追加のシステム・コール引数が必要な場合,dbx コマンドを使用して,任意のシステム・コールについて,記録する引数を動的に変更できます。システム・コールは,/usr/include/sys ディレクトリ内の関連する .h ファイルで定義されています。たとえば,flock はシステム・コール 131 (/usr/sinclude/sys/syscall.h ファイルで定義) であり,ファイル記述子とオプションを引数として受け取ります。これらの引数を監査するには,次のように dbx コマンドを入力します。

     (dbx) a sysent[131].aud_param[0]='c'
     99
     (dbx) a sysent[131].aud_param[1]='a'
     97

aud_parm 配列の最初のエントリはシステム・コールの最初の引数に対応し,2 番目のエントリはシステム・コールの 2 番目の引数に対応し,以降も同様に対応します。c エンコードはファイル記述子を記録することを示します。a エンコードは整数の引数を記録することを示します。エンコードのセットについては,<sys/audit.h> ファイルに説明があります。

3.4.6    ファイル操作の監査

オブジェクトの選択および選択解除は,監査ログの拡大を管理するための強力なツールです。

mount および reboot などのイベントは,システムの状態に影響を及ぼします。open および stat などのデータ・アクセス・イベントはファイルに作用します。reboot の動作は,通常,セキュリティに影響しますが,ファイルの open イベントは,必ずしもセキュリティに影響しません (サイトのセキュリティ・モデルに依存します)。

オブジェクトの選択および選択解除により,ファイルがデータ・アクセス操作の対象となったときに,どのファイルについて監査レコードを記録 (選択) し,またどのファイルについては記録しない (選択解除) かを選択できます。

データ・アクセス操作を次に示します。

read, open, close, link, lseek, access, 
stat, lstat, dup, open, revoke, readlink, 
fstat, pre_F64_stat, pre_F64_lstat, 
dup2, pre_F64_fstat, readv, pread, getdirentries, 
stat, lstat, fstat, _F64_readv

オブジェクトの選択および選択解除は次のように機能します。

選択

オブジェクトの選択を行って,指定のファイル・セットのいずれかで実行された特定のデータ・アクセス操作を監査できます。auditmask -X コマンドまたは auditmask -x コマンドを使って,ファイル・プロパティ・リストでオブジェクトの選択フラグを設定することによって,これらのファイルが指定されます。同じ操作でも,フラグが設定されていないファイルで実行された場合は,監査データを作成しません。

たとえば,/etc/passwd ファイルと /.rhosts ファイルにフラグを設定し,open システム・コールを監査できます。これにより,/etc/passwd ファイルまたは /.rhosts ファイルの open は監査されますが,/tmp/xxxx ファイルの open は監査されません。

選択解除

オブジェクトの選択解除を行って,指定のファイル・セットのいずれかを変更する特定のデータ・アクセス操作を監査できます。フラグが設定されていないファイルで実行された同じ操作は,ファイルが変更されたかどうかにかかわりなく監査データを作成します。auditmask -Y コマンドまたは auditmask -y コマンドを使って,ファイル・プロパティ・リストでオブジェクトの選択解除フラグを設定することによって,これらのファイルが指定されます。

open によるファイルの書き込みアクセスや切り捨てアクセスがファイル変更の例です。

監査の選択および選択解除では,auditmask -c usr コマンドで指定したプロセスに対する監査を削減するものではありません (監査制御フラグの値は AUDIT_USR)。

オブジェクトの選択および選択解除を使用するには,次の 3 ステップの手順を実行する必要があります。

  1. オブジェクトの選択および選択解除を適用するファイルを選択します。複数のファイルに選択または選択解除を適用する場合,ファイル名 (完全なパス名) をリストしたファイルを作成します。1 行に 1 つファイル名を記述します。

  2. 必要に応じて,監査スタイルを Object Selection または Object Deselection のいずれかに設定します。

    監査マネージャから: 「収集」-->「システムマスクの変更」

    コマンド行から:

    # auditmask -s obj_sel
    

    または

    # auditmask -s obj_desel
    

  3. オブジェクトの選択および選択解除を次のように起動します。

    オブジェクトの選択が 1 ファイルの場合:

    # auditmask -x filename

    オブジェクトの選択が filelist という名前のファイルにリストされている一連のファイルの場合:

    # auditmask -X filelist

    オブジェクトの選択解除が 1 ファイルの場合:

    # auditmask -y filename

    オブジェクトの選択解除が filelist という名前のファイルにリストされている一連のファイルの場合:

    # auditmask -Y filelist

次の例に,監査対象ファイルの選択を有効にする方法を示します。

# auditmask -s obj_sel
# auditmask -q /etc/passwd
selection:off    deselection:off  --  /etc/passwd
# auditmask -x /etc/passwd
selection:off => on   --  /etc/passwd
# auditmask -q /etc/passwd
selection:on     deselection:off  --  /etc/passwd
 
 

次の例に,一連のファイルを選択解除する方法を示します。

# auditmask -s obj_desel
# cat desel_file
/etc/motd
/etc/fstab
/etc/passwd
# auditmask -Q desel_file
selection:off    deselection:off  --  /etc/motd
selection:off    deselection:off  --  /etc/fstab
selection:off    deselection:off  --  /etc/passwd
# auditmask -Y desel_file
deselection:off => on   --  /etc/motd
deselection:off => on   --  /etc/fstab
deselection:off => on   --  /etc/passwd
 
 

ファイル・リストに対するオブジェクトの選択フラグおよび選択解除フラグのステータスは,CDE のダッシュボードから次のように表示できます。

  1. 「アプリケーション・マネージャ」-->「日常管理」-->「監査マネージャ」--> [収集] --> [システムマスクの変更] --> [現在] --> [編集] --> [Object Selection/Deselection] を選択します。

  2. 「ファイル」で,/etc/sec/fs_objects を指定します。

  3. 「ファイル・タイプ」で,「ファイルの一覧」を指定します。

  4. 「設定」はそのままにします。

  5. [Query] をクリックします。

システムのオブジェクト選択およびオブジェクト選択解除の監査スタイルは相互に排他的ですが,異なるシステム上で同じオブジェクトに対して両方のモデルを同時に指定する可能性があります (NFS 経由)。NFS を介して属性を転送するには,proplistd デーモンを実行している必要があります。

3.5    監査レポートの生成および表示

省略時の設定では,次のような名前の付いた監査ログ・ファイルの /var/audit ディレクトリに監査レコードが保存されています。

auditlog.hostname.nnn

hostname はローカル・ホストの名前です。nnn は,自動生成される数値のサフィックスで,監査ログ・ファイル名に付加されます。数値のサフィックスは,000 〜 999 までの連番です。

監査ログから,表示する監査レコードを含んだレポートを生成できます。次の機能を使用して,監査レポートを生成し,表示できます。

3.5.1    監査レコードのフィルタリング

選択解除ファイルの内容を使用して,表示したくない監査レコードをフィルタ処理によって除外することができます。選択解除ファイルは,次の形式で入力された 1 行以上の文字列で構成されています。

[hostname audit_ID RUID event pathname flag]

フィールド内のアスタリスク (*) はワイルドカードであり,常に一致します。文字列の末尾にプラス記号 (+) を付けると,指定した文字列で始まるすべての文字列と一致します。flag では,open イベントに対して読み取りモード (r) または書き込みモード (w) を指定します。たとえば,パス名が /usr/lib/ で始まるオブジェクトについて,読み取りアクセスを行うすべての open 操作をフィルタ処理によって除外するには,ファイルに次の行を指定します。

* * * open /usr/lib/+ r

選択解除ファイルで指定した行は,その他の選択オプションよりも優先されます。複数の選択解除ファイルを作成できますが,監査の縮小を実行するときには,選択解除ファイルは 1 つしか指定できません。

選択解除ファイルを使って,監査レポートを表示するには,次のコマンドを実行します。

# audit_tool -d deselection_file

3.5.2    簡略型監査レコードの表示

audit_tool -B コマンドにより,簡略レコード形式で監査レポートが生成されます。

簡略型レポートの例は次のとおりです。

AUID:RUID:EUID    PID    RES/(ERR)   EVENT
--------------    ---    ---------   -------------------------------------
-1:0:0            2056   0x0         execve (/usr/sbin/rlogind rlogind )
-1:0:0            2057   0x0         execve (/usr/bin/login login -p -h
alpha1.sales.dec.com guest)
1234:0:0          2057   0x0         login  (guest)
1234:1234:1234    2057   0x0         execve (/bin/sh -sh)
1234:1234:1234    2058   0x0         execve (/usr/bin/stty stty dec)

簡略型レポートのカラム見出しは次のとおりです。

AUID:RUID:EUID

イベントに関連する監査 ID,実ユーザ ID,および実効ユーザ ID。

PID

プロセス ID 番号。

RES/(ERR)

RES は結果コードです。結果コードについては,各システム・コールのリファレンス・ページを参照してください。

(ERR) は,エラーが発生した場合のエラー・コードです。エラー・コードの一覧と各コードの意味については, errno(2) を参照してください。

EVENT

最後の欄にはイベントと引数が表示されます。

以下の情報は,簡略型レポートには表示されません。

カスタマイズした簡易レポートを生成するには, audit_tool(8)-O オプションを参照してください。

3.5.3    監査イベント間の依存関係

監査ログの一部の情報は,以前に監査したイベントに基づいています。たとえば,LOGIN イベントはログイン名と実 UID (RUID) を対応付けます。その結果,以降の (あるプロセスに対する) RUID はログイン名と対応付けられます。このようなデータは,状態依存情報と呼ばれます。省略時の設定では,audit_tool コマンドは監査レコードの状態に関する情報を相互参照します。参照しないようにするには,-F オプションを実行します。

次の 3 つの監査レコードは,状態依存情報の例を示します。最初のレコードは,/etc/passwd の正常な open() を示し,3 という値を返しています。

audit_id:    1621      ruid/euid: 0/0         (username: root)
pid:         23213     ppid: 23203            cttydev: (6,1)
procname:    state_data_test
event:       open
char param:  /etc/passwd
flags:       2 : rdwr
vnode id:    2323       vnode dev:   (8,1024)   [regular file]
object mode: 0644
result:      3 (0x3)
ip address:  16.153.127.241 (alpha1.sales.dec.com)
timestamp:   Wed Nov 10 17:49:59.93 2000

次のレコードは,/etc/passwd ファイルに対する ftruncate() システム・コールの結果を状態依存情報を使って示します。状態依存データにより,このプロセスの記述子 3 にファイル名 /etc/passwd が対応付けられています。

audit_id:    1621      ruid/euid: 0/0         (username: root)
pid:         23213     ppid: 23203            cttydev: (6,1)
procname:    state_data_test
event:       ftruncate
vnode id:    2323      vnode dev:   (8,1024)   [regular file]
object mode: 0644
descriptor:  /etc/passwd (3)
result:      0
ip address:  16.153.127.241 (alpha1.sales.com)
timestamp:   Wed Nov 10 17:49:59.96 2000

状態依存データを管理していない場合,ftruncate() システム・コールが記述子 3 (vnode ID = 2323, dev = 8,1024) に対して発行されたことのみ表示されます。

audit_id:    1621      ruid/euid: 0/0         (username: root)
pid:         23213     ppid: 23203            cttydev: (6,1)
event:       ftruncate
vnode id:    2323      vnode dev:   (8,1024)   [regular file]
object mode: 0644
descriptor:  3
result:      0
ip address:  16.153.127.241 (alpha1.sales.com)
timestamp:   Wed Nov 10 17:49:59.96 2000

表 3-2 に,状態依存情報およびそれを管理するのに必要な監査イベントをリストします。

表 3-2:  状態依存情報

必要な状態依存情報 監査するイベント
ログイン・ユーザ名 loginlogout
プロセス名 execv,execve,exec_with_loader,exit
ファイル情報/ソケット情報 open,old_open,close, dup, dup2,fcntl,bind,connect,accept,naccept,socket,proplist_syscall
現在のディレクトリ chdir,chroot,fchdir
監査の状態 audit_suspend,audit_log_create,audit_log_overwrite,audit_shutdown,audit_xmit_fail

exit() システム・コールは,このシステム・コールによって終了するプロセスに対する状態依存情報が不要になることを audit_tool に知らせます。これにより,audit_tool の実行が速くなります。

状態依存データに関心がない場合,exit() を監査する必要はありません。また,audit_tool プログラムに -F オプションを指定して,高速モードにします。

詳細については, audit_tool(8) を参照してください。

3.6    従来の UNIX のロギング・ツール

セキュリティ関連の監査には監査サブシステムを使用します。従来の UNIX オペレーティング・システムのロギング・ツールが使用でき,次のイベント・カテゴリに対する監査機能が提供されています。

これらの各カテゴリの監査には,関連情報を保存するデータ・ファイル,および保存されたデータを参照する手段などが関係します。データを参照する手段として lastlastcomm などの特定コマンドを使用する場合もあります。その他の場合は,ファイル内容を,more コマンドなどで直接表示します。

表 3-3 のように,アカウント・データは /var/adm ディレクトリのいくつかのファイルに保存されます。システムにあるログ・ファイルは,どのロギング機能およびアカウント機能を有効にしているかによって異なります。

表 3-3:  /var/adm にある従来の UNIX ログ・ファイル

ファイル名 セキュリティ関連情報
wtmp すべてのログイン,ログアウト,およびシャットダウンが記録されます。このログは last コマンドを使用して表示します。
syslog.dated/date/daemon.log システム・デーモンによって生成されたメッセージ。
syslog.dated/date/kern.log カーネルによって生成されたメッセージ (システム・クラッシュなど)。
syslog.dated/date/lpr.log ライン・プリンタのスプール・システムによって生成されたメッセージ。
syslog.dated/date/mail.log メール・システムによって生成されたメッセージ。
syslog.dated/date/user.log ユーザ・プロセスによって生成されたメッセージ。
syslog.dated/date/syslog.log DECnet ファイル転送の要求。
acct ユーザ・コマンドを含む生のシステム・アカウント・データ。

これらのファイルの内容を保護してください。これらのファイルおよびディレクトリは,root アカウントが所有し,groupother では書き込み不可とする必要があります。

UNIX アカウントについては,『システム管理ガイド』 を参照してください。

3.7    TruCluster での監査

/usr/sbin/sysman auditconfig ユーティリティの [Custom Setup] メニュー上の「Audit Configuration」アイコンを使うと,監査オプションをクラスタ単位で構成できます。クラスタ作成時のカーネル構築では,監査のサポートが自動的に組み込まれます。

監査の構成は,2 段階の手順で行います。最初に,監査ログ・ファイルの名前および位置などの,監査デーモンのパラメータを指定します。次に,監査マスクと呼ばれる,監査対象のイベント一式を選択します。構成ユーティリティによって,各クラスタ・メンバで同じパラメータとイベントが使われるようになります。一元管理を維持するために,auditconfig ユーティリティは,この監査構成情報を /etc/rc.config.common ファイルに格納します。

監査を有効にするために新たにカーネルを構築する必要ありません。これは,クラスタ・カーネルの最初の構築で,DEC_AUDIT カーネル・オプションと特殊ファイル /dev/audit がすべてのクラスタ・メンバに自動的に組み込まれるためです。

監査が有効のとき,監査デーモン (auditd) がクラスタの各メンバ上で実行されます。各監査デーモンは,イベント固有の監査ログ・エントリをプライベート監査ログ・ファイルに記録します。省略時のプライベート監査ログ・ファイルの名前は,/var/audit/auditlog.{membername}.nnn です。各監査ログ・エントリにはそのログが発生したメンバのホスト名が含まれているため,複数の監査ログ・ファイルのエントリを簡単にマージして表示することができます。図 3-2 は,監査データが収集される様子を示しています。

図 3-2:  クラスタ内の監査データの流れ

各監査デーモンは,そのエラーまたは状態のメッセージをローカルの /var/adm/syslog.dated/DATE/daemon.log ファイルか,共通の監査コンソール・ファイル (オプション) に書き込みます。

監査するイベント一式を監査マスクと呼びます。この監査マスクは,auditconfig ユーティリティを使って最初に生成されます。このユーティリティでは,クラスタ単位で作成される共通監査マスクを指定します。監査デーモンの最初のスタートアップでは,/etc/rc.config.common ファイルの情報を使います。このため,各メンバで,同じ auditd コマンド行オプションと,同じ監査マスクが使用されます。

実行中のクラスタでは,auditd -cluster オプションを使うと,すべてのアクティブ・デーモンを auditd コマンドの対象とすることができます。たとえば auditd -cluster -w は,各メンバの状態を表示します。同じように auditmask -cluster オプションでは,すべてのアクティブ・メンバの監査マスクを変更または表示することができます。

1 つのクラスタ内の監査デーモンに異なる監査パラメータや異なる監査マスクを指定することは可能ですが,混乱しやすいため避けてください。

audit_tool ユーティリティでは,複数の監査ログ・ファイルをマージして,時間経過順でソートされたイベントをクラスタ単位で表示することができます。各イベントにホスト名情報が記録されるため,イベントの発生箇所を簡単に確認することができます。

3.7.1    クラスタ・コマンドの例

この項では,2 つのメンバ (haydnhandel) からなるバージョン 5.1 A クラスタ内のメンバ・システムで実行する監査コマンドの例を示します。

各メンバの auditd 状態を表示するには,次のようにコマンドを実行します。

# auditd -cluster -w
 
Audit data and msgs:
-l) audit data destination                 = /var/audit/auditlog.handel.003
-c) audit console messages                 = syslog
 
Network:
-s) network audit server status (toggle)   = off
-t) connection timeout value (sec)         = 4
 
Overflow control:
-f) % free space before overflow condition = 10
-o) action to take on overflow             = ignore
 
cluster member haydn.necorp.com auditd standard output:
 
Audit data and msgs:
-l) audit data destination                 = /var/audit/testauditlog.haydn.003
-c) audit console messages                 = syslog
 
Network:
-s) network audit server status (toggle)   = off
-t) connection timeout value (sec)         = 4
 
Overflow control:
-f) % free space before overflow condition = 10
-o) action to take on overflow             = ignore

各メンバの auditd マスクの状態を表示するには,次のようにコマンドを実行します。

# auditmask -cluster
 
!  Audited system calls:
 
!  Audited trusted events:
login                                    fail
 
!  Audstyle flags:exec_argp exec_envp login_uname obj_sel
 
**** cluster member haydn.necorp.com standard output: ******
!  Audited system calls:
 
!  Audited trusted events:
login                                    fail
 
!  Audstyle flags:exec_argp exec_envp login_uname obj_sel

メンバが現在ログをとっているログ・ファイルの名前を表示するには,(メンバ hayden から) 次のようにコマンドを実行します 。

# auditd -cluster -q
 
/var/audit/auditlog.haydn.001
 
cluster member handel.necorp.com auditd standard output:
/var/audit/auditlog.handel.001

すべてのクラスタ・メンバのカーネル auditd バッファを明示的にフラッシュして最新の監査記録を取得するには,次のようにコマンドを実行します。

# auditd -cluster -d

stdout に対する handel および haydn というメンバのログイン・イベントを表示するには,次にようにコマンドを実行します。

# audit_tool -e login auditlog.handel.001 auditlog.haydn.001
 
ruid/euid:   0/0
pid:525424       ppid:525423              cttydev: (6,1)
event:ログイン
login name:root
devname:/dev/pts/1
...........
-- remote/secondary identification data --
hostname:    mk.necorp.com
...........
char param:  argv=login -h mk.necorp.com -p
char param:Failed authentication
error:       13
ip address:10.0.0.1 (haydn-mc0)
timestamp:Mon May  3 15:54:180.19 1999 EDT
 
 
ruid/euid:   0/0
pid:525424       ppid:525423              cttydev: (6,1)
event:ログイン
login name:(nil)
devname:/dev/pts/1
...........
-- remote/secondary identification data --
hostname:    mk.necorp.com
...........
char param:  argv=login -h mk.necorp.com -p
char param:Failed authentication
error:       13
ip address:10.0.0.1 (haydn-mc0)
timestamp:Mon May  3 15:54:260.44 1999 EDT
 
 
ruid/euid:   0/0
pid:1049810       ppid:1049809              cttydev: (6,2)
event:ログイン
login name:root
devname:/dev/pts/2
...........
-- remote/secondary identification data --
hostname:    mk.necorp.com
...........
char param:  argv=login -h mk.necorp.com -
char param:Failed authentication
error:       13
ip address:10.0.0.2 (handel-mc0)
timestamp:Mon May  3 15:54:370.74 1999 EDT
 
 
ruid/euid:   0/0
pid:1049810       ppid:1049809              cttydev: (6,2)
event:ログイン
login name:(nil)
devname:/dev/pts/2
...........
-- remote/secondary identification data --
hostname:    mk.necorp.com
...........
char param:  argv=login -h mk.necorp.com -p
char param:Failed authentication
error:       13
ip address:10.0.0.2 (handel-mc0)
timestamp:Mon May  3 15:54:43.14 1999 EDT
 
 
4 records output
6 records processed
 
 

3.8    監査レポートに対する対処

セキュリティ違反の兆候が見られる場合,監査の頻度を上げることを検討してください。さらに,違反の企てについての詳細情報を収集するため,監査するイベントのリストを調整することも必要です。たとえば,ファイル・システムに対する攻撃の場合,ファイルに対して成功または失敗したすべての opencloselinkunlinkchdirchmodchown およびその他のファイル関連アクセスのログを取ります。

監査トレールで,特定の承認されたユーザがセキュリティ違反を犯していると示された場合,セキュリティ違反の処理に関するサイトのセキュリティ規則に注意し,これらの規則に即した行動をとるようにします。さらに,次のような行動をとることも検討します。

監査トレールにセキュリティ違反の兆候が見られるのに特定のユーザに焦点を絞れない場合は,外部から侵入されている可能性があります。このような場合の対応は,システムおよびもっと広範囲のユーザ・コミュニティに向ける必要があります。この場合,次の手順を実行します。