Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
コンテンツコンテンツ
セキュリティ強化ガイド
  1. 前書き
  2. 1 セキュリティと機密保持
  3. 2 コモンクライテリア (Common Criteria)
  4. I 認証
    1. 3 PAM を利用した認証
    2. 4 NIS の使用
    3. 5 YaST を利用した認証クライアントの設定
    4. 6 389 LDAP ディレクトリサービス
    5. 7 Kerberos を利用したネットワーク認証
    6. 8 Active Directory サポート
    7. 9 FreeRADIUS サーバの構築
  5. II ローカルセキュリティ
    1. 10 物理的なセキュリティ
    2. 11 seccheck を利用した自動的なセキュリティチェック
    3. 12 ソフトウエア管理
    4. 13 ファイルの管理
    5. 14 パーティションやファイルの暗号化
    6. 15 cryptctl を利用したアプリケーション向けのストレージ暗号化
    7. 16 ユーザ管理
    8. 17 Spectre/Meltdown チェッカー
    9. 18 YaST を利用したセキュリティの設定
    10. 19 PolKit による認可制御
    11. 20 Linux でのアクセス制御リスト
    12. 21 証明書ストア
    13. 22 AIDE を利用した侵入検知
  6. III ネットワークセキュリティ
    1. 23 X Window System と X 認証
    2. 24 SSH: 機密を保持するネットワーク操作
    3. 25 マスカレードとファイアウオール
    4. 26 VPN サーバの設定
    5. 27 X Window System で動作する PKI マネージャ XCA による管理
  7. IV AppArmor による権限の制限
    1. 28 AppArmor の紹介
    2. 29 入門
    3. 30 プログラムに対する予防接種
    4. 31 プロファイルのコンポーネントと文法
    5. 32 AppArmor のプロファイルリポジトリ
    6. 33 YaST を利用したプロファイルの構築と管理
    7. 34 コマンドラインからのプロファイル構築
    8. 35 チェンジハット機能による Web アプリケーションのプロファイル作成
    9. 36 pam_apparmor によるユーザの制限
    10. 37 プロファイルを作成したアプリケーションの管理
    11. 38 サポート
    12. 39 AppArmor 用語集
  8. V SELinux
    1. 40 SELinux の設定
  9. VI Linux 監査フレームワーク
    1. 41 Linux 監査システムの概要
    2. 42 Linux 監査フレームワークの設定
    3. 43 監査ルールセットの紹介
    4. 44 その他の情報源
  10. A GNU ライセンス
ナビゲーション
適用先 openSUSE Leap 15.2

41 Linux 監査システムの概要

概要

本バージョンの openSUSE Leap に同梱されている Linux 監査フレームワークは、 CAPP (Controlled Access Protection Profiles) 互換の監査システムとして提供され、セキュリティに関連するイベントを確実に収集します。監査記録からは、セキュリティポリシーへの違反有無と、それが誰によって行われたものであるのかを調べることができます。

監査フレームワークは CC-CAPP/EAL (Common Criteria-Controlled Access Protection Profiles/Evaluation Assurance Level) の認証を受ける際に重要な要件となるものです。また、 Common Criteria (CC) for Information Technology Security Information は、独立したセキュリティ評価に対する国際標準です。 Common Criteria の仕組みにより、顧客が任意の IT 製品に対するセキュリティレベルを判断し、ミッションクリティカルな環境への導入を支援することができます。

Common Criteria でのセキュリティ評価には、 2 種類の評価要件セット (機能要件/保証要件) があります。機能要件は評価対象の製品のセキュリティ属性を記述するもので、 Controlled Access Protection Profiles (CAPP) のもとまとめられるものです。一方の保証要件は、 Evaluation Assurance Level (EAL) に従ってまとめられるものです。 EAL は、評価者がセキュリティ属性を判断するにあたって、それが存在し、効果があって、実装されていることを確認するためのすべての作業を記述するものです。この種類の作業には、たとえば開発者によるセキュリティの脆弱性の検索、修正処理、テストなどの文書化が含まれます。

このガイドでは、監査システムの動作概要と、設定方法について説明しています。 Common Criteria に関する一般的な情報については、 コモンクライテリア (Wikipedia) などの情報をお読みください。

Linux 監査システムでは、お使いのシステム内で発生している内容を非常に細かく分析することによって、セキュリティをより強固にする支援を行います。ただし、それ自身でセキュリティが強化されるわけではありません。つまり、コードの誤動作や様々な脆弱性からシステムを保護するわけではありません。その代わり、監査システムではそれらの問題を追跡し、 AppArmor などのそれらを保護するための様々な仕組みを使用するよう促すためのものです。

監査システムは複数のコンポーネントから構成される仕組みですが、それぞれがフレームワーク全体に重要な機能を提供しています。監査システムのカーネルモジュールは、システムコールを中継し、その際に関連するイベントを記録します。また auditd デーモンは、監査レポートをディスクに記録します。このほか、様々なコマンドラインユーティリティを利用することで、監査証跡の表示や問い合わせ、書庫保存などを行うことができます。

監査システムは下記の機能を提供します:

ユーザとプロセスとの関連づけ

監査システムはプロセスとそれを起動したユーザ ID との間の関連づけを行います。これにより、管理者やセキュリティ責任者が、プロセスを所有しているユーザを正確に追跡することができるほか、システム内での不審な動作を検出することができるようになります。

重要
重要: ユーザ ID の名前変更について

監査デーモンは UID の変更を処理しません。そのため、たとえばユーザ名 tux の UID を uid=1001 から uid=2000 に変更したり、廃止したりすることは避けてください。このような作業を行ってしまった場合は、 auditctl データ (監査ルール) を変更する必要が発生してしまうほか、古いデータを正しく取得できなくなってしまうことがあります。

監査証跡の確認

Linux 監査システムでは、監査レポートのディスクへの書き込みのほか、レポートを人間にとって読みやすい形式に変換する処理も行います。

特定の監査イベントの確認

監査システムでは、監査レポート内の特定のイベントのみを抽出するためのユーティリティを提供しています。下記の検索条件を指定することができます:

  • ユーザ

  • グループ

  • 監査 ID

  • リモートホスト名

  • リモートホストアドレス

  • システムコール

  • システムコールのパラメータ

  • ファイル

  • ファイル操作

  • 成功もしくは失敗

選択的監査の適用

監査システムにはフィルタリング機能が用意され、注目対象のイベントに対して監査レポートを作成することができるほか、特定のイベントのみを記録するよう監査システムを構成することもできます。このほか、独自のルールセットを作成して、これらの記録のみを実施するよう監査デーモンを構成することもできます。

レポートデータの可用性の保証

監査レポートは root が所有するもので、 root のみが削除することができます。それ以外のユーザは監査ログを削除できません。

監査データの喪失保護

カーネルのメモリが不足した場合や監査デーモンのバックログが超過した場合、もしくは監査デーモンの流量制限を超過した場合、監査デーモンはシステムのシャットダウンを実施して、監査システムの監視から外れないように設定することができます。このシャットダウンは、監査システムの中枢部からシステムの即時停止を求めるもので、この場合は直近のログがディスクに書き込まれることはありません。既定の設定では、システムの停止ではなく、 syslog への警告記録のみを行うように設定されています。

ログの記録に必要なディスク領域が不足した場合、監査システムに対してクリーンなシャットダウンを求めるように設定することもできます。既定の設定では、ディスク領域が不足した場合、ログを停止するように設定されています。

41.1 Linux 監査システムのコンポーネント紹介

下記の図には、監査システムでの様々なコンポーネントと、相互作用の関係を示しています:

Linux 監査システムのコンポーネント紹介
図 41.1: Linux 監査システムのコンポーネント紹介

実線の矢印はコンポーネント間でのデータの流れを、点線の矢印はコンポーネント間の制御を表わしています。

auditd

監査デーモンは、アプリケーションやシステムの動作によって生成され、監査カーネルインターフェイスを介して提供された監査メッセージを、ディスクに書き込む責任を持つデーモンです。監査デーモンは systemd によって起動されます。監査システムの (起動時の) 設定は、 /etc/audit/auditd.conf で制御します。 auditd に関する詳細情報と設定方法について、詳しくは 41.2項 「監査デーモンの設定」 をお読みください。

auditctl

auditctl ユーティリティは、監査システムを制御するためのユーティリティです。ログ生成に関わるパラメータのほか、監査インターフェイスのカーネル設定や、どのイベントを追跡するかのルールなどを設定することができます。auditctl に関する詳細は、 41.3項 「auditctl による監査システムの制御」 をお読みください。

監査ルール

/etc/audit/audit.rules ファイルには、 auditctl コマンドのシーケンスが含まれていて、監査デーモンの起動直後のシステム起動時に読み込まれる内容が記述されています。監査ルールに関する詳細は、 41.4項 「監査システムに対するパラメータ指定」 をお読みください。

aureport

aureport ユーティリティは、監査イベントログから独自のレポートを作成することができるユーティリティです。このレポート生成は簡単にスクリプトに組み込むことができますし、出力は他のアプリケーションから使用することができる (たとえば結果のグラフ化など) ようになっています。 aureport に関する詳細は、41.5項 「監査ログの仕組みとレポートの生成」 をお読みください。

