CentOS7でLinux監査システムを使用する方法

序章

Linux監査システムは、システム管理者がサーバー上のすべてのアクションのログである監査証跡を作成するのに役立ちます。監査ログファイルを検査することで、セキュリティ関連のイベントを追跡し、イベントをログファイルに記録し、誤用や不正なアクティビティを検出できます。サーバー上のどのアクションをどの程度監視するかを選択できます。監査は、システムに追加のセキュリティを提供するのではなく、システムポリシーの違反を追跡するのに役立ち、それらを防ぐために追加のセキュリティ対策を講じることができます。

このチュートリアルでは、監査システム、その構成方法、レポートの生成方法、およびこれらのレポートの読み取り方法について説明します。また、特定のイベントの監査ログを検索する方法についても説明します。

前提条件

このチュートリアルでは、次のものが必要です。

CentOS 7ドロップレット（CentOS 6でも動作します）
sudo権限を持つroot以外のユーザー。このタイプのユーザーをセットアップするには、 CentOS7を使用したサーバーの初期セットアップのチュートリアルに従ってください。すべてのコマンドはこのユーザーとして実行されます。

監査インストールの確認

監査システムには2つの主要な部分があります。

監査カーネルコンポーネントは、ユーザーアプリケーションからのシステムコールをインターセプトし、イベントを記録し、これらの監査メッセージを監査デーモンに送信します
auditdデーモンはカーネルから情報を収集し、ログファイルにエントリを作成します

監査システムは、auditおよびaudit-libsのパッケージを使用します。これらのパッケージは、デフォルトで新しいCentOS 7ドロップレット（および新しいCentOS 6ドロップレット）にインストールされます。以下を使用して、サーバーにインストールされていることを確認することをお勧めします。

sudo yum list audit audit-libs

出力のInstalled Packagesの下に両方のパッケージが表示されます。

Installed Packages
audit.x86_64
audit-libs.x86_64

監査の構成

auditdの主な構成ファイルは/etc/audit/auditd.confです。このファイルは、イベントをログに記録する場所、フルディスクを処理する方法、およびログローテーションを含む構成パラメーターで構成されています。このファイルを編集するには、sudoを使用する必要があります。

sudo nano /etc/audit/auditd.conf

たとえば、サーバーに保持される監査ログファイルの数を10に増やすには、次のオプションを編集します。

/etc/audit/auditd.conf

num_logs = 10

ログファイルの最大サイズをMB単位で構成し、サイズに達したときに実行するアクションを構成することもできます。

/etc/audit/auditd.conf

max_log_file = 30
max_log_file_action = ROTATE

構成を変更する場合は、以下を使用してauditdサービスを再起動する必要があります。

sudo service auditd restart

変更を有効にします。

他の設定ファイルは/etc/audit/rules.d/audit.rulesです。（CentOS 6を使用している場合、ファイルは代わりに/etc/audit/audit.rulesになります。）これは、監査ルールを永続的に追加するために使用されます。

auditdが実行されている場合、監査メッセージはファイル/var/log/audit/audit.logに記録されます。

監査ログファイルについて

デフォルトでは、監査システムは監査メッセージを/var/log/audit/audit.logファイルに記録します。監査ログファイルには多くの有用な情報が含まれていますが、提供される情報の量、使用される略語やコードなどにより、多くのユーザーにとってログファイルの読み取りと理解は難しいように思われる場合があります。このセクションでは、監査ログファイルの一般的な監査メッセージのいくつかのフィールドを理解しようとします。

'注： auditdが何らかの理由で実行されていない場合、監査メッセージがrsyslogに送信されます。

この例では、ファイル/etc/ssh/sshd_configへのすべてのアクセスまたは変更をログに記録するために、ラベル（key）sshconfigchangeを使用してサーバーに監査ルールが構成されていると仮定します。必要に応じて、次を使用してこのルールを一時的に追加できます。

sudo auditctl -w /etc/ssh/sshd_config -p rwxa -k sshconfigchange

次のコマンドを実行してsshd_configファイルを表示すると、監査ログファイルに新しいイベントが作成されます。

sudo cat /etc/ssh/sshd_config

audit.logファイルのこのイベントは次のようになります。

