CentOS7でカスタムシステム監査ルールを作成する方法

序章

Linux監査システムは、システム上のあらゆる種類の情報を追跡する方法である監査証跡を作成します。イベントの種類、日時、ユーザーID、システムコール、プロセス、使用されるファイル、SELinuxコンテキスト、機密性レベルなどの多くのデータを記録できます。ファイルがアクセス、編集、または実行されたかどうかを追跡できます。ファイル属性への変更があるかどうかを追跡することもできます。システムコールの使用状況、ユーザーが実行したコマンド、ログイン試行の失敗、およびその他の多くのイベントをログに記録できます。デフォルトでは、監査システムは、ログインしているユーザー、sudoを使用しているユーザー、SELinux関連のメッセージなどのいくつかのイベントのみをログに記録します。監査ルールを使用して特定のイベントを監視し、関連するログエントリを作成します。監査ルールを作成することが可能です。

このチュートリアルでは、さまざまな種類の監査ルールと、サーバーでカスタムルールを追加または削除する方法について説明します。

前提条件

このチュートリアルを開始する前に、次のものが必要です。

CentOS 7ドロップレット（CentOS 6でも動作します）
sudo権限を持つroot以外のユーザー。このタイプのユーザーをセットアップするには、 CentOS7を使用したサーバーの初期セットアップのチュートリアルに従ってください。すべてのコマンドはこのユーザーとして実行されます。
Linux監査システムの基本的な理解。詳細については、 CentOS7上のLinux監査システムについてを確認してください。

監査ルールの表示

コマンドauditctl -lを使用して、現在の監査ルールのセットを表示できます。

sudo auditctl -l

ルールが存在しない場合、ルールは表示されません（これがデフォルトです）。

No rules

このチュートリアルでルールを追加するときに、このコマンドを使用して、ルールが追加されたことを確認できます。

監査システムの現在のステータスは、以下を使用して表示できます。

sudo auditctl -s

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

AUDIT_STATUS: enabled=1 flag=1 pid=9736 rate_limit=0 backlog_limit=320 lost=0 backlog=0

enabled=1値は、このサーバーで監査が有効になっていることを示します。 pidの値は、監査デーモンのプロセス番号です。 pid 0は、監査デーモンが実行されていないことを示します。 lostエントリは、カーネル監査キューがオーバーフローしたために破棄されたイベントレコードの数を示します。 backlogフィールドには、auditdによる読み取りを待機している現在キューに入れられているイベントレコードの数が表示されます。このチュートリアルの次のセクションで、残りの出力フィールドについて説明します。

監査ルールの追加

コマンドラインツールauditctlを使用して、カスタム監査ルールを追加できます。デフォルトでは、ルールは現在のリストの一番下に追加されますが、一番上にも挿入できます。ルールを永続的にするには、ルールをファイル/etc/audit/rules.d/audit.rulesに追加する必要があります。 auditdサービスが開始されるたびに、ファイルからすべてのルールがアクティブ化されます。監査デーモンと監査システムの詳細については、他の記事 CentOS7[X129Xの監査システムについて]を参照してください。監査ルールは、最初の一致の勝ちに基づいて機能します—ルールが一致すると、それ以降のルールは評価されません。ルールの正しい順序が重要です。

CentOS 6を使用している場合、監査ルールファイルは代わりに/etc/audit/audit.rulesにあります。

監査ルールには次の3つのタイプがあります。

制御ルール：これらのルールは、監査システム自体の構成と設定を変更するために使用されます。
ファイルシステムのルール：これらはファイルまたはディレクトリの監視です。これらのルールを使用して、特定のファイルまたはディレクトリへのあらゆる種類のアクセスを監査できます。
システムコールルール：これらのルールは、任意のプロセスまたは特定のユーザーによって行われたシステムコールを監視するために使用されます。

管理規則

追加できる制御ルールのいくつかを見てみましょう。

auditctl -b <backlog>-許可される未処理の監査バッファーの最大数を設定します。すべてのバッファがいっぱいになると、カーネルが失敗フラグを調べてアクションを実行します。 CentOSサーバーに設定されているデフォルトのバックログ制限は320です。これは、次を使用して表示できます。

sudo auditctl -s

出力では、現在のbacklog_limit値を確認できます。

AUDIT_STATUS: enabled=1 flag=1 pid=9736 rate_limit=0 backlog_limit=320 lost=0 backlog=0

バックログ値が現在設定されているbacklog_limitより大きい場合、監査ログが正しく機能するようにbacklog_limitを増やす必要がある場合があります。たとえば、値を1024に増やすには、次のコマンドを実行します。

sudo auditctl -b 1024

出力にはステータスが表示されます。

AUDIT_STATUS: enabled=1 flag=1 pid=9736 rate_limit=0 backlog_limit=1024 lost=0 backlog=0