ausearch

ausearch ユーティリティは監査ログ内を検索するためのユーティリティで、様々なキーを指定してイベントを検索したり、様々なログ形式の属性を指定して検索したりすることができるようになっています。 ausearch に関する詳細は、41.6項 「ausearch による監査デーモンログへの問い合わせ」 をお読みください。

audispd

監査ディスパッチャデーモン ( audispd ) は、監査ログをディスクに書き込む代わりに (もしくはディスクに書き込むのと並行して) 、他のアプリケーションにイベント通知を中継することのできるデーモンです。 audispd に関する詳細は、 41.9項 「監査イベント通知の中継」 をお読みください。

autrace

autracestrace のように、特定のプロセスを追跡するためのユーティリティです。 autrace の出力についても、監査ログに記録されるようになっています。 autrace に関する詳細は、 41.7項 「autrace によるプロセスの解析」 をお読みください。

aulast

last コマンドのように、ユーザが直近にログインした日時を一覧表示します。 aulast は過去の監査ログ (もしくは指定した監査ログファイル) を読み込んで、指定した日時範囲におけるユーザのログインおよびログアウトを一覧で表示します。

aulastlog

lastlog コマンドのように、マシンに対する最新のログイン日時を一覧表示します。ログイン名のほか、ポートと最終ログイン日時が表示されます。

41.2 監査デーモンの設定

監査ログの生成やそのログの処理を行う前に、まずは監査デーモン自身の設定を行います。 設定ファイル /etc/audit/auditd.conf では、デーモンの起動時にどのようにして監査システムを動作させるのかを設定します。ほとんどの用途では、 openSUSE Leap に同梱されている既定の設定のままでかまいません。 CAPP 環境向けに使用する場合は、ほとんどのパラメータに調整が必要です。下記に利用可能なパラメータの主な概要を示します:

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

CAPP の要件を満たすよう環境を設定する必要があるかどうかによって異なりますが、必要である場合は監査デーモンの設定をより厳密に行う必要があります。 CAPP の要件を満たす場合は、 CAPP 環境について と書かれた注記に従って設定を行ってください。

log_file , log_format , log_group

log_file では、監査ログの保存先の場所を指定します。 log_format はディスクへの監査ログの書き込み方法を、 log_group は監査ログを所有するグループの指定をそれぞれ行います。 log_format では raw (カーネルが送信したメッセージをそのまま保存する) か nolog (メッセージを廃棄してディスクには書き込まない) のいずれかを指定します。なお、 nolog を指定しても、監査ディスパッチャへ送信されるデータには影響がありません。既定の設定は raw です。なお、 aureportausearch を使用して、監査ログからレポートを作成したり、監査ログに対して問い合わせを行ったりしたい場合は、監査ログを保存しておく必要があります。また、 log_group ではグループ名のほか、グループ ID で指定することもできます。

注記
注記: CAPP 環境について

CAPP 環境では、監査ログは独自のパーティション内に保存しなければなりません。これを実現するには、まず監査デーモン向けの領域を確認して、他のプロセスからの書き込みが混在していないかどうかをお確かめください。

priority_boost

監査デーモンが獲得する優先度ブースト (nice 値) を指定します。 0 から 20 までの範囲で指定することができます。 nice 値は優先度ブーストの値をマイナスにした値になります。

flush および freq

ディスクに対して監査ログを書き込む際のパラメータ指定を行います。 flush に設定可能な値は none , incremental , data , sync のいずれかです。 none を指定した場合、監査デーモンは監査データをディスクに書き込むにあたって、特に何の処理も行いません。 incremental を指定すると、監査デーモンはディスクに書き込む際、明示的にフラッシュ処理を行います。 incremental を指定した場合は、頻度 (freq) もあわせて設定しなければなりません。たとえば freq20 を指定すると、監査デーモンは 20 レコードごとにカーネルに対してディスクへのフラッシュを要求します。 flushdata を指定すると、データ部分のみのフラッシュを毎回実施し、 sync を指定すると、データとメタデータの両方に対して、フラッシュを毎回実施するようになります。

注記
注記: CAPP 環境について

CAPP 環境では、監査証跡を常に最新に維持しておかなければなりません。そのため、 flush パラメータには sync もしくは data を指定します。

num_logs

max_log_file_actionrotate を指定した場合、どれだけの数のログファイルを残しておくのかを指定します。設定可能な値は 0 から 99 までです。 2 より小さい値を指定すると、ログファイルの切り替えを行わない意味になります。また、残すログの数を増やした場合は、その際に監査デーモンの処理が増えることになります。 auditd がログファイルを切り替える際には、カーネルから届く新しいデータを即時に処理できなくなり、バックログ状態 (auditd が失敗フラグに従って処理を行う状態。詳しくは 41.3項 「auditctl による監査システムの制御」 を参照) になります。このような状況下では、バックログ制限を設定しておくことをお勧めします。バックログ制限は /etc/audit/audit.rules 内の -b の値を変更することで調整することができます。

disp_qos および dispatcher

ディスパッチャは監査デーモンの起動時に開始される仕組みです。監査デーモンは監査メッセージを中継して、 dispatcher 内で指定したアプリケーションにメッセージを渡します。ただし、アプリケーションは root で動作しなければならないものであるため、セキュリティ上の信頼性の高いものでなければなりません。また disp_qos では、監査デーモンとディスパッチャの間の通信手段を指定することができます。 lossy (喪失を許容する) もしくは lossless (喪失を許容しない) のいずれかを指定します。

lossy を選択した場合、監査デーモンはメッセージキューが一杯になると、監査メッセージを廃棄することがあります。これらのイベントは log_formatraw に設定されていればディスク内に書き込まれますが、ディスパッチャには届けられません。逆に lossless を指定すると、メッセージキューに空きがない場合、監査ログのディスクへの書き込みがブロックされるようになります。既定値は lossy です。

name_format および name

name_format はコンピュータ名の解決方法を指定するパラメータです。設定可能な値は、 none (名前解決を行わない), hostname (gethostname で名前を解決する), fqd (DNS 参照を介して完全修飾ドメイン名を取得する), numeric (IP アドレス), user のいずれかです。 user は独自の名前を設定する指定で、その名前を name で指定します。

max_log_file および max_log_file_action

max_log_file は数値を指定するパラメータで、ログファイルの最大ファイルサイズをメガバイト単位で指定します。ここで指定した値に到達した場合に実行される処理を max_log_file_action で指定します。 max_log_file_action に指定可能な値は ignore , syslog , suspend , rotate , keep_logs のいずれかです。 ignore を指定した場合は、サイズ制限に到達しても何も行いません。 syslog は警告メッセージを syslog に対して送信し、 suspend は監査デーモンに対して、ログのディスクへの書き込みを停止させるが、監査デーモンはそのまま動作し続ける意味になります。 rotate を指定すると、 num_logs の設定に従ってログをローテーションします。 keep_logs でも同じようにログをローテーションしますが、この場合は num_log の設定を使用せず、すべてのログを保持する意味になります。

注記
注記: CAPP 環境について

CAPP 環境で監査証跡を完全に残しておくには、 keep_logs を使用すべきです。監査ログ用の個別のパーティションを設定している場合は、 max_log_filenum_logs の設定を調整して、パーティション内の領域をすべて使用するよう設定してください。なお、ローテーションのファイル数が増えると、監査イベントの受信を再開するまでに時間を要することがあることに注意してください。

space_left および space_left_action

space_left は数値を指定するパラメータで、監査デーモンが残り容量を監視する際の閾 (しきい) 値をメガバイト単位で指定します。閾値を超過した際に実行される処理を space_left_action で指定します。このパラメータに指定可能な値は、 ignore , syslog , email , exec , suspend , single , halt のいずれかです。 ignore を指定した場合は、閾値に到達しても何も行いません。 syslog は警告メッセージを syslog に対して送信し、 emailaction_mail_acct で指定したアカウントに対して、電子メールを送信します。 exec は値の後ろにスクリプトのパスを指定することで、そのスクリプトを実行します。なお、スクリプトに対してはパラメータを指定することができませんので、注意してください。 suspend は監査デーモンに対して、ログのディスクへの書き込みを停止させるが、監査デーモンはそのまま動作し続ける意味になります。 single はシステムに対して、シングルユーザモードへの移行を指示します。 halt はシステムを完全にシャットダウンさせる意味になります。

注記
注記: CAPP 環境について

space_left の値を調整して、管理者に対して警告を処理するのに十分な時間を確保するとともに、監査デーモンがその間動作し続けるのに十分な容量を確保するようにしてください。ディスク領域の解放を行うには aureport -t コマンドを使用することができるほか、古いログを別途の書庫用パーティションやリソースにコピーしてもかまいません。 space_left に指定する値は、お使いの環境の用途によって大きく異なります。また、 space_left_actionemail を指定してください。

action_mail_acct

警告メッセージの送信先となる電子メールアドレス、もしくは別名を指定します。既定値は root ですが、その他のローカルアカウントを電子メールアドレスとして指定することができるほか、ネットワークが正しく設定されていて、 /usr/lib/sendmail が存在していれば、リモートのアカウントでもかまいません。

