TOC

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

前書き

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

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

前提条件

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

  • CentOS 7 Droplet（CentOS 6でも動作します）

  • sudo特権を持つ非rootユーザー。 このタイプのユーザーをセットアップするには、https：//www.digitalocean.com/community/tutorials/initial-server-setup-with-centos-7 [CentOS 7での初期サーバーセットアップ]チュートリアルに従ってください。 すべてのコマンドはこのユーザーとして実行されます。

監査インストールの検証

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

  1. 監査カーネルコンポーネントは、ユーザーアプリケーションからのシステムコールをインターセプトし、イベントを記録し、これらの監査メッセージを監査デーモンに送信します

  2. `+ auditd +`デーモンはカーネルから情報を収集し、ログファイルにエントリを作成します

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

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 =

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

/etc/audit/auditd.conf

max_log_file =
max_log_file_action =

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

この例では、ファイル（+ / 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

  • + success = yes +

`+ success `フィールドは、その特定のイベントのシステムコールが成功したか失敗したかを示します。 この場合、呼び出しは成功しました。 ユーザーsammyは、 ` sudo cat / etc / ssh / sshd_config `コマンドが実行されたときに、ファイル ` 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 +`コマンドはuid 0のユーザーrootによって開始されました。

  • + comm =" cat "+

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

  • + exe =" / usr / bin / cat "+

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

  • + key =" sshconfigchange "+

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

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

  • + type = CWD +

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

  • + cwd =" / home / sammy "+

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

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

  • + type = PATH +

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

  • + msg = audit（1434371271.277：135496）：+

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

  • + name =" / etc / ssh / sshd_config "+

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

  • + ouid = 0 +

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

イベントの監査ログを検索する

Linux Auditing Systemには、監査ログを検索するための `+ 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 +」に永続的にルールを追加できます。 カスタムルールの作成および事前定義されたルールセットの使用については、https：//www.digitalocean.com/community/tutorials/writing-custom-system-audit-rules-on-centos-7 [カスタムシステム監査ルールの作成CentOS 7]チュートリアル。

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

Related