auditdを使用したLinuxファイルアクセスの監視

投稿日: 2022-11-11 2022-11-11
タグ: Filesystems

1. 序章

Linuxシステムには、多くの場合、複数のユーザーがいます。監査は、このようなマルチユーザー環境の重要な部分です。特に、ファイルシステムのアトミック部分として、ファイルは通常監視対象のユニットです。

このチュートリアルでは、Linuxでファイルアクセスの監視を実行する方法について説明します。最初に、ファイルアクセス許可の復習を行います。次に、監査の一般的なトピックにジャンプします。その後、Linuxでの監査について詳しく説明します。具体的には、広く使用されている監査コンポーネントを使用したファイルアクセスのインストール、構成、および監視について説明します。

このチュートリアルのコードは、GNU Bash5.1.4を使用したDebian11（Bullseye）でテストしました。ほとんどのPOSIX準拠環境で機能するはずです。

2. 俳優を探す

どのシステムでも誰が何をしたかを知ることは簡単ではありません。

たとえば、単純なケースを考えてみましょう。マルチユーザーLinux環境でファイルが失われます。通常、管理者は ls を介して、誰がそのファイルを所有またはアクセスしたかを確認できます。

$ ls -l /dir/file
-rwxr--r-- 1 user1 user1 666 May 6 16:56 file

行を読むと、所有権と権限を解読できます。

特に、ユーザー user1 が唯一の所有者であり、読み取り（ r ）および書き込み（ w ]）通常の（最初の – ）ファイルへのアクセス。さらに、 user1 とも呼ばれるユーザーのプライベートグループ、およびグローバル権限は読み取り専用です。

実際には、削除には、含まれているディレクトリに対する読み取り、書き込み、および実行権限が必要です。

$ ls -l /dir
drwxrwxrwx 1 root root 4096 May 6 16:25 .
drwxr-xr-x 1 root root 4096 May 6 06:25 ..

追加したことに注意してください -a スペシャルを取得するためのフラグ。ディレクトリの / dir 、その属性を教えてくれます。

これで、user1が/dir /fileを削除した可能性があることがわかりました。将来、どのように確認しますか？

3. 監査

監査の一般的な考え方は、ユーザーのアクションを抑制できるようにすることです。アクティビティを特定のアカウントにマッピングする方法を提供し、管理者が以下を追跡できるようにします。

実行されたアクション
どのユーザーが行動したか
どのオブジェクトが関与していたか
イベントが発生した時間

暗号化で保護された認証と承認などの強力なセキュリティの概念と組み合わせることで、監査はほぼ完全な説明責任を保証できます。

このようにして、レコードの証跡が存在し、それによってイベントを再構築できます。実際、このメカニズムは、データに関して、mysqlなどのデータベースの追跡に使用されるログとほぼ同じです。

$ cat /var/lib/mysql/audit.log
[...]
<AUDIT_RECORD>
  <TIMESTAMP>2022-10-05T16:06:56 UTC</TIMESTAMP>
  <RECORD_ID>6_2022-10-05T16:03:33</RECORD_ID>
  <NAME>Query</NAME>
  <CONNECTION_ID>5</CONNECTION_ID>
  <STATUS>0</STATUS>
  <STATUS_CODE>0</STATUS_CODE>
  <USER>root[root] @ localhost [127.0.0.1]</USER>
  <OS_LOGIN/>
  <HOST>localhost</HOST>
  <IP>127.0.0.1</IP>
  <COMMAND_CLASS>drop_table</COMMAND_CLASS>
  <SQLTEXT>DROP TABLE IF EXISTS t</SQLTEXT>
 </AUDIT_RECORD>
 [...]

もちろん、オペレーティングシステムの監査では、一部のデータベースのように直接リカバリを行うことはできません。そのためには、データと手段が必要です。このように、監査データはバックアップログと単純な履歴ログの間のどこかにあります。

$ cat /home/user1/.mysql_history
create database baeldung
create user user1@localhost IDENTIFIED BY 'password'
grant select,insert,update,delete,create,drop,index,alter,create temporary tables,lock tables on baeldung.* to user1@localhost
flush privileges
exit

ただし、そのような知識を備えているため、手動のフォレンジックに頼るよりもはるかに優れた立場にあります。これがオペレーティングシステムレベルでどのように機能するかを見てみましょう。

4. auditdを使用したLinux監査

Linuxでは、さまざまな方法で監査を実行および自動化できます。非常に単純なケースでは、inotifywaitとinotifywatchを使用できます。ただし、包括的なauditdパッケージの方が適している場合があります。

