独自の監査設定を作成する前に、まずはどの程度監査するのかを決定する必要があります。下記の一般的な判断基準を利用して、用途や環境に合わせたコンポーネントを選択してください:

監査デーモンの基本的な設定は、 /etc/audit/auditd.conf ファイルの編集で行うことができます。 YaST › セキュリティとユーザ › Linux 監査フレームワーク (LAF) を選択することで、 YaST から基本設定を行うこともできます。 YaST から設定を行う場合は、 ログファイル と ディスク容量 の各タブを使用してください。

log_file = /var/log/audit/audit.log
log_format = RAW
log_group = root
priority_boost = 4
flush = INCREMENTAL
freq = 20
num_logs = 5
disp_qos = lossy
dispatcher = /sbin/audispd
name_format = NONE
##name = mydomain
max_log_file = 6
max_log_file_action = ROTATE
space_left = 75
space_left_action = SYSLOG
action_mail_acct = root
admin_space_left = 50
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND
##tcp_listen_port =
tcp_listen_queue = 5
tcp_max_per_addr = 1
##tcp_client_ports = 1024-65535
tcp_client_max_idle = 0
cp_client_max_idle = 0

多くの環境では既定の設定で問題なく動作します。ただし、 num_logs , max_log_file , space_left , admin_space_left などの各値については、お使いの環境のサイズに合わせて調整してください。ディスク領域が少ない場合は、ローテーション時に保持しておく古いログファイルの数を減らすとともに、ディスク領域が残り少なくなった場合により早く警告を得られるよう設定を行ってください。 CAPP 準拠の設定を行う場合は、 40.2項 「監査デーモンの設定」 で説明しているとおりに log_file , flush , max_log_file , max_log_file_action , space_left , space_left_action , admin_space_left , admin_space_left_action , disk_full_action , disk_error_action の設定を変更してください。 CAPP 準拠の設定は、たとえば下記のようになります:

log_file = 監査ログ記録専用のパーティションのパス/audit.log
log_format = RAW
priority_boost = 4
flush = SYNC                       ### DATA でもかまいません
freq = 20
num_logs = 4
dispatcher = /sbin/audispd
disp_qos = lossy
max_log_file = 5
max_log_file_action = KEEP_LOGS
space_left = 75
space_left_action = EMAIL
action_mail_acct = root
admin_space_left = 50
admin_space_left_action = SINGLE   ### HALT でもかまいません
disk_full_action = SUSPEND         ### HALT でもかまいません
disk_error_action = SUSPEND        ### HALT でもかまいません

### 以降はコメントで、その他の選択肢を説明しているものです。実際の設定ファイル内には、このようなコメントは追加しないでください。

ヒント: さらなる情報

auditd.conf の設定パラメータについて、背景となる詳細情報を読みたい場合は、 40.2項 「監査デーモンの設定」 を参照してください。

監査フレームワークがインストールされていない場合は、まず audit をインストールしてください。標準的な openSUSE Leap システムでは、 auditd が既定で 動作しています。システムの起動時に開始するよう設定されていない場合は、下記のようにして有効化してください:

> sudo systemctl enable auditd

利用可能な監査機能には、下記のものがあります:

通常のファイルやディレクトリを監視するよう設定している場合で、システムコールの監査機能も必要とする場合は、システムコールに対する監査コンテキストを有効化する必要があります。システムを再起動するまでの間にのみ監査コンテキストを有効化したい場合は、 root で auditctl -e 1 と入力して実行します。また、この機能を無効化したい場合は、同様に root で auditctl -e 0 と入力して実行します。

監査コンテキストは既定で有効化されています。この機能を一時的に無効化したい場合は、 auditctl -e 0 と入力して実行してください。

監査ルールを使用することで、監査システムがシステムのどの部分を分析するのかを決定することになります。通常は重要なデータベースやセキュリティに関連する設定ファイルを監視の対象とします。お使いのシステムに幅広い分析が必要である場合は、様々なシステムコールを分析することもあります。 CAPP 準拠の環境下で必要となるほとんどのルールを網羅する、詳細な設定例は 第42章 「監査ルールセットの紹介」 に示されています。

