Print-friendly Version

BSM によって作成された監査ファイルの保護

はじめに

Solaris オペレーティングシステムとともに配布されている基本セキュリティモジュール (BSM) を使用すると、プロセスによって実行されたさまざまな処理を記録できます。 しかし、BSM システムには大きな課題があります。 それは、root 権限が乗っ取られた場合にも、監査ファイルを改ざんから保護することです。 システムによってすでに記録されたデータの喪失を防ぐことのできる方法で情報を記録する必要があります。

この記事では、こうした問題への対処法をいくつか検証し、そのうちの 1 つ、SSH (Secure Shell) と RBAC (Role Based Access Control) を使用する方法を詳しく解説します。 BSM の設定を完全に説明することは、この記事の範囲を超えています。 代わりに、この記事では上記の問題に焦点を絞り、ユーザーのニーズに合わせてカスタマイズできる最低限の機能の設定だけを紹介し、問題解決のためのスクリプトと設定手順に関連する情報だけを記載します。

基本セキュリティモジュールの使い方

BSM を有効にする

デフォルトでは、BSM は無効になり、監査は実行されません。 監査を有効にするには、システムに付属している bsmconv スクリプトを実行してから、システムを起動し直す必要があります。

監査プロセスを設定する

システムを起動し直すと、c2audit カーネルモジュールがロードされ、auditd デーモンが起動します。 auditd は自分専用の構成ファイル /etc/security/audit_control を読み込み、情報の収集方法 (記録する情報の量、データストアの場所など) を制御します。

さらに、auditconfig コマンドを使うと、その他の各種の機能 (情報を記録するスペースが足りないときにどうするか、監査レコードに exec(2) システムコールのパラメータ引数を記録するかなど) を表示および設定できます。

auditconfig で行なった変更を永久的なものにするには、起動時に /etc/init.d/audit から呼び出される /etc/security/audit_startup スクリプトに、auditconfig の呼び出しを組み込む必要があります。

記録された情報を参照する

情報の記録先のファイルには、明確な命名規則が適用されます。現在記録先として使われているファイルの名前は <yyyymmddhhmmss>.not_terminated.<ホスト名> になり、すでに閉じられ、これ以上は情報が記録されない古いファイルの名前は <yyyymmddhhmmss>.<yyyymmddhhmmss>.<ホスト名> になります。これらのファイル名の最初の日付は、書き込みのためにいつファイルが初めて開かれたかを示します。2 番目の日付がある場合、その日付はファイルがいつ閉じられたかを示しています。これらのタイムスタンプは GMT で表現されます。

これらのファイルには、文書化された形式で表現されたバイナリレコードが含まれています。特定のレコードの選択と出力を行うには、それぞれ auditreduce コマンドと praudit コマンドを使います。

問題

監査には 2 つの目的があります。それは、不適切なユーザーアクティビティの防止と追跡です。異常なユーザーアクティビティを観察し、ダメージが起きる前に必要な対処 を行えば、そのアクティビティを阻止できます。阻止するには遅すぎたとしても、ログを分析すれば、何が起きたかを解明できます。

ただし、セキュリティの潜在的な侵害があった後でデータを分析する場合、問題があります。攻撃者が root 権限を奪った場合、その攻撃者には auditd デーモンのすべての権限、すなわち監査ファイルの内容を変更する権限までもが与えられてしまいます。したがって、標準的な BSM の設定では、攻撃者が root ユーザーになってしまえば、情報の改ざんを阻止する手だては何もなく、攻撃の痕跡を消されてしまう可能性があります。

考えられる対処法

基本的に、監視先のシステムにある audit デーモンだけが監査ファイルにデータを追加できるようにすれば、問題を解決できます。このようにすれば、すでに書き込まれた情報を変更したり、書き込む前の状態に戻すことはできません。

この記事では、そのためのさまざまな方法を説明します。