admin_space_left および admin_space_left_action

admin_space_left は数値を指定するパラメータで、ディスク領域の残りをメガバイト単位で指定します。システムがこの制限よりも少ないディスク領域しか残されていない場合、管理者は最後のチャンスとして、この警告に応じて監査ログ向けの空きディスク領域を確保できるようになります。なお、 admin_space_left の値は space_left よりも小さい値であるべきです。 admin_space_left_action に指定可能な値は、 space_left_action と同じです。

注記
注記: CAPP 環境について

管理者の作業内容を記録することができる程度の値を admin_space_left に指定してください。また、 admin_space_left_action single にしてください。

disk_full_action

監査ログ用のディスク領域を使い果たした場合に、システムが取るべきアクションを指定します。指定可能な値は ignore , syslog , rotate , exec , suspend , single , halt のいずれかです。値の詳しい意味については、 space_left および space_left_action をお読みください。

注記
注記: CAPP 環境について

disk_full_action はディスクの空き容量が全く残っていない場合に発動するもので、これ以上の監査ログを書き込むことができない状態であることを示しています。そのため、システムをシングルユーザモードに移行させる ( single ) か、完全にシャットダウン ( halt ) してください。

disk_error_action

監査デーモンがログをディスクに書き込む際、およびログをローテーションする際に、ディスクエラーを検知した場合、どのような処理を行うべきかを指定します。指定可能な値は space_left_action と同じです。

注記
注記: CAPP 環境について

何らかのハードウエア障害に関しては、ご自身のサイト内のポリシーに従って、 syslog , single , halt のいずれかを指定してください。

tcp_listen_port , tcp_listen_queue , tcp_client_ports , tcp_client_max_idle , tcp_max_per_addr

監査デーモンは他の監査デーモンからのイベントを受け付けることもできます。 TCP パラメータは、そのようなイベント受信に関する設定を行います。 tcp_listen_port には、 1 から 65535 までの範囲で、 auditd が接続を待ち受けるべきポートを指定します。 tcp_listen_queue は、待機中として保持すべき最大の接続数を指定します。あまりにも小さい値を指定してしまうと、たとえばサイト内の停電時など、一斉に監査イベントを受信するような場合に耐えられなくなってしまいます。 tcp_client_ports では、クライアント側で許可するポート範囲を指定します。ここでは単一のポート番号のほか、ハイフンで区切って複数のポートを指定することもできます (たとえば 1-1023 のように指定すると、いわゆる特権ポートからの接続のみを受け付けることになります) 。

なお、この設定で単一のポートだけを指定してしまうと、クライアント側の監査システムを再起動するのが難しくなってしまいます。なぜなら、同じアドレスの同じポート番号は、しばらくの間 TIME_WAIT 状態に遷移するため、再利用できなくなるためです。クライアント側の監査デーモンの応答がなくなってしまった場合は、 auditd がその旨を警告します。また、サーバ側で通信のない状態を検知して自動切断したい場合は、 tcp_client_max_idle を指定してください。なお、この設定はすべてのクライアントに対して適用されるため、クライアント側のハートビート設定の 2 倍程度か、それより大きい値を指定してください。 tcp_max_per_addr では、同一の IP アドレスからの同時接続許可数を数値で指定します。

ヒント
ヒント

監査デーモンへの接続の際、 root (CAP_NET_BIND_SERVICE) 以外からの接続を拒否する目的で、サーバもクライアントも特権ポートを使用することをお勧めします。

/etc/audit/auditd.conf でのデーモン設定が完了したら、次は監査デーモンが監査する範囲の制御と、デーモンが適切に動作するために必要な十分なリソースの割り当てと制限を行います。

41.3 auditctl による監査システムの制御

auditctl は状態の制御のほか、監査デーモンの基本的なシステムパラメータを設定することができます。このほか、システム内で実施される監査範囲の制御を行うこともできます。監査ルールを使用することで、 auditctl はお使いのシステム内のどのコンポーネントを監査するのか、およびどの範囲までを監査するのかを制御することができます。監査ルールは auditctl コマンドを使用してコマンドラインから渡すことができるほか、ルールセットを作成して監査デーモン側で処理させることもできます。既定では、 auditd/etc/audit/audit.rules にある監査ルールを使用するようになっています。監査ルールに関する詳細は、 41.4項 「監査システムに対するパラメータ指定」 をお読みください。

基本的な監査システムパラメータを制御するための主な auditctl コマンドは下記のとおりです:

  • auditctl -e: 監査の有効化と無効化

  • auditctl -f: 失敗フラグの制御

  • auditctl -r: 監査メッセージの流量制限の制御

  • auditctl -b: バックログ制限の制御

  • auditctl -s: 監査デーモンに関する現在の状態の表示

  • auditctl -S では監査対象とするシステムコールを指定します。なお、お使いのシステムで auditctl -S を実行する際は、 -F arch=b64 を指定して、アーキテクチャの間違いに関する警告が発生しないようにしてください。

-e , -f , -r , -b オプションは audit.rules ファイル内でも指定することができます。これにより、監査デーモンの起動時に毎回入力するような手間を省くことができます。

auditctl -s で監査デーモンの状態を問い合わせる場合や、 auditctl -eフラグ で状態フラグを変更する場合は、状態メッセージ (上述のパラメータに関する情報を含む) が出力されます。下記は、一般的な監査状態のメッセージ例を示しています。

例 41.1: auditctl -s の出力例
enabled 1
failure 1
pid 790
rate_limit 0
backlog_limit 64
lost 0
backlog 0
backlog_wait_time 15000
loginuid_immutable 0 unlocked
表 41.1: 監査状態フラグ

フラグ

意味 [取り得る値]

コマンド

enabled

有効化フラグを設定します。 [0..2] 0=無効, 1=有効, 2=有効にして設定をロックダウンします。なお、この有効化フラグはシステムコールのログにのみ適用されるものであり、その他のイベントについては効果がありません (詳しくはaudit-devel パッケージ内の man 3 audit_set_enabled をお読みください) 。

auditctl -e [0|1|2]

flag

失敗フラグを設定します。 [0..2] 0=何もしない, 1=printk, 2=panic (ディスクへの書き込み待ちのデータを書き込むことなく、即時に停止する)

auditctl -f [0|1|2]

pid

auditd のプロセス ID を表わします。

rate_limit

メッセージの流量制限 (毎秒メッセージ数) を設定します。この値にゼロより大きい値が設定され、その値を超過した場合は、失敗フラグ内で設定した動作を実行します。

auditctl -r 流量

backlog_limit

未処理の監査バッファの最大サイズを指定します。すべてのバッファが使用中になると、失敗フラグ内で設定した動作を実行します。

auditctl -b バックログ

lost

現時点までに喪失した監査メッセージの数を表わします。

backlog

現時点での未処理の監査バッファ数を表わします。

41.4 監査システムに対するパラメータ指定

監査システムに対するコマンドは auditctl コマンドを利用してシェルから個別に実行することもできますし、 auditctl - R のように指定して、ファイルから読み込んで一括処理することもできます。後者のやり方は起動時のスクリプトでも使用していて、監査デーモンの起動後に、 /etc/audit/audit.rules ファイルからルールを読み込む目的で使用しています。ルールは上から順に実行されます。それぞれのルールは、それぞれが auditctl のコマンドに展開されます。ルールファイル内で使用する書式は、 auditctl コマンドと同じです。

動作中の監査システムを auditctl で設定変更しても、その変更点はシステムの再起動で失われてしまいます。恒久的に変更したい場合は、 /etc/audit/audit.rules ファイルに追加するとともに、現時点で監査デーモン内に読み込まれていない場合は、 systemctl restart auditd を実行して、監査システムを再起動してください。

例 41.2: 監査ルール例: 監査システムのパラメータ
-b 10001
-f 12
-r 103
-e 14

1

未処理の監査バッファの最大数を指定しています。ログの発生頻度にも依存しますが、監査の負荷がシステムにとって重すぎない程度の値に設定してください。

2

使用する失敗フラグを指定しています。指定可能な値は 表41.1「監査状態フラグ」 をご覧ください。

3

カーネル側で発信される最大流量のメッセージ数を指定しています。詳しくは 表41.1「監査状態フラグ」 をご覧ください。

4

監査サブシステムの有効化/無効化を設定しています。

監査の仕組みを使用することで、重要なファイルや設定、リソースなどのファイルシステムアクセスを追跡することができるようになります。また、これらに対して監視を設定してキーを割り当てることで、ログ内でより見つけやすくすることができます。

例 41.3: 監査ルール例: ファイルシステムの監査
-w /etc/shadow1
-w /etc -p rx2
-w /etc/passwd -k fk_passwd -p rwxa3

1

-w オプションは、指定したファイル (この例では /etc/shadow) に対する監視を監査システムに設定しています。このファイルに対するアクセス許可要求に関わるすべてのシステムコールが、分析の対象となります。

2

