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

序章

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

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

前提条件

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

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

監査インストールの確認

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

1. 監査カーネルコンポーネントは、ユーザーアプリケーションからのシステムコールをインターセプトし、イベントを記録し、これらの監査メッセージを監査デーモンに送信します
2. The 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に増やすには、次のオプションを編集します。

num_logs = 10

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

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 ファイル。 監査ログファイルには多くの有用な情報が含まれていますが、提供される情報の量、使用される略語やコードなどにより、多くのユーザーにとってログファイルの読み取りと理解は難しいように思われる場合があります。 このセクションでは、監査ログファイルの一般的な監査メッセージのいくつかのフィールドを理解しようとします。

この例では、サーバーに（（key) sshconfigchange ファイルへのすべてのアクセスまたは変更をログに記録する /etc/ssh/sshd_config. 必要に応じて、次を使用してこのルールを一時的に追加できます。

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

次のコマンドを実行して、 sshd_config fileは、監査ログファイルに新しいeventを作成します。

sudo cat /etc/ssh/sshd_config

このイベントは 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

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

最初のレコード：

• type=SYSCALL

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

• msg=audit(1434371271.277:135496):

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

• arch=c000003e

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

• syscall=2

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

sudo ausyscall 2

出力は次のとおりです。

open

• success=yes

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

• ppid=6265

The ppid フィールドには、親プロセスID（PPID）が記録されます。 この場合、 6265 のPPIDでした bash 処理する。

• pid=6266

The pid フィールドには、プロセスID（PID）が記録されます。 この場合、 6266 のPIDでした cat 処理する。

• auid=1000

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

• uid=0

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

• comm="cat"

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

• exe="/usr/bin/cat"

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

• key="sshconfigchange"

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

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

• type=CWD

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

• cwd="/home/sammy"

The cwd フィールドには、システムコールが呼び出されたディレクトリへのパスが含まれます。 私たちの場合、 cat をトリガーしたコマンド open 最初のレコードのsyscallはディレクトリから実行されました /home/sammy.

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

• type=PATH

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

• msg=audit(1434371271.277:135496):

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

• name="/etc/ssh/sshd_config"

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

• ouid=0

The 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

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

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

例を試してみましょう。たとえば、プロセスを追跡したい場合 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チュートリアルでのカスタムシステム監査ルールの作成で詳しく説明されています。

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

• 監査記録の種類

• CAPP環境のauditdの構成

• 監査イベントフィールドとその定義