/var/log/audit/audit.log

type=SYSCALL msg=audit(1434371271.277:135496): arch=c000003e syscall=2 success=yes exit=3 a0=7fff0054e929 a1=0 a2=1fffffffffff0000 a3=7fff0054c390 items=1 ppid=6265 pid=6266 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=113 comm="cat" exe="/usr/bin/cat" key="sshconfigchange"

type=CWD msg=audit(1434371271.277:135496):  cwd="/home/sammy"

type=PATH msg=audit(1434371271.277:135496): item=0 name="/etc/ssh/sshd_config" inode=392210 dev=fd:01 mode=0100600 ouid=0 ogid=0 rdev=00:00 objtype=NORMAL

上記のイベントは、同じタイムスタンプ（1434371271.277）とID（135496）を共有する3つのレコード（それぞれtype=キーワードで始まる）で構成されています。各レコードは、空白またはコンマで区切られたいくつかの name =valueペアで構成されます。これらのフィールドのいくつかが何を表すのかを詳しく見ていきます。

最初のレコード：

type=SYSCALL

typeフィールドには、監査メッセージのタイプが含まれます。この場合、SYSCALL値は、このメッセージがカーネルへのシステムコールによってトリガーされたことを示しています。

msg=audit(1434371271.277:135496):

audit(time_stamp:ID)の形式の監査メッセージのタイムスタンプとID。複数の監査メッセージ/レコードは、同じ監査イベントの一部として生成された場合、同じタイムスタンプとIDを共有できます。この例では、監査イベントによって生成された3つのメッセージすべてに同じタイムスタンプ（1434371271.277）とID（135496）が表示されます。

arch=c000003e

archフィールドには、システムのCPUアーキテクチャに関する情報が含まれています。値c000003eは、16進表記であり、x86_64を表します。

syscall=2

syscallフィールドは、カーネルに送信されたシステムコールのタイプを示します。この場合、2はopenシステムコールです。 ausyscallユーティリティを使用すると、システムコール番号を人間が読める形式に変換できます。たとえば、次のコマンドを実行して、値2を人間が読める形式に変換します。

sudo ausyscall 2

出力は次のとおりです。

open

注： sudo ausyscall --dumpコマンドを使用して、すべてのシステムコールとその番号のリストを表示できます。

success=yes

successフィールドは、その特定のイベントのシステムコールが成功したか失敗したかを示します。この場合、呼び出しは成功しました。 sudo cat /etc/ssh/sshd_configコマンドが実行されたときに、ユーザーsammyはファイルsshd_configを開いて読み取ることができました。

ppid=6265

ppidフィールドは、親プロセスID（PPID）を記録します。この場合、6265はbashプロセスのPPIDでした。

pid=6266

pidフィールドは、プロセスID（PID）を記録します。この場合、6266はcatプロセスのPIDでした。

auid=1000

auidは、この監査メッセージをトリガーしたユーザーの監査UIDまたは元のUIDです。監査システムは、最初のログイン後にsuまたはsudoを介して特権を昇格させた場合でも、元のUIDを記憶します。

uid=0

uidフィールドには、分析されたプロセスを開始したユーザーのユーザーIDが記録されます。この場合、catコマンドは、uid0のユーザーrootによって開始されました。

comm="cat"

commは、この監査メッセージをトリガーしたコマンドの名前を記録します。

exe="/usr/bin/cat"

exeフィールドは、この監査メッセージをトリガーするために使用されたコマンドへのパスを記録します。

key="sshconfigchange"

keyフィールドは、このイベントを生成した監査ルールに関連付けられた管理者定義の文字列をログに記録します。キーは通常、カスタム監査ルールを作成するときに設定され、監査ログから特定の種類のイベントを簡単に検索できるようにします。

2番目のレコードの場合：

type=CWD

2番目のレコードでは、タイプはCWD —現在の作業ディレクトリです。このタイプは、最初のレコードで指定されたシステムコールをトリガーしたプロセスが実行された作業ディレクトリを記録するために使用されます。

cwd="/home/sammy"