auditd によって書き込まれた監査データを、書き込まれた直後にライトワンスメディア (光ディスク、用紙など) に自動的にコピーできます。そのためには、tail(1) や praudit(1m) などを使用できます。セキュリティの観点から見ると、この記事で紹介している手法の中で、このソリューションがもっとも優れています。データをメディアに書き込んでしまえば、それらのメディアに物理的に近付けない限り、攻撃者は内容を変更できません。

ただし、この手法は、実現するには難しすぎたり、コストがかかりすぎる場合があります。データの分析と保管が複雑になる可能性もあります。

2. BSM の audit_syslog(5) プラグインを使用する

最新の Solaris 10 OS では、audit_syslog プラグインが提供されます。 このプラグインを使用すると、例えば tail(1) と praudit(1m) を使って、auditd に監査データを syslog へ送出させることができます。

この手法の主な利点は使いやすいことです。 すでに syslog サーバーは設定されているので、audit_control ファイルを修正し、その後で監査対象のシステムで syslog.conf を編集し、機能監査データと優先順位の通知を付けたメッセージを syslog セキュアリモートサーバーに転送させるだけで済みます。

前提条件として、リモート syslog サーバーのセキュリティレベルが監査対象のものより高いか、少なくとも監査対象のシステムで不正な人物が root ユーザーになったとしても、その人物が syslog サーバーでも root ユーザーになることが困難でなければなりません。この前提条件が満たされていれば、syslog だけがメッセージの受け取りと書き込みを行うことができ、syslog にメッセージを消去させることはできません。

ただし、この手法にはいくつかの留意すべき点があります。

• Solaris 10 が必要です。
  監査対象のシステムで Solaris 10 OS を実行する必要があります。
• syslog と監査トレールの形式の問題
• syslog では監査データの処理は想定されていません。 syslog にはテキスト形式でデータを渡す必要があり、auditreduce や praudit では syslog からのデータを受け取れません。 そのため、ユーザー独自のスクリプトを作成する必要があります。
• syslog のログエントリは 1024 バイト以内に制限されています。 これよりも長い監査エントリは切り詰められます。 syslog プラグインでは、できるだけ多くの情報を残すように処理が行われますが、切り詰めが発生することが問題になる場合があります。

3. ゾーンを使用する

Solaris 10 OS のゾーン機能を使用すると、対処が実に簡単になります。

グローバルゾーンでは最小限必要な数のサービスだけを実行し、それ以外のサービスはすべて非グローバルゾーンに組み込むことができます。

まず、ゾーンをお互いに分離します。非グローバルゾーンとグローバルゾーンとの間のトラフィックは認められません。 次に、グローバルゾーンの中から、これらのゾーンを監査します。誰かが非グローバルゾーンで root ユーザーになったとしても、そのユーザーはグローバルゾーンとの間にある障壁を越えられません。

この手法は、設定が簡単でセキュリティに優れています。別のリモートシステムも必要ありません。

この手法に欠点があるとすれば以下の点くらいでしょう。

• 上記の手法と同様に、Solaris 10 が必要
  通常、最新のバージョンがリリースされたからといって、すぐにアップグレードする余裕はないかもしれません。
• ゾーンの設定が必要
  監査の設定に加えて、ゾーンを設定し、ユーザーのすべてのサービスを非グローバルゾーンで実行する必要があります。 ゾーンの構成で問題が起こることもあるかもしれません。

4. SSH (Secure Shell) と RBAC (Role Based Access Control) を使用する

この記事では、この手法について詳しく説明します。

この手法では、2 番目の手法と同様にリモートセキュアシステムが必要です。このリモートシステムで、非常に特殊なスクリプトの実行だけができるアカウントを作成し、このス クリプトで記録を実行します。このアカウントでは、たとえ非特権ユーザーであっても、これ以外の権限は一切許可しません。このアカウントを作成するため、 RBAC を使用します。

