test

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

第 30 章 Solaris 監査の管理 (作業)

この章では、監査対象の Solaris システムの設定と管理に役立つ手順を説明します。また、監査トレールの管理方法についても説明します。この章の内容は次のとおりです。

監査サービスの概要は、第 28 章Solaris 監査 (概要)を参照してください。計画の提案については、第 29 章Solaris 監査の計画を参照してください。参照情報については、第 31 章Solaris 監査 (参照)を参照してください。

Solaris 監査 (作業マップ)

次の作業マップは、監査の管理に必要な主な作業を示します。作業は順番に並んでいます。

作業 

説明 

参照先 

1. 監査を計画します 

監査サービスを構成する前に判断する構成上の問題を含みます。 

「Solaris 監査の計画 (作業マップ)」

2. 監査ファイルを構成します 

監査を必要とするイベント、クラス、およびユーザーを定義します。 

「監査ファイルの構成 (作業マップ)」

3. 監査を構成および有効化します 

ディスク容量とほかの監査サービスの要件に対して各ホストを構成します。その後、監査サービスを開始します。 

「監査サービスの構成と有効化 (作業マップ)」

非大域ゾーンがインストールされたホストでは、システムに対して 1 つの監査サービスを構成するか、ゾーンごとに監査サービスを 1 つずつ構成します。 

「ゾーンでの監査サービスの構成 (手順)」

4. 監査レコードを管理します。 

監査データを収集して分析します。 

「監査レコードの管理 (作業マップ)」

監査ファイルの構成 (作業マップ)

次の作業マップは、サイトで監査をカスタマイズするファイルの構成手順の一覧です。ほとんどの作業は省略可能です。

作業 

説明 

参照先 

監査クラスの選択、および audit_control 設定のカスタマイズを行います

次のことを行います: 

  • システム全体の監査クラスを事前に選択する

  • システムごとに監査ディレクトリを指定する

  • 監査ファイルシステム上のディスク容量の制限を設定する

「audit_control ファイルの変更方法」

(省略可能) 2 つのモードでの監査イベントを記録します 

バイナリ形式で監査レコードを格納できるようにするほか、リアルタイムでの監視を有効にします。 

「syslog 監査ログの構成方法」

(省略可能) ユーザーの監査特性を変更します 

システム全体の事前選択された監査クラスに対してユーザー固有の例外を設定します。 

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

(省略可能) 監査クラスを追加します 

イベントを保持する新しい監査クラスを作成して、監査レコードの数を減らします。 

「監査クラスの追加方法」

(省略可能) イベントからクラスへのマッピングを変更します 

イベントからクラスへのマッピングを変更して、監査レコードの数を減らします。 

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

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

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

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

Procedureaudit_control ファイルの変更方法

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

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

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

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


    # cp /etc/security/audit_control /etc/security/audit_control.orig

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

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


    keyword:value
    keyword

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

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

    value

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

    注 –

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

  4. (省略可能) ファイルの構文を確認します。


    # 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 電子メールエイリアスの構成方法」を参照してください。

Proceduresyslog 監査ログの構成方法

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

始める前に

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

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

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

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


    # cp /etc/security/audit_control /etc/security/audit_control.save

  3. 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) のマニュアルページを参照してください。

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

    エントリは、ログファイルの場所を含みます。


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

    テキストログは、バイナリ監査ファイルの格納場所には格納しないでください。バイナリ監査ファイルを読み取る auditreduce コマンドは、監査パーティション内にあるファイルをすべてバイナリ監査ファイルと見なします。

  5. ログファイルを作成します。


    # touch /var/adm/auditlog

  6. syslog サービスの構成情報を更新します。


    # svcadm refresh system/system-log

  7. 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

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

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

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

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

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


    # cp /etc/security/audit_user /etc/security/audit_user.orig

  3. 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=...

Procedure監査クラスの追加方法

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

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

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

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


    # cp /etc/security/audit_class /etc/security/audit_class.orig

  3. 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 データベースのサブセットになっていないと、エラーが発生します。

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

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

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

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

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


    # cp /etc/security/audit_event /etc/security/audit_event.orig

  3. 特定のイベントがどのクラスに属するかを変更するには、イベントの 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

監査サービスの構成と有効化 (作業マップ)

次の作業マップは、監査サービスの構成と有効化の手順を示しています。作業は順番に並んでいます。

作業 

説明 

参照先 

1. (省略可能) 監査構成ファイルを変更します 

監査を必要とするイベント、クラス、およびユーザーを選択します。 

「監査ファイルの構成 (作業マップ)」

2. 監査パーティションを作成します 

監査ファイル用のディスク容量を作成し、ファイルのアクセス権を使用して監査ファイルを保護します。 

「監査ファイルのパーティションの作成方法」

3. audit_warn 別名を作成します

監査サービスに注意が必要なとき、電子メール警告を受信するユーザーを決定します。 

「audit_warn 電子メールエイリアスの構成方法」

4. (省略可能) 監査ポリシーを変更します 

サイトに必要な追加の監査データを定義します。 

「監査ポリシーを構成する方法」

6. 非大域ゾーンの監査を構成します 

非大域ゾーンで監査レコードが収集されるようにします 

「ゾーンでの監査サービスの構成 (手順)」

7. 監査を有効にします 

監査サービスを有効にします。 

「監査サービスを有効にする方法」

perzone 監査が有効になっている場合は、非大域ゾーンで監査を有効にします。

例 30–20

8. (省略可能) 監査を無効にします 

監査サービスを無効にします。 

「監査サービスを無効にする方法」

perzone 監査が有効になっている場合は、非大域ゾーンで監査を無効にします。

例 30–25

9. (省略可能) 監査構成変更を再読み込みします 

auditd デーモンの実行中に監査構成の変更をカーネルに読み込みます。

「監査サービスの更新方法」

監査サービスの構成と有効化 (手順)

構成ファイルをサイト用に構成したあと、監査ファイルのディスク容量を設定する必要があります。監査サービスのほかの属性を設定して、サービスを有効にする必要もあります。この節では、構成の設定を変更したときに監査サービスを更新する手順も説明します。

非大域ゾーンがインストールされている場合、監査対象の大域ゾーンと同じようにゾーンを監査することができます。非大域ゾーンを別々に監査する場合は、非大域ゾーンの監査構成ファイルを変更することができます。監査構成ファイルをカスタマイズする方法については、「監査ファイルの構成 (作業マップ)」を参照してください。

Procedure監査ファイルのパーティションの作成方法

次の手順では、監査ファイル用のパーティションの作成方法、および監査に対応するファイルシステムとディレクトリの作成方法について説明します。すでに空のパーティションがある場合、またはすでに空のファイルシステムをマウントしている場合は、必要に応じて手順を省略してください。

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

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

  2. 必要なディスク容量を決定します。

    ホストごとに 200M バイト以上を割り当てます。ただし、必要な監査の量によりディスク容量要件が決まります。つまり、要件によっては、この数値を超えることもあります。予備ディレクトリのローカルパーティション領域も含めてください。

  3. 必要に応じて、監査パーティションを作成します。

    この手順は、サーバーのインストール時に実行するのがもっとも簡単です。サーバーにマウントされていないディスク上にパーティションを作成することもできます。パーティションの作成方法については、『Solaris のシステム管理 (デバイスとファイルシステム)』の第 11 章「ディスクの管理 (手順)」を参照してください。


    # newfs /dev/rdsk/cwtxdysz

    この例で、 /dev/rdsk/cwt xdysz は、パーティションの raw デバイス名です。

    ローカルホストを監査する場合は、ローカルホスト用に予備の監査ディレクトリも作成します。

  4. 新しいパーティションのマウント先を作成します。


    # mkdir /var/audit/server-name.n

    server-name.n は、サーバー名と各パーティションの識別番号を結合したものです。この識別番号は省略できますが、多数の監査ディレクトリを作成する場合はこの番号を使用すると便利です。

  5. 新しいパーティションを自動的にマウントするエントリを追加します。

    /etc/vfstab ファイルに次のような行を追加します。


    /dev/dsk/cwtxdysz /dev/rdsk/cwtxdysz /var/audit/server-name.n   ufs  2  yes

  6. (省略可能) 各パーティションの最小空き容量のしきい値を削除します。

    デフォルトの構成を使用した場合、ディレクトリの 80% がいっぱいになった時点で警告が生成されます。このため、パーティション上に空き容量を予約する必要はありません。


    # tunefs -m 0 /var/audit/server-name.n

  7. 新しい監査パーティションをマウントします。


    # mount /var/audit/server-name.n

  8. 新しいパーティションに監査ディレクトリを作成します。


    # mkdir /var/audit/server-name.n/files

  9. マウント先と新しいディレクトリへのアクセス権を訂正します。


    # chmod -R 750 /var/audit/server-name.n/files

  10. ファイルサーバー上で、ほかのホストからアクセスできるファイルシステムを定義します。

    監査レコードを格納するために、ディスクファームをインストールすることがよく行われます。監査ディレクトリを複数のシステムで使用する場合は、そのディレクトリを NFS サービスを通して共有する必要があります。/etc/dfs/dfstab ファイルに対して、次のようなエントリをディレクトリごとに追加します。


    share -F nfs /var/audit/server-name.n/files

  11. ファイルサーバー上で、NFS サービスを起動し直します。

    このコマンドが、ユーザーが起動した最初の 1 つまたは複数の share コマンドの場合、NFS デーモンが実行されていないことがあります。

    • NFS サービスがオフラインの場合、サービスを有効にします。


      % svcs \*nfs\*