cwdフィールドには、システムコールが呼び出されたディレクトリへのパスが含まれています。この例では、最初のレコードでopensyscallをトリガーしたcatコマンドが、ディレクトリ/home/sammyから実行されました。

3番目のレコードの場合：

type=PATH

3番目のレコードでは、タイプはPATHです。監査イベントには、引数としてシステムコールに渡されるすべてのパスのPATHレコードが含まれます。監査イベントでは、1つのパス（/etc/ssh/sshd_config）のみが引数として使用されました。

msg=audit(1434371271.277:135496):

msgフィールドには、3つのレコードすべてが同じ監査イベントの一部であるため、最初と2番目のレコードと同じタイムスタンプとIDの組み合わせが表示されます。

name="/etc/ssh/sshd_config"

nameフィールドは、引数としてシステムコール（open）に渡されたファイルまたはディレクトリのフルパスを記録します。この場合、それは/etc/ssh/sshd_configファイルでした。

ouid=0

ouidフィールドには、オブジェクトの所有者のユーザーIDが記録されます。ここでのオブジェクトはファイル/etc/ssh/sshd_configです。

注：監査レコードの種類の詳細については、このチュートリアルの最後にあるリンクから入手できます。

イベントの監査ログの検索

Linux監査システムには、監査ログを検索するためのausearchと呼ばれる強力なツールが付属しています。 ausearchを使用すると、イベントタイプをフィルタリングおよび検索できます。また、数値をシステムコールやユーザー名などの人間が読める形式の値に変換することで、イベントを解釈することもできます。

いくつかの例を見てみましょう。

次のコマンドは、監査ログで今日からのタイプLOGINのすべての監査イベントを検索し、ユーザー名を解釈します。

sudo ausearch -m LOGIN --start today -i

以下のコマンドは、イベントID 27020のすべてのイベントを検索します（そのIDのイベントがある場合）。

sudo ausearch -a 27020

このコマンドは、ファイル/etc/ssh/sshd_configに接触しているすべてのイベント（存在する場合）を検索し、それらを解釈します。

sudo ausearch -f /etc/ssh/sshd_config -i

監査レポートの生成

生の監査ログを読み取る代わりに、ツールaureportを使用して監査メッセージの要約を取得できます。人間が読める形式でレポートを提供します。これらのレポートは、より複雑な分析の構成要素として使用できます。 aureportをオプションなしで実行すると、監査ログに存在するさまざまなタイプのイベントの概要が表示されます。検索オプションとともに使用すると、検索条件に一致するイベントのリストが表示されます。

aureportの例をいくつか試してみましょう。サーバーでのすべてのコマンド実行に関する要約レポートを生成する場合は、次のコマンドを実行します。

sudo aureport -x --summary

出力は、値が異なると次のようになります。

Executable Summary Report
=================================
total  file
=================================
117795  /usr/sbin/sshd
1776  /usr/sbin/crond
210  /usr/bin/sudo
141  /usr/bin/date
24  /usr/sbin/autrace
18  /usr/bin/su

最初の列はコマンドが実行された回数を示し、2番目の列は実行されたコマンドを示します。デフォルトでは、すべてのコマンドがログに記録されるわけではないことに注意してください。セキュリティ関連のものだけがログに記録されます。

次のコマンドは、失敗したすべてのイベントの統計を提供します。

sudo aureport --failed

出力は次のようになります。

Failed Summary Report
======================
Number of failed logins: 11783
Number of failed authentications: 41679
Number of users: 3
Number of terminals: 4
Number of host names: 203
Number of executables: 3
Number of files: 4
Number of AVC's: 0
Number of MAC events: 0
Number of failed syscalls: 9

システムコールとユーザー名でアクセスされたファイルに関するレポートを生成するには：

sudo aureport -f -i

サンプル出力：

File Report
===============================================
# date time file syscall success exe auid event
===============================================
1. Monday 15 June 2015 08:27:51 /etc/ssh/sshd_config open yes /usr/bin/cat sammy 135496
2. Tuesday 16 June 2015 00:40:15 /etc/ssh/sshd_config getxattr no /usr/bin/ls root 147481
3. Tuesday 16 June 2015 00:40:15 /etc/ssh/sshd_config lgetxattr yes /usr/bin/ls root 147482
4. Tuesday 16 June 2015 00:40:15 /etc/ssh/sshd_config getxattr no /usr/bin/ls root 147483
5. Tuesday 16 June 2015 00:40:15 /etc/ssh/sshd_config getxattr no /usr/bin/ls root 147484
6. Tuesday 16 June 2015 05:40:08 /bin/date execve yes /usr/bin/date root 148617

