前書き
Linux Audit Systemは、システム上のあらゆる種類の情報を追跡する方法である監査証跡を作成します。 イベントの種類、日付と時刻、ユーザーID、システムコール、プロセス、使用ファイル、SELinuxコンテキスト、感度レベルなどの多くのデータを記録できます。 ファイルがアクセス、編集、または実行されたかどうかを追跡できます。 ファイル属性の変更を追跡することもできます。 システムコールの使用状況、ユーザーが実行したコマンド、失敗したログイン試行、および他の多くのイベントを記録できます。 デフォルトでは、監査システムは、ログインしているユーザー、sudoを使用しているユーザー、SELinux関連のメッセージなど、いくつかのイベントのみをログに記録します。 監査ルールを使用して、特定のイベントを監視し、関連するログエントリを作成します。 監査ルールを作成することは可能です。
このチュートリアルでは、さまざまな種類の監査ルールと、サーバーでカスタムルールを追加または削除する方法について説明します。
前提条件
このチュートリアルを始める前に、次のものが必要です。
-
CentOS 7 Droplet（CentOS 6でも動作します）
-
sudo特権を持つ非rootユーザー。 このタイプのユーザーをセットアップするには、https：//www.digitalocean.com/community/tutorials/initial-server-setup-with-centos-7 [CentOS 7での初期サーバーセットアップ]チュートリアルに従ってください。 すべてのコマンドはこのユーザーとして実行されます。
-
Linux Audit Systemの基本的な理解。 詳細については、https：//www.digitalocean.com/community/tutorials/understanding-the-linux-auditing-system-on-centos-7 [CentOS 7の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 +」フィールドには、監査対象の読み取りを待機しているイベントレコードの数が現在キューに入れられています。 このチュートリアルの次のセクションで、残りの出力フィールドについて説明します。
監査ルールの追加
コマンドラインツール `+ auditctl `を使用して、カスタム監査ルールを追加できます。 デフォルトでは、ルールは現在のリストの一番下に追加されますが、一番上にも挿入できます。 ルールを永続的にするには、それらをファイル ` / etc / audit / rules.d / audit.rules `に追加する必要があります。 ` auditd +`サービスが開始されるたびに、ファイルのすべてのルールがアクティブになります。 監査デーモンと監査システムの詳細については、他の記事https://www.digitalocean.com/community/tutorials/understanding-the-linux-auditing-system-on-centos-7 [監査システムについて]をご覧ください。 CentOS 7で]。 監査ルールは、最初に一致したものが優先的に機能します。ルールが一致すると、それ以降のルールは評価されません。 ルールの正しい順序が重要です。
監査ルールには次の3つのタイプがあります。
-
制御規則：これらの規則は、監査システム自体の構成と設定を変更するために使用されます。
-
ファイルシステムのルール：これらはファイルまたはディレクトリの監視です。 これらのルールを使用して、特定のファイルまたはディレクトリへのあらゆる種類のアクセスを監査できます。
-
システムコールルール：これらのルールは、プロセスまたは特定のユーザーによるシステムコールの監視に使用されます。
制御規則
追加できる制御ルールのいくつかを見てみましょう。
-
+ auditctl -b <backlog> +-許可される未処理の監査バッファーの最大数を設定します。 すべてのバッファーがいっぱいの場合、カーネルはアクションのために障害フラグを調べます。 CentOSサーバーに設定されているデフォルトのバックログ制限は320です。 これは次を使用して表示できます。
sudo auditctl -s出力では、現在の* backlog_limit *値を確認できます。
AUDIT_STATUS: enabled=1 flag=1 pid=9736 rate_limit=0 lost=0 backlog=0バックログ値が現在設定されている* backlog_limit よりも大きい場合、監査ロギングが正しく機能するために backlog_limit *を増やす必要がある場合があります。 たとえば、値を1024に増やすには、次を実行します。
sudo auditctl -b 1024出力にはステータスが表示されます。
AUDIT_STATUS: enabled=1 flag=1 pid=9736 rate_limit=0 lost=0 backlog=0-
+ auditctl -f [0 1 2] +-障害フラグを設定します（0 =サイレント、1 = printk。 2 =パニック）。 このオプションにより、カーネルが重大なエラーを処理する方法を決定できます。 0に設定すると、ログに記録できなかった監査メッセージは静かに破棄されます。 1に設定すると、メッセージがカーネルログサブシステムに送信されます。 2に設定すると、カーネルパニックが発生します。 このフラグが参照される条件の例には、バックログ制限の超過、カーネルメモリ不足、レート制限の超過が含まれます。 デフォルト値は1です。 サーバーの監査デーモンに大きな問題がない限り、この値を変更する必要はありません。 -
+ auditctl -R <filename> +-指定されたファイルから監査ルールを読み取ります。 これは、一時的なルールをテストしていて、 `+ audit.rules +`ファイルから古いルールを再度使用する場合に便利です。
`+ auditctl s`を介して追加するルールは永続的ではありません。 再起動後もそれらを永続的にするには、ファイル「+ / 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に変更するには、-b 320 *を -b 8192 *に変更し、次を使用して監査デーモンを再起動します。
sudo service auditd restartデーモンを再起動しないと、次回のサーバーの再起動時に構成から新しい値が設定されます。
ファイルシステムのルール
ファイルシステムの監視は、ファイルとディレクトリに設定できます。 監視するアクセスの種類を指定することもできます。 ファイルシステムルールの構文は次のとおりです。
auditctl -w -p -kどこで
`+ path_to_file `は監査されるファイルまたはディレクトリです。 ` permissions `はログに記録される許可です。 この値は、r（読み取り）、w（書き込み）、x（実行）、およびa（属性変更）の1つまたは組み合わせにすることができます。 ` key_name +`は、特定のログエントリを生成したルールを識別するのに役立つオプションの文字列です。
いくつかの例を見てみましょう。
sudo auditctl -w /etc/hosts -p wa -k hosts_file_change上記のルールは、ファイル + / etc / hosts +`への書き込みアクセスまたは属性の変更を監視し、usによって指定されたカスタムキー文字列- + 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 +`については、他のチュートリアルhttps://www.digitalocean.com/community/tutorials/understanding-the-linux-auditing-system-on-centos-7[CentOS 7の監査システムについて]で詳しく説明しています。 。
システムコールルール
システムコールを監査することにより、アプリケーションレベルをはるかに超えるサーバー上のアクティビティを追跡できます。 システムコールルールの構文は次のとおりです。
auditctl -a -S -F -k `ここで、
-
上記のコマンドで「+ -a 」を「 -A +」に置き換えると、ルールが下部ではなく上部に挿入されます。
-
`+ action `と ` filter `は、特定のイベントが記録されるタイミングを指定します。 「 action」は「+ always」または「+ never」のいずれかです。 `+ filter `は、イベントに適用されるカーネルルール一致フィルターを指定します。 ルール一致フィルターは、次のいずれかです。「 task 」、「 exit 」、「 user 」、および「 exclude 」。 ほとんどの場合、「 action、filter 」は「 always、exist」になり、終了時にこのシステムコールを監査することを「+ auditctl s」に伝えます。
-
`+ 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 "+`を使用できます。
監査ルールの削除
現在のすべての監査ルールを削除するには、コマンド `+ 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ルールは現在リストにないはずです。
監査ルールのロック
`+ auditctl -e [0 1 2] +`を使用して、監査システムを無効または有効にし、監査ルールをロックすることができます。 たとえば、監査を一時的に無効にするには、次を実行します。
auditctl -e 0`+ 1 `が引数として渡されると、監査が有効になります。 変更できないように監査設定をロックするには、引数として「+2」を渡します。 これにより、現在の監査ルールのセットは不変になります。 ルールの追加、削除、編集はできなくなり、監査デーモンは停止できなくなりました。 設定のロックは、この機能を有効にしたい人のための `+ audit.rules +`の最後のコマンドになることを目的としています。 このモードで構成を変更しようとすると、監査されて拒否されます。 構成を変更するには、サーバーを再起動する必要があります。
結論
Linux監査システムが提供する情報は、侵入検知に非常に役立ちます。 これで、カスタム監査ルールを追加して、特定のイベントをログに記録できるようになります。
カスタムロギングルールを追加するときはいつでも `+ auditctl `のマニュアルページを参照できることに注意してください。 コマンドラインオプション、パフォーマンスのヒント、および例の完全なリストを提供します。 ` / usr / share / doc / audit-/ +`ディレクトリには、いくつかの一般的な認証基準に基づいて事前に設定された監査ルールを持つファイルが含まれています。