disabled       Nov_02   svc:/network/nfs/rquota:default
offline        Nov_02   svc:/network/nfs/server:default
# svcadm enable network/nfs/server

    • NFS サービスが実行中の場合、サービスを再起動します。


      % svcs \*nfs\*
online         Nov_02   svc:/network/nfs/client:default
online         Nov_02   svc:/network/nfs/server:default
# svcadm restart network/nfs/server

    NFS サービスの詳細は、『Solaris のシステム管理 (ネットワークサービス)』の「NFS サービスの設定」を参照してください。永続的なサービスの管理の詳細は、『Solaris のシステム管理 (基本編)』の第 18 章「サービスの管理 (概要)」および smf(5) のマニュアルページを参照してください。

例 30–13 予備の監査ディレクトリを作成する

監査サービスを実行するすべてのシステムには、利用できるファイルシステムがほかにない場合に使用するローカルファイルシステムが必要です。この例では、ファイルシステムが egret という名前のシステムに追加されます。このファイルシステムは、ローカルシステムだけで使用されるため、ファイルサーバーの手順は必要ありません。


# newfs /dev/rdsk/c0t2d0
# mkdir /var/audit/egret
# grep egret /etc/vfstab
/dev/dsk/c0t2d0s1  /dev/rdsk/c0t2d0s1  /var/audit/egret ufs  2  yes  -
# tunefs -m 0 /var/audit/egret
# mount /var/audit/egret
# mkdir /var/audit/egret/files
# chmod -R 750 /var/audit/egret/files
例 30–14 新しい監査パーティションを作成する

この例では、新しいファイルシステムが、2 つの新しいディスクに作成されます。この 2 つのディスクは、ネットワーク上のほかのシステムと共有します。


# newfs /dev/rdsk/c0t2d0
# newfs /dev/rdsk/c0t2d1
# mkdir /var/audit/egret.1
# mkdir /var/audit/egret.2
# grep egret /etc/vfstab
/dev/dsk/c0t2d0s1  /dev/rdsk/c0t2d0s1  /var/audit/egret.1 ufs  2  yes  -
/dev/dsk/c0t2d1s1  /dev/rdsk/c0t2d1s1  /var/audit/egret.2 ufs  2  yes  -
# tunefs -m 0 /var/audit/egret.1
# tunefs -m 0 /var/audit/egret.2
# mount /var/audit/egret.1
# mount /var/audit/egret.2
# mkdir /var/audit/egret.1/files
# mkdir /var/audit/egret.2/files
# chmod -R 750 /var/audit/egret.1/files /var/audit/egret.2/files
# grep egret /etc/dfs/dfstab
 share -F nfs /var/audit/egret.1/files
 share -F nfs /var/audit/egret.2/files
# svcadm enable network/nfs/server
例 30–15 ZFS 監査パーティションを作成する

この例では、管理者は、ZFS 監査パーティションの作成後に script コマンドを実行します。コマンドの出力は次のとおりです。


# zpool create auditf mirror c0t4d0 c0t5d0
# zfs create -o mountpoint=/audit auditf/audit
# zfs create auditf/audit/noddy
# zfs create auditf/audit/noddy/files
# zfs create auditf/audit/blinken
# zfs create auditf/audit/blinken/files
# zfs set devices=off auditf/audit
# zfs set exec=off auditf/audit
# zfs set setuid=off auditf/audit
# zfs set sharenfs=on auditf/audit
# share
-               /audit/blinken/files   rw   ""
-               /audit/noddy   rw   ""
-               /audit/blinken   rw   ""
-               /audit/noddy/files   rw   ""
-               /audit   rw   ""
# ^D
script done on Fri Apr 10 10:10:20 2009

次に、遠隔システム remotesys からのマウントを表示します。


# dfshares remotesys
RESOURCE                             SERVER ACCESS    TRANSPORT
remotesys:/audit/blinken/files       remotesys  -         -
remotesys:/audit/noddy               remotesys  -         -
remotesys:/audit/blinken             remotesys  -         -
remotesys:/audit/noddy/files         remotesys  -         -
remotesys:/audit                     remotesys  -         -

最後に、/audit ファイルシステムを /var/audit にマウントします。


# mount remotesys:/audit /var/audit
# ls /var/audit
blinken  noddy

Procedureaudit_warn 電子メールエイリアスの構成方法

audit_warn スクリプトは、audit_warn という電子メールエイリアスに対してメールを生成します。有効な電子メールアドレスにこのメールを送信するには、手順 2 で説明するオプションのいずれか 1 つに従います。

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

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

  2. audit_warn 電子メールエイリアスを構成します。

    次のオプションのいずれかを選択します。

    • オプション 1 – audit_warn スクリプトで、audit_warn 電子メールエイリアスをほかの電子メールアカウントに置き換えます。

      スクリプトの次の行で電子メールエイリアスを変更します。


      ADDRESS=audit_warn            # standard alias for audit alerts

    • オプション 2 – audit_warn 電子メールをほかの電子メールアカウントにリダイレクトします。

      この場合、audit_warn 電子メールエイリアスを適切なメールエイリアスファイルに追加します。別名の追加先として、ローカルの /etc/mail/aliases ファイル、名前空間の mail_aliases データベースのいずれかを選択します。root 電子メールアカウントを audit_warn 電子メールエイリアスのメンバーとして登録する場合、新しいエントリは次のようになります。


      audit_warn: root

Procedure監査ポリシーを構成する方法

監査ポリシーを使用して、ローカルホストの監査レコードの特性を決定します。監査が有効な場合、/etc/security/audit_startup ファイルの内容により、監査ポリシーが決まります。

auditconfig コマンドを使用すると、現在の監査ポリシーオプションを検査および変更できます。また、監査ポリシーの変更内容を固定するために、audit_startup スクリプト内で auditconfig コマンドの監査ポリシーオプションを変更することも可能です。

  1. Audit Control プロファイルを含む役割を引き受けるか、スーパーユーザーになります。

    Audit Control プロファイルを含む役割を作成する方法およびユーザーに役割を割り当てる方法については、「RBAC の構成 (作業マップ)」を参照してください。

  2. 監査ポリシーを確認します。

    監査を有効にする前に、audit_startup ファイルの内容により、監査ポリシーが決まります。


    #! /bin/sh
...
/usr/bin/echo "Starting BSM services."
/usr/sbin/auditconfig -setpolicy +cnt Counts rather than drops records
/usr/sbin/auditconfig -conf  Configures event-class mappings
/usr/sbin/auditconfig -aconf Configures nonattributable events

  3. 使用可能なポリシーオプションを表示します。


    $ auditconfig -lspolicy
    注 –

    perzone と ahlt ポリシーオプションは、大域ゾーンでのみ設定できます。

  4. 選択した監査ポリシーオプションを有効または無効にします。


    # auditconfig -setpolicy prefixpolicy
    prefix

    prefix 値 + を指定するとポリシーオプションが有効になります。prefix 値 - を指定するとポリシーオプションが無効になります。

    policy

    有効または無効にするポリシーを選択します。

    このポリシーの設定は、次回ブートするまで、または auditconfig setpolicy コマンドを使ってポリシーを変更するまで持続します。

    各ポリシーオプションの詳細は、「監査ポリシーの決定」を参照してください。

例 30–16 cnt および ahlt 監査ポリシーオプションを設定する

この例では、cnt ポリシーが無効になり、ahlt ポリシーが有効になります。これらの設定では、監査パーティションがいっぱいで非同期イベントが発生した場合、システムの使用が停止します。同期イベントが発生すると、スレッドを作成したプロセスがハングアップします。これらの設定は、セキュリティーが可用性よりも重要な場合に適しています。

次の audit_startup エントリによって、再起動を行なっても cnt ポリシーオプションが無効で ahlt ポリシーを有効のままになります。


# cat /etc/security/audit_startup
#!/bin/sh
/usr/bin/echo "Starting BSM services."
/usr/sbin/deallocate -Is
/usr/sbin/auditconfig -conf
/usr/sbin/auditconfig -aconf
/usr/sbin/auditconfig -setpolicy -cnt	
/usr/sbin/auditconfig -setpolicy +ahlt
例 30–17 seq 監査ポリシーを一時的に設定する

この例では、auditd デーモンが実行中で、ahlt 監査ポリシーが設定されています。seq 監査ポリシーが現在のポリシーに追加されます。seq ポリシーは、sequence トークンをすべての監査レコードに追加します。監査レコードが破壊されたときやレコードが破棄されているとき、監査サービスのデバッグに役立ちます。

+ 接頭辞により、現在の監査ポリシーを seq に置き換えるのではなく、seq オプションが監査ポリシーに追加されます。auditconfig コマンドにより、ポリシーはコマンドが次に起動するまで、または次のブートまで有効になります。


$ auditconfig -setpolicy +seq
$ auditconfig -getpolicy
audit policies = ahlt,seq
例 30–18 perzone 監査ポリシーを設定する

この例では、perzone 監査ポリシーが、大域ゾーンの audit_startup スクリプト内で設定されます。ゾーンのブート時に、非大域ゾーンは、そのゾーン内の監査構成設定に関する監査レコードを収集します。