4.1. インストールと主な構成

デフォルトではすべてのLinuxディストリビューションの一部ではないため、auditdを独自にインストールする必要がある場合があります。

$ apt-get install auditd
[...]

次に、/etc/audit/auditd.confでデーモンのデフォルト構成を確立します。

$ cat /etc/audit/auditd.conf
#
# This file controls the configuration of the audit daemon
#

local_events = yes
write_logs = yes
log_file = /var/log/audit/audit.log
log_group = adm
log_format = ENRICHED
flush = INCREMENTAL_ASYNC
freq = 50
max_log_file = 8
num_logs = 5
priority_boost = 4
name_format = NONE
##name = mydomain
... long output omited
transport = TCP
krb5_principal = auditd
##krb5_key_file = /etc/audit/audit.key
distribute_network = no
q_depth = 400
overflow_action = SYSLOG
max_restarts = 10
plugin_dir = /etc/audit/plugins.d

ファイル内の重要な設定のほとんどは自明であり、適切なデフォルトがあります。残りの部分については、構成リファレンスを使用できます。

重要なのは、 log_file へのパスを書き留めておく必要があります：/var/log/audit/audit.log。もちろん、それが問題になるには、write_logsがyesである必要があります。

auditd がニーズに合うようにするには、監査が実行されることに基づいて、いくつかのルールを設定する必要がある場合もあります。

4.2. ルール構造

基本的に、ルールは監査イベントの記録を管理するトリガーです。ファイアウォールと同様に、イベントがルールに一致すると、ログに記録されます。

ルールは/etc/audit/audit.rulesファイルに保存されます：

$ cat /etc/audit/audit.rules
## This file is automatically generated from /etc/audit/rules.d
-D
-b 8192
-f 1
--backlog_wait_time 60000

ただし、このファイルは、/etc/audit/rules.d/ディレクトリにあるすべての.rulesファイルの統合バージョンにすぎません。

$ ls /etc/audit/rules.d/
audit.rules

したがって、ルールを適切に変更または追加するには、最初にそこでファイルを変更または作成する必要があります。

4.3. ルールを理解する

まず、デフォルトを確認しましょう。

$ cat /etc/audit/rules.d/audit.rules
## First rule - delete all
-D

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

## This determine how long to wait in burst of events
--backlog_wait_time 60000

## Set failure mode to syslog
-f 1

ほとんどの場合、オプションはコメントで説明されています。バッファサイズは、バイトの倍数ではなく、エントリに含まれていることに注意してください。

ルールファイル行のすべてのオプションは次のとおりです：

＃
-w -p -k
-a 、 -S -F -k
–

パッケージはルール構文に関して非常に厳密であることに注意してください。たとえば、ルールと同じ行のコメントは許容されません。また、ルールの繰り返しは危険です。したがって、問題を回避するには、構文に厳密に従う必要があります。これを念頭に置いて、続行できます。

4.4. ルールの設定

それでは、非常に単純なルールファイル/etc/audit/rules.d/baeldung.rulesを作成しましょう。

## Enable ruleset
-e 1
## Limit the rate to 120 audit entries per second
-r 120

## Monitor /baeldung for rwxa events
-w /baeldung -p rwxa -k toplevel_baeldung
## Monitor /file for read events
-w /file     -p r    -k root_file
## Monitor for name change syscall
-S sethostname -a always,exit -k hostname_change

ここで、 -w / baeldung -p rwxa -k toplevel_baeldungは、読み取り（r）、書き込み（w）、実行（x）、または属性変更（a）を含むイベントがないか/baeldungディレクトリを監視します。

一方、 -a always、exit -S sethostname -k hostname_change は、システムコールを監視します（ -S with sethostname ）。イベントをログに記録するにはalwaysアクションが必要ですが、exitはそれがいつどのように発生するかを決定します。

基本的に、ルールファイルのすべての行がユーザースペース監査制御コンポーネントauditctlに渡されます。したがって、ツールのマニュアルを介して任意のルールを解釈できます。

4.5. デーモンの起動

準備手順が完了したら、augenrulesを介して構成をロードできます。

$ augenrules --check
/sbin/augenrules: Rules have changed and should be updated
$ augenrules --load
No rules
enabled 1
failure 2
[...]
$ augenrules --check
/sbin/augenrules: No change

ここで、 –check スイッチは新しいルールの追加をテストし、 –loadは/etc/audit/rules.d/からすべてのルールを再生成します。

