この章では、監査対象の Solaris システムの設定と管理に役立つ手順を説明します。また、監査トレールの管理方法についても説明します。この章の内容は次のとおりです。
監査サービスの概要は、第 28 章Solaris 監査 (概要)を参照してください。計画の提案については、第 29 章Solaris 監査の計画を参照してください。参照情報については、第 31 章Solaris 監査 (参照)を参照してください。
次の作業マップは、監査の管理に必要な主な作業を示します。作業は順番に並んでいます。
作業 |
説明 |
参照先 |
---|---|---|
1. 監査を計画します |
監査サービスを構成する前に判断する構成上の問題を含みます。 | |
2. 監査ファイルを構成します |
監査を必要とするイベント、クラス、およびユーザーを定義します。 | |
3. 監査を構成および有効化します |
ディスク容量とほかの監査サービスの要件に対して各ホストを構成します。その後、監査サービスを開始します。 | |
非大域ゾーンがインストールされたホストでは、システムに対して 1 つの監査サービスを構成するか、ゾーンごとに監査サービスを 1 つずつ構成します。 | ||
4. 監査レコードを管理します。 |
監査データを収集して分析します。 |
次の作業マップは、サイトで監査をカスタマイズするファイルの構成手順の一覧です。ほとんどの作業は省略可能です。
ネットワーク上で監査を有効にする前に、サイトの監査要件の監査構成ファイルをカスタマイズします。また、監査サービスを再起動またはローカルシステムをリブートして、監査サービスが有効になったあとに変更された構成ファイルの読み取りを行うこともできます。ただし、監査構成のカスタマイズに必要な作業は、できる限り監査サービスを開始する前に行います。
ゾーンを実装している場合、大域ゾーンからすべてのゾーンを監査することができます。監査出力内のゾーンを区別するには、zonename ポリシーオプションを指定します。非大域ゾーンを別々に監査するには、大域ゾーン内の perzone ポリシーを指定して、非大域ゾーンの監査構成ファイルをカスタマイズします。概要については、「監査と Solaris ゾーン」を参照してください。計画については、「ゾーン内の監査の計画方法」を参照してください。手順については、「ゾーンでの監査サービスの構成 (手順)」を参照してください。
/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 |
行の種類を定義します。種類には、dir、flags、minfree、naflags、および plugin があります。Solaris 10 リリースでは、dir 行および minfree 行は非推奨です。
キーワードの説明は、次の例を参照してください。
その種類の行に関連するデータを指定します。
監査ディレクトリの場所を指定するには、audit_binfile.so プラグインの p_dir 属性を使用します。最小空き容量を指定するには、p_minfree 属性を使用します。
# audit -v /etc/security/audit_control syntax ok |
audit_control ファイルの flags 行には、監査対象のユーザーに起因するイベントのクラスを定義します。このフラグは、システム上のすべてのユーザーに適用されます。クラスをコンマで区切ります。空白が使用できます。この例では、すべてのユーザーを対象に lo クラスおよび ap クラスのイベントが監査されます。°
## audit_control file flags:lo,ap naflags:lo plugin:name=... |
どのイベントがクラスに割り当てられているかを確認するには、audit_event ファイルを参照してください。bsmrecord コマンドを使用することもできます (例 30–27 参照)。
この例では、na クラス内のすべてのイベント、およびユーザーに起因しないすべての login イベントが監査対象です。
## audit_control file flags:lo naflags:lo,na plugin:name=... |
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 |
バイナリ監査データを保持するファイルシステムの設定方法は、「監査ファイルのパーティションの作成方法」を参照してください。
この例では、すべての監査ファイルシステムの最小空き領域レベルが設定され、利用できるファイルシステムの領域が 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 にコピーできます。次の手順では、バイナリ監査データとテキスト監査データを保存します。収集されたテキスト監査データは、バイナリデータのサブセットです。
監査クラスを事前に選択する必要があります。事前に選択される監査クラスは、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: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 |
# svcadm refresh system/system-log |
syslog ログファイルを定期的に保管します。
監査サービスでは、大量の出力が生成される可能性があります。ログの管理方法については、logadm(1M) のマニュアルページを参照してください。
次の例では、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 で作成されます。
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 |
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 |
監査するユーザー名を選択します。
指定したユーザーについて常に監査する監査クラスの一覧を選択します。
指定したユーザーについて監査しない監査クラスの一覧を選択します。
複数のクラスを指定するには、監査クラスをコンマで区切ります。
audit_user エントリは、ユーザーの次回のログイン時に有効になります。
この例では、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 |
この例では、システム上での 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 |
number が 16 進であることを示します。
一意の監査クラスマスクを定義します。
監査クラスの文字の名前を定義します。
監査クラスの記述名を定義します。
エントリはファイル内で一意である必要があります。既存の監査クラスのマスクを使用しないでください。
この例では、監査イベントの小さなセットを保持するクラスを作成します。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 |
監査イベント ID です。
監査イベントの名前です。
通常、監査レコードの作成を発生させるシステムコールまたは実行可能プログラム。
コンマ区切りの監査クラスの一覧です。
この例では、既存の監査イベントを 例 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 |
この例では、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 別名を作成します |
監査サービスに注意が必要なとき、電子メール警告を受信するユーザーを決定します。 | |
4. (省略可能) 監査ポリシーを変更します |
サイトに必要な追加の監査データを定義します。 | |
6. 非大域ゾーンの監査を構成します |
非大域ゾーンで監査レコードが収集されるようにします | |
7. 監査を有効にします |
監査サービスを有効にします。 | |
perzone 監査が有効になっている場合は、非大域ゾーンで監査を有効にします。 | ||
8. (省略可能) 監査を無効にします |
監査サービスを無効にします。 | |
perzone 監査が有効になっている場合は、非大域ゾーンで監査を無効にします。 | ||
9. (省略可能) 監査構成変更を再読み込みします |
auditd デーモンの実行中に監査構成の変更をカーネルに読み込みます。 |
構成ファイルをサイト用に構成したあと、監査ファイルのディスク容量を設定する必要があります。監査サービスのほかの属性を設定して、サービスを有効にする必要もあります。この節では、構成の設定を変更したときに監査サービスを更新する手順も説明します。
非大域ゾーンがインストールされている場合、監査対象の大域ゾーンと同じようにゾーンを監査することができます。非大域ゾーンを別々に監査する場合は、非大域ゾーンの監査構成ファイルを変更することができます。監査構成ファイルをカスタマイズする方法については、「監査ファイルの構成 (作業マップ)」を参照してください。
次の手順では、監査ファイル用のパーティションの作成方法、および監査に対応するファイルシステムとディレクトリの作成方法について説明します。すでに空のパーティションがある場合、またはすでに空のファイルシステムをマウントしている場合は、必要に応じて手順を省略してください。
Primary Administrator 役割を引き受けるか、スーパーユーザーになります。
Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。
必要なディスク容量を決定します。
ホストごとに 200M バイト以上を割り当てます。ただし、必要な監査の量によりディスク容量要件が決まります。つまり、要件によっては、この数値を超えることもあります。予備ディレクトリのローカルパーティション領域も含めてください。
必要に応じて、監査パーティションを作成します。
この手順は、サーバーのインストール時に実行するのがもっとも簡単です。サーバーにマウントされていないディスク上にパーティションを作成することもできます。パーティションの作成方法については、『Solaris のシステム管理 (デバイスとファイルシステム)』の第 11 章「ディスクの管理 (手順)」を参照してください。
# newfs /dev/rdsk/cwtxdysz |
この例で、 /dev/rdsk/cwt xdysz は、パーティションの raw デバイス名です。
ローカルホストを監査する場合は、ローカルホスト用に予備の監査ディレクトリも作成します。
新しいパーティションのマウント先を作成します。
# mkdir /var/audit/server-name.n |
server-name.n は、サーバー名と各パーティションの識別番号を結合したものです。この識別番号は省略できますが、多数の監査ディレクトリを作成する場合はこの番号を使用すると便利です。
新しいパーティションを自動的にマウントするエントリを追加します。
/etc/vfstab ファイルに次のような行を追加します。
/dev/dsk/cwtxdysz /dev/rdsk/cwtxdysz /var/audit/server-name.n ufs 2 yes |
(省略可能) 各パーティションの最小空き容量のしきい値を削除します。
デフォルトの構成を使用した場合、ディレクトリの 80% がいっぱいになった時点で警告が生成されます。このため、パーティション上に空き容量を予約する必要はありません。
# tunefs -m 0 /var/audit/server-name.n |
新しい監査パーティションをマウントします。
# mount /var/audit/server-name.n |
新しいパーティションに監査ディレクトリを作成します。
# mkdir /var/audit/server-name.n/files |
マウント先と新しいディレクトリへのアクセス権を訂正します。
# chmod -R 750 /var/audit/server-name.n/files |
ファイルサーバー上で、ほかのホストからアクセスできるファイルシステムを定義します。
監査レコードを格納するために、ディスクファームをインストールすることがよく行われます。監査ディレクトリを複数のシステムで使用する場合は、そのディレクトリを NFS サービスを通して共有する必要があります。/etc/dfs/dfstab ファイルに対して、次のようなエントリをディレクトリごとに追加します。
share -F nfs /var/audit/server-name.n/files |
ファイルサーバー上で、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) のマニュアルページを参照してください。
監査サービスを実行するすべてのシステムには、利用できるファイルシステムがほかにない場合に使用するローカルファイルシステムが必要です。この例では、ファイルシステムが 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 |
この例では、新しいファイルシステムが、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 |
この例では、管理者は、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 |
audit_warn スクリプトは、audit_warn という電子メールエイリアスに対してメールを生成します。有効な電子メールアドレスにこのメールを送信するには、手順 2 で説明するオプションのいずれか 1 つに従います。
Primary Administrator 役割を引き受けるか、スーパーユーザーになります。
Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。
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 |
監査ポリシーを使用して、ローカルホストの監査レコードの特性を決定します。監査が有効な場合、/etc/security/audit_startup ファイルの内容により、監査ポリシーが決まります。
auditconfig コマンドを使用すると、現在の監査ポリシーオプションを検査および変更できます。また、監査ポリシーの変更内容を固定するために、audit_startup スクリプト内で auditconfig コマンドの監査ポリシーオプションを変更することも可能です。
Audit Control プロファイルを含む役割を引き受けるか、スーパーユーザーになります。
Audit Control プロファイルを含む役割を作成する方法およびユーザーに役割を割り当てる方法については、「RBAC の構成 (作業マップ)」を参照してください。
監査を有効にする前に、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 |
使用可能なポリシーオプションを表示します。
$ auditconfig -lspolicy |
perzone と ahlt ポリシーオプションは、大域ゾーンでのみ設定できます。
選択した監査ポリシーオプションを有効または無効にします。
# auditconfig -setpolicy prefixpolicy |
prefix 値 + を指定するとポリシーオプションが有効になります。prefix 値 - を指定するとポリシーオプションが無効になります。
有効または無効にするポリシーを選択します。
このポリシーの設定は、次回ブートするまで、または auditconfig setpolicy コマンドを使ってポリシーを変更するまで持続します。
各ポリシーオプションの詳細は、「監査ポリシーの決定」を参照してください。
この例では、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 |
この例では、auditd デーモンが実行中で、ahlt 監査ポリシーが設定されています。seq 監査ポリシーが現在のポリシーに追加されます。seq ポリシーは、sequence トークンをすべての監査レコードに追加します。監査レコードが破壊されたときやレコードが破棄されているとき、監査サービスのデバッグに役立ちます。
+ 接頭辞により、現在の監査ポリシーを seq に置き換えるのではなく、seq オプションが監査ポリシーに追加されます。auditconfig コマンドにより、ポリシーはコマンドが次に起動するまで、または次のブートまで有効になります。
$ auditconfig -setpolicy +seq $ auditconfig -getpolicy audit policies = ahlt,seq |
この例では、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 |
この例では、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 オプションをファイル内で指定する必要はありません。この設定は、監査レコードのセキュリティーよりも可用性が重要な場合に適しています。
この手順では、監査サービスをすべてのゾーンで有効にします。非大域ゾーンで監査デーモンを起動するには、例 30–20 を参照してください。
監査が安全に構成されると、監査が有効化されるまで、システムはシングルユーザーモードになります。マルチユーザーモードで監査を有効にすることもできます。
次の作業を完了してから、この手順をスーパーユーザーとして実行してください。
監査ファイルのカスタマイズ – 「監査ファイルの構成 (作業マップ)」
監査パーティションの設定 – 「監査ファイルのパーティションの作成方法」
監査警告メッセージの設定 – 「audit_warn 電子メールエイリアスの構成方法」
監査ポリシーの設定 – 「監査ポリシーを構成する方法」
監査が成功するには、ホスト名変換が正しく機能している必要があります。ネームサービスの hosts データベースが正しく構成され、機能している必要があります。
hosts データベースの構成については、nsswitch.conf(4) および netconfig(4) のマニュアルページを参照してください。詳細は、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』または『Solaris のシステム管理 (ネーミングとディレクトリサービス : NIS+ 編)』を参照してください。
監査サービスを有効にするスクリプトを実行します。
/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) のマニュアルページを参照してください。
システムを再起動します。
# reboot |
システムがマルチユーザーモードに移行すると、起動ファイル /etc/security/audit_startup によって auditd デーモンが自動的に動作します。
スクリプトのもう 1 つの働きは、デバイス割り当てを有効にすることです。デバイス割り当ての設定方法は、「デバイス割り当ての管理 (作業マップ)」を参照してください。
次の例では、監査が大域ゾーンで有効になり非大域ゾーンがブートされたあと、大域ゾーン管理者が perzone ポリシーを有効にします。非大域ゾーンのゾーン管理者は、ゾーンの監査ファイルを構成して、ゾーンで監査デーモンを起動します。
zone1# svcadm enable svc:/system/auditd |
ある時点で監査サービスが不要になった場合、この手順は監査が有効になる前のシステム状態にシステムを戻します。非大域ゾーンが監査されている場合は、その監査サービスも無効になります。
このコマンドによって、デバイス割り当ても無効になります。デバイス割り当てを可能にする場合は、このコマンドを実行しないでください。デバイス割り当てを保ったまま監査を無効にする方法については、例 30–21 を参照してください。
スーパーユーザーになり、システムをシングルユーザーモードにします。
% su Password: <Type root password> # init S |
詳細は、init(1M) のマニュアルページを参照してください。
スクリプトを実行して、監査を無効にします。
/etc/security ディレクトリに移動し、bsmunconv スクリプトを実行します。
# cd /etc/security # ./bsmunconv |
スクリプトのもう 1 つの働きは、デバイス割り当てを無効にすることです。
bsmunconv スクリプトの詳細は、bsmconv(1M) のマニュアルページを参照してください。
システムをマルチユーザーモードにします。
# init 6 |
この例では、監査サービスはレコードの収集を停止しますが、デバイス割り当ては引き続き機能します。audit_user ファイルのすべてのユーザーエントリと同様に、audit_control ファイルの flags、naflags、および plugin エントリからのすべての値が削除されます。
## audit_control file flags: naflags: ## audit_user file |
auditd デーモンが実行されますが、監査レコードは保持されません。
この例では、監査サービスが無効化された zone1 内で、監査サービスが実行を停止します。デバイス割り当ては引き続き機能します。perzone 監査ポリシーが設定されていない状態で、このコマンドが大域ゾーンで実行されると、大域ゾーンだけでなくすべてのゾーンで監査が無効になります。
zone1 # audit -t |
この手順では、デーモの実行中に監査構成ファイルを変更した場合に、auditd デーモンを再起動します。
Audit Control 権利プロファイルを含む役割を引き受けるか、あるいはスーパーユーザーになります。
Audit Control 権利プロファイルを含む役割の作成方法およびユーザーに役割を割り当てる方法については、「RBAC の構成 (作業マップ)」を参照してください。
適切なコマンドを選択します。
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 |
ユーザー ID です。
事前に選択された監査クラスです。
例については、「ユーザーの事前選択マスクを変更する方法」を参照してください。
稼動中のシステムで監査ポリシーを変更するには、例 30–17 を参照してください。
この例では、システムをシングルユーザーモードにしたあとで、マルチユーザーモードに戻します。システムがマルチユーザーモードになったとき、変更された構成ファイルがシステムに読み込まれます。
# init S # init 6 |
監査サービスは、ゾーン内での監査イベントも含め、システム全体を監査します。非大域ゾーンがインストールされたシステムでは、すべてのゾーンを同様に監査することも、ゾーンごとに監査を制御することもできます。背景情報については、「ゾーンを含むシステムでの監査」を参照してください。計画を立てるには、「ゾーン内の監査の計画方法」を参照してください。
この手順に従えば、すべてのゾーンを同様に監査できます。この方法を使えば、必要とされるコンピュータオーバーヘッドと管理リソースが最小になります。
大域ゾーンの監査を構成します。
「監査ファイルの構成 (作業マップ)」の作業を行います。
「監査サービスの構成と有効化 (作業マップ)」の作業を行います。ただし、次の点は例外になります。
perzone 監査ポリシーを有効にしないでください。
監査サービスを有効にしないでください。監査サービスの有効化は、非大域ゾーンの監査の構成が完了したあとで行います。
大域ゾーンからすべての非大域ゾーンに、監査構成ファイルをコピーします。
編集した次のファイルをすべてコピーします。 audit_class、audit_control、audit_event、audit_user。audit_startup と audit_warn はコピーしないでください。編集していないファイルをコピーする必要はありません。
2 つの選択肢があります。スーパーユーザーとして、ファイルをコピーすることも、ファイルをループバックマウントすることもできます。非大域ゾーンが動作している必要があります。
ファイルをコピーします。
構成ファイルをループバックマウントします。
大域ゾーンから、非大域ゾーンを停止します。
# zoneadm -z non-global-zone halt |
大域ゾーンで変更した監査構成ファイルごとに読み取り専用のループバックマウントを 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 |
変更を有効にするには、非大域ゾーンをブートします。
# zoneadm -z non-global-zone boot |
システムをリブートしても構いません。
その後、ある監査構成ファイルを大域ゾーンで変更した場合には、非大域ゾーンにループバックマウントされたファイルを更新するためにシステムをリブートします。
この例では、システム管理者が 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 |
ゾーンがリブートされると、監査構成ファイルはゾーン内で読み取り専用になります。
この手順に従えば、個々のゾーン管理者が自身のゾーン内で監査サービスを制御できます。ポリシーオプションの完全な一覧については、auditconfig(1M) のマニュアルページを参照してください。
大域ゾーンで監査を構成します。ただし、監査サービスは有効にしないでください。
「監査ファイルの構成 (作業マップ)」の作業を行います。
「監査サービスの構成と有効化 (作業マップ)」の作業を行います。ただし、次の点は例外になります。
perzone 監査ポリシーを追加してください。例については、例 30–18 を参照してください。
監査サービスを有効にしないでください。監査サービスの有効化は、非大域ゾーンの監査の構成が完了したあとで行います。
各非大域ゾーンで監査ファイルを構成します。
監査を無効にする予定の非大域ゾーンでは、この手順をスキップできます。監査を無効にするには、例 30–25 を参照してください。
「監査ファイルの構成 (作業マップ)」の作業を行います。
「監査サービスの構成と有効化 (作業マップ)」で説明した手順に従います。
システム全体の監査設定は構成しないでください。
具体的には、非大域ゾーンの audit_startup ファイルに perzone や ahlt ポリシーを追加しないでください。また、非大域ゾーンから bsmconv コマンドを実行しないでください。
使用するゾーンで監査を有効にします。
監査の構成後に大域ゾーンをリブートすると、使用するゾーンの監査が自動的に有効になります。
システムのリブート後に大域ゾーン管理者が perzone 監査ポリシーを有効にした場合、個々のゾーン管理者が監査の有効化を行う必要があります。詳細は、例 30–20 を参照してください。
大域ゾーンで監査サービスを有効にします。
手順については、「監査サービスを有効にする方法」を参照してください。
この例は、大域ゾーンで perzone 監査ポリシーが設定されている場合に正しく機能します。noaudit ゾーンのゾーン管理者が、そのゾーンの監査を無効にします。この管理者は、監査を無効にするつもりであったため、監査構成ファイルを編集していませんでした。
noauditzone # svcadm disable svc:/system/auditd |
次の作業マップは、監査レコードの選択、分析、および管理の手順を示しています。
作業 |
説明 |
参照先 |
---|---|---|
監査レコードの書式を表示します |
監査イベント用に収集される情報、および表示される情報の順番を表示します。 | |
監査レコードをマージします |
複数のマシンの監査ファイルを 1 つの監査トレールに結合します。 | |
調査するレコードを選択します |
調査対象の特定のイベントを選択します。 | |
監査レコードを表示します |
バイナリ監査レコードの表示を有効にします。 | |
正確でない名前を付けられた監査ファイルを整理します |
監査サービスにより意図的でなく開いたままにされた監査ファイルに最終タイムスタンプを設定します。 | |
監査トレールのオーバーフローを防止します |
監査ファイルシステムがいっぱいになることを防止します。 |
監査トレールを管理することによって、ネットワーク上のユーザーの動作を監視することができます。監査プロセスを行うと、大量のデータが生成される可能性があります。次の手順では、さまざまな監査データを使用して作業を行う方法について説明します。
必要な監査データを検索するスクリプトを作成するためには、監査イベント内のトークンの順番を知る必要があります。bsmrecord コマンドは、監査イベントの監査イベント番号、監査クラス、選択マスク、およびレコード書式を表示します。
すべての監査イベントレコードを HTML ファイルに出力します。
-a オプションを指定すると、すべての監査イベントレコードの書式が表示されます。-h オプションを指定すると、ブラウザで表示できる HTML 形式で一覧が出力されます。
% bsmrecord -a -h > audit.events.html |
ブラウザで *html ファイルを表示する場合は、ブラウザの検索ツールを使用して特定のレコードを検索します。
詳細は、bsmrecord(1M) のマニュアルページを参照してください。
この例では、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 … |
この例では、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 … |
すべての監査ディレクトリ内のすべての監査ファイルをマージすると、監査トレール全体の内容を分析できます。auditreduce コマンドを使用すると、入力ファイルのすべてのレコードが 1 つの出力ファイルにマージされます。マージが完了すると、入力ファイルを削除できます。出力ファイルが /etc/security/audit/server-name/files という名前のディレクトリに配置されている場合、完全パスを指定しなくても、auditreduce コマンドは出力ファイルを検索できます。
この手順は、バイナリ監査レコードだけに適用します。
Audit Review プロファイルを含む役割を引き受けるか、スーパーユーザーになります。
System Administrator 役割には、 Audit Review プロファイルが含まれます。Audit Review プロファイルを含む役割を別々に作成することもできます。役割を作成する方法と役割をユーザーに割り当てる方法については、「RBAC の構成 (作業マップ)」を参照してください。
マージされた監査ファイルを格納するディレクトリを作成します。
# mkdir audit-trail-directory |
ディレクトリへのアクセスを制限します。
# 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 .. |
監査トレール内の監査レコードをマージします。
ディレクトリを audit-trail-directory に変更して、指定した接尾辞を持つファイルに監査レコードをマージします。ローカルシステム上にある audit_control ファイルの dir 行に指定されているすべてのディレクトリがマージされます。
# cd audit-trail-directory # auditreduce -Uppercase-option -O suffix |
大文字オプションを auditreduce コマンドに指定すると、監査トレール内のファイルを操作できます。次の大文字オプションがあります。
監査トレール内のすべてのファイルを選択します。
完全ファイルだけを選択します。このオプションは、接尾辞 not_terminated を持つファイルを無視します。
特定の接尾辞を持つファイルを選択します。接尾辞はマシン名、またはサマリーファイルに指定した接尾辞です。
開始時刻と終了時刻を示す 14 文字のタイムスタンプおよび接尾辞 suffix が付いた監査ファイルを現在のディレクトリに作成します。
次の例では、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 |
auditreduce で - D オプションを指定すると、監査ファイルをほかの場所にコピーしたときにその監査ファイルを削除します。次の例では、あるシステムの完全監査ファイルを、あとで調べるためにサマリーディレクトリにコピーします。
$ cd /var/audit/audit_summary.dir $ auditreduce -C -O daily_example1 -D example1 $ ls *example1 20030827183214.20030827214217.daily_example1 |
このコマンドが正常に完了すると、*daily_example1 ファイルへの入力となった example1 システムの監査ファイルが削除されます。
調べる監査レコードをフィルタリングすることができます。フィルタリングオプションの一覧については、auditreduce(1M) のマニュアルページを参照してください。
Audit Review プロファイルを含む役割を引き受けるか、スーパーユーザーになります。
System Administrator 役割には、 Audit Review プロファイルが含まれます。Audit Review プロファイルを含む役割を別々に作成することもできます。役割を作成する方法と役割をユーザーに割り当てる方法については、「RBAC の構成 (作業マップ)」を参照してください。
監査トレールまたは指定した監査ファイルから必要なレコードを選択します。
auditreduce -lowercase-option argument [optional-file] |
小文字オプションが必要とする特定の引数。たとえば、-c オプションは、ua などの監査クラスの argument を必要とします。
特定の日付のイベントをすべて選択します。argument の日付の形式は、yyyymmdd です。ほかの日付オプション -b と -a は、特定の日付の前と後のイベントを選択します。
特定のユーザーのイベント属性をすべて選択します。argument はユーザー名です。もう 1 つのユーザーオプション -e は、実効ユーザー ID のイベント属性をすべて選択します。
事前選択された監査クラス内のイベントをすべて選択します。argument は監査クラス名です。
特定の監査イベントのインスタンスをすべて選択します。argument は監査イベントです。
監査ファイルの名前です。
auditreduce コマンドを使用すると、入力ファイルの結合時に不要なレコードを除外できます。たとえば、auditreduce コマンドを使用して、1 か月以上経過した監査ファイルから、ログインレコードとログアウトレコード以外のレコードを削除することができます。監査トレール全体が必要になった場合は、バックアップメディアから監査トレールを復元します。
# cd /var/audit/audit_summary.dir # auditreduce -O lo.summary -b 20030827 -c lo; compress *lo.summary |
この例では、監査トレール内の、ユーザーに起因しない監査イベントのすべてのレコードが、1 つのファイルに収集されます。
$ whoami sysadmin $ cd /var/audit/audit_summary.dir $ auditreduce -c na -O nasumm $ ls *nasumm 20030827183214.20030827215318.nasumm |
マージされた nasumm 監査ファイルは、na レコードの開始時刻と終了時刻のタイムスタンプが記録されます。
監査ファイルを手動で選択して、指定された一連のファイルだけを検索できます。たとえば、前の例の *nasumm ファイルをさらに処理して、システムブートイベントを検索できます。これを行うには、auditreduce コマンドの最後の引数にファイル名を指定します。
$ auditreduce -m 113 -O systemboot 20030827183214.20030827215318.nasumm 20030827183214.20030827183214.systemboot |
20030827183214.20030827183214.systemboot ファイルは、システムブート監査イベントだけを含みます。
この例では、特定のユーザー名を含む監査トレール内のレコードがマージされます。-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 |
この例では、特定の日付におけるログイン、ログアウトのメッセージが監査トレールから選択されます。これらのメッセージは対象ファイルにマージされます。対象ファイルは、通常の監査ルートディレクトリ以外のディレクトリに書き込まれます。
# 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 |
praudit コマンドを使用すると、バイナリ監査ファイルの内容を表示できます。auditreduce コマンドから出力をパイプしたり、特定の監査ファイルを読み取ったりできます。さらに処理する場合に -x オプションが役立ちます。
Audit Review プロファイルを含む役割を引き受けるか、スーパーユーザーになります。
System Administrator 役割には、 Audit Review プロファイルが含まれます。Audit Review プロファイルを含む役割を別々に作成することもできます。役割を作成する方法と役割をユーザーに割り当てる方法については、「RBAC の構成 (作業マップ)」を参照してください。
次の 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> |
lp コマンドにパイプすると、監査トレール全体の出力がプリンタに送られます。プリンタへのアクセスを制限してください。
# auditreduce | praudit | lp -d example.protected.printer |
この例では、サマリーログインファイルを端末ウィンドウで調べます。
# cd /var/audit/audit_summary.dir/logins # praudit 20030827183936.20030827232326.logins | more |
この例では、監査レコードを XML 形式に変換します。
# praudit -x 20030827183214.20030827215318.logins > 20030827.logins.xml |
*xml ファイルはブラウザを使って表示できます。スクリプトを使えば、XML ファイルの内容を操作して目的の情報を抽出できます。
次のようなメッセージは、praudit コマンドを使用するために必要な権限がないことを示しています。
praudit: Can't assign 20090408164827.20090408171614.example1 to stdin.
監査ファイルが開いている状態で監査デーモンが終了することがあります。また、サーバーがアクセス不能になって、強制的に別のサーバーに切り替わってしまうことがあります。このような場合、その監査ファイルは監査レコードとして使用されなくなりますが、監査ファイルの終了タイムスタンプとして文字列 not_terminated が付いたままになります。auditreduce -O コマンドを使用して、ファイルに正しいタイムスタンプを付けます。
監査ファイル上の not_terminated 文字列が付いたファイルを作成順に一覧表示します。
# ls -R1t audit-directory*/files/* | grep not_terminated |
サブディレクトリ内のファイルを一覧表示します。
最新のファイルからもっとも古いファイルの順で一覧表示します。
1 列でファイルを一覧表示します。
古い not_terminated ファイルを整理します。
古いファイルの名前を auditreduce -O コマンドに指定します。
# auditreduce -O system-name old-not-terminated-file |
古い not_terminated ファイルを削除します。
# rm system-name old-not-terminated-file |
次の例では、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 ファイル内にある最初の監査イベントの時間を反映します。終了タイムスタンプは、そのファイル内にある最後の監査ファイルの時間を反映します。
セキュリティーポリシーの関係ですべての監査データを保存する必要がある場合は、次の手順に従います。
監査ファイルを定期的に保存するスケジュールを設定します。
ファイルをオフラインのメディアにバックアップして、監査ファイルを保管します。これらのファイルを保存ファイルシステムに移動することもできます。
syslog ユーティリティーを使用してテキスト監査ログを収集している場合、テキストログを保管します。詳細は、logadm(1M) のマニュアルページを参照してください。
補助情報を保存し保管します。
監査レコードの解釈に必要な情報を、監査トレールとともに格納します。
保管した監査ファイルの記録をとります。
保存したメディアを適切な方法で保管します。
サマリーファイルを作成して、格納する監査データのボリュームを削減します。
監査トレールからサマリーファイルを抽出するには、auditreduce コマンドのオプションを使用します。サマリーファイルには、指定された種類の監査イベントのレコードだけが含まれます。サマリーファイルを抽出するには、例 30–30 および例 30–34 を参照してください。
この節では、さまざまな Solaris 監査のエラーメッセージ、設定、ほかのツールによる監査について説明します。ここで示す手順は、使用中のシステムで必要な監査イベントを記録する際に役立ちます。
次の作業マップでは、Solaris 監査のトラブルシューティングの手順を示します。
問題 |
解決方法 |
説明 |
---|---|---|
監査を構成したときに監査ファイルが作成されないのはなぜでしょうか。 |
監査デーモンと監査構成ファイルのトラブルシューティングを行います。 | |
収集される監査情報を減らすには、どうすればよいでしょうか。 |
監査が必要なイベントについてのみ、監査を行います。 | |
システムでのユーザーの動作をすべて監査するには、どうすればよいでしょうか。 |
すべてのコマンドについて 1 人または複数のユーザーを監査します。 | |
記録される監査イベントを変更して、その変更内容を既存のセッションに適用するには、どうすればよいでしょうか。 |
ユーザーの事前選択マスクを更新します。 | |
変更内容を特定のファイルに格納するには、どうすればよいでしょうか。 |
ファイルの変更を監査し、auditreduce コマンドを使用して特定のファイルを検索します。 | |
監査ファイルのサイズを減らすには、どうすればよいでしょうか。 |
バイナリ監査ファイルのサイズを制限します。 | |
audit_event ファイルから監査イベントを削除するには、どうすればよいでしょうか。 |
audit_event ファイルを更新します。 | |
Solaris システムへのすべてのログインを監査するには、どうすればよいでしょうか。 |
システムからのログインを監査します。 | |
FTP 転送で監査レコードが保持されないのはなぜでしょうか。 |
ログを生成するユーティリティーに適切な監査ツールを使用します。 |
監査が有効になっているはずだが、1 次監査ディレクトリに監査レコードがない場合、次の手順を試してください。
ネームサービスの hosts データベースが正しく構成され、機能しています。ネームサービスの問題をデバッグする場合は、次の情報を参照してください。
nsswitch.conf(4) のマニュアルページ
監査が実行中であるかどうかを判定します。
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 |
監査サービスが実行中でない場合、有効にします。手順については、「監査サービスを有効にする方法」を参照してください。
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 というメッセージは、ファイルの構文が正しいことを示しています。
audit_control ファイルについて、flags キーワードおよび naflags キーワードの値が有効であることを確認します。
# grep flags /etc/security/audit_control flags:lo naflags:na,lp |
audit_control ファイルに無効な値が含まれている場合、有効な値を指定します。前述の例で、lp は無効なクラスです。
audit_user ファイルについて、すべてのユーザーの値が有効であることを確認します。
# tail audit_user ... # User Level Audit User File # # File Format # # username:always:never # root:lo:no admin:lp:no |
audit_user ファイルに無効な値が含まれている場合、有効な値を指定します。前述の例で、lp は無効なクラスです。
カスタマイズ監査クラスを作成した場合、そのクラスにイベントが割り当て済みであることを確認します。
たとえば、次の audit_control ファイルには、Oracle Solaris ソフトウェアが配信していないクラスが含まれています。
# grep flags /etc/security/audit_control flags:lo,pf naflags:na,lo |
pf クラスの作成については、「監査クラスの追加方法」を参照してください。
クラスが audit_class ファイルで定義されていることを確認します。
監査クラスマスクは一意である必要があります。
# grep pf /etc/security/audit_class 0x10000000:pf:profile command |
クラスが定義されていない場合、定義します。そうでない場合、audit_control ファイルおよび audit_user ファイルからクラスを削除します。
イベントがクラスに割り当てられていることを確認します。
# grep pf /etc/security/audit_event 6180:AUE_prof_cmd:profile command:ua,as,pf |
イベントがクラスに割り当てられていない場合、適切なイベントをこのクラスに割り当てます。
前述の手順で問題が見つからなかった場合、システムログファイル /var/adm/messages および /var/log/syslog を確認します。
問題を検出して修正します。
次に、監査サービスが実行中である場合、再起動します。
# audit -s |
監査サービスが実行中でない場合、有効にします。
手順については、「監査サービスを有効にする方法」を参照してください。
使用しているシステムで監査する必要のあるイベントを決定した後、次に示す方法で管理可能な監査ファイルを作成します。
デフォルトの監査ポリシーを使用します。
具体的には、監査証跡へのイベントと監査トークンの追加を回避します。次のポリシーは、監査証跡のサイズに影響します。
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 |
audit_syslog.so プラグインを使用して、一部の監査イベントを syslog に送信します。
この方法は、syslog ログに送信する監査イベントのバイナリレコードを保持する必要がない場合にのみ有効です。auditreduce コマンドを使用すると、レコードからバイナリファイルを取り除くことができるため、バイナリファイルのサイズが削減されます。
特定のユーザーおよび役割について、監査イベントに audit_user ファイルを使用します。
audit_control ファイルの監査クラスの数を減らすことにより、すべてのユーザーの監査の量を削減します。audit_user ファイルで、特定のユーザーおよび役割の監査クラスを追加します。
独自のカスタマイズ監査クラスを作成します。
使用しているシステムで監査クラスを作成できます。このクラスに、監視が必要な監査イベントをすべて指定します。手順については、「監査クラスの追加方法」を参照してください。
既存の監査クラスの割り当てを変更する場合、新しいバージョンの Solaris OS にアップグレードするときに変更内容が失われることがあります。インストールログを慎重に確認してください。
サイトのセキュリティーポリシーの一環として、root ユーザーまたは管理役割により実行されるすべてのコマンドについて監査レコードが必要になることがあります。また、サイトによっては、ユーザーが実行するすべてのコマンドの監査レコードを必要とする場合もあります。
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 |
コマンドの引数を記録するには、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 |
コマンドの実行環境を記録するには、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 |
引数とコマンド環境を記録するには、両方のポリシーを設定します。
## 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 |
/etc/passwd や /etc/default ディレクトリ内のファイルなど、限られた数のファイルに対するファイル書き込みを記録する場合、auditreduce コマンドを使用してファイルを見つけます。
fw クラスを監査します。
audit_user ファイルにクラスを追加すると、audit_control ファイルにクラスを追加する場合よりも、生成されるレコードが少なくなります。
特定のファイルの監査レコードを検索するには、auditreduce コマンドを使用します。
# /usr/sbin/auditreduce -o file=/etc/passwd,/etc/default -O filechg |
auditreduce コマンドは、file 引数のすべてのインスタンスについて監査証跡を検索します。このコマンドにより、接尾辞 filechg を持つバイナリファイルが作成されます。このファイルには、必要なファイルのパス名を含むすべてのレコードが含まれています。-o file=pathname オプションの構文については、auditreduce(1M) のマニュアルページを参照してください。
filechg ファイルを読み取るには、praudit コマンドを使用します。
# /usr/sbin/praudit *filechg |
audit_control ファイルまたは ファイルを変更する場合、すでにログインしているユーザーの事前選択マスクは変更されません。事前選択マスクを強制的に変更する必要があります。
監査を有効にしてユーザーがログインしてから、audit_control ファイルの flags または naflags の値を変更しました。新しく選択された監査クラスの監査対象とするために、すでにログインしているユーザーが必要です。
すでにログインしているユーザーの事前選択マスクを更新します。
2 つの選択肢があります。既存のセッションを終了するか、auditconfig コマンドを使用してユーザーの事前選択マスクを更新します。
ユーザーの既存のセッションを終了します。
ユーザーがログアウトしてふたたびログインするか、管理者がアクティブなセッションを手動で終了できます。新しいセッションでは、新しい事前選択マスクが継承されます。ただし、ユーザーの終了が実用的でない場合もあります。
各ユーザーの事前選択マスクを動的に変更します。
audit_control ファイルの flags 属性が lo から lo,ex に変更されたものとします。
ユーザーの監査 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 つの方法のいずれかを使用します。
事前選択マスクが変更されたことを確認します。
# 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 |
メンテナンスのために、監査イベントが監査されないようにする必要が生じることがあります。
イベントのクラスを 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 コマンドがバイナリ監査ファイルを読み取るときに使用します。また、このファイルに一覧表示されたイベントが、保管された監査ファイルに含まれることがあります。
ユーザーの事前選択マスクを更新するには、「ユーザーの事前選択マスクを変更する方法」の手順に従います。
バイナリ監査ファイルは無制限に増大します。保管や検索を容易にするために、サイズの制限が必要となることがあります。元のファイルから小さいバイナリファイルを作成することもできます。
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 |
auditreduce コマンドを使用して、レコードを選択し、これらのレコードを詳細分析用にファイルに書き込みます。
auditreduce -lowercase オプションは特定のレコードを検索します。
auditreduce -Uppercase オプションは選択したレコードをファイルに書き込みます。詳細は、auditreduce(1M) のマニュアルページを参照してください。
Solaris OS では、ソースに関係なく、すべてのログインを監査できます。
ユーザーに起因するイベントおよび起因しないイベントの lo クラスを監査します。
このクラスは、ログイン、ログアウト、および画面ロックを監査します。
## audit_control file flags:lo naflags:lo ... |
ssh ログインを監査するには、使用している Solaris システムで Solaris ssh デーモンを実行する必要があります。このデーモンは、Solaris 監査用に変更されます。詳細は、「Solaris Secure Shell と OpenSSH プロジェクト」を参照してください。
FTP サービスは、ファイル転送のログを作成します。SSH プロトコルで実行する SFTP サービスは、Solaris 監査で監査できます。Solaris 監査では、両方のサービスへのログインを監査できます。
FTP サービスのファイル転送とコマンドのログを作成するには、ftpaccess(4) のマニュアルページを参照してください。
使用可能なログ作成オプションについては、「ログ作成機能」に関する節を参照してください。特に、有用なログを作成できるのは、log commands オプションおよび log transfers オプションです。
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 |
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 |