$ cat /etc/security/audit_startup
#!/bin/sh
/usr/bin/echo "Starting BSM services."
/usr/sbin/deallocate -Is
/usr/sbin/auditconfig -conf
/usr/sbin/auditconfig -aconf
/usr/sbin/auditconfig -setpolicy +perzone
/usr/sbin/auditconfig -setpolicy +cnt
例 30–19 監査ポリシーを変更する

この例では、auditd デーモンが実行中で、監査ポリシーが設定されています。auditconfig コマンドは、セッションの間、ahlt と cnt ポリシーを変更します。これらの設定により、監査ファイルシステムがいっぱいになると、監査レコードは破棄されますが、カウントされます。ahlt ポリシーの設定での制限については、手順 3 を参照してください。


$ auditconfig -setpolicy +cnt
$ auditconfig -setpolicy -ahlt
$ auditconfig -getpolicy
audit policies = cnt,seq

変更をaudit_startup ファイルに書き込むと、ポリシーは永続的に有効になります。


$ cat /etc/security/audit_startup
#!/bin/sh
/usr/bin/echo "Starting BSM services."
/usr/sbin/deallocate -Is
/usr/sbin/auditconfig -conf
/usr/sbin/auditconfig -aconf
/usr/sbin/auditconfig -setpolicy +cnt

ahlt ポリシーはデフォルトで無効になっているため、-ahlt オプションをファイル内で指定する必要はありません。この設定は、監査レコードのセキュリティーよりも可用性が重要な場合に適しています。

Procedure監査サービスを有効にする方法

この手順では、監査サービスをすべてのゾーンで有効にします。非大域ゾーンで監査デーモンを起動するには、例 30–20 を参照してください。

監査が安全に構成されると、監査が有効化されるまで、システムはシングルユーザーモードになります。マルチユーザーモードで監査を有効にすることもできます。

始める前に

次の作業を完了してから、この手順をスーパーユーザーとして実行してください。

注 –

監査が成功するには、ホスト名変換が正しく機能している必要があります。ネームサービスの hosts データベースが正しく構成され、機能している必要があります。

hosts データベースの構成については、nsswitch.conf(4) および netconfig(4) のマニュアルページを参照してください。詳細は、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』または『Solaris のシステム管理 (ネーミングとディレクトリサービス : NIS+ 編)』を参照してください。

  1. 監査サービスを有効にするスクリプトを実行します。

    /etc/security ディレクトリに移動し、bsmconv スクリプトを実行します。


    # cd /etc/security
# ./bsmconv
This script is used to enable the Basic Security Module (BSM).
Shall we continue with the conversion now? [y/n] y
bsmconv: INFO: checking startup file.
bsmconv: INFO: turning on audit module.
bsmconv: INFO: initializing device allocation.

The Basic Security Module is ready.
If there were any errors, please fix them now.
Configure BSM by editing files located in /etc/security.
Reboot this system now to come up with BSM enabled.

    スクリプトの働きについては、bsmconv(1M) のマニュアルページを参照してください。

  2. システムを再起動します。


    # reboot

    システムがマルチユーザーモードに移行すると、起動ファイル /etc/security/audit_startup によって auditd デーモンが自動的に動作します。

    スクリプトのもう 1 つの働きは、デバイス割り当てを有効にすることです。デバイス割り当ての設定方法は、「デバイス割り当ての管理 (作業マップ)」を参照してください。

例 30–20 非大域ゾーンで監査を有効にする

次の例では、監査が大域ゾーンで有効になり非大域ゾーンがブートされたあと、大域ゾーン管理者が perzone ポリシーを有効にします。非大域ゾーンのゾーン管理者は、ゾーンの監査ファイルを構成して、ゾーンで監査デーモンを起動します。


zone1# svcadm enable svc:/system/auditd

Procedure監査サービスを無効にする方法

ある時点で監査サービスが不要になった場合、この手順は監査が有効になる前のシステム状態にシステムを戻します。非大域ゾーンが監査されている場合は、その監査サービスも無効になります。

注意 – 注意 –

このコマンドによって、デバイス割り当ても無効になります。デバイス割り当てを可能にする場合は、このコマンドを実行しないでください。デバイス割り当てを保ったまま監査を無効にする方法については、例 30–21 を参照してください。

  1. スーパーユーザーになり、システムをシングルユーザーモードにします。


    % su
Password: <Type root password>
# init S

    詳細は、init(1M) のマニュアルページを参照してください。

  2. スクリプトを実行して、監査を無効にします。

    /etc/security ディレクトリに移動し、bsmunconv スクリプトを実行します。


    # cd /etc/security
# ./bsmunconv

    スクリプトのもう 1 つの働きは、デバイス割り当てを無効にすることです。

    bsmunconv スクリプトの詳細は、bsmconv(1M) のマニュアルページを参照してください。

  3. システムをマルチユーザーモードにします。


    # init 6
例 30–21 デバイス割り当てを保持したまま監査を無効にする

この例では、監査サービスはレコードの収集を停止しますが、デバイス割り当ては引き続き機能します。audit_user ファイルのすべてのユーザーエントリと同様に、audit_control ファイルの flags、naflags、および plugin エントリからのすべての値が削除されます。 


## audit_control file
flags:
naflags:

## audit_user file

auditd デーモンが実行されますが、監査レコードは保持されません。

例 30–22 監査をゾーン単位で無効にする

この例では、監査サービスが無効化された zone1 内で、監査サービスが実行を停止します。デバイス割り当ては引き続き機能します。perzone 監査ポリシーが設定されていない状態で、このコマンドが大域ゾーンで実行されると、大域ゾーンだけでなくすべてのゾーンで監査が無効になります。


zone1 # audit -t

Procedure監査サービスの更新方法

この手順では、デーモの実行中に監査構成ファイルを変更した場合に、auditd デーモンを再起動します。

  1. Audit Control 権利プロファイルを含む役割を引き受けるか、あるいはスーパーユーザーになります。

    Audit Control 権利プロファイルを含む役割の作成方法およびユーザーに役割を割り当てる方法については、「RBAC の構成 (作業マップ)」を参照してください。

  2. 適切なコマンドを選択します。

    • audit_control ファイルの naflags 行を変更する場合は、ユーザーに起因しないイベント用のカーネルマスクを変更します。


      $ /usr/sbin/auditconfig -aconf

      リブートすることもできます。

    • audit_control ファイルのほかの行を変更する場合は、audit_control ファイルを再度読み込みます。

      監査デーモンは、audit_control ファイルからの情報を内部で格納します。新しい情報を使用するには、システムを再起動するか、または変更されたファイルを監査デーモンが読み込むようにします。


      $ /usr/sbin/audit -s
      注 –

      監査レコードは、各プロセスに関連付けられた監査事前選択マスクに基づいて生成されます。audit -s を実行しても、既存のプロセス内のマスクは変更されません。既存プロセスの事前選択マスクを変更するには、プロセスを再起動する必要があります。リブートすることもできます。

      audit -s コマンドを使用すると、監査デーモンはディレクトリと最小限の空きの値を audit_control ファイルから再度読み取ります。このコマンドにより、後続のログインにより発生するプロセス用の事前選択マスクの生成が変更されます。

    • 監査デーモンの実行中に audit_event ファイルまたは audit_class ファイルを変更する場合は、監査サービスを再表示します。

      変更したイベントからクラスへのマッピングをシステムに読み込み、マシンを使用する各ユーザーが正しく監査されているかを確認します。


      $ auditconfig -conf
$ auditconfig -setumask auid classes
      auid

      ユーザー ID です。

      classes

      事前に選択された監査クラスです。

      例については、「ユーザーの事前選択マスクを変更する方法」を参照してください。

    • 稼動中のシステムで監査ポリシーを変更するには、例 30–17 を参照してください。

例 30–23 監査デーモンを再起動する

この例では、システムをシングルユーザーモードにしたあとで、マルチユーザーモードに戻します。システムがマルチユーザーモードになったとき、変更された構成ファイルがシステムに読み込まれます。


# init S
# init 6

ゾーンでの監査サービスの構成 (手順)

監査サービスは、ゾーン内での監査イベントも含め、システム全体を監査します。非大域ゾーンがインストールされたシステムでは、すべてのゾーンを同様に監査することも、ゾーンごとに監査を制御することもできます。背景情報については、「ゾーンを含むシステムでの監査」を参照してください。計画を立てるには、「ゾーン内の監査の計画方法」を参照してください。

Procedureすべてのゾーンの監査を同様に構成する方法