このルールは /etc ディレクトリに対する監視を追加していて、読み込みと実行のアクセスに対するフィルタリングを設定 ( -p rx ) しています。これら 2 種類の許可に関わるシステムコールが分析の対象となります。ディレクトリに対する監視では、新しいファイルの作成と既存のファイルの削除のみが記録の対象となります。特定のディレクトリ内にあるファイルに対して、より詳しいイベントを監視したい場合は、それぞれのファイルに対してルールを作成してください。ただし、監視を設定する前に、あらかじめファイルが存在していなければなりません。なお、ファイル作成時点からの監査には対応していません。

3

このルールは、 /etc/passwd ファイルに対する監視を追加しています。このとき、読み込みと書き込み、実行と属性変更を監視しています。 -k オプションを指定すると、後から特定のイベントを検索する (たとえば ausearchなど) 目的で、監査ログ内にキーを書き込むことができます。なお、複数のルールに対して同じキーを指定しておくことで、それらをまとめて出力することもできるようになります。逆に、 1 つのルールに複数のキーを設定することもできます。

システムコールの監査では、アプリケーションよりも下のレベルで、システムの動作を追跡することができます。これらのルールを設計する際は、多数のシステムコールに対して監査を行うと、システムの負荷が上昇するだけでなく、ディスク領域も不足する危険性があることに注意してください。追跡対象のイベントと、それらのフィルタリング方法については、より具体的に設定するようにしてください。

例 41.4: 監査ルール例: システムコールの監査
-a exit,always -S mkdir1
-a exit,always -S access -F a1=42
-a exit,always -S ipc -F a0=23
-a exit,always -S open -F success!=04
-a task,always -F auid=05
-a task,always -F uid=0 -F auid=501 -F gid=wheel6

1

このルールは mkdir システムコールに対する監査を設定しています。 -a オプションは、システムコールルールを追加するためのオプションです。この監査は、 mkdir システムコールが実行されるたびに毎回 ( exit , always ) 行われます。また、 -S オプションでは、このルールの適用先となるシステムコール名を指定しています。

2

このルールは access システムコールに対する監査を設定していますが、システムコールの 2 番目のパラメータ ( mode ) が 4 ( R_OK ) である場合にのみ監査を行っています。 exit,always は監査システムに対して、このシステムコールへの突入時に監査コンテキストを追加し、監査発生時にレポートを書き出すように指定しています。

3

このルールは IPC 多重化システムコールに対して監査コンテキストを設定しています。特定の ipc システムコールは最初の syscall パラメータとして渡され、 -F a0=IPC_コール番号 の指定で選択することができます。

4

このルールは open システムコールが失敗した場合に対する監査を設定しています。

5

このルールはタスクルール (キーワード: task ) の例です。これはこれまでのルールとは異なり、 fork や clone されるプロセスに適用されます。これらの種類のイベントにフィルタを設定したい場合は、 fork の時点で既知の状態にあるフィールドのみを使用することができます。具体的には UID, GID, AUID です。この例では、監査 ID が 0 であるすべてのタスクに対して監査を行っています。

6

最後のルールはフィルタを複雑に設定した場合の例です。すべてのフィルタオプションが組み合わせられていて、それらを論理積 (AND) で結んでいます。つまり、このルールは監査 ID が 501 であり、 root で実行され、かつグループが wheel であるものに適用されます。監査 ID はユーザのログイン時にプロセスに対して設定されます。この ID は、そのユーザの初期プロセスから起動されたすべての子プロセスに渡されます。ユーザが自身の識別情報を変更した場合でも、監査 ID は変わらずそのままであり続けるため、元のユーザの動きをそのまま追跡できることになります。

ヒント
ヒント: システムコールパラメータのフィルタリングについて

システムコールパラメータのフィルタリングについて、詳しくは 43.6項 「システムコールのパラメータでのフィルタリング」 をお読みください。

監査システムにはルールを追加するだけでなく、ルールを削除することもできます。ルール全体を一括で削除することができるほか、個別のシステムコールルールやファイル/ディレクトリの監視ルールを削除することができます:

例 41.5: 監査ルールとイベントの削除
-D1
-d exit,always -S mkdir2
-W /etc3

1

監査ルールのキューを消去して、既存のルールをすべて削除します。このルールは /etc/audit/audit.rules 内の冒頭で使用すべきもので、ルールを適用し直す際に、それまでに存在したルールをいったん削除するために設定します。もちろん auditctl -D のように入力して実行し、 autrace を実行する前に audit.rules 内にある既存のトレース規則をいったん削除しておくような使い方もできます。

2

このルールでは、システムコールのルールを削除しています。ルールキューから削除する必要のあるシステムコールを指定する場合は、その前に -d オプションを指定する必要があるほか、 -d は正確にマッチするものでなければなりません。

3

このルールでは、監査システムのルールキューから /etc ディレクトリに対するルールを破棄するよう指定しています。このルール削除では、パーミッションのフィルタリングやキーのオプション指定にかかわらず、すべての /etc を含むディレクトリの監視を削除します。

現時点での監査設定で使用しているルールの概要を知りたい場合は、 auditctl -l と入力して実行します。このコマンドは、 1 ルールあたり 1 行で表示します。

例 41.6: auditctl -l によるルール一覧の表示
exit,always watch=/etc perm=rx
exit,always watch=/etc/passwd perm=rwxa key=fk_passwd
exit,always watch=/etc/shadow perm=rwxa
exit,always syscall=mkdir
exit,always a1=4 (0x4) syscall=access
exit,always a0=2 (0x2) syscall=ipc
exit,always success!=0 syscall=open
注記
注記: フィルタルールの作成について

様々なフィルタオプションを組み合わせることで、より洗練された監査ルールを構築することができます。監査フィルタルールを構築する際に利用可能なオプションのほか、一般的な監査ルールに関する詳細については、 auditctl(8) のマニュアルページをお読みください。

41.5 監査ログの仕組みとレポートの生成

aureport ユーティリティが何かをするものなのかを知るには、まず監査デーモンが生成するログの構造について知っておく必要があるほか、イベント内にどのような情報が存在するのかを知っておく必要があります。これにより、要件に対応できる最適なレポートタイプを判断することができるようになります。

41.5.1 監査ログの仕組み

下記の例には、監査デーモンが記録した 2 種類の典型的なイベントと、それらの証跡が示されています。監査ログは、ローテーションしたものを含め、 /var/log/audit 内に保存されます。最初の例はシンプルな less コマンドの例です。 2 つ目の例は、監査デーモンが動作しているマシンに対して、ユーザがリモートからログインしようとしている際の PAM の動作に対して、記録されているログを示しています。

例 41.7: シンプルな監査イベント例: 監査ログの表示
type=SYSCALL msg=audit(1234874638.599:5207): arch=c000003e syscall=2 success=yes exit=4 a0=62fb60 a1=0 a2=31 a3=0 items=1 ppid=25400 pid
=25616 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1164 comm="less" exe="/usr/bin/less" key="doc_log"
type=CWD msg=audit(1234874638.599:5207):  cwd="/root"
type=PATH msg=audit(1234874638.599:5207): item=0 name="/var/log/audit/audit.log" inode=1219041 dev=08:06 mode=0100644 ouid=0 ogid=0 rdev=00:00

上記のイベントは less /var/log/audit/audit.log を実行した場合のログで、 3 種類のメッセージが記録されています。これらのすべては密接にリンクしているため、その他の情報が無ければ意味を理解するのが難しいものと思います。最初のメッセージには下記の情報が記録されています:

type

記録されたイベントの種類を示しています。この場合は SYSCALL という種類で、システムコールによる記録であることを示しています。それ以外には CWD という種類のイベントもあり、これはシステムコール時点でのカレントディレクトリを示しています。次の PATH という種類のイベントは、システムコールに渡されたパスに関する情報が示されています。 open システムコールは 1 つのパラメータを取るシステムコールであることから、 PATH イベントも 1 つだけ生成されます。ここで重要となるのが、 PATH イベントはパス名の文字列パラメータを報告するだけで、それ以外の解釈については何も行わないものである点です。そのため、相対パスを指定した場合は、 CWD のイベントで示されたカレントディレクトリの情報とあわせて、手作業で絶対パスに戻さなければならないことになります。

msg

括弧内にはメッセージ ID が書かれています。メッセージ ID は 2 種類のパーツから構成されていて、 : の前は Unix エポックタイムを、後ろは実際のイベント ID を表わしています。同じシステムコール内であれば、同じイベント ID が割り当てられます。アプリケーションがさらに別のシステムコールを行うと、イベント ID が新たに割り当てられます。

arch

システムコールに対応する CPU アーキテクチャを示しています。この情報は ausearch コマンドでログを検索する際、 -i オプションを指定するとデコードすることができます。

syscall

このシステムコールに対して strace で表示することのできる、システムコールの種類を表わしています。このデータは /usr/include/asm/unistd.h ファイル内に示されていて、アーキテクチャによって番号体系が異なります。このアーキテクチャでは、 syscall=2 は open システムコール (詳しくは man open(2) をお読みください) を表わしています。

success

システムコールが成功したか、失敗したかを示しています。

exit