auditd によって書き込まれた最新の監査データを、tail を使ってそのまま取得するスクリプトを作成します。鍵認証の機能がある ssh を使用して、(上記の特殊な RBAC として) リモートサーバーに非対話的にログインし、この記録用のスクリプトを実行します。

この方式により、auditd によって書き込まれたデータを、ただちに記録できます。監査対象のシステムで、誰かが root アクセスを不正に奪ったとしても、その人物はリモートシステム上のファイルにデータを書き込むことしかできません。古いデータを変更することはできません。

上記の手法ほど設定は簡単ではありませんが、この手法は Solaris 8 OS 以降であれば使用できます。

ここでは、リモートセキュアシステムを loggersys、監査対象のクライアントを auditedsys と呼ぶことにします。

監査対象のシステムと記録先のシステムのどちらについても、この手法の設定手順は Solaris 9 OS でテスト済みです。

loggersys でのユーザーアカウントの設定

ここでは、loggersys システムがすでにセキュア化されていることを前提にしています。このサーバーでは、サービスとして Secure Shell を実行し、この Secure Shell に監査対象のシステムからアクセスできるようにする必要があります。この記事の目的では、loggersys には Secure Shell 以外のサーバーサービスは必要ありません (当然、loggersys システムをこれ以外の目的でも使用する場合、他のサービスが必要になる場合がある)。

設定手順は次のとおりです。

注: あらかじめ、この手順で修正する構成ファイルのバックアップコピーをとっておくことをお勧めします。

1. RBAC アカウントを設定します。

まず、/etc/security/policy.conf の中にある "AUTHS_GRANTED" と "PROFS_GRANTED" の行をコメントにします。デフォルトでは、システムでコマンドを実行する権限がユーザー全員に与えられます。1 つのスクリプトしか実行できない特殊なアカウントが必要なので、このデフォルト設定を変更する必要があります。

注: システムですでに RBAC を使用している場合、設定しているアカウントやロールによっては、この変更を適切に行えない場合があります。その場合、プロファイルシェルを使用している ロールやユーザーアカウントごとに、デフォルトでユーザー全員に与えられる権限を明示的に割り当てます。

変更後の policy.conf の該当する行は次のようになります。

#AUTHS_GRANTED=solaris.device.cdrw
#PROFS_GRANTED=Basic Solaris User

次に、アカウントを作成します。このアカウントに logger という名前を付け、ルートファイルシステムの /logger にホームディレクトリを作成します。ここでは、プロファイルシェル pfsh を使用します。その理由は、このシェルが RBAC の設定を適用できるシェルだからです。

root ユーザーとして次のコマンドを実行します。

root@loggersys# groupadd logger
root@loggersys# useradd -g logger -d /logger -m  \
-c "Append audit messages to audit files" \
-s /bin/pfsh logger

root@loggersys# chmod 700 /logger

デフォルトでは、作成したアカウントはロックされます。通常は、passwd(1) コマンドを使用して、このアカウントのパスワードを設定します。

ここでは、鍵を使って認証を行うので、パスワードは使用しません。Solaris の Secure Shell では、鍵に基づくアクセスは許可されないので、このアカウントをロックしたままにしておくこともできません。そのため、このアカウントを NP として指定します。これで、パスワードを使ったアクセスはできなくなり、鍵認証を使ったアクセスができるようになります。

変更後の /etc/shadow の該当する行は次のようになります。

logger:NP:::::::

2. 記録用のスクリプトを作成します。

/logger ディレクトリに記録用のスクリプトを作成します。

このスクリプトを次に示します。

#!/bin/ksh

#
# Syntax:
#      (1)  appender.sh  append <logname>
#      (2)  appender.sh  rename <logname> <closedate>
# (1) causes script to append all standard input to file <logname>
#     under directory AUDIT_DIR
# (2) rename file <logname> under directory AUDIT_DIR by replacing
#     not_terminated with string closedate

#
# Script vars
#
# Directory where files are created
AUDIT_DIR=/var/auditcentral
# max allowed length of any argument received by script
maxarglen=80