この手順に従えば、すべてのゾーンを同様に監査できます。この方法を使えば、必要とされるコンピュータオーバーヘッドと管理リソースが最小になります。

  1. 大域ゾーンの監査を構成します。

    1. 「監査ファイルの構成 (作業マップ)」の作業を行います。

    2. 「監査サービスの構成と有効化 (作業マップ)」の作業を行います。ただし、次の点は例外になります。

      • perzone 監査ポリシーを有効にしないでください。

      • 監査サービスを有効にしないでください。監査サービスの有効化は、非大域ゾーンの監査の構成が完了したあとで行います。

  2. 大域ゾーンからすべての非大域ゾーンに、監査構成ファイルをコピーします。

    編集した次のファイルをすべてコピーします。 audit_class、audit_control、audit_event、audit_user。audit_startup と audit_warn はコピーしないでください。編集していないファイルをコピーする必要はありません。

    2 つの選択肢があります。スーパーユーザーとして、ファイルをコピーすることも、ファイルをループバックマウントすることもできます。非大域ゾーンが動作している必要があります。

    • ファイルをコピーします。

      1. 大域ゾーンから、非大域ゾーンの /etc/security ディレクトリを一覧表示します。


        # ls /zone/zonename/etc/security/

      2. ゾーンの /etc/security ディレクトリに監査構成ファイルをコピーします。


        # cp /etc/security/audit-file /zone/zonename/etc/security/audit-file

        その後、ある監査構成ファイルを大域ゾーンで変更した場合には、そのファイルを非大域ゾーンにコピーし直します。

    • 構成ファイルをループバックマウントします。

      1. 大域ゾーンから、非大域ゾーンを停止します。 


        # zoneadm -z non-global-zone halt

      2. 大域ゾーンで変更した監査構成ファイルごとに読み取り専用のループバックマウントを 1 つずつ作成します。


        # zonecfg -z non-global-zone
 add fs
    set special=/etc/security/audit-file
    set dir=/etc/security/audit-file
    set type=lofs
    add options [ro,nodevices,nosetuid]
    end
 exit

      3. 変更を有効にするには、非大域ゾーンをブートします。 


        # zoneadm -z non-global-zone boot

        システムをリブートしても構いません。

        その後、ある監査構成ファイルを大域ゾーンで変更した場合には、非大域ゾーンにループバックマウントされたファイルを更新するためにシステムをリブートします。

例 30–24 監査構成ファイルをループバックマウントする

この例では、システム管理者が audit_class、audit_event、audit_control、audit_user、audit_startup、および audit_warn ファイルを変更しました。

audit_startup および audit_warn ファイルは、大域ゾーンでしか読み取られないため、非大域ゾーンでループバックマウントする必要はありません。

このシステム machine1 上で、管理者は 2 つの非大域ゾーン machine1–webserver と machine1–appserver を作成しました。管理者が監査構成ファイルのカスタマイズを完了しました。管理者があとでファイルを変更した場合は、変更を有効にするためにシステムがリブートされます。


# zoneadm -z machine1-webserver halt
# zoneadm -z machine1-appserver halt
# zonecfg -z machine1-webserver 
 add fs
    set special=/etc/security/audit_class
    set dir=/etc/security/audit_class
    set type=lofs
    add options [ro,nodevices,nosetuid]
    end
 add fs
    set special=/etc/security/audit_event
    set dir=/etc/security/audit_event
    set type=lofs
    add options [ro,nodevices,nosetuid]
    end
 add fs
    set special=/etc/security/audit_control
    set dir=/etc/security/audit_control
    set type=lofs
    add options [ro,nodevices,nosetuid]
    end 
add fs
    set special=/etc/security/audit_user
    set dir=/etc/security/audit_user
    set type=lofs
    add options [ro,nodevices,nosetuid]
    end
 exit
# zonecfg -z machine1-appserver 
 add fs
    set special=/etc/security/audit_class
    set dir=/etc/security/audit_class
    set type=lofs
    add options [ro,nodevices,nosetuid]
    end
...
 exit

ゾーンがリブートされると、監査構成ファイルはゾーン内で読み取り専用になります。

Procedureゾーンごとの監査を構成する方法

この手順に従えば、個々のゾーン管理者が自身のゾーン内で監査サービスを制御できます。ポリシーオプションの完全な一覧については、auditconfig(1M) のマニュアルページを参照してください。

  1. 大域ゾーンで監査を構成します。ただし、監査サービスは有効にしないでください。

    1. 「監査ファイルの構成 (作業マップ)」の作業を行います。

    2. 「監査サービスの構成と有効化 (作業マップ)」の作業を行います。ただし、次の点は例外になります。

      • perzone 監査ポリシーを追加してください。例については、例 30–18 を参照してください。

      • 監査サービスを有効にしないでください。監査サービスの有効化は、非大域ゾーンの監査の構成が完了したあとで行います。

  2. 各非大域ゾーンで監査ファイルを構成します。

    注 –

    監査を無効にする予定の非大域ゾーンでは、この手順をスキップできます。監査を無効にするには、例 30–25 を参照してください。

    1. 「監査ファイルの構成 (作業マップ)」の作業を行います。

    2. 「監査サービスの構成と有効化 (作業マップ)」で説明した手順に従います。

    3. システム全体の監査設定は構成しないでください。

      具体的には、非大域ゾーンの audit_startup ファイルに perzone や ahlt ポリシーを追加しないでください。また、非大域ゾーンから bsmconv コマンドを実行しないでください。

    4. 使用するゾーンで監査を有効にします。

      監査の構成後に大域ゾーンをリブートすると、使用するゾーンの監査が自動的に有効になります。

      システムのリブート後に大域ゾーン管理者が perzone 監査ポリシーを有効にした場合、個々のゾーン管理者が監査の有効化を行う必要があります。詳細は、例 30–20 を参照してください。

  3. 大域ゾーンで監査サービスを有効にします。

    手順については、「監査サービスを有効にする方法」を参照してください。

例 30–25 非大域ゾーンで監査を無効にする

この例は、大域ゾーンで perzone 監査ポリシーが設定されている場合に正しく機能します。noaudit ゾーンのゾーン管理者が、そのゾーンの監査を無効にします。この管理者は、監査を無効にするつもりであったため、監査構成ファイルを編集していませんでした。


noauditzone # svcadm disable svc:/system/auditd

監査レコードの管理 (作業マップ)

次の作業マップは、監査レコードの選択、分析、および管理の手順を示しています。

作業 

説明 

参照先 

監査レコードの書式を表示します 

監査イベント用に収集される情報、および表示される情報の順番を表示します。 

「監査レコードの書式の表示方法」

監査レコードをマージします 

複数のマシンの監査ファイルを 1 つの監査トレールに結合します。 

「監査トレールの監査ファイルをマージする方法」

調査するレコードを選択します 

調査対象の特定のイベントを選択します。 

「監査トレールから監査イベントを選択する方法」

監査レコードを表示します 

バイナリ監査レコードの表示を有効にします。 

「バイナリ監査ファイルの内容を表示する方法」

正確でない名前を付けられた監査ファイルを整理します 

監査サービスにより意図的でなく開いたままにされた監査ファイルに最終タイムスタンプを設定します。 

「not_terminated 監査ファイルを整理する方法」

監査トレールのオーバーフローを防止します 

監査ファイルシステムがいっぱいになることを防止します。 

「監査トレールのオーバーフローを防ぐ方法」

監査レコードの管理

監査トレールを管理することによって、ネットワーク上のユーザーの動作を監視することができます。監査プロセスを行うと、大量のデータが生成される可能性があります。次の手順では、さまざまな監査データを使用して作業を行う方法について説明します。

Procedure監査レコードの書式の表示方法

必要な監査データを検索するスクリプトを作成するためには、監査イベント内のトークンの順番を知る必要があります。bsmrecord コマンドは、監査イベントの監査イベント番号、監査クラス、選択マスク、およびレコード書式を表示します。

  1. すべての監査イベントレコードを HTML ファイルに出力します。

    -a オプションを指定すると、すべての監査イベントレコードの書式が表示されます。-h オプションを指定すると、ブラウザで表示できる HTML 形式で一覧が出力されます。


    % bsmrecord -a -h > audit.events.html

    ブラウザで *html ファイルを表示する場合は、ブラウザの検索ツールを使用して特定のレコードを検索します。

    詳細は、bsmrecord(1M) のマニュアルページを参照してください。

例 30–26 プログラムの監査レコード書式を表示する

この例では、login プログラムによって生成されたすべての監査レコードの書式を表示します。login プログラムには、rlogin、telnet、newgrp、Solaris 管理コンソールへの役割ログイン、および Solaris Secure Shell も含まれます。


% bsmrecord -p login
login: logout
  program     various              See login(1)
  event ID    6153                 AUE_logout
…

newgrp
  program     newgrp               See newgrp login
  event ID    6212                 AUE_newgrp_login
…

rlogin
  program     /usr/sbin/login      See login(1) - rlogin
  event ID    6155                 AUE_rlogin
…

SMC: role login
  program     SMC server           See role login
  event ID    6173                 AUE_role_login
…

/usr/lib/ssh/sshd
  program     /usr/lib/ssh/sshd    See login - ssh
  event ID    6172                 AUE_ssh
…

telnet login
  program     /usr/sbin/login      See login(1) - telnet
  event ID    6154                 AUE_telnet
  …
例 30–27 ある監査クラスの監査レコード書式を表示する

この例では、fd クラスに属するすべての監査レコードの書式を表示します。


% bsmrecord -c fd

rmdir
  system call rmdir                See rmdir(2)
  event ID    48                   AUE_RMDIR
  class       fd                   (0x00000020)
      header
      path
      [attribute]
      subject
      [use_of_privilege]
      return

unlink
  system call unlink               See unlink(2)
  event ID    6                    AUE_UNLINK
  …

unlinkat
  system call unlinkat             See openat(2)
  event ID    286                  AUE_UNLINKAT
  …

Procedure監査トレールの監査ファイルをマージする方法

すべての監査ディレクトリ内のすべての監査ファイルをマージすると、監査トレール全体の内容を分析できます。auditreduce コマンドを使用すると、入力ファイルのすべてのレコードが 1 つの出力ファイルにマージされます。マージが完了すると、入力ファイルを削除できます。出力ファイルが /etc/security/audit/server-name/files という名前のディレクトリに配置されている場合、完全パスを指定しなくても、auditreduce コマンドは出力ファイルを検索できます。

注 –