システムコールの返り値を表わしています。この例では open システムコールに対する返り値ですが、これは作成されたファイルディスクリプタ番号を表わしています。返り値の意味はシステムコールによって異なります。

a0 から a3

数値形式で表現された、システムコールの最初の 4 つのパラメータです。これらはシステムコールによって異なる解釈になります。この例 (open システムコール) では、下記のように解釈します:

a0=62fb60 a1=8000 a2=31 a3=0

a0 はパス名の開始アドレスを表わしています。 a1 はフラグを表わしていて、 16 進数の 8000 は 8 進数でいうと 100000 にあたることから、 O_LARGEFILE というフラグを指定していることになります。また a2 はモード指定で、 O_CREAT を指定していないことから、使用していないパラメータであることがわかります。 a3open システムコールでは使用していないパラメータです。それぞれのパラメータの意味については、マニュアルページをお読みください。

items

アプリケーションに渡された文字列の数を表わしています。

ppid

このプロセスの親のプロセス ID を表わしています。

pid

このプロセスのプロセス ID を表わしています。

auid

監査 ID を表わしています。監査 ID はユーザのログイン時にプロセスに対して設定されます。この ID は、そのユーザの初期プロセスから起動されたすべての子プロセスに渡されます。ユーザが自身の識別情報を変更した場合 (たとえば root になった場合) でも、監査 ID は変わらずそのままであり続けるため、元のユーザの動きをそのまま追跡できることになります。

uid

プロセスを起動したユーザの実ユーザ ID を表わしています。この場合は 0 であることから、 root であることになります。

gid

プロセスを起動したユーザの実グループ ID を表わしています。この場合は 0 であることから、 root であることになります。

euid , suid , fsuid

プロセスを起動したユーザの実効ユーザ ID, Set User ID, ファイルシステムユーザ ID をそれぞれ表わしています。

egid , sgid , fsgid

プロセスを起動したユーザの実効グループ ID, Set Group ID, ファイルシステムグループ ID をそれぞれ表わしています。

tty

アプリケーションを起動した端末を表わしています。この場合は、 SSH セッション内で疑似端末 (pts) を使用していることを表わしています。

ses

ログインセッション ID を表わしています。このプロセス属性はユーザのログイン時に設定されるほか、どのプロセスも特定のユーザログインに結びつけることができます。

comm

タスクリストに表示されるアプリケーション名を表わしています。

exe

バイナリプログラムに対する解決済みパス名を表わしています。

subj

auditd は、プロセスに対して AppArmor などのセキュリティコンテキストが割り当てられている場合、その内容を記録することができます。この場合は unconstrained になっていますが、これは AppArmor でプロセスが保護されていないことを表わしています。プロセスが何らかの制限を受けた場合、バイナリパス名と AppArmor のプロファイルモードも記録されます。

key

多数のディレクトリやファイルに対して監査を行っている際、監視対象の判別用にキー文字列を指定することができます。これらのキーを ausearch に指定すると、そのキーに合致するもののみを表示することができます。

less コマンドが生成した 2 つ目のメッセージには、 less コマンドを実行した時点でのカレントディレクトリを表わしています。

3 つ目のメッセージの意味は下記のとおりです (typemessage のフラグは既に説明しているとおりです):

item

この例では、 itema0 パラメータを表わしています。ここには元々の SYSCALL メッセージ内に対応する、パス名が書かれています。 cpmv などのように、複数のパスパラメータを指定する場合は、さらに PATH イベントが生成されて記録されることになります。

name

open システムコールのパラメータとして渡されたパス名を表わしています。

inode

name に対応する inode 番号を表わしています。

dev

ファイルが保存されているデバイスを表わしています。この場合、 08:06 と書かれていますので、 /dev/sda1 もしくは 最初の IDE デバイス上の最初のパーティション であることを示しています。

mode

ファイルのアクセス許可を数値で表現したものです。この場合は root が読み書きの権限を持ち、グループ (root) は読み込みのみ、その他のユーザはファイルへのアクセス権を持たない設定になっています。

ouidogid

inode が指し示すものに対する UID と GID を表わしています。

rdev

この例では意味を持たないものです。 rdev はブロックデバイスやキャラクタデバイスの場合にのみ意味を持つもので、ファイルでは意味を持ちません。

例41.8「複雑な監査イベント例: SSH でのログイン」 には、 SSH 接続を受け付けた際の監査イベントを示しています。ほとんどのメッセージは PAM スタックに関連するもので、 SSH PAM の処理における様々なステージを表わしています。また、いくつかの監査メッセージは入れ子になっていて、それぞれの PAM の処理段階を示しています。監査システムでは PAM の処理についても記録を行いますが、独自のメッセージタイプが割り当てられます:

例 41.8: 複雑な監査イベント例: SSH でのログイン
type=USER_AUTH msg=audit(1234877011.791:7731): user pid=26127 uid=0 1
auid=4294967295 ses=4294967295 msg='op=PAM:authentication acct="root" exe="/usr/sbin/sshd"
(hostname=jupiter.example.com, addr=192.168.2.100, terminal=ssh res=success)'
type=USER_ACCT msg=audit(1234877011.795:7732): user pid=26127 uid=0 2
auid=4294967295 ses=4294967295 msg='op=PAM:accounting acct="root" exe="/usr/sbin/sshd"
(hostname=jupiter.example.com, addr=192.168.2.100, terminal=ssh res=success)'
type=CRED_ACQ msg=audit(1234877011.799:7733): user pid=26125 uid=0 3
auid=4294967295 ses=4294967295 msg='op=PAM:setcred acct="root" exe="/usr/sbin/sshd"
(hostname=jupiter.example.com, addr=192.168.2.100, terminal=/dev/pts/0 res=success)'
type=LOGIN msg=audit(1234877011.799:7734): login pid=26125 uid=0
old auid=4294967295 new auid=0 old ses=4294967295 new ses=1172
type=USER_START msg=audit(1234877011.799:7735): user pid=26125 uid=0 4
auid=0 ses=1172 msg='op=PAM:session_open acct="root" exe="/usr/sbin/sshd"
(hostname=jupiter.example.com, addr=192.168.2.100, terminal=/dev/pts/0 res=success)'
type=USER_LOGIN msg=audit(1234877011.823:7736): user pid=26128 uid=0 5
auid=0 ses=1172 msg='uid=0: exe="/usr/sbin/sshd"
(hostname=jupiter.example.com, addr=192.168.2.100, terminal=/dev/pts/0 res=success)'
type=CRED_REFR msg=audit(1234877011.828:7737): user pid=26128 uid=0 6
auid=0 ses=1172 msg='op=PAM:setcred acct="root" exe="/usr/sbin/sshd"
(hostname=jupiter.example.com, addr=192.168.2.100, terminal=/dev/pts/0 res=success)'

1

リモートのホスト (jupiter.example.com, 192.168.2.100) から root に対してユーザ認証が求められ、それが成功したことを PAM が報告しています。ここで使用されている端末は ssh になっています。

2

PAM は、ユーザにログイン権限があることを確認した、と報告しています。

3

PAM はログインにあたって適切な資格情報が必要である旨を報告するとともに、端末が通常の端末 ( /dev/pts0 ) に変更されたことを報告しています。

4

PAM は、 root に対してセッションを開くことができたことを報告しています。

5

ユーザのログインが成功したことを示しています。このイベントは aureport -l でユーザログイン情報を報告させる際に、使用されるイベントです。

6

PAM は資格情報を再取得したことを報告しています。

41.5.2 独自の監査レポートの生成

/var/log/audit ディレクトリ内にある未加工の監査レポートは、非常にかさばって理解しにくいものになってしまっています。必要なメッセージを簡単に取得できるようにするには、 aureport ユーティリティを利用して、独自にレポートを作成してください。

下記の利用例では、 aureport で生成することのできる、いくつかのレポートタイプについて説明しています:

他のファイルからの監査ログ読み込み

監査ログを他のマシンに移動させた場合や、それぞれのマシンに接続することなく、ローカルのマシン内で複数のマシンの監査ログを分析したりしたい場合は、対象となるログファイルをローカルに移動したあと、 aureport を利用してローカルで分析してください:

tux > sudo aureport -if myfile

Summary Report
======================
Range of time in logs: 2009年02月03日 14:13:38.225 - 2009年02月17日 14:52:27.971
Selected time for report: 2009年02月03日 14:13:38 - 2009年02月17日 14:52:27.971
Number of changes in configuration: 13
Number of changes to accounts, groups, or roles: 0
Number of logins: 6
Number of failed logins: 13
Number of authentications: 7
Number of failed authentications: 573
Number of users: 1
Number of terminals: 9
Number of host names: 4
Number of executables: 17
Number of files: 279
Number of AVC's: 0
Number of MAC events: 0
Number of failed syscalls: 994
Number of anomaly events: 0
Number of responses to anomaly events: 0
Number of crypto events: 0
Number of keys: 2
Number of process IDs: 1211
Number of events: 5320

上記のコマンドでは aureport に何もパラメータを指定しておらず、 myfile 内に含まれているログ情報から、標準的で一般的な概要レポートのみを生成するように指定しています。より詳しいレポートを作成したい場合は、 -if オプションに加えて、必要なオプションを指定してください。たとえば特定の時間帯のログインレポートのみを生成したい場合は、下記のように入力して実行します:

