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

42 Linux 監査フレームワークの設定

本章では、シンプルな監査環境を構築するまでの説明を行っています。各手順には設定や監査の有効化に関する詳細な説明が含まれています。下記の内容を学習したあとは、 第43章 「監査ルールセットの紹介 に示されている実際の例に読み進めてください。

openSUSE Leap で監査を設定するには、下記の手順を踏む必要があります:

手順 42.1: Linux 監査フレームワークの設定
  1. まずは必要なパッケージが全てインストールされていることを確認します。必要なパッケージは audit , audit-libs の各パッケージで、必要であれば audit-libs-python もインストールします。また、 42.6項 「ログの可視化の設定」 で説明しているログの可視化機能が必要である場合は、 gnuplotgraphviz の各パッケージもインストールしてください。いずれも openSUSE Leap のメディア内に同梱されています。

  2. 監査対象のコンポーネントを決定します。詳しくは 42.1項 「監査対象のコンポーネントの決定」 をお読みください。

  3. 基本的な監査デーモンの設定を確認し、必要であれば修正します。詳しくは 42.2項 「監査デーモンの設定」 をお読みください。

  4. システムコールに対する監査を有効化します。詳しくは 42.3項 「システムコールに対する監査の有効化」 をお読みください。

  5. お使いの目的にあわせて監査ルールを構築します。詳しくは 42.4項 「監査ルールの設定」 をお読みください。

  6. ログを生成し、目的にあったレポートを設定します。詳しくは 42.5項 「監査レポートの設定」 をお読みください。

  7. 必要であれば、ログの可視化を行います。詳しくは 42.6項 「ログの可視化の設定」 をお読みください。

重要
重要: 監査デーモンの制御について

監査システムのコンポーネントの設定を行う場合は、あらかじめ rootsystemctl status auditd を実行し、監査デーモンが動作していないことを確認してください。既定の openSUSE Leap では監査システムがシステムの起動時に動作するように設定されてしまっていますので、 systemctl stop auditd を実行して停止させる必要があります。設定が完了したら、 systemctl start auditd を実行して監査デーモンを開始してください。

42.1 監査対象のコンポーネントの決定

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

  • CAPP/EAL 認証を取るために完全なセキュリティ監査を行う必要がある場合は、システムコールに対して完全な監査を行い、様々なファイルやディレクトリに対して監視を設定してください。ルールセットは 第43章 「監査ルールセットの紹介 に示されているものをベースにすることができます。

  • 監査ルールをベースにしたプロセス追跡を行う必要がある場合は、 autrace を使用します。

  • 重要なデータや機密データを含むファイルやディレクトリに対するアクセスを追跡し、監視したい場合は、これらの要件に沿ったルールセットを作成する必要があります。 42.3項 「システムコールに対する監査の有効化」 に示されている手順で監査を有効化し、その後 42.4項 「監査ルールの設定」 に進んでください。

42.2 監査デーモンの設定

監査デーモンの基本的な設定は、 /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 準拠の設定を行う場合は、 41.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 の設定パラメータについて、背景となる詳細情報を読みたい場合は、 41.2項 「監査デーモンの設定」 を参照してください。

42.3 システムコールに対する監査の有効化

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

tux > sudo systemctl enable auditd

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

基本的なログ機能

openSUSE Leap の標準状態 (特に何も設定を行っていない状態) では、 auditd は /var/log/audit/audit.log に対する設定変更のイベントのみを記録します。また、カーネルの監査コンポーネントは、 auditctl で制御を行わない限り、ファイルアクセスやシステムコールなどのイベントも生成しません。しかしながら、その他のカーネルコンポーネントやモジュールが、 auditctl の制御範囲外で監査イベントを生成し、監査ログ内に現われることがあります。既定では、 AppArmor モジュールのみが監査イベントを生成します。

システムコールを監査する高度なログ機能

システムコールを監視し、意味のあるファイル監視を実施したい場合は、システムコールに対する監査コンテキストを有効化する必要があります。

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

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

42.4 監査ルールの設定

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