この手順は、バイナリ監査レコードだけに適用します。

  1. Audit Review プロファイルを含む役割を引き受けるか、スーパーユーザーになります。

    System Administrator 役割には、 Audit Review プロファイルが含まれます。Audit Review プロファイルを含む役割を別々に作成することもできます。役割を作成する方法と役割をユーザーに割り当てる方法については、「RBAC の構成 (作業マップ)」を参照してください。

  2. マージされた監査ファイルを格納するディレクトリを作成します。


    # mkdir audit-trail-directory

  3. ディレクトリへのアクセスを制限します。


    # chmod 700 audit-trail-directory
# ls -la audit-trail-directory
drwx------   3 root     sys          512 May 12 11:47 .
drwxr-xr-x   4 root     sys         1024 May 12 12:47 ..

  4. 監査トレール内の監査レコードをマージします。

    ディレクトリを audit-trail-directory に変更して、指定した接尾辞を持つファイルに監査レコードをマージします。ローカルシステム上にある audit_control ファイルの dir 行に指定されているすべてのディレクトリがマージされます。


    # cd audit-trail-directory
# auditreduce -Uppercase-option -O suffix

    大文字オプションを auditreduce コマンドに指定すると、監査トレール内のファイルを操作できます。次の大文字オプションがあります。

    -A

    監査トレール内のすべてのファイルを選択します。

    -C

    完全ファイルだけを選択します。このオプションは、接尾辞 not_terminated を持つファイルを無視します。

    -M

    特定の接尾辞を持つファイルを選択します。接尾辞はマシン名、またはサマリーファイルに指定した接尾辞です。

    -O

    開始時刻と終了時刻を示す 14 文字のタイムスタンプおよび接尾辞 suffix が付いた監査ファイルを現在のディレクトリに作成します。

例 30–28 サマリーファイルに監査ファイルをコピーする

次の例では、System Administrator 役割 sysadmin は、すべてのファイルを監査トレールからマージされたファイルにコピーします。


$ whoami
sysadmin
$ mkdir /var/audit/audit_summary.dir
$ chmod 700 /var/audit/audit_summary.dir
$ cd /var/audit/audit_summary.dir
$ auditreduce -A -O All
$ ls *All
20030827183214.20030827215318.All

次の例では、完全ファイルだけが監査トレールからマージされたファイルにコピーされます。


$ cd /var/audit/audit_summary.dir
$ auditreduce -C -O Complete
$ ls *Complete
20030827183214.20030827214217.Complete

次の例では、完全ファイルだけが example1 マシンからマージされたファイルにコピーされます。


$ cd /var/audit/audit_summary.dir
$ auditreduce -M example1 -O example1summ
$ ls *summ
20030827183214.20030827214217.example1summ
例 30–29 監査ファイルをサマリーファイルに移動する

auditreduce で - D オプションを指定すると、監査ファイルをほかの場所にコピーしたときにその監査ファイルを削除します。次の例では、あるシステムの完全監査ファイルを、あとで調べるためにサマリーディレクトリにコピーします。


$ cd /var/audit/audit_summary.dir
$ auditreduce -C -O daily_example1 -D example1
$ ls *example1
20030827183214.20030827214217.daily_example1

このコマンドが正常に完了すると、*daily_example1 ファイルへの入力となった example1 システムの監査ファイルが削除されます。

Procedure監査トレールから監査イベントを選択する方法

調べる監査レコードをフィルタリングすることができます。フィルタリングオプションの一覧については、auditreduce(1M) のマニュアルページを参照してください。

  1. Audit Review プロファイルを含む役割を引き受けるか、スーパーユーザーになります。

    System Administrator 役割には、 Audit Review プロファイルが含まれます。Audit Review プロファイルを含む役割を別々に作成することもできます。役割を作成する方法と役割をユーザーに割り当てる方法については、「RBAC の構成 (作業マップ)」を参照してください。

  2. 監査トレールまたは指定した監査ファイルから必要なレコードを選択します。


    auditreduce -lowercase-option argument [optional-file]
    argument

    小文字オプションが必要とする特定の引数。たとえば、-c オプションは、ua などの監査クラスの argument を必要とします。

    -d

    特定の日付のイベントをすべて選択します。argument の日付の形式は、yyyymmdd です。ほかの日付オプション -b と -a は、特定の日付の前と後のイベントを選択します。

    -u

    特定のユーザーのイベント属性をすべて選択します。argument はユーザー名です。もう 1 つのユーザーオプション -e は、実効ユーザー ID のイベント属性をすべて選択します。

    -c

    事前選択された監査クラス内のイベントをすべて選択します。argument は監査クラス名です。

    -m

    特定の監査イベントのインスタンスをすべて選択します。argument は監査イベントです。

    optional-file

    監査ファイルの名前です。

例 30–30 監査ファイルを結合して削減する

auditreduce コマンドを使用すると、入力ファイルの結合時に不要なレコードを除外できます。たとえば、auditreduce コマンドを使用して、1 か月以上経過した監査ファイルから、ログインレコードとログアウトレコード以外のレコードを削除することができます。監査トレール全体が必要になった場合は、バックアップメディアから監査トレールを復元します。


# cd /var/audit/audit_summary.dir
# auditreduce -O lo.summary -b 20030827 -c lo; compress *lo.summary
例 30–31 na 監査レコードをサマリーファイルにコピーする

この例では、監査トレール内の、ユーザーに起因しない監査イベントのすべてのレコードが、1 つのファイルに収集されます。


$ whoami
sysadmin
$ cd /var/audit/audit_summary.dir
$ auditreduce -c na -O nasumm
$ ls *nasumm
20030827183214.20030827215318.nasumm

マージされた nasumm 監査ファイルは、na レコードの開始時刻と終了時刻のタイムスタンプが記録されます。

例 30–32 指定した監査ファイル内で監査イベントを検索する

監査ファイルを手動で選択して、指定された一連のファイルだけを検索できます。たとえば、前の例の *nasumm ファイルをさらに処理して、システムブートイベントを検索できます。これを行うには、auditreduce コマンドの最後の引数にファイル名を指定します。


$ auditreduce -m 113 -O systemboot 20030827183214.20030827215318.nasumm
20030827183214.20030827183214.systemboot

20030827183214.20030827183214.systemboot ファイルは、システムブート監査イベントだけを含みます。

例 30–33 ユーザー監査レコードをサマリーファイルにコピーする

この例では、特定のユーザー名を含む監査トレール内のレコードがマージされます。-e オプションを指定すると実効ユーザーが検索されます。-u オプションを指定すると監査ユーザーが検索されます。


$ cd /var/audit/audit_summary.dir
$ auditreduce -e tamiko -O tamiko

このファイル内の特定のイベントを検索できます。次の例では、2003 年 9 月 7 日にユーザーがログインした時間が確認されます。接尾辞にユーザーの名前が付いたファイルだけが確認されます。日付の短い形式は、yyyymmdd です。


# auditreduce -M tamiko -O tamikolo -d 20030907 -u tamiko -c lo
例 30–34 選択レコードを 1 つのファイルにコピーする

この例では、特定の日付におけるログイン、ログアウトのメッセージが監査トレールから選択されます。これらのメッセージは対象ファイルにマージされます。対象ファイルは、通常の監査ルートディレクトリ以外のディレクトリに書き込まれます。


# auditreduce -c lo -d 20030827 -O /var/audit/audit_summary.dir/logins
# ls /var/audit/audit_summary.dir/*logins
/var/audit/audit_summary.dir/20030827183936.20030827232326.logins

Procedureバイナリ監査ファイルの内容を表示する方法

praudit コマンドを使用すると、バイナリ監査ファイルの内容を表示できます。auditreduce コマンドから出力をパイプしたり、特定の監査ファイルを読み取ったりできます。さらに処理する場合に -x オプションが役立ちます。

  1. Audit Review プロファイルを含む役割を引き受けるか、スーパーユーザーになります。

    System Administrator 役割には、 Audit Review プロファイルが含まれます。Audit Review プロファイルを含む役割を別々に作成することもできます。役割を作成する方法と役割をユーザーに割り当てる方法については、「RBAC の構成 (作業マップ)」を参照してください。

  2. 次の praudit コマンドの 1 つを使用して、目的に沿った出力を生成します。

    次の例は、同じ監査イベントからの praudit 出力を表示します。監査ポリシーは、sequence トークンと trailer トークンを含むように設定されています。

    • praudit -s コマンドを使用して、短い書式で 1 行につき 1 トークンの監査レコードを表示します。-l オプションを指定して、1 行に各レコードを配置します。


      $ auditreduce -c lo | praudit -s
header,101,2,AUE_rlogin,,example1,2003-10-13 11:23:31.050 -07:00
subject,jdoe,jdoe,staff,jdoe,staff,749,749,195 1234 server1
text,successful login 
return,success,0 
sequence,1298

    • praudit -r コマンドを使用して、監査レコードの raw 書式で 1 行につき 1 トークンの監査レコードを表示します。-l オプションを指定して、1 行に各レコードを配置します。


      $ auditreduce -c lo | praudit -r
21,101,2,6155,0x0000,192.168.60.83,1062021202,64408258
36,2026700,2026700,10,2026700,10,749,749,195 1234 192.168.60.17
40,successful login
39,0,0
47,1298

    • praudit -x コマンドを使用して、XML 形式で 1 行につき 1 トークンの監査レコードを表示します。-l オプションを指定して、1 レコードの XML 出力を 1 行に配置します。


      $ auditreduce -c lo | praudit -x
