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
The enabled=1
値は、このサーバーで監査が有効になっていることを示します。 The pid
valueは、監査デーモンのプロセス番号です。 pid 0は、監査デーモンが実行されていないことを示します。 The lost
エントリは、カーネル監査キューがオーバーフローしたために破棄されたイベントレコードの数を示します。 The backlog
フィールドには、auditdが読み取るのを待って現在キューに入れられているイベントレコードの数が表示されます。 このチュートリアルの次のセクションで、残りの出力フィールドについて説明します。
監査ルールの追加
コマンドラインツールを使用してカスタム監査ルールを追加できます auditctl
. デフォルトでは、ルールは現在のリストの一番下に追加されますが、一番上にも挿入できます。 ルールを永続的にするには、ルールをファイルに追加する必要があります /etc/audit/rules.d/audit.rules
. いつでも auditd
サービスが開始されると、ファイルからすべてのルールがアクティブになります。 監査デーモンと監査システムの詳細については、他の記事
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
前に自分自身を命令します。 空の行またはハッシュ記号(#)に続くテキストは無視されます。 デフォルトのルールファイルは次のようになります。
# 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
このように下部に:
-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
は、特定のログエントリを生成したルールまたはルールのセットを後で識別するのに役立つオプションの文字列です。
ここで、いくつかのシステムコールルールの例を見てみましょう。
ラベルの付いたログエントリを作成する監査ルールを定義するには rename
IDが1000以上のユーザーによってファイルの名前が変更されるたびに、次のコマンドを実行します。
- sudo auditctl -a always,exit -F arch=b64 -F "auid>=1000" -S rename -S renameat -k rename
The -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
このように下部に:
-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"
.
注:監査デーモン自体よりも前に開始されたすべてのプロセスには、 auid
の 4294967295
. それらをルールから除外するには、追加できます -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
カスタムロギングルールを追加するときのマニュアルページ。 コマンドラインオプション、パフォーマンスのヒント、および例の完全なリストを提供します。 The /usr/share/doc/audit-<version>/
ディレクトリには、いくつかの一般的な認証基準に基づいて事前に構成された監査ルールを含むファイルが含まれています。