重要なのは、 augenrules –check が偽陰性を示し、構文に問題がある場合は変更なしと主張する場合があることです。ここで問題を診断するには、ルールを確認し、それらが正しいことを確認します。さらに、何が有効であるかを確認できます。

$ auditctl -l
-w /baeldung -p rwxa -k toplevel_baeldung
-w /file -p r -k root_file
-a always,exit -S sethostname -F key=hostname_change

-lをauditctlに切り替えると、現在アクティブなすべてのルールが一覧表示されます。

最後に、auditdを使用してデーモンを実行できます。

$ auditd

通常、 journalctl -uauditdを使用して起動中に問題を探すことができます。

4.6. ログを読む

上記の構成で見たパスを使用してログを確認してみましょう。

$ cat /var/log/audit/audit.log
type=DAEMON_START msg=audit(1644796660.200:666): op=start ver=3.0.7
  format=enriched kernel=4.9.0-8-amd64 auid=4294967295 pid=1666000 =0 ses=4294967295
  subj=unconfined  res=success AUID="unset" UID="root"
[...]
type=SERVICE_START msg=audit(1644796660.216:669): pid=1 uid=0 auid=4294967295
  ses=4294967295 subj==unconfined msg='unit=auditd comm="systemd"
  exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
  UID="root" AUID="unset"

明らかに、サービスは開始されました。また、 type = DAEMON_START 行から、 PID 1666000であることがわかります。

さらに、他のイベントの一部である msg セクション（ 1644796660.200 ）からタイムスタンプを抽出できます。その後にコロンで区切られ、イベント識別番号（666および669）があります。

これで、ログを手動で参照するか、提供されているausearchを使用してフィルター検索を行うことができます：

$ ausearch --event 666
----
time->Tue Feb 15 20:11:06 2022
type=DAEMON_START msg=audit(1644948666.200:666): op=start ver=3.0.7
  format=enriched kernel=4.9.0-8-amd64 auid=4294967295 pid=1666000 uid=0
  ses=4294967295 subj=unconfined  res=success AUID="unset" UID="root"

特に、 ausearchの大きな利点は–interpret（-i）フラグです。これは、メッセージの一部が16進エンコードされているため、メッセージ内のデータをデコードします。

$ ausearch --event 666 --interpret
----
time->Tue Feb 15 20:11:06 2022
type=DAEMON_START msg=audit(02/15/2022 20:11:06.200:666): op=start ver=3.0.7
  format=enriched kernel=4.9.0-8-amd64 auid=unset pid=1666000 uid=0 ses=unset
  subj=unconfined  res=success

出力を比較すると、レコード内のauidパラメーターの値が16進数の文字列からunsetに変換されたことがわかります。また、日付スタンプは人間が読める形式に変換されます。

上記の両方の例では、イベント番号を直接使用しましたが、他にも多くの基準があります。例：

-m （ –message ）メッセージタイプでクエリ
-c （ –comm ）コマンド名でクエリ
-ui （ –uid ）ユーザーIDでクエリ

さらに、出力を raw 、 default 、 interpret 、 csv 、およびtextとしてフォーマットできます。これは、 –formatフラグを介して可能です。

5. auditdを使用したイベントの生成とレコードの確認

最後に、いくつかの簡単な例を使用して、auditdの動作を確認できます。最初に読み取りと書き込みを調べてから、削除に移りましょう。

5.1. 読み書き

まず、 /fileに書き込みましょう。

$ echo Input. > /file

次に、 –fileフラグが設定されたファイルでアクションがないかログを確認します。

$ ausearch --file /file
<no matches>

ここでは、一致するものはありません。これは、ルールに従って、読み取りイベントのみを監査しているためです。これを念頭に置いて、catを介して簡単な読み取りを実行してみましょう。

$ cat /file
Input.
$ ausearch --file /file --interpret
----
type=PROCTITLE msg=audit(02/15/2022 20:12:22.240:11666) : proctitle=cat /file
type=PATH msg=audit(02/15/2022 20:12:22.240:11666) : item=0 name=/file inode=22
  dev=08:11 mode=file,644 ouid=root ogid=root rdev=00:00 nametype=NORMAL
  cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(02/15/2022 20:12:22.240:11666) : cwd=/
type=SYSCALL msg=audit(02/15/2022 20:12:22.240:11666) : arch=x86_64
  syscall=openat success=yes exit=3 a0=AT_FDCWD a1=0x7fffd21697d9 a2=O_RDONLY
  a3=0x0 items=1 ppid=1732318 pid=1733641 auid=user1 uid=user1 gid=user1
  euid=user1 suid=user1 fsuid=user1 egid=user1 sgid=user1 fsgid=user1
  tty=pts1 ses=3873 comm=cat exe=/usr/bin/cat subj==unconfined key=root_file