<record version="2" event="login - rlogin" host="example1" 
time="Wed Aug 27 14:53:22 PDT 2003" msec="64">
<subject audit-uid="jdoe" uid="jdoe" gid="staff" ruid="jdoe" 
rgid="staff" pid="749" sid="749" tid="195 1234 server1"/>
<text>successful login</text>
<return errval="success" retval="0"/>
<sequence seq-num="1298"/>

</record>
例 30–35 監査トレール全体を印刷する

lp コマンドにパイプすると、監査トレール全体の出力がプリンタに送られます。プリンタへのアクセスを制限してください。


# auditreduce | praudit | lp -d example.protected.printer
例 30–36 特定の監査ファイルを表示する

この例では、サマリーログインファイルを端末ウィンドウで調べます。


# cd /var/audit/audit_summary.dir/logins
# praudit 20030827183936.20030827232326.logins | more
例 30–37 監査レコードを XML 形式に変換する

この例では、監査レコードを XML 形式に変換します。


# praudit -x 20030827183214.20030827215318.logins > 20030827.logins.xml

*xml ファイルはブラウザを使って表示できます。スクリプトを使えば、XML ファイルの内容を操作して目的の情報を抽出できます。

注意事項

次のようなメッセージは、praudit コマンドを使用するために必要な権限がないことを示しています。

praudit: Can't assign 20090408164827.20090408171614.example1 to stdin.

Procedurenot_terminated 監査ファイルを整理する方法

監査ファイルが開いている状態で監査デーモンが終了することがあります。また、サーバーがアクセス不能になって、強制的に別のサーバーに切り替わってしまうことがあります。このような場合、その監査ファイルは監査レコードとして使用されなくなりますが、監査ファイルの終了タイムスタンプとして文字列 not_terminated が付いたままになります。auditreduce -O コマンドを使用して、ファイルに正しいタイムスタンプを付けます。

  1. 監査ファイル上の not_terminated 文字列が付いたファイルを作成順に一覧表示します。


    # ls -R1t audit-directory*/files/* | grep not_terminated
    -R

    サブディレクトリ内のファイルを一覧表示します。

    -t

    最新のファイルからもっとも古いファイルの順で一覧表示します。

    -1

    1 列でファイルを一覧表示します。

  2. 古い not_terminated ファイルを整理します。

    古いファイルの名前を auditreduce -O コマンドに指定します。


    # auditreduce -O system-name old-not-terminated-file

  3. 古い not_terminated ファイルを削除します。


    # rm system-name old-not-terminated-file
例 30–38 閉じた not_terminated 監査ファイルを整理する

次の例では、not_terminated ファイルを検索し、名前を変更して、元のファイルを削除します。


ls -R1t */files/* | grep not_terminated
…/egret.1/20030908162220.not_terminated.egret
…/egret.1/20030827215359.not_terminated.egret
# cd */files/egret.1
# auditreduce -O egret 20030908162220.not_terminated.egret
# ls -1t
20030908162220.not_terminated.egret Current audit file
20030827230920.20030830000909.egret Input (old) audit file
20030827215359.not_terminated.egret
# rm 20030827215359.not_terminated.egret
# ls -1t
20030908162220.not_terminated.egret Current audit file
20030827230920.20030830000909.egret Cleaned up audit file

新しいファイルの開始タイムスタンプは、not_terminated ファイル内にある最初の監査イベントの時間を反映します。終了タイムスタンプは、そのファイル内にある最後の監査ファイルの時間を反映します。

Procedure監査トレールのオーバーフローを防ぐ方法

セキュリティーポリシーの関係ですべての監査データを保存する必要がある場合は、次の手順に従います。

  1. 監査ファイルを定期的に保存するスケジュールを設定します。

    ファイルをオフラインのメディアにバックアップして、監査ファイルを保管します。これらのファイルを保存ファイルシステムに移動することもできます。

    syslog ユーティリティーを使用してテキスト監査ログを収集している場合、テキストログを保管します。詳細は、logadm(1M) のマニュアルページを参照してください。

  2. スケジュールを設定して、保管された監査ファイルを監査ファイルシステムから削除します。

  3. 補助情報を保存し保管します。

    監査レコードの解釈に必要な情報を、監査トレールとともに格納します。

  4. 保管した監査ファイルの記録をとります。

  5. 保存したメディアを適切な方法で保管します。

  6. サマリーファイルを作成して、格納する監査データのボリュームを削減します。

    監査トレールからサマリーファイルを抽出するには、auditreduce コマンドのオプションを使用します。サマリーファイルには、指定された種類の監査イベントのレコードだけが含まれます。サマリーファイルを抽出するには、例 30–30 および例 30–34 を参照してください。

Solaris 監査のトラブルシューティング (作業)

この節では、さまざまな Solaris 監査のエラーメッセージ、設定、ほかのツールによる監査について説明します。ここで示す手順は、使用中のシステムで必要な監査イベントを記録する際に役立ちます。

Solaris 監査のトラブルシューティング (作業マップ)

次の作業マップでは、Solaris 監査のトラブルシューティングの手順を示します。

問題 

解決方法 

説明 

監査を構成したときに監査ファイルが作成されないのはなぜでしょうか。 

監査デーモンと監査構成ファイルのトラブルシューティングを行います。 

「Solaris 監査が実行中であるかどうかを判定する方法」

収集される監査情報を減らすには、どうすればよいでしょうか。 

監査が必要なイベントについてのみ、監査を行います。 

「生成される監査レコードの量を削減する方法」

システムでのユーザーの動作をすべて監査するには、どうすればよいでしょうか。 

すべてのコマンドについて 1 人または複数のユーザーを監査します。 

「ユーザーによるすべてのコマンドを監査する方法」

記録される監査イベントを変更して、その変更内容を既存のセッションに適用するには、どうすればよいでしょうか。 

ユーザーの事前選択マスクを更新します。 

「ユーザーの事前選択マスクを変更する方法」

変更内容を特定のファイルに格納するには、どうすればよいでしょうか。 

ファイルの変更を監査し、auditreduce コマンドを使用して特定のファイルを検索します。

「特定のファイルに対する変更の監査レコードを検索する方法」

監査ファイルのサイズを減らすには、どうすればよいでしょうか。 

バイナリ監査ファイルのサイズを制限します。 

「バイナリ監査ファイルのサイズを制限する方法」

audit_event ファイルから監査イベントを削除するには、どうすればよいでしょうか。

audit_event ファイルを更新します。

「特定のイベントが監査されないようにする方法」

Solaris システムへのすべてのログインを監査するには、どうすればよいでしょうか。 

システムからのログインを監査します。 

「ほかの OS からのログインを監査する方法」

FTP 転送で監査レコードが保持されないのはなぜでしょうか。 

ログを生成するユーティリティーに適切な監査ツールを使用します。 

「FTP および SFTP ファイル転送を監査する方法」

ProcedureSolaris 監査が実行中であるかどうかを判定する方法

監査が有効になっているはずだが、1 次監査ディレクトリに監査レコードがない場合、次の手順を試してください。

始める前に

ネームサービスの hosts データベースが正しく構成され、機能しています。ネームサービスの問題をデバッグする場合は、次の情報を参照してください。

  1. 監査が実行中であるかどうかを判定します。

    • c2audit カーネルモジュールがロード済みであることを確認します。


      # modinfo | grep c2audit

      リストがない場合、監査が実行中でないことを示しています。次のリストは、監査が実行中であることを示しています。


      40  132ce90  14230 186   1  c2audit (C2 system call)

    • 監査デーモンが動作していることを確認します。

      auditd サービスの状態を確認します。次のリストは、監査が実行中でないことを示しています。


      # svcs -x auditd
svc:/system/auditd:default (Solaris audit daemon)
 State: disabled since Fri Aug 14 19:02:35 2009
Reason: Disabled by an administrator.
   See: http://sun.com/msg/SMF-8000-05
   See: auditd(1M)
   See: audit(1M)
Impact: This service is not running.

      次のリストは、監査サービスが実行中であることを示しています。


      # svcs auditd
STATE          STIME    FMRI
online         10:10:10 svc:/system/auditd:default

    • 現在の監査の状況を確認します。

      次のリストは、監査が実行中でないことを示しています。


      # auditconfig -getcond
auditconfig: auditon(2) failed.
auditconfig: error = Operation not supported(48)

      次のリストは、監査が実行中であることを示しています。


      # auditconfig -getcond
audit condition = auditing

    監査サービスが実行中でない場合、有効にします。手順については、「監査サービスを有効にする方法」を参照してください。

  2. audit_control ファイルの構文を確認します。


    # audit -v /etc/security/audit_control
audit: audit_control must have either a valid "dir:" entry 
or a valid "plugin:" entry with "p_dir:" specified.

    エラーを修正します。syntax ok というメッセージは、ファイルの構文が正しいことを示しています。

  3. audit_control ファイルについて、flags キーワードおよび naflags キーワードの値が有効であることを確認します。


    # grep flags /etc/security/audit_control
flags:lo
naflags:na,lp

    audit_control ファイルに無効な値が含まれている場合、有効な値を指定します。前述の例で、lp は無効なクラスです。

  4. audit_user ファイルについて、すべてのユーザーの値が有効であることを確認します。


    # tail audit_user
