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

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

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

問題	解決方法	説明
監査を構成したときに監査ファイルが作成されないのはなぜでしょうか。	監査デーモンと監査構成ファイルのトラブルシューティングを行います。	「Solaris 監査が実行中であるかどうかを判定する方法」
収集される監査情報を減らすには、どうすればよいでしょうか。	監査が必要なイベントについてのみ、監査を行います。	「生成される監査レコードの量を削減する方法」
システムでのユーザーの動作をすべて監査するには、どうすればよいでしょうか。	すべてのコマンドについて 1 人または複数のユーザーを監査します。	「ユーザーによるすべてのコマンドを監査する方法」
記録される監査イベントを変更して、その変更内容を既存のセッションに適用するには、どうすればよいでしょうか。	ユーザーの事前選択マスクを更新します。	「ユーザーの事前選択マスクを変更する方法」
変更内容を特定のファイルに格納するには、どうすればよいでしょうか。	ファイルの変更を監査し、`auditreduce` コマンドを使用して特定のファイルを検索します。	「特定のファイルに対する変更の監査レコードを検索する方法」
監査ファイルのサイズを減らすには、どうすればよいでしょうか。	バイナリ監査ファイルのサイズを制限します。	「バイナリ監査ファイルのサイズを制限する方法」
`audit_event` ファイルから監査イベントを削除するには、どうすればよいでしょうか。	`audit_event` ファイルを更新します。	「特定のイベントが監査されないようにする方法」
Solaris システムへのすべてのログインを監査するには、どうすればよいでしょうか。	システムからのログインを監査します。	「ほかの OS からのログインを監査する方法」
FTP 転送で監査レコードが保持されないのはなぜでしょうか。	ログを生成するユーティリティーに適切な監査ツールを使用します。	「FTP および SFTP ファイル転送を監査する方法」

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

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

始める前に

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

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

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 クラスの作成については、「監査クラスの追加方法」を参照してください。
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
  イベントがクラスに割り当てられていない場合、適切なイベントをこのクラスに割り当てます。

前述の手順で問題が見つからなかった場合、システムログファイル /var/adm/messages および /var/log/syslog を確認します。
1. 問題を検出して修正します。
2. 次に、監査サービスが実行中である場合、再起動します。
  # audit -s
3. 監査サービスが実行中でない場合、有効にします。
  
  手順については、「監査サービスを有効にする方法」を参照してください。

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

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

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

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

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 ファイルにクラスを追加する場合よりも、生成されるレコードが少なくなります。
- 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 ...

特定のファイルの監査レコードを検索するには、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 に変更されたものとします。
  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 つの方法のいずれかを使用します。
- ユーザーの監査セッション ID を使用して、ユーザーの事前選択マスクを変更します。
  # /usr/sbin/auditconfig -setsmask lo,ex 713
- ユーザーの監査 ID を使用して、ユーザーの事前選択マスクを変更します。
  # /usr/sbin/auditconfig -setumask lo,ex 1002

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

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

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

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

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

このクラスは、ログイン、ログアウト、および画面ロックを監査します。
## audit_control file flags:lo naflags:lo ...
注 –
ssh ログインを監査するには、使用している Solaris システムで Solaris ssh デーモンを実行する必要があります。このデーモンは、Solaris 監査用に変更されます。詳細は、「Solaris Secure Shell と OpenSSH プロジェクト」を参照してください。

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

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