監査ルールはコマンドラインツールである 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 つ注意しておくべき点として、ルールの作成時に存在していないファイルに対しては、監視を設定することができないという点です。監査システムが動作している間にシステムに追加されたファイルは、そのファイルに対して後からルールセットに追加しない限り、監視することができません。

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

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

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

42.5 監査レポートの設定

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

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

  • どのような種類のイベントに対して定期的なレポートを生成し、監視を行うのか?... 41.5.2項 「独自の監査レポートの生成」 で説明している aureport の使用方法を参照して、適切なコマンドラインを作成してください。

  • 監査レポートで何をするのか? ... 蓄積されたデータからグラフを作成するのか、それとも表計算やデータベースシステムなどに取り込んで利用するのか、などです。レポートを可視化したい場合は、 42.6項 「ログの可視化の設定」 での例などを参考にして、 aureport のコマンドラインを設定し、処理を進めてください。

  • レポートの作成間隔とタイミングをどうするのか? ... cron 等を利用して適切な自動化を構成してください。

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

  1. 全てのイベントに対して完全な概要レポートを生成していて、何らかの異常が存在していないかどうかを調べたい場合は、 failed syscalls の箇所をご確認ください。この失敗は、許可のないファイルに対するアクセスのほか、存在していないファイルに対するアクセスなどが含まれるためです:

    tux > sudo aureport
    
    Summary Report
    ======================
    Range of time in logs: 2009年02月03日 14:13:38.225 - 2009年02月17日 16:30:10.352
    Selected time for report: 2009年02月03日 14:13:38 - 2009年02月17日 16:30:10.352
    Number of changes in configuration: 24
    Number of changes to accounts, groups, or roles: 0
    Number of logins: 9
    Number of failed logins: 15
    Number of authentications: 19
    Number of failed authentications: 578
    Number of users: 3
    Number of terminals: 15
    Number of host names: 4
    Number of executables: 20
    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: 1238
    Number of events: 5435
  2. さらに失敗イベントに対する概要レポートを作成する (--failed) と、 files 内にファイルアクセスの失敗数が表示されるようになります:

    tux > sudo aureport --failed
    
    Failed Summary Report
    ======================
    Range of time in logs: 2009年02月03日 14:13:38.225 - 2009年02月17日 16:30:10.352
    Selected time for report: 2009年02月03日 14:13:38 - 2009年02月17日 16:30:10.352
    Number of changes in configuration: 0
    Number of changes to accounts, groups, or roles: 0
    Number of logins: 0
    Number of failed logins: 15
    Number of authentications: 0
    Number of failed authentications: 578
    Number of users: 1
    Number of terminals: 7
    Number of host names: 4
    Number of executables: 12
    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: 713
    Number of events: 1589
  3. アクセスのできなかったファイルを一覧表示したい場合は、さらにファイルイベントに限定してレポートを作成します:

    tux > sudo aureport -f -i --failed --summary
    
    Failed File Summary Report
    ===========================
    total  file
    ===========================
    80  /var
    80  spool
    80  cron
    80  lastrun
    46  /usr/lib/locale/en_GB.UTF-8/LC_CTYPE
    45  /usr/lib/locale/locale-archive
    38  /usr/lib/locale/en_GB.UTF-8/LC_IDENTIFICATION
    38  /usr/lib/locale/en_GB.UTF-8/LC_MEASUREMENT
    38  /usr/lib/locale/en_GB.UTF-8/LC_TELEPHONE
    38  /usr/lib/locale/en_GB.UTF-8/LC_ADDRESS
    38  /usr/lib/locale/en_GB.UTF-8/LC_NAME
    38  /usr/lib/locale/en_GB.UTF-8/LC_PAPER
    38  /usr/lib/locale/en_GB.UTF-8/LC_MESSAGES
    38  /usr/lib/locale/en_GB.UTF-8/LC_MONETARY
    38  /usr/lib/locale/en_GB.UTF-8/LC_COLLATE
    38  /usr/lib/locale/en_GB.UTF-8/LC_TIME
    38  /usr/lib/locale/en_GB.UTF-8/LC_NUMERIC
    8  /etc/magic.mgc
    ...

    /etc/audit/auditd.conf , /etc/pam.d , /etc/sysconfig など、特定のファイルやディレクトリに対してレポートを作成したい場合は、下記のようなコマンドを実行します:

    tux > sudo aureport -f -i --failed --summary |grep -e "/etc/audit/auditd.conf" -e "/etc/pam.d/" -e "/etc/sysconfig"
    
    1  /etc/sysconfig/displaymanager
  4. 上記の概要レポートを読むことで、ようやくログファイルの中から調査対象を絞り込むことができました。あとはさらに詳しく調べるため、イベント ID を取得します:

    tux > sudo aureport -f -i --failed |grep -e "/etc/audit/auditd.conf" -e "/etc/pam.d/" -e "/etc/sysconfig"
    
    993. 2009年02月17日 16:47:34 /etc/sysconfig/displaymanager readlink no /bin/vim-normal root 7887
    994. 2009年02月17日 16:48:23 /etc/sysconfig/displaymanager getxattr no /bin/vim-normal root 7889
  5. あとはイベント ID を指定して詳細情報を取得します:

    tux > sudo ausearch -a 7887 -i
    ----
    time->Tue Feb 17 16:48:23 2009
    type=PATH msg=audit(1234885703.090:7889): item=0 name="/etc/sysconfig/displaymanager" inode=369282 dev=08:06 mode=0100644 ouid=0 ogid=0 rdev=00:00
    type=CWD msg=audit(1234885703.090:7889):  cwd="/root"
    type=SYSCALL msg=audit(1234885703.090:7889): arch=c000003e syscall=191 success=no exit=-61 a0=7e1e20 a1=7f90e4cf9187 a2=7fffed5b57d0 a3=84 items=1 ppid=25548 pid=23045 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=1166 comm="vim" exe="/bin/vim-normal" key=(null)