...
# User Level Audit User File
#
# File Format
#
#	username:always:never
#
root:lo:no
admin:lp:no

    audit_user ファイルに無効な値が含まれている場合、有効な値を指定します。前述の例で、lp は無効なクラスです。

  5. カスタマイズ監査クラスを作成した場合、そのクラスにイベントが割り当て済みであることを確認します。

    たとえば、次の audit_control ファイルには、Oracle Solaris ソフトウェアが配信していないクラスが含まれています。


    # grep flags /etc/security/audit_control
flags:lo,pf
naflags:na,lo

    pf クラスの作成については、「監査クラスの追加方法」を参照してください。

    1. クラスが audit_class ファイルで定義されていることを確認します。

      監査クラスマスクは一意である必要があります。


      # grep pf /etc/security/audit_class
0x10000000:pf:profile command

      クラスが定義されていない場合、定義します。そうでない場合、audit_control ファイルおよび audit_user ファイルからクラスを削除します。

    2. イベントがクラスに割り当てられていることを確認します。


      # grep pf /etc/security/audit_event
6180:AUE_prof_cmd:profile command:ua,as,pf

      イベントがクラスに割り当てられていない場合、適切なイベントをこのクラスに割り当てます。

  6. 前述の手順で問題が見つからなかった場合、システムログファイル /var/adm/messages および /var/log/syslog を確認します。

    1. 問題を検出して修正します。

    2. 次に、監査サービスが実行中である場合、再起動します。


      # audit -s

    3. 監査サービスが実行中でない場合、有効にします。

      手順については、「監査サービスを有効にする方法」を参照してください。

Procedure生成される監査レコードの量を削減する方法

使用しているシステムで監査する必要のあるイベントを決定した後、次に示す方法で管理可能な監査ファイルを作成します。

  1. デフォルトの監査ポリシーを使用します。

    具体的には、監査証跡へのイベントと監査トークンの追加を回避します。次のポリシーは、監査証跡のサイズに影響します。

    • arge ポリシー – 環境変数を exec 監査イベントに追加します。

    • argv ポリシー – コマンドパラメータを exec 監査イベントに追加します。

    • public ポリシー – ファイルイベントを監査対象とする場合、公開ファイルで監査可能なイベントが発生するたびに、監査証跡にイベントを追加します。ファイルクラスには、fa、fc、fd、fm、fr、fw、cl などがあります。公開ファイルの定義については、「監査の用語と概念」を参照してください。

    • path ポリシー – path トークンを、省略可能な path トークンを含む監査イベントに追加します。

    • group ポリシー – group トークンを、省略可能な newgroups トークンを含む監査イベントに追加します。

    • seq ポリシー – sequence トークンをすべての監査イベントに追加します。

    • trail ポリシー – trailer トークンをすべての監査イベントに追加します。

    • windata_down ポリシー – Trusted Extensions で構成されたシステムで、ラベル付きウィンドウの情報がダウングレードされるときにイベントを追加します。

    • windata_up ポリシー – Trusted Extensions で構成されたシステムで、ラベル付きウィンドウの情報がアップグレードされるときにイベントを追加します。

    • zonename ポリシー – ゾーン名をすべての監査イベントに追加します。大域ゾーンが唯一の構成ゾーンである場合、zone, global をすべての監査イベントに追加します。

    次の監査レコードは、ls コマンドの使用を示しています。ex クラスが監査対象で、デフォルトのポリシーが使用されています。


    header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00
path,/usr/bin/ls
subject,jdoe,root,root,root,root,1401,737,0 0 mach1
return,success,0

    すべてのポリシーがオンの場合、同じレコードが次のようになります。


    header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00
path,/usr/bin/ls
attribute,100555,root,bin,136,432,0
exec_args,1,ls
exec_env,9,HOME=/,HZ=,LANG=C,LOGNAME=root,MAIL=/var/mail/root,PATH=/u
sr/sbin:/usr/bin,SHELL=/sbin/sh,TERM=xterm,TZ=US/Pacific
path,/lib/ld.so.1
attribute,100755,root,bin,136,4289,0
subject,jdoe,root,root,root,root,1401,737,0 0 mach1
group,root,other,bin,sys,adm,uucp,mail,tty,lp,nuucp,daemon
return,success,0
zone,global
sequence,313540
trailer,375

  2. audit_syslog.so プラグインを使用して、一部の監査イベントを syslog に送信します。

    この方法は、syslog ログに送信する監査イベントのバイナリレコードを保持する必要がない場合にのみ有効です。auditreduce コマンドを使用すると、レコードからバイナリファイルを取り除くことができるため、バイナリファイルのサイズが削減されます。

  3. 特定のユーザーおよび役割について、監査イベントに audit_user ファイルを使用します。

    audit_control ファイルの監査クラスの数を減らすことにより、すべてのユーザーの監査の量を削減します。audit_user ファイルで、特定のユーザーおよび役割の監査クラスを追加します。

  4. 独自のカスタマイズ監査クラスを作成します。

    使用しているシステムで監査クラスを作成できます。このクラスに、監視が必要な監査イベントをすべて指定します。手順については、「監査クラスの追加方法」を参照してください。

    注 –

    既存の監査クラスの割り当てを変更する場合、新しいバージョンの Solaris OS にアップグレードするときに変更内容が失われることがあります。インストールログを慎重に確認してください。

Procedureユーザーによるすべてのコマンドを監査する方法

サイトのセキュリティーポリシーの一環として、root ユーザーまたは管理役割により実行されるすべてのコマンドについて監査レコードが必要になることがあります。また、サイトによっては、ユーザーが実行するすべてのコマンドの監査レコードを必要とする場合もあります。

  1. lo クラスおよび ex クラスを監査します。

    ex クラスは、exec() 関数および execve() 関数のすべての呼び出しを監査します。lo クラスは、ログイン、ログアウト、および画面ロックを監査します。次の出力は、ex クラスおよび lo クラスのすべてのイベントを一覧表示します。


    7:AUE_EXEC:exec(2):ps,ex
23:AUE_EXECVE:execve(2):ps,ex
...
6152:AUE_login:login - local:lo
6153:AUE_logout:logout:lo
6154:AUE_telnet:login - telnet:lo
6155:AUE_rlogin:login - rlogin:lo
6158:AUE_rshd:rsh access:lo
6159:AUE_su:su:lo
6162:AUE_rexecd:rexecd:lo
6163:AUE_passwd:passwd:lo
6164:AUE_rexd:rexd:lo
6165:AUE_ftpd:ftp access:lo
6171:AUE_ftpd_logout:ftp logout:lo
6172:AUE_ssh:login - ssh:lo
6173:AUE_role_login:role login:lo
6212:AUE_newgrp_login:newgrp login:lo
6213:AUE_admin_authenticate:admin login:lo
6221:AUE_screenlock:screenlock - lock:lo
6222:AUE_screenunlock:screenlock - unlock:lo
6227:AUE_zlogin:login - zlogin:lo

    • 管理者についてこれらのクラスを監査するには、audit_user ファイルを変更します。

      次の例では、サイトが sysadm、auditadm、および netadm という 3 つの役割を作成しています。これらの役割と root アカウントは、exec クラスおよび lo クラスについて監査されます。


      ## audit_user file
root:lo,ex:no
sysadm:lo,ex:no
auditadm:lo,ex:no
netadm:lo,ex:no

    • ユーザーに起因しないイベントについて lo クラスを監査するには、audit_control ファイルを変更します。


      ## audit_control file
...
naflags:lo
...

    • すべてのユーザーについてこれらのクラスを監視するには、audit_control ファイルを変更します。


      ## audit_control file
flags:lo,ex
naflags:lo
...

      出力は次のようになります。


      header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00
path,/usr/bin/ls
subject,jdoe,root,root,root,root,1401,737,0 0 mach1
return,success,0

  2. コマンドの引数を記録するには、argv ポリシーを設定します。


    ## audit_startup script
...
auditconfig -setpolicy +argv
...

    exec_args トークンは、コマンド引数を記録します。


    header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00
path,/usr/bin/ls
exec_args,1,ls
subject,jdoe,root,root,root,root,1401,737,0 0 mach1
return,success,0

  3. コマンドの実行環境を記録するには、arge ポリシーを設定します。


    ## audit_startup script
...
auditconfig -setpolicy +arge
...

    exec_env トークンは、コマンド環境を記録します。


    header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00
path,/usr/bin/ls
exec_env,9,HOME=/,HZ=,LANG=C,LOGNAME=root,MAIL=/var/mail/root,
  PATH=/usr/sbin:/usr/bin,SHELL=/sbin/sh,TERM=xterm,TZ=US/Pacific
subject,jdoe,root,root,root,root,1401,737,0 0 mach1
return,success,0

  4. 引数とコマンド環境を記録するには、両方のポリシーを設定します。


    ## audit_startup script
...
auditconfig -setpolicy +argv
auditconfig -setpolicy +arge
...

    出力は次のようになります。


    header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00
path,/usr/bin/ls
exec_args,1,ls
exec_env,9,HOME=/,HZ=,LANG=C,LOGNAME=root,MAIL=/var/mail/root,
  PATH=/usr/sbin:/usr/bin,SHELL=/sbin/sh,TERM=xterm,TZ=US/Pacific
subject,jdoe,root,root,root,root,1401,737,0 0 mach1
return,success,0

Procedure特定のファイルに対する変更の監査レコードを検索する方法

