Solaris のシステム管理 (セキュリティサービス)

監査ファイルの構成 (手順)

ネットワーク上で監査を有効にする前に、サイトの監査要件の監査構成ファイルをカスタマイズします。また、監査サービスを再起動またはローカルシステムをリブートして、監査サービスが有効になったあとに変更された構成ファイルの読み取りを行うこともできます。ただし、監査構成のカスタマイズに必要な作業は、できる限り監査サービスを開始する前に行います。

ゾーンを実装している場合、大域ゾーンからすべてのゾーンを監査することができます。監査出力内のゾーンを区別するには、zonename ポリシーオプションを指定します。非大域ゾーンを別々に監査するには、大域ゾーン内の perzone ポリシーを指定して、非大域ゾーンの監査構成ファイルをカスタマイズします。概要については、「監査と Solaris ゾーン」を参照してください。計画については、「ゾーン内の監査の計画方法」を参照してください。手順については、「ゾーンでの監査サービスの構成 (手順)」を参照してください。

`audit_control` ファイルの変更方法

/etc/security/audit_control ファイルを使用して、システム全体の監査を構成します。ファイルは、監査対象のイベント、監査警告の発行時期、および監査ファイルの場所を決定します。

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

(省略可能) audit_control ファイルのバックアップコピーを保存します。
# cp /etc/security/audit_control /etc/security/audit_control.orig

サイトの audit_control ファイルを変更します。

各エントリの書式は次のとおりです。
keyword:value
keyword

行の種類を定義します。種類には、dir、flags、minfree、naflags、および plugin があります。Solaris 10 リリースでは、dir 行および minfree 行は非推奨です。

キーワードの説明は、次の例を参照してください。

value

その種類の行に関連するデータを指定します。

注 –
監査ディレクトリの場所を指定するには、audit_binfile.so プラグインの p_dir 属性を使用します。最小空き容量を指定するには、p_minfree 属性を使用します。

(省略可能) ファイルの構文を確認します。
# audit -v /etc/security/audit_control syntax ok

例 30–1 すべてのユーザーの監査クラスを事前選択する

audit_control ファイルの flags 行には、監査対象のユーザーに起因するイベントのクラスを定義します。このフラグは、システム上のすべてのユーザーに適用されます。クラスをコンマで区切ります。空白が使用できます。この例では、すべてのユーザーを対象に lo クラスおよび ap クラスのイベントが監査されます。°

## audit_control file
flags:lo,ap
naflags:lo
plugin:name=...

どのイベントがクラスに割り当てられているかを確認するには、audit_event ファイルを参照してください。bsmrecord コマンドを使用することもできます (例 30–27 参照)。

例 30–2 ユーザーに起因しないイベントを事前選択する

この例では、na クラス内のすべてのイベント、およびユーザーに起因しないすべての login イベントが監査対象です。

## audit_control file
flags:lo
naflags:lo,na
plugin:name=...

例 30–3 バイナリ監査データの場所を指定する

audit_binfile.so プラグインの p_dir フラグは、バイナリ監査データに使用する監査ファイルシステムを一覧表示します。この例では、バイナリ監査データ用に 3 つの場所が定義されています。ディレクトリは、1 次ディレクトリから予備のディレクトリの順に一覧表示されます。plugin 行には改行は含まれません。

## audit_control file
##
flags:lo
naflags:lo,na
plugin:name=audit_binfile.so; p_dir=/var/audit/egret.1/files,
/var/audit/egret.2/files,/var/audit

バイナリ監査データを保持するファイルシステムの設定方法は、「監査ファイルのパーティションの作成方法」を参照してください。

例 30–4 警告のための弱い制限値を変更する

この例では、すべての監査ファイルシステムの最小空き領域レベルが設定され、利用できるファイルシステムの領域が 10% だけになったときに警告が発行されるようにします。

plugin 行には改行は含まれません。