同じものを要約形式で表示するには、次のコマンドを実行できます。

sudo aureport -f -i --summary

注： aureportツールは、入力が生のログデータ形式である限り、ログファイルの代わりにstdinから入力を取得することもできます。

autraceを使用したプロセスの分析

個々のプロセスを監査するには、autraceツールを使用できます。このツールは、プロセスによって実行されたシステムコールをトレースします。これは、疑わしいトロイの木馬や問題のあるプロセスを調査するのに役立ちます。 autraceの出力は/var/log/audit/audit.logに書き込まれ、標準の監査ログエントリに似ています。実行後、autraceは、ログを調査するためのausearchコマンドの例を示します。 sudo autrace /bin/ls /tmpのように、autraceで追跡するには、常にバイナリへのフルパスを使用してください。

注： autraceを実行すると、すべてのカスタム監査ルールが削除されることに注意してください。指定したプロセスをトレースするために必要な特定のルールに置き換えられます。 autraceが完了すると、追加した新しいルールがクリアされます。同じ理由で、監査ルールが不変に設定されている場合、autraceは機能しません。

例を試してみましょう。たとえば、プロセスdateをトレースして、プロセスで使用されるファイルとシステムコールを表示したいとします。次を実行します。

sudo autrace /bin/date

次のようなものが表示されます。

Waiting to execute: /bin/date
Wed Jun 17 07:22:03 EDT 2015
Cleaning up...
Trace complete. You can locate the records with 'ausearch -i -p 27020'

上記の出力からausearchコマンドを使用して、関連するログを表示したり、aureportに渡して、適切にフォーマットされた人間が読める形式の出力を取得したりできます。

sudo ausearch -p 27020 --raw | aureport -f -i

このコマンドは、監査ログからイベントID 27020のイベントを検索し、生のログ形式で抽出してaureportに渡します。これにより、結果がより適切な形式で解釈され、提供されます。読みやすくするため。

次のような出力が表示されます。

File Report
===============================================
# date time file syscall success exe auid event
===============================================
1. Wednesday 17 June 2015 07:22:03 /bin/date execve yes /usr/bin/date sammy 169660
2. Wednesday 17 June 2015 07:22:03 /etc/ld.so.preload access no /usr/bin/date sammy 169663
3. Wednesday 17 June 2015 07:22:03 /etc/ld.so.cache open yes /usr/bin/date sammy 169664
4. Wednesday 17 June 2015 07:22:03 /lib64/libc.so.6 open yes /usr/bin/date sammy 169668
5. Wednesday 17 June 2015 07:22:03 /usr/lib/locale/locale-archive open yes /usr/bin/date sammy 169683
6. Wednesday 17 June 2015 07:22:03 /etc/localtime open yes /usr/bin/date sammy 169691

結論

このチュートリアルでは、Linux監査システムの基本について説明しました。これで、監査システムがどのように機能するか、監査ログを読み取る方法、およびサーバーの監査を容易にするために使用できるさまざまなツールについて十分に理解できたはずです。

デフォルトでは、監査システムは、ログインしているユーザーやsudoを使用しているユーザーなどのいくつかのイベントのみをログに記録します。 SELinux関連のメッセージもログに記録されます。監査デーモンは、ルールを使用して特定のイベントを監視し、関連するログエントリを作成します。カスタム監査ルールを作成して、必要に応じて監視し、ログに記録することができます。これは、監査システムがシステム管理者にとって強力になる場所です。コマンドラインツールauditctlを使用するか、ファイル/etc/audit/rules.d/audit.rulesに永続的にルールを追加できます。カスタムルールの作成と事前定義されたルールセットの使用については、 CentOS7チュートリアルでのカスタムシステム監査ルールの作成で詳しく説明されています。

監査システムの詳細については、次のリソースを確認することもできます。