auditctl -f [0 1 2]-失敗フラグを設定します（0 =サイレント、1=printk。 2 =パニック）。このオプションを使用すると、カーネルで重大なエラーを処理する方法を決定できます。 0に設定すると、ログに記録できなかった監査メッセージはサイレントに破棄されます。 1に設定すると、メッセージはカーネルログサブシステムに送信されます。 2に設定すると、カーネルパニックが発生します。このフラグが参照される条件の例には、バックログ制限の超過、カーネルメモリの不足、およびレート制限の超過が含まれます。デフォルト値は1です。サーバー上のデーモンの監査に大きな問題がない限り、この値を変更する必要はありません。
auditctl -R <filename>-指定されたファイルから監査ルールを読み取ります。これは、いくつかの一時的なルールをテストしていて、audit.rulesファイルから古いルールを再度使用する場合に役立ちます。

auditctlを介して追加するルールは永続的ではありません。再起動後も永続的にするために、ファイル/etc/audit/rules.d/audit.rulesに追加できます。このファイルは、同じauditctlコマンドライン構文を使用してルールを指定しますが、auditctlコマンド自体は前にありません。空の行またはハッシュ記号（＃）に続くテキストは無視されます。デフォルトのルールファイルは次のようになります。

/etc/audit/rules.d/audit.rules

# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.

# First rule - delete all
-D

# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 320

# Feel free to add below this line. See auditctl man page

バックログ値を8192に変更するには、 -b320を-b8192 に変更し、次を使用して監査デーモンを再起動します。

sudo service auditd restart

デーモンを再起動しない場合でも、次回のサーバーの再起動時に構成から新しい値が設定されます。

ファイルシステムルール

ファイルシステムウォッチは、ファイルとディレクトリに設定できます。監視するアクセスの種類を指定することもできます。ファイルシステムルールの構文は次のとおりです。

auditctl -w path_to_file -p permissions -k key_name

どこ

path_to_fileは、監査されるファイルまたはディレクトリです。 permissionsは、ログに記録される権限です。この値は、r（読み取り）、w（書き込み）、x（実行）、およびa（属性変更）の1つまたは組み合わせにすることができます。 key_nameは、特定のログエントリを生成したルールを識別するのに役立つオプションの文字列です。

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

sudo auditctl -w /etc/hosts -p wa -k hosts_file_change

上記のルールは、監査システムに、ファイル/etc/hostsへの書き込みアクセスまたは属性の変更を監視し、指定されたカスタムキー文字列hosts_file_changeを使用して監査ログに記録するように要求します。

このルールを永続的にしたい場合は、次のように下部のファイル/etc/audit/rules.d/audit.rulesに追加します。

/etc/audit/rules.d/audit.rules

-w /etc/hosts -p wa -k hosts_file_change

ルールが正常に追加されたことを確認するには、次のコマンドを実行します。

sudo auditctl -l

すべてがうまくいけば、出力には次のように表示されます。

LIST_RULES: exit,always watch=/etc/hosts perm=wa key=hosts_file_change

ディレクトリに時計を追加することもできます。

sudo auditctl -w /etc/sysconfig/ -p rwa -k configaccess

上記のルールにより、ディレクトリ/etc/sysconfigとその下のすべてのファイルとディレクトリに監視が追加され、読み取り、書き込み、または属性変更のアクセスが可能になります。また、カスタムキーconfigaccessでログメッセージにラベルを付けます。

/sbin/modprobeコマンドの実行を監視するルールを追加するには（このコマンドはサーバーからカーネルモジュールを追加/削除できます）：

sudo auditctl -w /sbin/modprobe -p x -k kernel_modules

注：最上位ディレクトリに時計を挿入することはできません。これはカーネルによって禁止されています。ワイルドカードもサポートされておらず、警告が生成されます。

特定のイベントの監査ログを検索するには、コマンドausearchを使用できます。たとえば、キーconfigaccessでラベル付けされたすべてのイベントの監査ログを検索するには、次のコマンドを実行できます。

sudo ausearch -k configaccess

ausearchについては、他のチュートリアル CentOS7の監査システムについて詳しく説明しています。

システムコールルール

システムコールを監査することで、アプリケーションレベルをはるかに超えたサーバー上のアクティビティを追跡できます。システムコールルールの構文は次のとおりです。