#
# return codes
#
_ERR_AUDITDIR=1
_ERR_ARG=2
_ERR_SYNTAX=3
_ERR_FEXISTS=4

#
# write a message to syslog
# Syntax: logmsg message
#
logmsg() {
 logger -p daemon.notice -t "AUDIT_LOG_APPENDER" "$1"
}

#
# Description:
#     write a message to syslog and exit
# Syntax: logexit message exitcode
#
logexit() {
  logmsg "$1"
  exit "$2"
}

#
# Description:
#     make sure string is only one line long, not empty
#     and check that it only has 0-9a-zA-Z or underscore 
#     characters
# Syntax: validatestr string
# Return: 0 if valid; 1 if invalid
#
validatestr() {
   # check not a special directory name
   [ "$1" = "." -o "$1" = ".." ] && return 1
   nlines=`echo "$1" | wc -l`
   [ "$nlines" -eq "1" ] || return 1
   # check string length is valid
   nchars=`echo "$1" | wc -m`
   nchars=$(($nchars-1))
   [ "$nchars" -lt 1 -o "$nchars" -gt "$maxarglen" ] && return 1
   stripped=`echo "$1" | sed -e 's/[^-a-zA-Z0-9._]//g'`
   [ "$stripped" != "$1" ] && return 1
   return 0
}


#
# main
#
PATH=/usr/bin
[ -d  ] \
      || logexit "Dir  does not exist", 
cd 