## audit_control file
#
flags:lo
naflags:lo,na
plugin:name=audit_binfile.so; p_dir=/var/audit/examplehost.1/files,
/var/audit/examplehost.2/files,/var/audit/localhost/files; p_minfree=10

audit_warn エイリアスが警告を受け取ります。エイリアスを設定するには、「audit_warn 電子メールエイリアスの構成方法」を参照してください。

`syslog` 監査ログの構成方法

監査サービスで、監査キューにある一部またはすべての収集した監査レコードを syslog にコピーできます。次の手順では、バイナリ監査データとテキスト監査データを保存します。収集されたテキスト監査データは、バイナリデータのサブセットです。

始める前に

監査クラスを事前に選択する必要があります。事前に選択される監査クラスは、audit_control ファイルの naflags 行および flags 行で指定します。また、audit_user ファイルの個々のユーザーについてクラスを事前に選択し、auditconfig コマンドで監査クラスを動的に追加できます。

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

(省略可能) audit_control ファイルのバックアップコピーを保存します。
# cp /etc/security/audit_control /etc/security/audit_control.save

audit_syslog.so プラグインエントリを追加します。
## audit_control file flags:lo,ss naflags:lo,na plugin:name=audit_binfile.so;p_dir=/var/audit; p_minfree=20; plugin:name=audit_syslog.so;p_flags=+lo,-ss
plugin エントリの書式は次のとおりです。
plugin:name=name; qsize=max-queued-records;p_*=value
- name= name – プラグインの名前を一覧表示します。有効な値は、audit_binfile.so および audit_syslog.so です。
- qsize= max-queued-records – プラグインに送信される監査データについて、キューに入れるレコードの最大数を指定します。この属性は省略可能です。
- p_*=value – プラグイン固有の属性を指定します。audit_syslog.so プラグインは p_flags を受け入れます。audit_binfile.so プラグインは、p_dir、p_minfree、および p_fsize を受け入れます。p_fsize 属性は、Solaris 10 10/08 で導入されました。
プラグイン固有の属性の詳細は、audit_binfile(5) の OBJECT ATTRIBUTES の節および audit_syslog(5) のマニュアルページを参照してください。

audit.notice エントリを syslog.conf ファイルに追加します。

エントリは、ログファイルの場所を含みます。
# cat /etc/syslog.conf … audit.notice /var/adm/auditlog
テキストログは、バイナリ監査ファイルの格納場所には格納しないでください。バイナリ監査ファイルを読み取る auditreduce コマンドは、監査パーティション内にあるファイルをすべてバイナリ監査ファイルと見なします。

ログファイルを作成します。
# touch /var/adm/auditlog

syslog サービスの構成情報を更新します。
# svcadm refresh system/system-log

syslog ログファイルを定期的に保管します。

監査サービスでは、大量の出力が生成される可能性があります。ログの管理方法については、logadm(1M) のマニュアルページを参照してください。

例 30–5 `syslog` 出力の監査クラスを指定する

次の例では、syslog ユーティリティーを使用して、事前に選択された監査クラスのサブセットを収集します。

## audit_user file
jdoe:pf

## audit_control file
flags:lo,ss
naflags:lo,na
plugin:name=audit_binfile.so; p_dir=/var/audit/host.1/files,
/var/audit/host.2/files,/var/audit/localhost/files; p_minfree=10
plugin:name=audit_syslog.so; p_flags=-lo,-na,-ss,+pf

flags と naflags エントリにより、システムはログインおよびログアウト、ユーザーに起因しないイベント、およびシステム状態の変更のすべての監査レコードをバイナリ形式で収集します。audit_syslog.so プラグインエントリにより、syslog ユーティリティーは失敗したログイン、ユーザーに起因しない失敗したイベント、および失敗したシステム状態の変更だけを収集します。jdoe ユーザーの場合、バイナリ監査レコードにはプロファイル認識シェルの使用がすべて含まれます。syslog ユーティリティーは、成功したプロファイル認識コマンドを収集します。pf クラスは、例 30–10 で作成されます。