レコードとも呼ばれるこれらの行はすべて、同じイベント11666の一部です。そのイベントのtype= PATH 行には、 iノード番号、デバイス、モードなどのファイル自体の詳細が表示されます。

さらに、 type = SYSCALL で始まる行が主な関心事であり、ルールの key =root_file値によっても識別されます。実際には、完全なユーザー名（ uid = user1 ）が含まれています。結果を解釈しない場合、ユーザーは番号で記録されます。その場合、idを介してユーザー名を取得できます。

$ id -nu 1000
user1

type = SYSCALL レコードは、ファイルへのアクセスに使用されるコマンド（ comm = cat 、 exe = / usr / bin / cat ）も提供します。

5.2. 消す

前のファイル削除の例に戻ると、 /baeldungのサブディレクトリから誰がファイルを削除したかを検出できます。まず、1つのファイルを含むファイルを作成しましょう。

$ mkdir --parents /baeldung/x/
$ echo Input. > /baeldung/x/file.ext

次に、ログを確認します。

$ ausearch --file /baeldung --interpret
type=PROCTITLE msg=audit(02/15/2022 20:30:40.504:12666) : proctitle=mkdir --parents /baeldung/x/
type=PATH msg=audit(02/15/2022 20:30:40.504:12666) : item=4 name=(null) inode=1966583
  dev=08:11 mode=dir,755 ouid=root ogid=root rdev=00:00 nametype=CREATE cap_fp=none
  cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=PATH msg=audit(02/15/2022 20:30:40.504:12666) : item=3 name=(null) inode=1966582
  dev=08:11 mode=dir,755 ouid=root ogid=root rdev=00:00 nametype=PARENT cap_fp=none
  cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=PATH msg=audit(02/15/2022 20:30:40.504:12666) : item=2 name=(null) nametype=CREATE
  cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=PATH msg=audit(02/15/2022 20:30:40.504:12666) : item=1 name=(null) inode=1966582
  dev=08:11 mode=dir,755 ouid=root ogid=root rdev=00:00 nametype=PARENT cap_fp=none
  cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=PATH msg=audit(02/15/2022 20:30:40.504:12666) : item=0 name=/baeldung inode=1966582
  dev=08:11 mode=dir,755 ouid=root ogid=root rdev=00:00 nametype=PARENT cap_fp=none
  cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(02/15/2022 20:30:40.504:12666) : cwd=/baeldung
type=SYSCALL msg=audit(02/15/2022 20:30:40.504:12666) : arch=x86_64 syscall=mkdir
  success=yes exit=0 a0=0x7ffcf6eb17d8 a1=0777 a2=0x0 a3=0xfffffffffffffb8d items=5
  ppid=1732318 pid=1734036 auid=noot uid=root gid=root euid=root suid=root fsuid=root
  egid=root sgid=root fsgid=root tty=pts1 ses=3873 comm=mkdir exe=/usr/bin/mkdir
  subj==unconfined key=toplevel_baeldung
[...]

ディレクトリ/baeldung/xとファイル/baeldung/x/file.extの両方の作成と作成、および責任のあるユーザー（ root ）。次に、ディレクトリ全体のパーミッションを変更して、すべてのユーザーがファイルを削除できるようにします。

$ ls -la /baeldung
total 12
drwxr-xr-x  3 root root 4096 Feb 18 00:06 .
drwxr-xr-x 29 root root 4096 Feb 18 00:01 ..
drwxr-xr-x  2 root root 4096 Feb 15 00:06 x
$ chmod --recursive 777 /baeldung
$ ls -la /baeldung/.
total 12
drwxrwxrwx  3 root root 4096 Feb 15 00:06 .
drwxr-xr-x 29 root root 4096 Feb 15 00:01 ..
drwxrwxrwx  2 root root 4096 Feb 15 00:06 x

–comm フラグからわかるように、これらの変更にもレコードが関連付けられています。

$ ausearch --file /baeldung --comm chmod --interpret
----
type=PROCTITLE msg=audit(02/15/2022 20:56:56.248:12696) : proctitle=chmod --recursive 777 /baeldung
type=PATH msg=audit(02/15/2022 20:56:56.248:12696) : item=0 name=/baeldung inode=1966582
  dev=08:11 mode=dir,755 ouid=root ogid=root rdev=00:00 nametype=NORMAL cap_fp=none
  cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(02/15/2022 20:56:56.248:12696) : cwd=/