/etc/passwd や /etc/default ディレクトリ内のファイルなど、限られた数のファイルに対するファイル書き込みを記録する場合、auditreduce コマンドを使用してファイルを見つけます。

  1. fw クラスを監査します。

    audit_user ファイルにクラスを追加すると、audit_control ファイルにクラスを追加する場合よりも、生成されるレコードが少なくなります。

    • fw クラスを audit_user ファイルに追加します。


      ## audit_user file
root:fw:no
sysadm:fw:no
auditadm:fw:no
netadm:fw:no

    • fw クラスを audit_control ファイルに追加します。


      ## audit_control file
flags:lo,fw
...

  2. 特定のファイルの監査レコードを検索するには、auditreduce コマンドを使用します。


    # /usr/sbin/auditreduce -o file=/etc/passwd,/etc/default -O filechg

    auditreduce コマンドは、file 引数のすべてのインスタンスについて監査証跡を検索します。このコマンドにより、接尾辞 filechg を持つバイナリファイルが作成されます。このファイルには、必要なファイルのパス名を含むすべてのレコードが含まれています。-o file=pathname オプションの構文については、auditreduce(1M) のマニュアルページを参照してください。

  3. filechg ファイルを読み取るには、praudit コマンドを使用します。


    # /usr/sbin/praudit *filechg

Procedureユーザーの事前選択マスクを変更する方法

audit_control ファイルまたは ファイルを変更する場合、すでにログインしているユーザーの事前選択マスクは変更されません。事前選択マスクを強制的に変更する必要があります。

始める前に

監査を有効にしてユーザーがログインしてから、audit_control ファイルの flags または naflags の値を変更しました。新しく選択された監査クラスの監査対象とするために、すでにログインしているユーザーが必要です。

  1. すでにログインしているユーザーの事前選択マスクを更新します。

    2 つの選択肢があります。既存のセッションを終了するか、auditconfig コマンドを使用してユーザーの事前選択マスクを更新します。

    • ユーザーの既存のセッションを終了します。

      ユーザーがログアウトしてふたたびログインするか、管理者がアクティブなセッションを手動で終了できます。新しいセッションでは、新しい事前選択マスクが継承されます。ただし、ユーザーの終了が実用的でない場合もあります。

    • 各ユーザーの事前選択マスクを動的に変更します。

      audit_control ファイルの flags 属性が lo から lo,ex に変更されたものとします。

      1. ユーザーの監査 ID および監査セッション ID を決定します。

        まず、すべての通常ユーザーを検索します。次の例では、管理者が、root、daemon、または lp により所有されていないすべてのプロセスを検索します。


        # /usr/bin/pgrep -v -u root,daemon,lp | more 
..
3941
3948
3949
10640 ...

        次に、ユーザーのプロセスの 1 つを使用して、ユーザーの監査 ID を検索します。


        # auditconfig -getpinfo 3941
audit id = jdoe(1002)
process preselection mask = lo(0x1000,0x1000)
terminal id (maj,min,host) = 9426,65559,mach1(192.168.123.234)
audit session id = 713

        ユーザーの事前選択マスクには、lo クラスが含まれますが、新しく追加された ex クラスは含まれません。

      ユーザーの監査 ID は 1002 です。ユーザーの監査セッション ID は 713 です。

  2. ユーザーの事前選択マスクを変更します。

    次の 2 つの方法のいずれかを使用します。

    • ユーザーの監査セッション ID を使用して、ユーザーの事前選択マスクを変更します。


      # /usr/sbin/auditconfig -setsmask lo,ex 713

    • ユーザーの監査 ID を使用して、ユーザーの事前選択マスクを変更します。


      # /usr/sbin/auditconfig -setumask lo,ex 1002

  3. 事前選択マスクが変更されたことを確認します。


    # auditconfig -getpinfo 3941
audit id = jdoe(1002)
process preselection mask = ex,lo(0x40001000,0x40001000) 
terminal id (maj,min,host) = 9426,65559,mach1(192.168.123.234)
audit session id = 713

Procedure特定のイベントが監査されないようにする方法

メンテナンスのために、監査イベントが監査されないようにする必要が生じることがあります。

  1. イベントのクラスを no クラスに変更します。

    たとえば、イベント 26 および 27 は pm クラスに属しています。


    ## audit_event file
...
25:AUE_VFORK:vfork(2):ps
26:AUE_SETGROUPS:setgroups(2):pm
27:AUE_SETPGRP:setpgrp(2):pm
28:AUE_SWAPON:swapon(2):no
...

    これらのイベントを no クラスに変更します。


    ## audit_event file
...
25:AUE_VFORK:vfork(2):ps
26:AUE_SETGROUPS:setgroups(2):no
27:AUE_SETPGRP:setpgrp(2):no
28:AUE_SWAPON:swapon(2):no
...

    pm クラスが現在監査中である場合でも、既存のセッションはイベント 26 および 27 を監査します。これらのイベントの監査を停止するには、ユーザーの事前選択マスクを更新する必要があります。

    注意 – 注意 –

    audit_event ファイルではイベントをコメントにしないでください。このファイルは、praudit コマンドがバイナリ監査ファイルを読み取るときに使用します。また、このファイルに一覧表示されたイベントが、保管された監査ファイルに含まれることがあります。

  2. ユーザーの事前選択マスクを更新するには、「ユーザーの事前選択マスクを変更する方法」の手順に従います。

Procedureバイナリ監査ファイルのサイズを制限する方法

バイナリ監査ファイルは無制限に増大します。保管や検索を容易にするために、サイズの制限が必要となることがあります。元のファイルから小さいバイナリファイルを作成することもできます。

  1. Solaris 10 10/08 リリース以降、個々のバイナリ監査ファイルのサイズを制限するには p_fsize 属性を使用します。

    audit_binfile.so プラグインの p_fsize 属性により、監査ファイルのサイズを制限できます。デフォルト値はゼロ (0) で、この場合はファイルが無制限に増大します。値は、512,000 から 2,147,483,647 までのバイト数で指定します。指定したサイズに達すると、現在の監査ファイルが閉じられ、新しいファイルが開きます。

    次の例では、監査ファイルのサイズを 1M バイトに制限します。


    plugin:name=audit_binfile.so; p_dir:/var/audit; p_fsize=1024000

  2. auditreduce コマンドを使用して、レコードを選択し、これらのレコードを詳細分析用にファイルに書き込みます。

    auditreduce -lowercase オプションは特定のレコードを検索します。

    auditreduce -Uppercase オプションは選択したレコードをファイルに書き込みます。詳細は、auditreduce(1M) のマニュアルページを参照してください。

Procedureほかの OS からのログインを監査する方法

Solaris OS では、ソースに関係なく、すべてのログインを監査できます。

  1. ユーザーに起因するイベントおよび起因しないイベントの lo クラスを監査します。

    このクラスは、ログイン、ログアウト、および画面ロックを監査します。


    ## audit_control file
flags:lo
naflags:lo
...
    注 –

    ssh ログインを監査するには、使用している Solaris システムで Solaris ssh デーモンを実行する必要があります。このデーモンは、Solaris 監査用に変更されます。詳細は、「Solaris Secure Shell と OpenSSH プロジェクト」を参照してください。

ProcedureFTP および SFTP ファイル転送を監査する方法

FTP サービスは、ファイル転送のログを作成します。SSH プロトコルで実行する SFTP サービスは、Solaris 監査で監査できます。Solaris 監査では、両方のサービスへのログインを監査できます。

  1. FTP サービスのファイル転送とコマンドのログを作成するには、ftpaccess(4) のマニュアルページを参照してください。

    使用可能なログ作成オプションについては、「ログ作成機能」に関する節を参照してください。特に、有用なログを作成できるのは、log commands オプションおよび log transfers オプションです。

  2. sftp ファイル転送のログを作成するには、次の方法のいずれかまたは両方を実行します。

    • ファイル読み取りを監査します。

      SSH 接続によるファイル転送は、sftp コマンドを使用します。これらの転送は、+fr 監査フラグを使用して記録できます。失敗した sftp ファイル転送を監査するには、-fr 監査フラグを監査します。

      成功した sftp セッションの出力は次のとおりです。


      header,138,2,open(2) - read,,ma2,2009-08-25 14:48:58.770 -07:00
path,/home/jdoe/vpn_connect
attribute,100644,jdoe,staff,391,437,0
subject,jdoe,jdoe,staff,jdoe,staff,4444,120289379,8457 65558 ma1
return,success,6

    • 冗長オプションを sftp コマンドに使用します。

      -v オプションは 3 回まで繰り返すことができます。


      # sftp -vvv [ other options ] hostname

  3. FTP および SFTP サービスへのアクセスを記録するには、lo クラスを監査します。

    次の出力に示すとおり、ftpd デーモンへのログインおよびログアウトで監査レコードが生成されます。


    % bsmrecord -c lo | more
...
in.ftpd
  program     /usr/sbin/in.ftpd    See ftp access
  event ID    6165                 AUE_ftpd
  class       lo                   (0x00001000)
      header
      subject
      [text]                       error message
      return

in.ftpd
  program     /usr/sbin/in.ftpd    See ftp logout
  event ID    6171                 AUE_ftpd_logout
  class       lo                   (0x00001000)
      header
      subject
      return
...

    SSH ログインは、sftp コマンドへのすべてのアクセスを記録します。


    ...
/usr/lib/ssh/sshd
  program     /usr/lib/ssh/sshd    See login - ssh
  event ID    6172                 AUE_ssh
  class       lo                   (0x00001000)
      header
      subject
      [text]                       error message
      return