例 30–6 `syslog` 監査レコードを遠隔システムに配置する

syslog.conf ファイル内の audit.notice エントリを変更して、遠隔システムを指定します。この例では、ローカルシステムの名前は、example1 です。遠隔システムは、remote1 です。

example1 # cat /etc/syslog.conf
…
audit.notice       @remote1

remote1 システム上の syslog.conf ファイル内にある audit.notice エントリはログファイルを指定します。

remote1 # cat /etc/syslog.conf
…
audit.notice       /var/adm/auditlog

例 30–7 `audit_control` ファイルでプラグインを使用する

audit_control ファイルのフラグなし情報を指定する際には、plugin エントリの使用をお勧めします。この例では、監査フラグの選択の後に、プラグイン情報が一覧表示されています。

## audit_control file
flags:lo,ss
naflags:lo,na
plugin:name=audit_binfile.so;p_minfree=10; p_dir=/var/audit
plugin:name=audit_syslog.so; p_flags=+lo

ユーザーの監査特性の変更方法

ユーザーごとの定義は、audit_user データベースに格納されます。これらの定義は、指定されたユーザーに関して、audit_control ファイルで事前に選択されたクラスを変更します。nsswitch.conf ファイルは、ローカルファイルまたはネームサービスデータベースのどちらを使用するかを決定します。ユーザーの最終監査事前定義マスクを計算する方法は、「プロセスの監査特性」を参照してください。

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

(省略可能) audit_user データベースのバックアップコピーを保存します。
# cp /etc/security/audit_user /etc/security/audit_user.orig

audit_user データベースに新しいエントリを追加します。

ローカルデータベースの場合、各エントリの書式は次のようになります。
username:always-audit:never-audit
username

監査するユーザー名を選択します。

always-audit

指定したユーザーについて常に監査する監査クラスの一覧を選択します。

never-audit

指定したユーザーについて監査しない監査クラスの一覧を選択します。

複数のクラスを指定するには、監査クラスをコンマで区切ります。

audit_user エントリは、ユーザーの次回のログイン時に有効になります。

例 30–8 1 人のユーザーに関して監査するイベントを変更する

この例では、audit_control ファイルは、システム用の事前に選択された監査クラスを含みます。

## audit_control file
…
flags:lo,ss
naflags:lo,na

audit_user ファイルは例外を表示します。ユーザー jdoe がプロファイルシェルを使用すると、監査されます。

## audit_user file
jdoe:pf

jdoe の監査事前選択マスクは、audit_user 設定と audit_control 設定を結合したものです。auditconfig -getaudit コマンドは、jdoe の事前選択マスクを表示します。

# auditconfig -getaudit
audit id = jdoe(1234567)
process preselection mask = ss,pf,lo(0x13000,0x13000)
terminal id (maj,min,host) = 242,511,example1(192.168.160.171)
audit session id = 2138517656

例 30–9 システムではなくユーザーだけを監査する

この例では、システム上での 4 人のログインと役割活動が監査されます。audit_control ファイルは、システム用の監査クラスを事前に選択しません。

## audit_control file
…
flags:
naflags:

audit_user ファイルは、次のように 4 人のユーザー用の 2 つの監査クラスを事前に選択します。

## audit_user file
jdoe:lo,pf
kdoe:lo,pf
pdoe:lo,pf
sdoe:lo,pf

次の audit_control ファイルは、不当な侵入を記録します。audit_user ファイルとの組み合わせにより、この例の最初の audit_control ファイルに比べてシステムをより確実に保護します。

## audit_control file
…
flags:
naflags:lo
plugin:name=...

監査クラスの追加方法

