test

Trusted Solaris の監査管理

第 4 章 障害発生時の対策

監査異常が発生した場合に迅速な処置をとることも監査作業の 1 つです。監査結果を分析する担当者とシステム管理者は、主に次のような作業に取り組むことになります。

監査トレールのオーバーフローの予防

ワークステーションの監査ファイルシステムがいっぱいになると、audit_warn スクリプトが起動して、すべての監査ファイルシステムで制限値を越えたことを伝えるメッセージがコンソールに送られ、エイリアスには電子メールが送られます。このとき、デフォルトでは、監査デーモンはループに入り、ディスク領域が解放されるまで休眠して容量の確認を行います。

サイトのセキュリティポリシーで別の解決策が定められる場合もあります。他の解決策としては、オーバーフローの予防やドロップされた監査レコードのカウントなどがあります。

セキュリティポリシーで、オーバーフローを予防して監査データを消失させないよう定められている場合には、「監査トレールのオーバーフローを計画的に予防する方法」を参照してください。

注 -

監査システムの構成によっては、カーネル監査バッファーがオーバーフローした場合に監査レコードを破棄することができます。このような構成は評価済みのシステム構成ではありません。監査バッファーがオーバーフローした場合は、システムを中断させるようにしてください。

セキュリティポリシーで、監査トレールがオーバーフローしたときに、監査データの一部を失ってもシステムの活動は停止しないよう定められていることがあります。この場合、auditconfig ポリシーの設定によってレコードをカウントしたりしなかったりできます。レコードをカウントするかどうかの設定方法については、「監査ファイルシステムのオーバーフローを処理する方法」を参照してください。

セキュリティポリシーで、ファイルシステムのオーバーフローの影響を受けるワークステーションを停止して処理することが求められている場合には、ワークステーションをシングルユーザーモードに移行させる必要があります。ただし、これは安全な方法ではありません。手順については、「監査ファイルシステムのオーバーフローを処理する方法」を参照してください。

監査トレールのオーバーフローを計画的に予防する方法

セキュリティポリシーですべての監査データを保存するよう定められている場合には、次の操作を行います。

  1. 定期的に監査ファイルを保存するスケジュールを立て、全監査ファイルシステムから、保存処理の済んだ監査ファイルを削除します。

    システムの制限値に達する前に、システムからファイルが必ず削除されるようにスケジュールを組んでください。修正した audit_warn スクリプトなどのスクリプトを使って、監査ファイルを別のディスクへ自動で移して保存することができます。

  2. テープにバックアップをとったり、アーカイブファイルシステムへ移動したりして、監査ファイルを手動で保存します。

  3. 監査レコードの変換に必要なコンテキスト情報を監査トレールと一緒に保存します。

    ユーザーとパスワードの現行リスト、ワークステーションのディレクトリリスト、その他の揮発性の情報を保存してください。

  4. どの監査ファイルをオフラインに移動したかを示すレコードを保管します。

  5. 記録テープを適切に保存します。

  6. サマリファイルを作成して、保存する監査データの量を減らします。

    auditreduce コマンドに各種オプションを付けると、監査トレールから、指定した特定種類の監査イベントのレコードだけを含むサマリファイルを抽出することができます。たとえば、すべてのログインとログアウトの監査レコードだけを含むサマリファイルなどがあります。第 3 章「監査トレールの管理と監査結果の分析」を参照してください。

監査ファイルシステムのオーバーフローを処理する方法

    監査ファイルシステムがいっぱいになった場合に監査レコードをカウントし続けるように、ラベル admin_low でセキュリティ管理者になって、監査ポリシーを設定します。


    $ auditconfig -setpolicy +cnt

注意 - 注意 -

評価済みの構成で監査を実行する場合、+cnt ポリシーは設定できません。

    監査ファイルシステムがいっぱいになった場合にワークステーションを停止するように、監査ポリシーを設定します。


    $ auditconfig -setpolicy +ahlt

上記のポリシーの 1 つを常時設定するためには、audit_startup(1M) スクリプトにコマンドを入力します。スクリプトの編集方法については、「常時監査ポリシーを設定する方法」を参照してください。

注 -

分散システムでは、すべてのワークステーションに同じ監査ポリシーを適用します。

not_terminated と表示された監査ファイルの処分

監査ファイルを開いた状態で監査デーモンが終了したり、ワークステーションが、アクセスできなくなったサーバーから強制的に別のサーバーに接続変更されることがあると、もう監査レコードの記録を行っていないにもかかわらず、監査ファイル名の終了時刻の部分が文字列 not_terminated のままになります。

auditreduce(1M) コマンドでは、not_terminated と表示されたファイルでも処理されますが、このようなファイルの末尾には不完全なレコードが含まれていることがあるので、後日、処理にエラーが発生する恐れがあります。エラーを防ぐためには、auditreduce の -O オプションで不完全なファイルを処分します。このコマンドによって新しいファイルが作成され、古いファイルにあったレコードはすべてそこへ入れられて、ファイル名には正しい終了時刻が付けられます。なお、この操作を行うと、各監査ファイルの冒頭に維持されていたそれまでのファイルポインタが失われます。