tux > sudo aureport -l -ts 14:00 -te 15:00 -if myfile

Login Report
============================================
# date time auid host term exe success event
============================================
1. 2017年02月09日 14:21:09 root: 192.168.2.100 sshd /usr/sbin/sshd no 7718
2. 2017年02月09日 14:21:15 0 jupiter /dev/pts/3 /usr/sbin/sshd yes 7724
数値表現の文字列変換

ユーザ ID などの情報は数値で出力されます。これらを読みやすいテキスト形式に変換するには、 aureport コマンドに -i オプションを追加してください。

大まかな概要レポートの作成

現在の監査統計情報 (イベント数, ログイン数, プロセス数など) のみを知りたい場合は、 aureport に何もパラメータを指定せずに実行してください。

失敗イベントの概要レポートの作成

純粋な aureport の概要統計情報を失敗イベントのみの統計情報に変更したい場合は、 aureport --failed のように入力して実行します:

tux > sudo aureport --failed

Failed Summary Report
======================
Range of time in logs: 2009年02月03日 14:13:38.225 - 2009年02月17日 14:57:35.183
Selected time for report: 2009年02月03日 14:13:38 - 2009年02月17日 14:57:35.183
Number of changes in configuration: 0
Number of changes to accounts, groups, or roles: 0
Number of logins: 0
Number of failed logins: 13
Number of authentications: 0
Number of failed authentications: 574
Number of users: 1
Number of terminals: 5
Number of host names: 4
Number of executables: 11
Number of files: 77
Number of AVC's: 0
Number of MAC events: 0
Number of failed syscalls: 994
Number of anomaly events: 0
Number of responses to anomaly events: 0
Number of crypto events: 0
Number of keys: 2
Number of process IDs: 708
Number of events: 1583
成功イベントの概要レポートの作成

純粋な aureport の概要統計情報を成功イベントのみの統計情報に変更したい場合は、 aureport --success のように入力して実行します:

tux > sudo aureport --success

Success Summary Report
======================
Range of time in logs: 2009年02月03日 14:13:38.225 - 2009年02月17日 15:00:01.535
Selected time for report: 2009年02月03日 14:13:38 - 2009年02月17日 15:00:01.535
Number of changes in configuration: 13
Number of changes to accounts, groups, or roles: 0
Number of logins: 6
Number of failed logins: 0
Number of authentications: 7
Number of failed authentications: 0
Number of users: 1
Number of terminals: 7
Number of host names: 3
Number of executables: 16
Number of files: 215
Number of AVC's: 0
Number of MAC events: 0
Number of failed syscalls: 0
Number of anomaly events: 0
Number of responses to anomaly events: 0
Number of crypto events: 0
Number of keys: 2
Number of process IDs: 558
Number of events: 3739
概要レポートの作成

専用の概要レポート (全体概要/失敗概要/成功概要) に加えて、 --summary オプションと他のオプションを併用することで、指定した分野のみの概要レポートを作成することもできます。ただし、すべてのオプションがレポートに対応しているわけではありません。この例では、ユーザのログインイベントに関する概要レポートを作成しています:

tux > sudo aureport -u -i --summary

User Summary Report
===========================
total  auid
===========================
5640  root
13  tux
3  wilber
イベント一覧レポートの作成

監査デーモンが記録したイベントの概要を取得するには、 aureport -e コマンドを使用します。このコマンドは順序番号付きのリストで、すべてのイベントに対する日付と時刻、イベント番号と種類、そして監査 ID を出力します。

tux > sudo aureport -e -ts 14:00 -te 14:21

Event Report
===================================
# date time event type auid success
===================================
1. 2009年02月17日 14:20:27 7462 DAEMON_START 0 yes
2. 2009年02月17日 14:20:27 7715 CONFIG_CHANGE 0 yes
3. 2009年02月17日 14:20:57 7716 USER_END 0 yes
4. 2009年02月17日 14:20:57 7717 CRED_DISP 0 yes
5. 2009年02月17日 14:21:09 7718 USER_LOGIN -1 no
6. 2009年02月17日 14:21:15 7719 USER_AUTH -1 yes
7. 2009年02月17日 14:21:15 7720 USER_ACCT -1 yes
8. 2009年02月17日 14:21:15 7721 CRED_ACQ -1 yes
9. 2009年02月17日 14:21:15 7722 LOGIN 0 yes
10. 2009年02月17日 14:21:15 7723 USER_START 0 yes
11. 2009年02月17日 14:21:15 7724 USER_LOGIN 0 yes
12. 2009年02月17日 14:21:15 7725 CRED_REFR 0 yes
すべてのプロセスイベントからのレポート作成

プロセスの観点からログを分析したい場合は、 aureport -p コマンドを使用します。このコマンドは順序番号付きのリストで、プロセス関連のイベントを列挙します。これには日付と時刻、プロセス ID と実行ファイルの名前、システムコールと監査 ID 、イベント番号が含まれます。

aureport -p

Process ID Report
======================================
# date time pid exe syscall auid event
======================================
1. 2009年02月13日 15:30:01 32742 /usr/sbin/cron 0 0 35
2. 2009年02月13日 15:30:01 32742 /usr/sbin/cron 0 0 36
3. 2009年02月13日 15:38:34 32734 /usr/lib/gdm/gdm-session-worker 0 -1 37
すべてのシステムコールイベントからのレポート作成

システムコールの観点からログを分析したい場合は、 aureport -s コマンドを使用します。このコマンドは順序番号付きのリストで、システムコール関連のイベントを列挙します。これには日付と時刻、システムコールの回数とそのコールを使用したコマンドの名前、監査 ID とイベント番号が含まれます。

tux > sudo aureport -s

Syscall Report
=======================================
# date time syscall pid comm auid event
=======================================
1. 2009年02月16日 17:45:01 2 20343 cron -1 2279
2. 2009年02月16日 17:45:02 83 20350 mktemp 0 2284
3. 2009年02月16日 17:45:02 83 20351 mkdir 0 2285
すべての実行ファイルイベントからのレポート作成

実行ファイルの観点からログを分析したい場合は、 aureport -x コマンドを使用します。このコマンドは順序番号付きのリストで、実行ファイル関連のイベントを列挙します。これには日付と時刻、実行ファイルの名前と実行していた端末、実行していたホストと監査 ID 、イベント番号が含まれます。

aureport -x

Executable Report
====================================
# date time exe term host auid event
====================================
1. 2009年02月13日 15:08:26 /usr/sbin/sshd sshd 192.168.2.100 -1 12
2. 2009年02月13日 15:08:28 /usr/lib/gdm/gdm-session-worker :0 ? -1 13
3. 2009年02月13日 15:08:28 /usr/sbin/sshd ssh 192.168.2.100 -1 14
ファイルに関するレポート作成

ファイルアクセスの観点からログを分析したい場合は、 aureport -f コマンドを使用します。このコマンドは順序番号付きのリストで、アクセスしているファイル、アクセスに使用したシステムコールの数と成功可否、実行ファイルと監査 ID 、イベント番号が含まれます。

tux > sudo aureport -f

File Report
===============================================
# date time file syscall success exe auid event
===============================================
1. 2009年02月16日 17:45:01 /etc/shadow 2 yes /usr/sbin/cron -1 2279
2. 2009年02月16日 17:45:02 /tmp/ 83 yes /bin/mktemp 0 2284
3. 2009年02月16日 17:45:02 /var 83 no /bin/mkdir 0 2285
ユーザに関するレポートの作成

システム内で、どのユーザが何の実行ファイルを実行させたのかを監査ログから調べ、レポートとしてまとめたい場合は、 aureport -u コマンドを使用します。このコマンドは順序番号付きのリストで、日付や時刻、監査 ID や使用した端末とホスト、実行ファイルの名前とイベント ID がそれぞれ示されます。

aureport -u

User ID Report
====================================
# date time auid term host exe event
====================================
1. 2009年02月13日 15:08:26 -1 sshd 192.168.2.100 /usr/sbin/sshd 12
2. 2009年02月13日 15:08:28 -1 :0 ? /usr/lib/gdm/gdm-session-worker 13
3. 2009年02月13日 08:25:39 -1 ssh 192.168.2.101 /usr/sbin/sshd 14
ログインに関するレポートの作成

マシンに対するログイン試行に着目してレポートを作成するには、 aureport -l コマンドを使用します。このコマンドは順序番号付きのリストで、日付や時刻、監査 ID や使用したホストおよび端末、実行ファイルの名前と試行の成功可否、イベント ID がそれぞれ含まれる、ログイン関連のレポートを生成します。

tux > sudo aureport -l -i

Login Report
============================================
# date time auid host term exe success event
============================================
1. 2009年02月13日 15:08:31 tux: 192.168.2.100 sshd /usr/sbin/sshd no 19
2. 2009年02月16日 12:39:05 root: 192.168.2.101 sshd /usr/sbin/sshd no 2108
3. 2009年02月17日 15:29:07 geeko: ? tty3 /bin/login yes 7809
特定の時刻範囲に限定したレポート作成