#
# append case
#
if [ $# -eq "2" ]; then
   # check args
   validatestr "$1" \
      || logexit "Argument 1 has invalid chars", 
   validatestr "$2" \
      || logexit "Argument 2 has invalid chars", 
   [ "$1" = "append" ] \
      || logexit "Syntax error. Arg 1 should be append", 
   [ -f "$1" ] || touch "$2"
   # append data
   cat  >>"$2"
fi

#
# rename case
#
if [ $# -eq "3" ]; then
   #
   # check args
   #
   validatestr "$1" || logexit "Argument 1 has invalid chars", 
   validatestr "$2" || logexit "Argument 2 has invalid chars", 
   validatestr "$3" \
         || logexit "Argument 3 has invalid chars", 
   [ "$1" == "rename" ] \
         || logexit "Syntax error. Arg 1 should be rename", 
   logname="$2"
   closedate="$3"
   # logname must contain "not_terminated" string
   echo "$logname" |  grep '^[0-9].*\.not_terminated\..*$' \
           || logexit "Argument logname invalid", 
   # close date must only have numbers
   echo "$closedate" | grep '^[0-9]*$' \
        || logexit "Argument closedate is invalid", 

   newfname=`echo $logname | sed -e 's/not_terminated/''/'`
   # check newfname doesn't exist
   [ -e "$newfname" ] \
     && logexit "Rename to existing file not permitted. Abort" 
   mv  
   logmsg "File  renamed to "
fi

exit 0

スクリプトの説明:

行 16 および 18: 監査ファイルの保存先のディレクトリの絶対パス (この例では /var/auditcentral) を定義しています。スクリプトの引数の最大長も定義しています。

行 46 〜 66: スクリプトの引数が有効かどうかをチェックする、validatestr というシェルプロシージャを定義しています。

行 77 〜 88: 記録の実行。監査対象のシステムにあるクライアントスクリプトが、監査ファイルにデータを書き込みたい場合、この構文を使用します。このスクリプトが引数をチェックし、標準入力から渡されたデータを /var/auditcentral にあるファイルに書き込みます。

行 90 〜 120: ファイル名の変更。auditd は、監査対象のシステムでファイルを閉じたときに、そのファイルの名前を変更します。同様に、auditcentral にあるファイルの名前も変更する必要があります。この 2 番目の構文はそのために使用します。このスクリプトが引数をチェックし、可能であれば auditcentral にある既存のファイルの名前を変更します。

悪意のあるユーザーがこの構文を使用し、既存のファイルをでたらめな名前に変更しようとするかもしれません。ただし、auditd はファイルへの記録を終えるたびに、そのファイルの先頭と末尾にファイルレコードを 1 つずつ書き込みます。必要であれば、これらのレコードからファイル名を構築し直すことができます。

3. スクリプトの権限を設定します。

このファイルの所有者を root ユーザーにし、権限を 755 に設定します。

root@loggersys# chown root /logger/appender.sh
root@loggersys# chmod 755 /logger/appender.sh

4. auditappender プロファイルを作成します。

ユーザー logger がスクリプト appender.sh を実行できるようにします。そのために、プロファイルを作成し、そのプロファイルに実行権を割り当て、そのプロファイルをユーザー logger に割り当てます。

1. root@loggersys# echo "auditappender:::Append data to audit log files" \  
    >>/etc/security/prof_attr
2. root@loggersys# echo "auditappender:suser:cmd:::/logger/appender.sh:" \ 
  >>/etc/security/exec_attr
3. root@loggersys# echo "logger::::profiles=auditappender" >> /etc/user_attr

行 1 では、auditappender というプロファイルを作成しています。

行 2 では、このプロファイルに /logger/appender.sh の実行権を与えています。

行 3 では、このプロファイルをユーザー logger に割り当てています。

5. 監査ファイルの格納先のディレクトリを作成します。

appender.sh スクリプトから (AUDIT_DIR シェル変数を介して) 参照されている /var/auditcentral ディレクトリを作成します。

root@loggersys# mkdir /var/auditcentral
root@loggersys# chown logger /var/auditcentral
root@loggersys# chmod 700 /var/auditcentral

Secure Shell の鍵認証の設定

監査対象のクライアントシステムごとに Secure Shell の鍵を設定し、クライアント上の root アクセスユーザーから、記録先のシステムの logger アカウントにログインできるようにします。

クライアントシステムで、root ユーザーとして次のコマンドを実行します。

root@auditedsys# ssh-keygen -t dsa -b 1024 -N''

Generating public/private dsa key pair.
Enter file in which to save the key (/.ssh/id_dsa):
Your identification has been saved in /.ssh/id_dsa.
Your public key has been saved in /.ssh/id_dsa.pub.
The key fingerprint is:
 11:1c:55:9c:0f:54:2d:c9:c3:40:20:c8:98:4a:dd:41 root@myhost

記録先のシステムの /logger/.ssh/authorized_keys ファイルに公開鍵を追加します。この最初の鍵を追加するために、.ssh ディレクトリを作成しなければならない場合があります。

(shadow でこのユーザーを NP と指定しているために) ユーザー logger としてはログインできないので、scp を使って、このユーザーを非特権アカウントにコピーします。その後で、su を使って root ユーザーになり、ファイルを最終的な配置先に移動します。

root@auditedsys# scp /.ssh/id_dsa.pub unprivusr@loggersys:.
unprivusr@loggersys's password:

root@auditedsys# ssh unprivusr@loggersys
unprivusr@loggersys's password:

unprivusr@loggersys$ su -
Password:

root@loggersys# mkdir /logger/.ssh
root@loggersys# chown logger /logger/.ssh; chmod 700 /logger/.ssh
root@loggersys# cat <unprivusr_homedir>/id_dsa.pub >>  /logger/.ssh/authorized_keys
root@loggersys# rm <unprivusr_homedir>/id_dsa.pub
root@loggersys# chown logger /logger/.ssh/authorized_keys

これで、クライアント上の root ユーザーが、loggersys システムにユーザー logger として非対話的にログインできるかどうかを、ssh を使ってテストできます。

BSM による監査の有効化と設定

次に、それぞれのクライアントで BSM を設定します。ここでは、作成したスクリプトの動作チェックを行うための最小限の設定例を紹介します。

root@auditedsys# /usr/sbin/init 1

root@auditedsys# /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: move aside /etc/rc3.d/S81volmgt.
bsmconv: INFO: turning on audit module.
bsmconv: INFO: initializing device allocation files.

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.

2. 必要に応じて argv ポリシーを設定します。

/etc/security/audit_startup に argv ポリシーを追加し、exec コールに渡される引数を記録できるようにします。

root@auditedsys# echo "/usr/sbin/auditconfig -setpolicy \
+argv" >> /etc/security/audit_startup

3. audit_control 構成ファイルを編集します。

ex クラスのイベントだけを監査します。すなわち、exec(2) コールをすべて記録します。このファイルでは、それ以外にもあらゆる設定を行えます。変更後の audit_control の "flags" の行は次のようになります。

flags:ex

4. auditwatcher.sh スクリプトを作成します。

/auditwatcher.sh スクリプトを作成し、その所有者を root ユーザーにします。このスクリプトは、audit デーモンが起動した直後に実行されます。このスクリプトでは、現在の監査ファイルに tail(1) を適用し、記録するデータをリモートに送信します。さらに、ファイルが閉じられたときに記録用のスクリプトを呼び出し、リモートシステムでもファイル名を変更させます。

root@auditedsys# vi /auditwatcher.sh 

#!/bin/ksh
#
# Script vars
#
LOGGERSYS=loggersys
LOGGERUSER=logger
SSH=/usr/bin/ssh
APPENDER=/logger/appender.sh
# the TAILLINK is created by this script
TAILLINK=/tmp/loggertail1234
# ret
RET_AUDIT_STOPPED=1

#
# kill processes with name 
#
kill_tails() {
    tail_pids=`ps -eo pid,comm | nawk '{ if ( NR != 1 && $2 == "''" ) print $1 }'`
    if [ -n "$tail_pids" ]; then
       for pid in  $tail_pids; do
          kill "$pid" >/dev/null 2>&1
       done
    fi
}

[ -L "$TAILLINK" ] ||  ln -s /usr/bin/tail  

while true
do
  # send current file
  CRTAUDIT=`nawk -F: '{print $2}' /etc/security/audit_data`
  # if file doesn't exist it means the audit daemon was stopped
  [ -f  ] || exit 
  AUDITBASE=`basename `
  AUDITDIR=`dirname `
   +0f  | \
            -l    append  &

  #
  # watch for audit log switch
  # if file record encountered => crt audit file closed
  #
   -0f  | praudit -l |
  nawk -F, '/^file,/ {print $0; exit}' |
   (
    read f
    # get end date for the just closed audit file
    set -- `echo  | nawk -F. '{print $1" "$3}'`
    start=$1
    host=$2
    fname=`ls /.*.`
    closedate=`basename  | nawk -F. '{print $2}'`
    terminated_name=`echo  | sed -e 's/not_terminated/''/'`
    kill_tails
    # rename the closed audit file
     -l    rename  
   )
  done
done

root@auditedsys# chmod 700 /auditwatcher.sh 

スクリプトの説明:

行 3 〜 9: このスクリプトで使用する変数:

LOGGERSYS: アカウント logger があるリモートシステムのホスト名

LOGGERUSER: ssh を使った接続に使用するユーザー名

SSH: Secure Shell クライアントの絶対パス

APPENDER: ユーザー logger として ssh を使って実行するコマンド

TAILLINK: 作成した tail プロセスを簡単かつ明確に特定できるように、このスクリプトで作成する /usr/bin/tail ファイルへのリンク。現在の監査ファイルが閉じられたときに、これらのプロセスを強制終了させ、別のプロセスを起動します。

行 32 〜 40: 現在の監査ファイルを監視し、このファイルに情報を記録します。auditd は、/etc/security/audit_data にある現在の監査ファイルの名前を保持しています。 そのファイル名を検索し、このファイルから ssh にデータを送信します。さらに、ssh から記録用のスクリプトを呼び出します。

行 41 〜 59: 別の tail プロセスを実行し、現在の監査ファイルの内容を監視します。その出力を praudit にパイプし、レコードをバイナリ形式からテキスト形式に変換します。ファイルレコードに到達した場合、監査ファイルがすでに閉じられていることを意味します。

このファイルレコードは、行 46 の nawk パターンと一致します。その後、このファイルからファイルが閉じられた日付を取得し、記録用のスクリプトにリモートシステムでのファイル名を変更させます (行 58)。

5. /etc/init.d/audit スクリプトを変更します。

audit デーモンの起動後に watcher スクリプトを自動的に起動させます。

そのために、/etc/init.d/audit の先頭に次の行を追加します。これらの行で、watch スクリプトの場所と、このスクリプトの PID の書き込み先のファイル名を指定します。

### BEGIN_AUDIT_MODIF ###
WATCHER=/auditwatcher.sh
WATCHERPIDF=/var/run/auditwatcher.pid
### END_AUDIT_MODIF ###

さらに、"start" 処理の中の auditd の起動直後に次の行を追加します。

 
### BEGIN_AUDIT_MODIF ###
# Wait for audit to update audit_data and then
# start auditwatcher
 if [ -f  ]; then
     echo "File  exists. Check if auditwatcher.sh is already running."
     echo "If it is not: remove  and start auditwatcher manually as root:"
     exit 1
 fi
 echo "Waiting for auditd to update /etc/security/audit_data"
 sleep 5
 echo "Starting auditwatcher"
 nohup  >/dev/null 2>&1 &
 echo $! >
### END_AUDIT_MODIF ###

"stop" 処理の最後に次の行を追加します。

### BEGIN_AUDIT_MODIF ###
rm -f  >/dev/null 2>&1
### END_AUDIT_MODIF ###

Solaris 9 04/04 での変更後のファイルは次のようになります。

#!/sbin/sh
#
# Copyright (c) 1997 by Sun Microsystems, Inc.
# All rights reserved.
#
#ident  "@(#)audit      1.6     01/03/27 SMI"

### BEGIN_AUDIT_MODIF ###
WATCHER=/root/scripts/auditwatcher.sh
WATCHERPIDF=/var/run/auditwatcher.pid
### END_AUDIT_MODIF ###


case "$1" in
'start')
   if [ -f /etc/security/audit_startup ]; then
      /etc/security/audit_startup
      /usr/sbin/auditd &
      ### BEGIN_AUDIT_MODIF ###
      # Wait for audit to update audit_data and then
      # start auditwatcher
      if [ -f  ]; then
         echo "File  exists. Check if auditwatcher.sh is already running."
         echo "If it is not: remove  and start auditwatcher manually as root:"
         echo "nohup  >/dev/null 2>&1 & echo "'$!'" >"
         exit 1
      fi
      echo "Waiting for auditd to update /etc/security/audit_data"
      sleep 5
      echo "Starting auditwatcher"
      nohup  >/dev/null 2>&1 &
      echo $! >
      ### END_AUDIT_MODIF ###

   fi
   ;;

'stop')
   if [ -f /etc/security/audit_startup ]; then
      /usr/sbin/audit -T
      ### BEGIN_AUDIT_MODIF ###
      rm -f  >/dev/null 2>&1
      ### END_AUDIT_MODIF ###
   fi
   ;;

