下記の設定例では、どのようにして監査システムからお使いのシステムを監視することができるのかについて説明しています。また、 Controlled Access Protection Profile (CAPP) で指定されている監査対象のイベントをカバーするのに必要な項目について、主なものを紹介しています。
ルールセットの例は下記のようなパーツから構成されています:
基本的な監査設定 ( 42.1項 「基本的な監査設定パラメータの追加」 )
監査ログファイルと監査設定ファイルに対する監視 ( 42.2項 「監査ログファイルと設定ファイルに対する監視の追加」 )
ファイルシステムオブジェクトに対する操作の監視 ( 42.3項 「ファイルシステムオブジェクトの監視」 )
セキュリティデータベースの監視 ( 42.4項 「セキュリティ設定ファイルとデータベースの監視」 )
その他のシステムコールの監視 ( 42.5項 「その他のシステムコールに対する監視」 )
システムコールのパラメータのフィルタリング ( 42.6項 「システムコールのパラメータでのフィルタリング」 )
下記に示す設定例を、実際に使用する設定ファイルに変換するには、下記の手順を実施してください:
まずはお使いの環境に合った設定を選んで、必要に応じて調整を行ってください。
下記の設定例から、 /etc/audit/audit.rules
ファイルに対してルールを追加していってください。このとき、必要に応じてルールを変更してもかまいません。
お使いの環境の要件にあわせることなく、設定例をそのまま使用して監査を行うことは避けてください。まずは何を監査するのか、どの範囲まで監査するのかを決定してから実施してください。
audit.rules
ファイルは auditctl
コマンドの集合体であると考えられます。このファイルの各行は、それぞれ auditctl
のコマンドラインとして解釈されます。そのため、このルールファイル内で使用する文法は、 auditctl
のコマンドラインと同じです。
-D1 -b 81922 -f 23
新しくルールセットを定義するため、既存のルールを全て削除しています。 | |
監査メッセージを受け付けるためのバッファ数を指定しています。お使いのシステムにおける監査ログの量に応じて、増やしたり減らしたりしてください。 | |
カーネルが致命的なエラーを処理する際に使用する、失敗フラグを指定しています。指定可能な値は |
-D
オプションを指定してルールキューをいったん空にすることで、それまでに設定されていたルールによる影響を受けることなく、このファイル内に書かれているルールを正しく適用することができるようになります。また、バッファ数の指定 ( -b
) は、監査システムの負荷を上昇させすぎてシステムに障害が発生したりしないようにするために重要な設定です。このほか、失敗フラグ -f 2
の選択は、お使いのシステムに対して致命的なエラーが発生した際、監査レコードを保全するために必要な設定です。致命的なエラーの際にシステムをシャットダウンすることで、監査から外れたプロセスが現れないようにすることができるためです。このような要件が無い場合は、 1 ( printk
) を選択してください。
本番環境にお使いの監査ルールを適用するにあたっては、あらかじめテスト環境で 想定される最大の負荷 をかけて、監査が正しく動作することをご確認ください。また、 -f 2
フラグを指定しておくことも重要です。この設定は、何らかの閾値を超過した場合に、カーネルをパニック状態 (書き込み待ちのデータを書き込むことなくシステムを即時に停止させる) にすることができる設定です。ただし、 -f 2
の設定は、セキュリティを最重要視する環境でのみお使いください。
ご利用の監査設定ファイルとログファイルに対して監視を設定して、設定ファイルやログファイルに対して改ざんを試みた形跡や、不正に読み取ろうとした形跡を記録するようにしておいてください。
ディレクトリに対する監視は、ファイルアクセスに対するイベントだけが必要な環境では、特に設定を行う必要はありません。ディレクトリアクセスのイベントは、メタデータの変更を伴うディレクトリの inode 変更の際にのみ発行されるためです。ファイルアクセスに対してイベントを発生させたい場合は、各ファイルを監視対象にしてください。
-w /var/log/audit/ 1 -w /var/log/audit/audit.log -w /var/log/audit/audit_log.1 -w /var/log/audit/audit_log.2 -w /var/log/audit/audit_log.3 -w /var/log/audit/audit_log.4 -w /etc/audit/auditd.conf -p wa2 -w /etc/audit/audit.rules -p wa -w /etc/libaudit.conf -p wa
システムコールに対する監査を行うことで、アプリケーションレベルよりも細かく、お使いのシステムにおける動作を追跡することができるようになります。ファイルシステム関連のシステムコールを追跡することで、お使いのアプリケーションがどのようなシステムコールを使用しているのかを判断することができるほか、その使用が適切であるかどうかを確認することもできます。また、マウントやマウント解除の操作を追跡することで、外部リソース (リムーバブルメディアやリモートのファイルシステムなど) の使用についても追跡を行うことができます。
システムコールの監査を行うと、ログを頻繁に書き込むことになります。そのため、カーネルに対しても重い負荷を与えることになります。監査を行った結果、通常よりも応答が遅くなったと感じた場合は、おそらくシステムのバックログ設定と流量制限の設定を超過したものと思われます。この場合は、監査ルール内にどのシステムコールを含めるのかを慎重に確認し、ログ設定についても調整を行ってください。 40.2項 「監査デーモンの設定」 では、関連する設定を調整する方法について説明しています。
-a entry,always -S chmod -S fchmod -S chown -S chown32 -S fchown -S fchown32 -S lchown -S lchown321 -a entry,always -S creat -S open -S truncate -S truncate64 -S ftruncate -S ftruncate642 -a entry,always -S mkdir -S rmdir3 -a entry,always -S unlink -S rename -S link -S symlink4 -a entry,always -S setxattr5 -a entry,always -S lsetxattr -a entry,always -S fsetxattr -a entry,always -S removexattr -a entry,always -S lremovexattr -a entry,always -S fremovexattr -a entry,always -S mknod6 -a entry,always -S mount -S umount -S umount27
ファイルの所有権とパーミッションを変更する操作に関連するシステムコールに対して、監査コンテキストを有効化しています。お使いのハードウエアアーキテクチャによっても異なりますが、 | |
ファイルの内容変更に関連するシステムコールに対して、監査コンテキストを有効化しています。お使いのハードウエアアーキテクチャによっても異なりますが、 | |
ディレクトリの作成や削除など、ディレクトリ操作に対する監査コンテキストを有効化しています。 | |
シンボリックリンクの作成やハードリンクの作成、削除や名前変更などのリンク操作に対して、監査コンテキストを有効化しています。 | |
ファイルシステムの属性操作に関する監査コンテキストを有効化しています。 | |
デバイスファイルを作成するための | |
マウントやマウント解除の操作に対して、監査コンテキストを有効化しています。 x86 アーキテクチャの場合は |
お使いのシステムに対して望ましくない行為をさせないようにするため、 cron
や at
の設定ファイルのほか、ジョブスケジュールの変更を行おうとする行為を追跡しておくことをお勧めします。このほか、ユーザやグループ、パスワードやログインデータベースやアクセスログなどへの書き込みアクセスについても追跡することで、お使いのシステムのユーザデータベースを改ざんしようとする行為を検出できるようになります。
また、お使いのシステムにおける設定 (カーネル, サービス, 時刻など) に対する変更を追跡しておくことで、お使いのシステムにおける重要な機能の改ざんを防ぐことができます。特に PAM の設定ファイルの変更は、認証スタックの設定変更は管理者以外から行われるべきではないことから、監視対象としておくべきです。また、アプリケーション側からの PAM の使用状況や用途についても、ログに記録を行っておくべきです。このほか、機密を確保しておくべき認証や通信にかかわる設定ファイルについても、同様に監視対象としておくのがよいでしょう。
1 -w /var/spool/atspool -w /etc/at.allow -w /etc/at.deny -w /etc/cron.allow -p wa -w /etc/cron.deny -p wa -w /etc/cron.d/ -p wa -w /etc/cron.daily/ -p wa -w /etc/cron.hourly/ -p wa -w /etc/cron.monthly/ -p wa -w /etc/cron.weekly/ -p wa -w /etc/crontab -p wa -w /var/spool/cron/root 2 -w /etc/group -p wa -w /etc/passwd -p wa -w /etc/shadow -w /etc/login.defs -p wa -w /etc/securetty -w /var/log/lastlog 3 -w /etc/hosts -p wa -w /etc/sysconfig/ w /etc/init.d/ w /etc/ld.so.conf -p wa w /etc/localtime -p wa w /etc/sysctl.conf -p wa w /etc/modprobe.d/ w /etc/modprobe.conf.local -p wa w /etc/modprobe.conf -p wa 4 w /etc/pam.d/ 5 -w /etc/aliases -p wa -w /etc/postfix/ -p wa 6 -w /etc/ssh/sshd_config -w /etc/stunnel/stunnel.conf -w /etc/stunnel/stunnel.pem -w /etc/vsftpd.ftpusers -w /etc/vsftpd.conf 7 -a exit,always -S sethostname -w /etc/issue -p wa -w /etc/issue.net -p wa
| |
ユーザ, グループ, パスワード, ログインデータベースに対して監視を設定しているほか、たとえばログインの失敗など、ログイン関連のイベントを記録し、ラベルでわかりやすく識別するように設定しています。 | |
まずはホスト名の設定を行っている | |
PAM の設定ファイルのディレクトリに対して監視を設定しています。このディレクトリ内にあるファイルを監視したい場合は、それぞれのファイルに対して監視を設定してください。 | |
postfix の設定ファイルに対して監視を設定し、書き込みや属性変更を行おうとした場合に、後から検索できるようラベルを指定して記録を行っています。 | |
SSH, | |
|
42.3項 「ファイルシステムオブジェクトの監視」 で説明しているファイルシステム関連のシステムコールの監査だけでなく、その他のシステムコールに対しても追跡を行うことができます。たとえばタスク (プロセス) の作成を追跡することで、アプリケーションの振る舞いを理解する手助けになったりすることがあります。また、 umask
システムコールを監査することで、プロセスがどのような作成マスクを使用しているのかを調べたりすることもできます。また、システム時刻の変更に関わるシステムコールを追跡することで、誰かがシステムの時刻を改ざんしようとしていないかどうかを確認することもできます。
1 -a entry,always -S clone -S fork -S vfork 2 -a entry,always -S umask 3 -a entry,always -S adjtimex -S settimeofday
42.3項 「ファイルシステムオブジェクトの監視」 や 42.5項 「その他のシステムコールに対する監視」 で説明しているシステムコールの監査に加えて、さらに高度にアプリケーションの動作を追跡することができます。具体的にはフィルタを設定することで、監査の範囲を絞り込むことができるようになります。本章では、多重化を伴わないシステムコールのほか、 socketcall や ipc などのように、多重化を伴うシステムコールのパラメータに対して、フィルタリングを設定する方法を紹介しています。なお、 AMD64/Intel 64 など、 64 ビット環境では、 socketcall も ipc も多重化されません。
システムコールの監査を行うと、ログを頻繁に書き込むことになります。そのため、カーネルに対しても重い負荷を与えることになります。監査を行った結果、通常よりも応答が遅くなったと感じた場合は、おそらくシステムのバックログ設定と流量制限の設定を超過したものと思われます。この場合は、監査ルール内にどのシステムコールを含めるのかを慎重に確認し、ログ設定についても調整を行ってください。 40.2項 「監査デーモンの設定」 では、関連する設定を調整する方法について説明しています。
access システムコールは、ファイルやファイルシステムのオブジェクトに対して、読み込みや書き込み、存在のチェックの機能を提供するシステムコールです。 -F
フィルタフラグを設定することで、特定の条件に該当するシステムコールのみを記録することができるようになります。具体的な書式は -F a1=アクセスモード
です。 access システムコールにおけるパラメータについて、詳しくは /usr/include/fcntl.h
ファイルをお読みください。
-a entry,always -S access -F a1=41 -a entry,always -S access -F a1=62 -a entry,always -S access -F a1=73
access システムコールに対して監査を設定していますが、システムコールの 2 番目のパラメータ ( | |
access システムコールに対して監査を設定していますが、システムコールの 2 番目のパラメータ ( | |
access システムコールに対して監査を設定していますが、システムコールの 2 番目のパラメータ ( |
socketcall システムコールは多重化型のシステムコールです。多重化とは複数のシステムコールを 1 つのシステムコールで賄う仕組みで、 libc 側で実際のシステムコールを最初のパラメータ ( a0
) として設定する仕組みです。 socketcall で利用できるシステムコールについては、マニュアルページをお読みください。また、パラメータの値とシステムコールの名前の一覧については、 /usr/src/linux/include/linux/net.h
ファイルをお読みください。監査システムでは、 -F a0=システムコール番号
の形式で、システムコールを指定することができます。
-a entry,always -S socketcall -F a0=1 -F a1=101 ## x86_64, ia64 アーキテクチャの場合は下記をお使いください #-a entry,always -S socket -F a0=10 -a entry,always -S socketcall -F a0=52 ## x86_64, ia64 アーキテクチャの場合は下記をお使いください #-a entry, always -S accept
socket(PF_INET6) システムコールを監査しています。 | |
上記と同様に socketcall システムコールを監査していますが、 |
ipc システムコールは多重化されるシステムコールのもう 1 つの例となります。実際のシステムコールは ipc システムコールの 1 つ目のパラメータとして指定されます。このようにしてフィルタを設定することで、特定の ipc システムコールのみを監査することができます。値の意味について、詳しくは /usr/include/linux/ipc.h
をお読みください。
1 ## msgctl -a entry,always -S ipc -F a0=14 ## msgget -a entry,always -S ipc -F a0=13 ## x86_64, ia64 アーキテクチャの場合は下記をお使いください #-a entry,always -S msgctl #-a entry,always -S msgget 2 ## semctl -a entry,always -S ipc -F a0=3 ## semget -a entry,always -S ipc -F a0=2 ## semop -a entry,always -S ipc -F a0=1 ## semtimedop -a entry,always -S ipc -F a0=4 ## x86_64, ia64 アーキテクチャの場合は下記をお使いください #-a entry,always -S semctl #-a entry,always -S semget #-a entry,always -S semop #-a entry,always -S semtimedop 3 ## shmctl -a entry,always -S ipc -F a0=24 ## shmget -a entry,always -S ipc -F a0=23 ## x86_64, ia64 アーキテクチャの場合は下記をお使いください #-a entry,always -S shmctl #-a entry,always -S shmget
IPC SYSV メッセージキューに関連するシステムコールを監査しています。この場合、 | |
IPC SYSV メッセージセマフォに関連するシステムコールを監査しています。この場合、 | |
IPC SYSV 共有メモリに関連するシステムコールを監査しています。この場合、 |
イベントを生成するためのルールを複数設定し、ログに出力するようにした場合、ログには一般に多くの項目が出力されることになり、必要なものを識別するだけでも手間がかかってしまいます。 ausearch
コマンドを使用することで、様々な条件を指定して検索を行うことができます。たとえば ausearch
-m メッセージの種類
のように指定すると、メッセージの種類を指定して検索を行うことができます。しかしながら、同じようなメッセージを出力するようなルールが複数あって、それらを区別して扱いたい場合、 /etc/audit/audit.rules
ファイルのルール内に、あらかじめ何らかの検索用のキーを指定しておくことができます。このキーはその条件に合致してログを出力する際、必ず書き込まれる仕組みになっています。そのため、ログを記録したあとから ausearch
-k キー名
のようにして検索することで、特定のキーが設定されたイベントのみを抽出することができるようになります。
例として、下記のようなルールをルールセットに追加したものします:
-w /etc/audit/audit.rules -p wa
キーを指定しない場合、まずは SYSCALL
や PATH
のイベントのみを抽出してから、さらに grep などのツールを利用して必要な項目を抜き出すような処理が必要になります。そのため、下記のように -k
オプションを指定して、キーを書き込むように設定します:
-w /etc/audit/audit.rules -p wa -k CFG_audit.rules
キーには任意の文字列を指定することができます。また、上記の例のように、CFG
は設定ファイル用、 LOG
はログファイル用等のように設定し、その後ろに実際のファイル名を続けるようにして、わかりやすくするとよいでしょう。上記のようなキーを設定した場合、検索は下記のようになります:
ausearch -k CFG_audit.rules
----
time->Thu Feb 19 09:09:54 2009
type=PATH msg=audit(1235030994.032:8649): item=3 name="audit.rules~" inode=370603 dev=08:06 mode=0100640 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1235030994.032:8649): item=2 name="audit.rules" inode=370603 dev=08:06 mode=0100640 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1235030994.032:8649): item=1 name="/etc/audit" inode=368599 dev=08:06 mode=040750 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1235030994.032:8649): item=0 name="/etc/audit" inode=368599 dev=08:06 mode=040750 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1235030994.032:8649): cwd="/etc/audit"
type=SYSCALL msg=audit(1235030994.032:8649): arch=c000003e syscall=82 success=yes exit=0 a0=7deeb0 a1=883b30 a2=2 a3=ffffffffffffffff items=4 ppid=25400 pid=32619 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1164 comm="vim" exe="/bin/vim-normal" key="CFG_audit.rules"