監査ルールはコマンドラインツールである auditctl を利用することで、監査デーモンに渡すことができるほか、 /etc/audit/audit.rules 内にルールセットを記述することでも構成することができます (この場合、監査デーモンの起動時に読み込まれます) 。 /etc/audit/audit.rules ファイルはエディタで編集することができるほか、 YaST でカスタマイズすることもできます。 YaST でカスタマイズする場合は、 セキュリティとユーザ › Linux 監査フレームワーク (LAF) › 「auditctl」 のルール から行ってください。なお、コマンドラインで渡されたルールはファイルに保存されたりすることがありませんので、監査デーモンを再起動するたびに再入力を行う必要があります。

いくつかの主要なファイルとディレクトリに対して、基本的に設定のみを行ったシンプルなルールセットは下記のとおりです:

# 基本的な監査システムのパラメータ
-D
-b 8192
-f 1
-e 1

# ファイルやディレクトリの監視 (キー機能付き)
-w /var/log/audit/ -k LOG_audit
-w /etc/audit/auditd.conf -k CFG_audit_conf -p rxwa
-w /etc/audit/audit.rules -k CFG_audit_rules -p rxwa

-w /etc/passwd -k CFG_passwd -p rwxa
-w /etc/sysconfig/ -k CFG_sysconfig

# システムコールルールの例
-a entry,always -S umask

### 以下に独自のルールを追加してください

基本的な監査システムのパラメータ (たとえば -b で指定することのできるバックログパラメータなど) を変更する場合は、あらかじめ実際の監査ルールセットで問題がないかどうかをテストしておいてください。たとえば -b であれば、現在の監査ルールセットで生成されるログの量に対して、バックログの値が適切なレベルかどうかを確認する必要があります。選択したバックログの値が小さすぎる場合は、お使いのシステムが監査の負荷に耐えられないことがありますので、バックログ制限を超過することで失敗フラグ ( -f ) が設定されてしまうことがあります。

重要: 失敗フラグの選択について

失敗フラグを設定する場合、 -f 2 はお使いの監査システムに対する制限を超過した場合、システムを即時にシャットダウンさせる設定であり、ディスクに未書き込みのデータが存在していても、それを書き込まずにシャットダウンさせてしまうことに注意してください。この方式によるシャットダウンは正常終了ではありませんので、セキュリティを最重視するシステムにのみ使用するものとし、通常は -f 1 を設定して、警告を発して監査システムを停止させるだけの処理に留めてください。これにより、データの損失や破壊などを防ぐことができます。