終了していない (not_terminated) 監査ファイルを処分する方法

  1. ラベル admin_high でシステム管理者になって、 /etc/security/audit_data ファイルを確認して、監査デーモンの現在のプロセス番号を判断します。

    そのプロセスが実行中の場合や audit_data(4) の中のファイル名が問題のファイルと同じ名前の場合には、ファイルを処分しないでください。

  2. auditreduce コマンドに -O (大文字の O) オプションを付けて実行します。

  3. -O の引数として、ワークステーション名と不完全なファイル名を指定します。もとのレコードを削除するためには、-D オプションを使います。


    $ auditreduce -O workstation 19970413120429.not_terminated.workstation

    すると、正しい名前の新しい監査ファイルが作成され、他の監査ファイルのポインタが再配置され、すべてのレコードが新しいファイルにコピーされます。終了時刻はコマンドが実行された時刻です。また、正しい接尾辞は workstation で明確に規定します。

  4. -D オプションを使わなかった場合は、新しいファイルにもとのファイルのレコードが入っていることを確認してから、もとのファイルを削除します。 


    $ ls -l 19970413120429*.workstation		

$ rm 19970413120429.not_terminated*

sequence トークンを使用したデバッグ

複数のワークステーションのレコードを併合して作成した監査トレールで、レコードが順不同で並べられている場合には、sequence トークンを使って監査トレールの不一致をデバッグすることができます。sequence トークンは、デフォルトでは記録されないので、セキュリティ管理者が監査ポリシーに追加します。監査ポリシーは、その監査トレールにかかわっている全ワークステーションで必ず同じ設定にしてください。

監査トレールのデバッグが終了したら、セキュリティ管理者はトークンを削除します。

sequence トークンを監査レコードに追加する方法

  1. seq 監査ポリシーを動的に追加するためには、ラベル admin_low でセキュリティ管理者になって、コマンド行に次のように入力します。


    $ auditconfig -setpolicy +seq
$ auditconfig -getpolicy		
slabel, seq

  2. seq 監査ポリシーを常置するためには、ラベル admin_low でセキュリティ管理者になって、audit_startup ファイルに次のように入力します。

    #!/bin/sh
auditconfig -setpolicy +slabel, seq

sequence トークンを監査レコードに含めない方法

  1. seq 監査ポリシーを動的に削除するためには、ラベル admin_low でセキュリティ管理者になって、コマンド行に次のように入力します。


    $ auditconfig -setpolicy -seq
$ auditconfig -getpolicy
slabel

  2. ラベル admin_low でセキュリティ管理者になって、seq 監査ポリシーを audit_startup ファイルから削除します。

    #!/bin/sh

auditconfig -setpolicy +slabel

監査デーモンを手動で起動する

分散システム上で監査デーモンを失った場合には、監査デーモンを起動しなおします。

    セキュリティ管理者になって、監査管理サーバーの admin_high シェルで、 /usr/sbin/auditd コマンドを実行します。次に監査サーバー、最後に監査クライアントの admin_high シェルで実行します。


    $ /usr/sbin/auditd

admin_high シェルの作成方法については、「Admin_High ワークスペースを作成する方法」を参照してください。

ワークステーションを個別に監査する

1 台のワークステーションで変更した監査構成ファイルをネットワーク上のその他のワークステーションにコピーできなかった場合には、各ワークステーションを個別に監査します。

  1. ラベル admin_low でセキュリティ管理者になって、監査構成ファイルを中央のロケーションからすべてのワークステーションへコピーします。

    ここで、「監査構成ファイルをネットワーク上の各ワークステーションに配布する方法」の手順に従います。

  2. ユーザーアクションによるイベントとユーザーアクションによらないイベントの監査クラスとの対応関係がカーネルキャッシュと一致していることを確認します。

ユーザーアクションによる監査イベントと監査クラスの対応関係を設定する方法

  1. ラベル admin_low でセキュリティ管理者になって、まずカーネルの事前選択マスクが audit_control(4) ファイルの flags: フィールドのクラスの対応関係に一致していることを確認します。そのためには次のコマンドを実行します。


    $ auditconfig -chkconf

  2. 実行時のクラスの対応関係がカーネルキャッシュと異なる場合には、次のコマンドを実行します。


    $ auditconfig -conf

ユーザーアクションを原因としない監査イベントと監査クラスの対応関係を設定する方法

  1. まずラベル admin_low でセキュリティ管理者になって、カーネルの事前選択マスクが audit_control(4) ファイルの naflags: フィールドのユーザーアクションを原因としないイベントに一致していることを確認します。そのためには次のコマンドを実行します。


    $ auditconfig -getkmask

    イベントが異なる場合には次のコマンドを実行します。


    $ auditconfig -setkmaskac

失敗したログインの検知

    ラベル admin_high でシステム管理者になって、auditreduce(1M) に付けるオプション -c の値として -lo を入力します。


    $ auditreduce -c -lo -O /usr/audit_summary/logins_failed

    値 -lo は、失敗した (-) ログイン (監査クラス lo) を示す監査フラグです。このコマンドを実行すると、/usr/audit_summary ディレクトリにバイナリファイルが 1 つ作成され、分散システム上の失敗したログイン行為がすべて記載されます。/usr/audit_summary ディレクトリには admin_high のラベルが付きます。

    /usr/audit_summary/19970313120429.19970613120415.logins_failed
    注 -

    このコマンドは、セキュリティ管理者が、ワークステーションや分散システム、またはユーザーのログイン失敗を事前選択している場合に限り有効です。