ヒント
ヒント: 特定の時間帯のみに着目したい場合について

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

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

42.6 ログの可視化の設定

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

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

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

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

  1. スクリプトを root のホームディレクトリ以下の ~/bin にダウンロードします:

    tux > sudo wget http://people.redhat.com/sgrubb/audit/visualize/mkbar -O ~/bin/mkbar
    tux > sudo wget http://people.redhat.com/sgrubb/audit/visualize/mkgraph -O ~/bin/mkgraph
  2. root に対して、読み込みと書き込み、実行のファイルパーミッションを設定します:

    tux > sudo chmod 744 ~/bin/mk{bar,graph}

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

イベントの概要グラフの作成
tux > sudo aureport -e -i --summary | mkbar events
ファイルイベントの概要グラフの作成
tux > sudo aureport -f -i --summary | mkbar files
ログインイベントの概要グラフの作成
tux > sudo aureport -l -i --summary | mkbar login
ユーザイベントの概要グラフの作成
tux > sudo aureport -u -i --summary | mkbar users
システムコールイベントの概要グラフの作成
tux > sudo aureport -s -i --summary | mkbar syscalls

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

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

ユーザと実行ファイルの関係性グラフ
tux > sudo LC_ALL=C aureport -u -i | awk '/^[0-9]/ { print $4" "$7 }' | sort | uniq | mkgraph users_vs_exec
ユーザとファイルの関係性グラフ
tux > sudo LC_ALL=C aureport -f -i | awk '/^[0-9]/ { print $8" "$4 }' | sort | uniq | mkgraph users_vs_files
システムコールとコマンドの関係性グラフ
tux > sudo LC_ALL=C aureport -s -i | awk '/^[0-9]/ { print $4" "$6 }' | sort | uniq | mkgraph syscall_vs_com
システムコールとファイルの関係性グラフ
tux > sudo LC_ALL=C aureport -s -i | awk '/^[0-9]/ { print $5" "$4 }' | sort | uniq | mkgraph | syscall_vs_file

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

このページを印刷