特定の時刻範囲に限定してログを分析したい場合、たとえば 2009 年 2 月 16 日の日中時間帯のみを調べたい場合は、まず対象のデータが現在の audit.log 内に含まれているか、それとも既にローテーションされてしまったものかどうかを確認します。これは aureport -t を実行することで判別することができます。

aureport -t

Log Time Range Report
=====================
/var/log/audit/audit.log: 2009年02月03日 14:13:38.225 - 2009年02月17日 15:30:01.636

現在の audit.log ファイル内に必要な時間帯のデータがすべて含まれていれば、通常通りにレポートを作成します。そうでない場合は、 aureport コマンドに -if オプションを指定し、必要なデータを含むログファイルを指定します。

あとは開始日時と終了日時を指定して、作成するレポートの種類を選ぶオプションを加えます。下記の例では、ログイン試行に着目してレポートを作成しています:

tux > sudo aureport -ts 02/16/09 8:00 -te 02/16/09 18:00 -l

Login Report
============================================
# date time auid host term exe success event
============================================
1. 2009年02月16日 12:39:05 root: 192.168.2.100 sshd /usr/sbin/sshd no 2108
2. 2009年02月16日 12:39:12 0 192.168.2.100 /dev/pts/1 /usr/sbin/sshd yes 2114
3. 2009年02月16日 13:09:28 root: 192.168.2.100 sshd /usr/sbin/sshd no 2131
4. 2009年02月16日 13:09:32 root: 192.168.2.100 sshd /usr/sbin/sshd no 2133
5. 2009年02月16日 13:09:37 0 192.168.2.100 /dev/pts/2 /usr/sbin/sshd yes 2139

開始日時は -ts で指定します。指定した日時と同じか、それより後のイベントがレポート内に出力されます。日付部分を省略した場合、 aureport今日 を指定したものとして扱います。時刻部分を省略した場合は、日付の切り替わった深夜を開始時刻として指定したものとして扱います。 なお、日付は // の形式で指定することに注意してください。

終了日時は -te で指定します。指定した日時と同じか、それより前のイベントがレポート内に出力されます。日付を省略した場合、 aureport今日 を指定したものとして扱います。また、時刻部分を省略した場合、 aureport現在時刻 を指定したものとして扱います。指定可能な書式は -ts と同じです。

概要を除き、レポートは表形式で標準出力に出力されます。つまり、出力された情報を他のコマンドに取り込むことが用意であることになります。たとえば 41.8項 「監査データの可視化」 で紹介されている可視化スクリプトを使用すると、監査デーモンが生成したデータをさらに詳しく処理することができます。

41.6 ausearch による監査デーモンログへの問い合わせ

aureport では、システム内で何が起こっているのかを概要レベルで表示することができますが、特定のイベントの詳細までは追うことができません。特定のイベントを追跡したい場合は、 ausearch ツールを使用します。

ausearch コマンドは /var/log/audit/audit.log にある監査ログ内を検索するためのツールで、キーや語句などを条件に指定して検索することができます。ただし、すべてのレコードタイプに同じ項目が含まれているわけではないことに注意してください。たとえば PATH レコードの場合、 hostnameuid の項目はありません。

検索を行う場合、必要なレコードをすべて抽出できるような適切な検索条件を指定してください。その一方、特定のレコードタイプを抽出したり、それに付随するその他の関連レコードを抽出したりすることもできます。これは、カーネル内の様々な箇所で、イベントに関連する複数のレコードを出力する仕組みであるためです。たとえば open システムコールの場合、 SYSCALL レコードだけでなく PATH レコードも同時に出力されます。

ヒント
ヒント: 複数の検索オプションの使用について

複数のコマンドラインオプションを指定すると、それらは論理積 (AND) 演算子で結びつけられ、検索を絞り込む用途として使用することができます。

他のファイルからの監査ログ読み込み

監査ログを他のマシンに移動させた場合や、それぞれのマシンに接続することなく、ローカルのマシン内で複数のマシンの監査ログを分析したりしたい場合は、対象となるログファイルをローカルに移動したあと、 ausearch を利用してローカルで分析してください:

tux > sudo ausearch - オプション -if ファイル名
数値表現の文字列変換

ユーザ ID などの情報は数値で出力されます。これらを読みやすいテキスト形式に変換するには、 ausearch コマンドに -i オプションを追加してください。

監査イベント ID での検索

既に監査レポートを作成している場合や、 autrace を実行している場合は、ログ内の特定のイベントに対して、証跡を分析する必要があります。 41.5項 「監査ログの仕組みとレポートの生成」 で説明しているほとんどの種類のレポートには、出力内に監査イベント ID が含まれます。監査イベント ID は監査メッセージ ID の第 2 パートの部分ですが、ここには Unix エポックのタイムスタンプと監査イベント ID がコロン区切りで書かれています。また、同じシステムコール内であれば、同じイベント ID が割り当てられます。 ausearch でこのイベント ID を使用することで、ログ内のイベント証跡を取得することができます。

下記のようにしてコマンドを使用してください:

tux > sudo ausearch -a 5207
----
time->Tue Feb 17 13:43:58 2009
type=PATH msg=audit(1234874638.599:5207): item=0 name="/var/log/audit/audit.log" inode=1219041 dev=08:06 mode=0100644 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1234874638.599:5207):  cwd="/root"
type=SYSCALL msg=audit(1234874638.599:5207): arch=c000003e syscall=2 success=yes exit=4 a0=62fb60 a1=0 a2=31 a3=0 items=1 ppid=25400 pid=25616 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1164 comm="less" exe="/usr/bin/less" key="doc_log"

ausearch -a コマンドを使用すると、指定したイベント ID に関連するログ内のすべてのレコードを検索して、表示します。このオプションは、他のオプションと組み合わせて指定することもできます。

メッセージタイプによる検索

特定のメッセージタイプの監査レコードを検索するには、 ausearch -m メッセージタイプ コマンドを実行します。指定できるメッセージタイプには、 PATH , SYSCALL , USER_LOGIN などがあります。メッセージタイプを指定せずに ausearch -m を実行すると、すべてのメッセージタイプの一覧を表示することができます。

ログイン ID による検索

特定のログインユーザ ID に関連するレコードを表示するには、ausearch -ul コマンドを使用します。このコマンドは、指定したログインユーザ ID に関連し、ログインに成功したすべてのレコードを取得します。

ユーザ ID による検索

特定の実ユーザ ID および実効ユーザ ID の両方に関連するレコードを表示するには、 ausearch -ua コマンドを使用します。特定の実ユーザ ID に関連するレコードを表示するには、 ausearch -ui UID のように入力して実行します。特定の実効ユーザ ID に関連するレコードを表示するには、 ausearch -ue EUID のように入力して実行します。実ユーザ ID での検索はプロセスを作成したユーザの ID を、実効ユーザ ID での検索は、そのプロセスを実行するのに必要なユーザ ID と権限の ID を意味しています。

グループ ID による検索

特定の実グループ ID および実効グループ ID の両方に関連するレコードを表示するには、 ausearch -ga コマンドを使用します。特定の実グループ ID に関連するレコードを表示するには、 ausearch -gi GID のように入力して実行します。特定の実効グループ ID に関連するレコードを表示するには、 ausearch -ge EGID のように入力して実行します。

コマンドライン名による検索

特定のコマンドに関連するレコードを表示するには、 ausearch -c コマンド名 コマンドを使用します。たとえば ausearch -c less のように入力して実行すると、 less コマンドに関連するすべてのレコードを表示することができます。

実行ファイル名による検索

特定の実行ファイルに関連するレコードを表示するには、 ausearch -x 実行ファイルのパス コマンドを使用します。たとえば ausearch -x /usr/bin/less のように入力して実行すると、 /usr/bin/less の実行ファイルに関連するすべてのレコードを表示することができます。

システムコール名による検索

特定のシステムコールに関連するレコードを表示するには、 ausearch -sc システムコール名 コマンドを使用します。たとえば ausearch -sc open のように入力して実行すると、 open システムコールに関連するすべてのレコードを表示することができます。

プロセス ID による検索

特定のプロセス ID に関連するレコードを表示するには、 ausearch -p プロセス_ID コマンドを使用します。たとえば ausearch -p 13368 のように入力して実行すると、指定したプロセス ID に関連するすべてのレコードを表示することができます。

イベントもしくはシステムコールの成功可否による検索

システムコールの成功可否を指定してレコードを表示するには、 ausearch -sv 成功可否 コマンドを使用します。たとえば ausearch -sv yes のように入力して実行すると、成功したシステムコールに関連するすべてのレコードを表示することができます。

ファイル名による検索

ファイル名を指定してレコードを表示するには、 ausearch -f ファイル名 コマンドを使用します。たとえば ausearch -f /foo/bar のように入力して実行すると、 /foo/bar ファイルに関連するすべてのレコードを表示することができます。なお、ファイル名だけの指定でも問題なく動作しますが、相対パスでの指定はできません。

端末による検索