*)
   echo "Usage: $0 { start | stop }"
   exit 1
   ;;
esac
exit 0

注: 上のスクリプト全体を単純にコピー＆ペーストしないでください。このファイルの内容は Solaris のリリースによって変わる場合があります。代わりに、上記のように手作業で変更を行う必要があります。

6. システムを起動し直し、監査を有効にします。

root@auditedsys# /usr/sbin/init 6

動作チェック

1. 監査対象のシステムで次の作業を行います。

a. auditd が起動していることを確認します。

root@auditedsys# pgrep -lx auditd
  641 auditd

b. auditwatcher スクリプトが起動していることを確認します。

root@auditedsys# ps -ef | grep auditwatcher
  root 301   1 0 17:43:12 ? 0:00 /bin/ksh /auditwatcher.sh
  root 330 301 0 17:43:13 ? 0:00 /bin/ksh auditwatcher.sh 20040920142037.not_terminated

c. 必要に応じて、exec(2) コールが記録されていることを確認します。

<あるシェルで次のコマンドを実行します>
root@auditedsys# tail -0f

<別のシェルでコマンドを実行します>
root@auditedsys# ls /

<最初のシェルに、ls コマンドの監査エントリが次のように表示されます>
header,133,2,execve(2),,Mon Sep 20 17:28:53 2004, + 0
msec,path,/usr/bin/ls,attribute,100555,root,bin,136,400,0,
exec_args,2,ls,/,subject,student,root,other,root,other,667,379,0 33481
vectra2,return,success,0