auditctl -a action,filter -S system_call -F field=value -k key_name`

どこ：

上記のコマンドで-aを-Aに置き換えると、ルールが下部ではなく上部に挿入されます。
actionおよびfilterは、特定のイベントがいつログに記録されるかを指定します。 actionは、alwaysまたはneverのいずれかになります。 filterは、イベントに適用されるカーネルルールマッチングフィルターを指定します。ルール整合フィルターは、task、exit、user、およびexcludeのいずれかになります。 action,filterはほとんどの場合always,exitになり、終了時にこのシステムコールを監査することをauditctlに通知します。
system_callは、システムコールをその名前で指定します。複数のシステムコールを1つのルールにグループ化でき、それぞれが-Sオプションの後に指定されます。 allという単語も使用できます。 sudo ausyscall --dumpコマンドを使用して、すべてのシステムコールとその番号のリストを表示できます。
field=valueは、指定されたアーキテクチャ、ユーザーID、プロセスID、パスなどに基づいてイベントに一致するようにルールを変更する追加オプションを指定します。
key_nameは、特定のログエントリを生成したルールまたはルールのセットを後で識別するのに役立つオプションの文字列です。

ここで、いくつかのシステムコールルールの例を見てみましょう。

IDが1000以上のユーザーによってファイルの名前が変更されるたびに、renameというラベルの付いたログエントリを作成する監査ルールを定義するには、次のコマンドを実行します。

sudo auditctl -a always,exit -F arch=b64 -F "auid>=1000" -S rename -S renameat -k rename

-F arch=b64は、ルール内の64ビットバージョンのシステムコールを監査するように指示しています。

特定のユーザー（UID 1001）がアクセスしたファイルをログに記録し、ログエントリにuserfileaccessのラベルを付けるルールを定義するには：

sudo auditctl -a always,exit -F arch=b64 -F auid=1001 -S open -k userfileaccess

このルールを永続的にしたい場合は、次のように下部のファイル/etc/audit/rules.d/audit.rulesに追加します。

/etc/audit/rules.d/audit.rules

-a always,exit -F arch=b64 -F auid=1001 -S open -k userfileaccess

システムコールルール構文を使用してファイルシステムルールを定義することもできます。たとえば、次のルール：

sudo auditctl -a always,exit -F path=/etc/hosts -F perm=wa -k hosts_file_change

前のセクションで見たファイルシステムルールと同じ仕事をします：

sudo auditctl -w /etc/hosts -p wa -k hosts_file_change

システムコールルールを使用してディレクトリを再帰的に監視するには、オプション-F "dir=/path/to/dir"を使用できます。

注：監査デーモン自体よりも前に開始されたすべてのプロセスには、4294967295のauidがあることに注意してください。それらをルールから除外するには、-F "auid!=4294967295"をルールに追加します。この問題を回避するには、カーネルのブートパラメータにaudit=1を追加します。これにより、監査デーモンが起動する前でも、起動時にカーネル監査システムが有効になり、すべてのプロセスに正しいログインuidが割り当てられます。

監査ルールの削除

現在のすべての監査ルールを削除するには、コマンドauditctl -Dを使用できます。 -wオプションを使用して追加されたファイルシステム監視ルールを削除するには、元のルールの-wを-Wに置き換えることができます。オプション-aまたは-Aを使用して追加されたシステムコールルールは、元のルールで-dオプションを使用して削除できます。たとえば、次のルールを追加したとします。

sudo auditctl -w /etc/passwd -p wa -k passwdaccess

以下を使用してルールセットを表示します。

sudo auditctl -l

出力には次のものが含まれている必要があります。

LIST_RULES: exit,always watch=/etc/passwd perm=wa key=passwdaccess

このルールを削除するには、-wを-Wに置き換えるだけで、次のコマンドを使用できます。

sudo auditctl -W /etc/passwd -p wa -k passwdaccess

次に、以下を使用してルールセットを表示します。

sudo auditctl -l

ルールは現在リストに含まれていないはずです。

注： audit.rulesファイル内に永続的な監査ルールが追加されている場合、監査デーモンの再起動またはシステムの再起動により、ファイルからすべてのルールが読み込まれます。監査ルールを完全に削除するには、ファイルからそれらを削除する必要があります。

監査ルールのロック

auditctl -e [0 1 2]を使用して、監査システムを無効または有効にし、監査ルールをロックすることができます。たとえば、監査を一時的に無効にするには、次のコマンドを実行します。

auditctl -e 0

1が引数として渡されると、監査が有効になります。監査構成をロックして変更できないようにするには、引数として2を渡します。これにより、現在の一連の監査ルールが不変になります。ルールを追加、削除、または編集することはできなくなり、監査デーモンを停止することもできなくなります。構成のロックは、この機能をアクティブにすることを希望するすべての人にとって、audit.rulesの最後のコマンドになることを目的としています。このモードで構成を変更しようとすると、監査されて拒否されます。構成は、サーバーを再起動することによってのみ変更できます。

結論

Linux監査システムによって提供される情報は、侵入検知に非常に役立ちます。これで、特定のイベントをログに記録できるように、カスタム監査ルールを追加できるようになります。

カスタムロギングルールを追加するときは、いつでもauditctlのマニュアルページを参照できることを忘れないでください。コマンドラインオプション、パフォーマンスのヒント、および例の完全なリストを提供します。 /usr/share/doc/audit-<version>/ディレクトリには、いくつかの一般的な認証基準に基づいて事前に構成された監査ルールを含むファイルが含まれています。