ディレクトリに対する監視は、そのディレクトリ内にあるファイルに対する監視に比べると、冗長性に欠ける出力になります。たとえば /etc/sysconfig ディレクトリ内にあるシステム設定ファイルに対して、詳細なログを採取したい場合は、各ファイルに対して監視を設定してください。ただし、監査ルールではグロブ (ワイルドカード) を使用することができないことに注意してください。たとえば /etc ディレクトリ内のファイルやディレクトリを監視する目的で、 -w /etc/* のようなルールを作成しても、正しく動作しません。

ログファイル内での識別を行う目的で、ファイルやディレクトリに対する監視にキーを設定することができます。キーを使用することで、特定のルールに関連するイベントを容易に取り出すことができるようになります。また、キーを設定する場合は、単なるログファイルの監視と設定ファイルの監視を区別して設定することをお勧めします。この場合、 LOG で始まるキーをログファイル監視用に、 CFG で始まるキーを設定ファイル監視用に使用しています。それ以外にも、キーの一部をファイル名と同じに設定しておくと、ログファイル内で必要な項目を簡単に見つけられるようになります。

また、ファイルやディレクトリの作成に対する監視に対してもう 1 つ注意しておくべき点として、ルールの作成時に存在していないファイルに対しては、監視を設定することができないという点です。監査システムが動作している間にシステムに追加されたファイルは、そのファイルに対して後からルールセットに追加しない限り、監視することができません。

なお、独自のルールの作成方法について、詳しくは 40.4項 「監査システムに対するパラメータ指定」 をお読みください。

重要: 監査ルールの変更について

監査ルールを変更した後は、変更点を読み込ませるため、 systemctl restart auditd と入力して実行し、監査デーモンを再起動してください。

未加工の監査ログを読んでお使いのシステムの動作を確認するような面倒な事態を避けるため、時間範囲を指定して独自の監査レポートを作成し、手間を省くことをお勧めします。独自の監査レポートを読むことで、注目したい範囲を絞り込むことができるほか、お使いのシステムの特徴を統計から取得し、更に細かいイベント監視の基礎資料とすることができるようになります。さらに細かく個別のイベントの詳細を追跡したい場合は、 ausearch ツールをお使いください。

監査レポート機能を設定する前に、まずは下記を考慮しておくことをお勧めします:

この例では、監査システムや PAM 、システムの設定へのアクセス試行に対して監査を行う想定でレポートを作成しています。お使いのシステム内のファイルイベントに関するレポートを作成するには、下記の手順で行います:

ヒント: 特定の時間帯のみに着目したい場合について

特定の日時に発生したイベントに着目したい場合は、 aureport コマンドに開始と終了の日時を指定 ( -ts および -te ) して、範囲を狭めることができます。詳しくは 40.5.2項 「独自の監査レポートの生成」 をお読みください。

最後のものを除いて、全ての手順はスクリプトから自動実行することができますので、 cron などのジョブとして実行することができます。たとえば --failed --summary オプションを指定したものについては、ファイルとアクセス失敗数を元にグラフ化することも簡単にできます。監査レポートデータの可視化について、詳しくは 41.6項 「ログの可視化の設定」 をお読みください。

mkbar や mkgraph のスクリプトを使用することで、グラフの形で監査の統計情報を可視化することができます。 aureport コマンドと同様に、グラフ化のコマンドもスクリプトとして実行することができますので、グラフ化までの部分を簡単に cron ジョブにすることができます。

mkbar や mkgraph のスクリプトは、 Red Hat 社の Steve Grubb 氏が作成したものです。スクリプト本体は https://people.redhat.com/sgrubb/audit/visualize/ からダウンロードすることができます。なお、 openSUSE Leap の現在の監査システムには、これらのスクリプトが含まれていませんので、下記の手順に従って作業を行ってください:

警告: ダウンロードコンテンツの危険性について

mkbar や mkgraph はインターネット上に公開されているソフトウエアであり、 openSUSE Leap の管理外にあるものです。使用にあたっては、ご自身の責任の下でお願いいたします。インターネットからのソフトウエアのダウンロードは、特にそれを root 権限で動作させるような場合は、基本的に危険を伴うものであることに留意してください。

41.5項 「監査レポートの設定」 などで作成した概要レポートのグラフを作成するには、 mkbar スクリプトを使用します。たとえば下記のように実行します:

上述のイベントタイプに対する失敗イベントのみの概要グラフを作成したい場合は、それぞれの aureport コマンド内に --failed オプションを追加してください。また、特定の時間帯のみに絞りたい場合は、それぞれの aureport コマンド内に -ts および -te オプションを追加してください。また、これらのコマンドラインに grep や egrep を追加して、正規表現で出力をフィルタすることで、さらに細かく調整を行うことができます。詳しくは mkbar スクリプト内のコメントなどをお読みください。また、上記のコマンドラインはいずれも、 PNG ファイルの書かれた棒グラフを生成します。

ユーザとシステムコールなど、様々な監査オブジェクト同士の関係性を可視化したい場合は、 mkgraph などのスクリプトをお使いください。たとえば下記のように実行します:

グラフを組み合わせることで、複雑な関係性を示すこともできます。詳しい情報と使用例については、 mkgraph スクリプト内のコメントをお読みください。また、このスクリプトで生成されるグラフは既定では PostScript 形式ですが、スクリプト内の EXT 変数の内容を ps から png や jpg に変更することで、形式を変更することもできます。