2. 記録先のシステムで次の作業を行います。

a. 記録用のスクリプトが起動していることを確認します。

root@loggersys# ps -ef | grep appender
  logger  986  985  0 12:44:32 ?  0:00 pfsh -c /logger/appender.sh 
append 20040920144306.not_terminated.auditedsys

  logger  987  986  0 12:44:32 ?  0:00 /bin/ksh /logger/appender.sh 
append 20040920144306.not_terminated.auditedsys

b. 監査対象のシステムで生成された監査エントリが受け取られていることを確認します。

<loggersys 上のあるシェルで現在の監査ファイルを監視します>
root@loggersys# tail -0f /var/auditcentral/*.not_terminated.auditedsys | praudi -l

<auditedsys でコマンドを実行します>
root@auditedsys# ls /

<loggersys 上の最初のシェルに、ls コマンドの監査エントリが次のように表示されます>
header,131,2,execve(2),,Mon Sep 20 17:50:55 2004, + 0
msec,path,/usr/bin/ls,attribute,100555,root,bin,136,400,0,
exec_args,1,ls,subject,student,student,staff,student,staff,388,377,0 33536 
vectra2.hpc,return,success,0

c. auditedsys で監査ファイルが切り替えられた後も、loggersys でデータが引き続き収集されていることを確認します。