特定の端末に関連するレコードを表示するには、 ausearch -tm 端末名 コマンドを使用します。たとえば ausearch -tm ssh のように入力して実行すると、 SSH 端末に関連するすべてのレコードを表示することができますし、 ausearch -tm tty のように入力して実行すると、コンソールに関連するすべてのレコードを表示することができます。

ホスト名による検索

特定のホストに関連するレコードを表示するには、 ausearch -hn ホスト名 コマンドを使用します。たとえば ausearch -hn jupiter.example.com のように入力して実行します。ホスト名や完全修飾ホスト名、ネットワークアドレスのいずれかを指定することができます。

キー項目による検索

あらかじめ特定の種類のイベントを識別するために設定して記録しておいたキー項目を指定してレコードを表示するには、 ausearch -k キー項目 コマンドを使用します。たとえば ausearch -k CFG_etc のように入力して実行すると、 CFG_etc というキーを含むレコードのみを表示します。

単語による検索
特定の時刻範囲に限定した検索

-ts-te の各オプションを指定することで、特定の時間帯範囲のものを検索することができるようになります。 -ts オプションでは開始日時を、 -te オプションでは終了日時をそれぞれ指定します。これらのオプションは、上述の任意のオプションと組み合わせて使用することができます。また、使用方法は aureport と同じです。

41.7 autrace によるプロセスの解析

監査システムでは、設定したルールを利用してシステムを監視するだけでなく、 autrace コマンドを使用することで、特定のプロセス専用の監査を実施することもできます。 autracestrace コマンドのように動作するコマンドですが、少し異なる情報を採取します。また、 autrace の出力は /var/log/audit/audit.log に書き込まれ、標準的な監査ログ項目と同様の書式で出力されます。

プロセスに対して autrace を実行する前に、まずはキュー内から監査ルールすべてを削除して、 autrace 自身の監査と衝突しないようにしておいてください。監査ルールの削除は auditctl -D で行います。これにより、すべての通常監査が停止します。

tux > sudo auditctl -D

No rules

autrace /usr/bin/less

Waiting to execute: /usr/bin/less
Cleaning up...
No rules
Trace complete. You can locate the records with 'ausearch -i -p 7642'

autrace で実行ファイルを指定する際には、必ずフルパスで指定してください。追跡が完了すると、 autrace はトレースのイベント ID を通知しますので、証跡を ausearch で検索できるようになります。作業後は監査ルールを元に戻すため、 systemctl restart auditd と入力して実行してください。

41.8 監査データの可視化

/var/log/audit/audit.log にある監査証跡も、 41.5.2項 「独自の監査レポートの生成」 で説明している様々な種類の aureport のレポートも、ユーザが読む場合にはある程度の経験が必要となります。 aureport の出力は表形式であるため、 sed, Perl, awk などのスクリプトを使用することで、容易に監査データを可視化することができます。

可視化に対応するスクリプト (詳しくは 42.6項 「ログの可視化の設定」 をお読みください) は、 openSUSE Leap やその他の Linux ディストリビューションで、読みやすい監査出力を作成するための標準的な Linux ツールの使い方の例となっているものです。下記の例では、純粋なテキスト形式の監査レポートを、グラフに変換する作業を行っています。

最初の例では、プログラムとシステムコールの対応付けを可視化しているものです。この種類のデータを取得するには、最終的なグラフを生成するための元となるデータを aureport で作成する必要があります:

tux > sudo aureport -s -i

Syscall Report
=======================================
# date time syscall pid comm auid event
=======================================
1. 2009年02月16日 17:45:01 open 20343 cron unset 2279
2. 2009年02月16日 17:45:02 mkdir 20350 mktemp root 2284
3. 2009年02月16日 17:45:02 mkdir 20351 mkdir root 2285
...

このレポートに対して可視化スクリプトが行うべき最初の処理は、必要な列の情報のみを抽出することです。この例では、 syscallcomm の列になります。出力は並べ替えられたあと重複を排除し、グラフ作成プログラム自身に渡すことになります:

LC_ALL=C aureport -s -i | awk '/^[0-9]/ { print $6" "$4 }' | sort | uniq | mkgraph
フローグラフ: プログラムとシステムコールの関係性
図 41.2: フローグラフ: プログラムとシステムコールの関係性

2 つ目の例では、様々な種類のイベントとそのログ記録数をまとめたグラフです。この種類のグラフを作成するにあたって、 aureport で対応するコマンドは aureport -e です:

tux > sudo aureport -e -i --summary

Event Summary Report
======================
total  type
======================
2434  SYSCALL
816  USER_START
816  USER_ACCT
814  CRED_ACQ
810  LOGIN
806  CRED_DISP
779  USER_END
99  CONFIG_CHANGE
52  USER_LOGIN

この種類のレポートは既に 2 列のみの出力になっていることから、単純にグラフ作成プログラムに渡して棒グラフにするだけです。

tux > sudo aureport -e -i --summary  | mkbar events
棒グラフ: 一般的なイベントの種類
図 41.3: 棒グラフ: 一般的なイベントの種類

監査データの可視化の背景となる情報について、詳しくは http://people.redhat.com/sgrubb/audit/visualize/index.html (英語) をお読みください。

41.9 監査イベント通知の中継

監査システムでは、リアルタイムに外部プログラムを呼び出して、 auditd にアクセスしたり、使用したりすることができます。この機能は 監査ディスパッチャ と呼ばれる仕組みで、たとえば侵入検知システムなどが auditd を使用し、より詳しい検知情報を取得したりすることができます。

audispd は監査ディスパッチャを制御するためのデーモンです。通常は auditd から起動されます。 audispd はリアルタイムに監査イベントを取得して、分析を行いたい各プログラムにそれらを配信する処理を行います。 audispd の設定は /etc/audisp/audispd.conf になります。このファイルには下記のようなオプションを記述します:

q_depth

監査ディスパッチャの内部キューのサイズを指定します。 syslog 内に監査イベントの喪失を表わすメッセージが現われた場合は、この値を増やしてください。既定値は 80 です。

overflow_action

監査ディスパッチャの内部キューが溢れてしまった場合、監査デーモンがどのように対応するのかを指定します。指定可能な値は ignore (何もしない), syslog (syslog に警告を発する), suspend (audispd に対してイベントの処理を停止させる), single (コンピュータシステムをシングルユーザモードに移行させる), halt (システムをシャットダウンする) のいずれかです。

priority_boost

監査イベントディスパッチャに対する優先度設定を指定します (監査デーモン自身の優先度からの相対指定です) 。既定値は 4 で、優先度を変更しません。

name_format

監査イベント内へ挿入するコンピュータノード名の設定方法を指定します。指定可能な値は none (コンピュータ名を挿入しない), hostname (gethostname システムコールで取得した名前), fqd (マシンの完全修飾ホスト名), numeric (マシンの IP アドレス), user (name オプションで指定する任意の値) のいずれかです。既定値は none です。

name

マシンを識別するためのユーザ定義の名前です。このオプションを動作させるには、 name_format オプションが user でなければなりません。それ以外の場合、このオプションは無視されます。

max_restarts

非負の整数を入れる項目で、監査イベントディスパッチャに対して、何回までクラッシュしたプラグインを再起動しようとするかを指定します。既定値は 10 です。

例 41.9: /etc/audisp/audispd.conf の例
  q_depth = 80
  overflow_action = SYSLOG
  priority_boost = 4
  name_format = HOSTNAME
  #name = mydomain

プラグインプログラムでは、自身の設定ファイルを audispd プラグイン専用のディレクトリにインストールします。このディレクトリは既定では /etc/audisp/plugins.d になっています。プラグインの設定ファイルには、下記のようなオプションがあります:

active

プログラムが audispd を使用するかどうかを指定します。指定可能な値は yes (はい), no (いいえ) のいずれかです。

direction

プラグインと監査システムの通信方法を指定します。これはイベントディスパッチャに対して、イベントの流れる方向を示すことになります。指定可能な値は in (入力), out (出力) のいずれかです。

path

プラグインの実行ファイルに対する絶対パスを指定します。内部プラグインの場合、ここにはプラグイン名を指定します。

type

プラグインの動作方法を指定します。指定可能な値は builtin, always のいずれかです。 builtin は内部プラグイン ( af_unix および syslog ) であることを示すもので、 always はほとんどすべて (ただし全てではありません) のプラグイン向けの値です。既定値は always です。

args

プラグインプログラムに渡すパラメータを指定します。通常、プラグインプログラムは自身の設定ファイルからパラメータを読み込む仕組みであるため、何もパラメータを指定する必要はありません。また、 2 個までのパラメータに対応しています。

format

監査ディスパッチャがプラグインプログラムに渡すデータの形式を指定します。指定可能な値は binary, string のいずれかです。 binary はイベントディスパッチャが監査デーモンから受信したデータをそのまま渡す指定で、 string はディスパッチャに対して、イベントデータを監査処理ライブラリで処理できる文字列に変換する指定です。既定値は string です。

例 41.10: /etc/audisp/plugins.d/syslog.conf の例
  active = no
  direction = out
  path = builtin_syslog
  type = builtin
  args = LOG_INFO
  format = string
このページを印刷