独自の監査クラスを作成すると、サイトで監視する監査イベントだけをそのクラスに入れることができます。1 つのシステムにそのクラスを追加するときは、監査されているすべてのシステムに変更をコピーする必要があります。

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

(省略可能) audit_class ファイルのバックアップコピーを保存します。
# cp /etc/security/audit_class /etc/security/audit_class.orig

audit_class ファイルに新しいエントリを追加します。

各エントリの書式は次のとおりです。
0xnumber:name:description
0x

number が 16 進であることを示します。

number

一意の監査クラスマスクを定義します。

name

監査クラスの文字の名前を定義します。

description

監査クラスの記述名を定義します。

エントリはファイル内で一意である必要があります。既存の監査クラスのマスクを使用しないでください。

例 30–10 新しい監査クラスを作成する

この例では、監査イベントの小さなセットを保持するクラスを作成します。audit_class ファイルに追加されるエントリは次のとおりです。

0x10000000:pf:profile command

このエントリによって、pf という名前の新しい監査クラスが作成されます。例 30–11 で、この新しい監査クラスにデータを割り当てます。

注意事項

audit_class ファイルをカスタマイズした場合、audit_user に対する変更が新しい監査クラスと一致するようにします。audit_user 内の監査クラスが audit_class データベースのサブセットになっていないと、エラーが発生します。

監査イベントの所属先クラスの変更方法

既存の監査クラスのサイズを減らしたり、独自のクラスにイベントを入れたりするために、監査イベントのクラスメンバーシップを変更できます。1 つのシステム上で監査イベントから監査クラスへのマッピングを再構成する場合は、監査されているすべてのシステムに変更をコピーする必要があります。

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

(省略可能) audit_event ファイルのバックアップコピーを保存します。
# cp /etc/security/audit_event /etc/security/audit_event.orig

特定のイベントがどのクラスに属するかを変更するには、イベントの class-list を変更します。

各エントリの書式は次のとおりです。
number:name:description:class-list
number

監査イベント ID です。

name

監査イベントの名前です。

description

通常、監査レコードの作成を発生させるシステムコールまたは実行可能プログラム。

class-list

コンマ区切りの監査クラスの一覧です。

例 30–11 既存の監査イベントを新しいクラスにマッピングする

この例では、既存の監査イベントを例 30–10 で作成した新しいクラスにマッピングします。audit_control ファイルに、バイナリ監査レコードは、pf クラス内のイベントの成功または失敗を書き込みます。syslog 監査ログは、pf クラスのイベントの失敗だけを書き込みます。

# grep pf | /etc/security/audit_class
0x10000000:pf:profile command
# vi /etc/security/audit_event
6180:AUE_prof_cmd:profile command:ua,as,pf
# vi audit_control
...
flags:lo,pf
plugin:name=audit_binfile.so; p_dir=/var/audit; p_minfree=10
plugin:name=audit_syslog.so; p_flags=-lo,-pf

例 30–12 `setuid` プログラムの使用を監査する

この例では、setuid と setgid プログラムの呼び出しを監視するためにイベントを保持するクラスを作成します。バイナリ監査レコードは、lo クラスおよび na クラスのイベントの成功と失敗、st クラスのイベントの成功を書き込みます。syslog 監査ログは、st クラスのイベントの成功だけを書き込みます。

# vi /etc/security/audit_class
0x00000800:st:setuid class
# vi /etc/security/audit_event
26:AUE_SETGROUPS:setgroups(2):st
27:AUE_SETPGRP:setpgrp(2):st
40:AUE_SETREUID:setreuid(2):st
41:AUE_SETREGID:setregid(2):st
214:AUE_SETEGID:setegid(2):st
215:AUE_SETEUID:seteuid(2):st

# vi audit_control
## audit_control file
flags:lo,+st
naflags:lo,na
plugin:name=audit_binfile.so; p_dir=/var/audit; p_minfree=10
plugin:name=audit_syslog.so; p_flags=-lo,+st