type=SYSCALL msg=audit(02/15/2022 20:56:56.248:12696) : arch=x86_64 syscall=fchmodat
  success=yes exit=0 a0=AT_FDCWD a1=0x55b15f13e500 a2=0777 a3=0xfffffffffffffd2c
  items=1 ppid=1732318 pid=1734049 auid=noot uid=root gid=root euid=root suid=root
  fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=3873 comm=chmod exe=/usr/bin/chmod
  subj==unconfined key=toplevel_baeldung
----
type=PROCTITLE msg=audit(02/15/2022 20:56:56.248:12697) : proctitle=chmod --recursive 777 /baeldung
type=PATH msg=audit(02/15/2022 20:56:56.248:12697) : item=0 name=/baeldung inode=1966582
  dev=08:11 mode=dir,777 ouid=root ogid=root rdev=00:00 nametype=NORMAL cap_fp=none
  cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(02/15/2022 20:56:56.248:12697) : cwd=/
type=SYSCALL msg=audit(02/15/2022 20:56:56.248:12697) : arch=x86_64 syscall=openat
  success=yes exit=3 a0=AT_FDCWD a1=0x55b15f13e500
  a2=O_RDONLY|O_NOCTTY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC a3=0x0 items=1 ppid=1732318
  pid=1734049 auid=noot uid=root gid=root euid=root suid=root fsuid=root egid=root
  sgid=root fsgid=root tty=pts1 ses=3873 comm=chmod exe=/usr/bin/chmod subj==unconfined
  key=toplevel_baeldung

最後に、file.extをuser1として削除しましょう。

$ whoami
user1
$ rm --force /baeldung/x/file.ext

イベントレコードには、必要なすべてのデータが含まれています。

$ ausearch --file /baeldung/x/file.ext --comm rm --interpret
----
type=PROCTITLE msg=audit(02/15/2022 23:59:59.159:16660) : proctitle=rm --force /baeldung/x/file.ext
type=PATH msg=audit(02/15/2022 23:59:59.159:16660) : item=1 name=/baeldung/x/file.ext
  inode=1966584 dev=08:11 mode=file,777 ouid=user1 ogid=user1 rdev=00:00 nametype=DELETE
  cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=PATH msg=audit(02/15/2022 23:59:59.159:16660) : item=0 name=/baeldung/x/
  inode=1966583 dev=08:11 mode=dir,777 ouid=user1 ogid=user1 rdev=00:00
  nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(02/15/2022 23:59:59.159:16660) : cwd=/
type=SYSCALL msg=audit(02/15/2022 23:59:59.159:16660) : arch=x86_64 syscall=unlinkat
  success=yes exit=0 a0=AT_FDCWD a1=0x56227e23e4d0 a2=0x0 a3=0xfffffffffffffbca items=2
  ppid=1732318 pid=1734073 auid=noot uid=user1 gid=user1 euid=user1 suid=user1 fsuid=user1
 egid=user1 sgid=user1 fsgid=user1 tty=pts1 ses=3873 comm=rm exe=/usr/bin/rm
  subj==unconfined key=toplevel_baeldung

内容を変更したため、監査エントリにもディレクトリのデータが含まれていることに注意してください。

これで、特定のディレクトリ内のデータの削除につながったすべてのイベントの証拠が得られました。議論の余地のないものにしましょう。

6. セキュリティと統合

あらゆる種類のログを保護することは重要ですが、監査情報はその性質上機密性があります。このため、rootのみが監査ログにアクセスできることを確認しましょう。

$ ls -la /var/log/audit/audit.log
-rw-r----- 1 root root 66600 May 16 12:15 /var/log/audit/audit.log

重要なことに、これは、複数のノードからの情報を格納するときにさらに重要になる可能性があります。 auditd パッケージを使用すると、サーバーを他のマシンからのイベントの統合ノードとして構成できるため、シナリオが発生する可能性があります。

もちろん、あらゆる面で中央ノードのセキュリティを強化することは非常に重要です。これには、SSHアクセスやファイアウォールなどの領域が含まれます。

7. 概要

この記事では、Linuxの包括的なauditdパッケージについて説明しました。具体的には、デーモンをインストール、構成、および使用してファイルアクセスを監視する方法について説明しました。

結論として、 auditd を使用すると、Linuxは、ファイルおよびオペレーティングシステムのイベントに関する情報を監査、監視、および収集するための包括的なオプションを提供します。

getdocs

13036