<auditedsys で現在の監査ファイルを切り替えます>
root@auditedsys# ls -l /var/audit
-rw-------   1 root  root  200 Sep 20 17:51 20040920145153.not_terminated.auditedsys
root@auditedsys# audit -n
root@auditedsys# ls -l /var/audit
-rw-------   1 root  root  404 Sep 20 17:54 20040920145153.20040920145426.auditedsys
-rw-------   1 root  root  200 Sep 20 17:54 20040920145426.not_terminated.auditedsys
<loggersys でファイル名が正しいかどうかを確認します>
root@loggersys# ls -l /var/auditcentral
-rw-r--r--   1 logger logger  404 Sep 17 12:55 20040920145153.20040920145426.auditedsys
-rw-r--r--   1 logger logger  345 Sep 17 12:55 20040920145426.not_terminated.auditedsys

参考情報

監査とBSM(基本セキュリティモジュール)について

• 第 20 章 BSM (概要) (Solaris 9 9/04 System Administrator Collection - Japanese)
• Sun BluePrints: Auditing in the Solaris 8 Operating Environment (pdf)
• Martin Englund のブログ

RBAC と SSH について

• Solaris 9 Security Services RBAC Documentation
• Sun BluePrints: Role Based Access Control and Secure Shell--A Closer Look At Two Solaris Operating Environment Security Features (pdf)

この記事は、 Protecting Audit Files Created by the Basic Security Module (By Vlad Grama, December 2004) を翻訳したものです。 原文は、Solaris 10 の正式リリース前に公開されているためリリースの情報が古くなっています。 今回の記事にあたりリリースに関する情報をアップデートしたために原文と異なる部分があります。