「Audit フレームワーク」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(英語版より部分的に翻訳)
 
(トラブルシューティングを翻訳して追加)
 
(4人の利用者による、間の9版が非表示)
1行目: 1行目:
 
[[Category:セキュリティ]]
 
[[Category:セキュリティ]]
  +
[[Category:ロギング]]
 
[[en:Audit framework]]
 
[[en:Audit framework]]
Linux の audit フレームワークは CAPP (Controlled Access Protection Profiles) に準拠した監査システムであり、システム上のセキュリティに関係したまたは無関係なイベントを収集できます。これを使うことにより、システム上で行われた動作を追跡できるようになります。
+
Linux の audit フレームワークは CAPP ([[Wikipedia:Controlled Access Protection Profile|Controlled Access Protection Profile]]) に準拠した監査システムであり、システム上のセキュリティに関係した(または無関係な)イベントを収集できます。audit を使うことにより、システム上で行われた動作を追跡できるようになります。
   
  +
Linux audit はシステム上で何が起きているかを詳細に分析できる手段であり、システムをよりセキュアにするために役に立ちます。しかしそれ自体がなにかセキュリティを強化するものではありません。つまり、それ自体が悪意のあるコードや様々な悪用からシステムを守ってくれるものではありません。そうではなく、これらの問題を追跡し、セキュリティ対策を施すための情報を audit は提供します。
Linux audit helps make your system more secure by providing you with a means to analyze what is happening on your system in great detail. It does not, however, provide additional security itself—it does not protect your system from code malfunctions or any kind of exploits. Instead, Audit is useful for tracking these issues and helps you take additional security measures, to prevent them.
 
   
 
audit フレームワークはカーネルが報告するイベントを受信し、ログファイルに書き込みます。
 
audit フレームワークはカーネルが報告するイベントを受信し、ログファイルに書き込みます。
   
  +
{{Note|1=audit フレームワークとコンテナとの互換性は Linux 3.15 で修正されました。[https://bugzilla.redhat.com/show_bug.cgi?id=893751] を参照してください。ただし、ネームスペース ID のサポートがまだ進行中であるため、audit レコードの解釈が難しい場合があります。[https://github.com/linux-audit/audit-kernel/issues/32] を参照してください。}}
{{Note|Linux 3.12の時点では、audit フレームワークは名前空間の実装と互換性がありません。名前空間を使っている場合は audit フレームワークを使わないでください。}}
 
{{Note|システムのパフォーマンスに影響を与える可能性があります。}}
 
   
==インストール==
+
== インストール ==
CONFIG_AUDIT を有効にしたカスタムカーネルをインストールします。
 
{{Pkg|audit}} をインストールし、次を実行します:
 
# systemctl enable auditd.service
 
# systemctl start auditd.service
 
   
  +
カーネルによる audit サポートは、{{Pkg|linux}}(4.18以降)、{{Pkg|linux-lts}}(4.19以降)、{{Pkg|linux-zen}}(4.18以降)、および {{Pkg|linux-hardened}} で利用できます。 カスタムカーネルの場合、{{ic|CONFIG_AUDIT}} を有効にする必要があります。 カーネルパラメータとして {{ic|1=audit=1}} を設定すると、ブート時に auditd を有効にできます。
audit フレームワークは auditd デーモンから構成されます。アプリケーションやシステムの動作によりカーネルの audit インターフェイスが発動し、audit インターフェイスが生成した audit メッセージを auditd が書き込みます。
 
  +
  +
ユーザースペースのサポートについては、{{Pkg|audit}} を [[インストール]]し、{{ic|auditd.service}} を[[起動]]・[[有効化]]します。
  +
  +
{{Note|audit を完全に無効にし、audit メッセージがジャーナルに表示されないようにするには、[[カーネルパラメータ]] として {{ic|1=audit=0}} を設定と、{{ic|systemd-journald-audit.socket}} を [[マスク]] のどちらか(または両方)を実行します。}}
  +
  +
audit フレームワークは auditd デーモンから設定されます。アプリケーションやシステムの動作によりカーネルの audit インターフェイスが発動し、audit インターフェイスが生成した audit メッセージを auditd が書き込みます。
   
 
このデーモンはいくつかのコマンドとファイルにより制御されます:
 
このデーモンはいくつかのコマンドとファイルにより制御されます:
 
* auditctl : その場でデーモンの挙動をコントロールします。ルールを追加するなど
 
* auditctl : その場でデーモンの挙動をコントロールします。ルールを追加するなど
* /etc/audit/audit.rules : ルールや auditd のパラメータを記述します
+
* {{ic|/etc/audit/audit.rules}} : ルールや auditd のパラメータを記述します
 
* aureport : システムの動作レポートを生成します
 
* aureport : システムの動作レポートを生成します
 
* ausearch : イベントを検索します
 
* ausearch : イベントを検索します
 
* auditspd : イベント通知をディスク上のログに書き込む代わりに他のアプリケーションに中継するデーモンです
 
* auditspd : イベント通知をディスク上のログに書き込む代わりに他のアプリケーションに中継するデーモンです
 
* autrace : プロセスをトレースするためのコマンド。straceに似ています
 
* autrace : プロセスをトレースするためのコマンド。straceに似ています
* /etc/audit/auditd.conf : ログに関する設定ファイルです
+
* {{ic|/etc/audit/auditd.conf}} : ログに関する設定ファイルです
  +
  +
== ルールの追加 ==
   
==ルールの追加==
 
 
ルールを追加する前に注意しなければならないのは、audit フレームワークは非常に饒舌で、ルールを実際に運用する前に注意深くテストする必要があることです。実際、たった1つのルールにより2,3分でログを溢れてしまうこともあり得ます。
 
ルールを追加する前に注意しなければならないのは、audit フレームワークは非常に饒舌で、ルールを実際に運用する前に注意深くテストする必要があることです。実際、たった1つのルールにより2,3分でログを溢れてしまうこともあり得ます。
   
===ファイルとディレクトリへのアクセスを監査する===
+
=== ファイルとディレクトリへのアクセスを監査する ===
  +
audit フレームワークの一番簡単な使い方は、特定のファイルへのアクセスをログに記録することです。
 
  +
audit フレームワークの一番簡単な使い方は、特定のファイルへのアクセスをログに記録することです。それには {{ic|-w}} オプションを使います。一番簡単なルールの例として passwd ファイルへのアクセスを追跡する例:
それには {{ic|-w}} オプションを使います。
 
一番簡単なルールの例として passwd ファイルへのアクセスを追跡する:
 
   
 
# auditctl -w /etc/passwd -p rwxa
 
# auditctl -w /etc/passwd -p rwxa
41行目: 43行目:
 
# auditctl -w /etc/security/
 
# auditctl -w /etc/security/
   
最初のルールは {{ic|/etc/passwd}} への読み込み {{ic|r}}、書き込み {{ic|w}}、実行 {{ic|x}}、属性変更 {{ic|a}} を追跡します。
+
最初のルールは {{ic|/etc/passwd}} への読み込み {{ic|r}}、書き込み {{ic|w}}、実行 {{ic|x}}、属性変更 {{ic|a}} を追跡します。2番目のルールは {{ic|/etc/security/}} への全てのアクセスを追跡します。
2番目のルールは {{ic|/etc/security/}} への全てのアクセスを追跡します。
 
   
 
有効なルールのリストを表示するには:
 
有効なルールのリストを表示するには:
57行目: 58行目:
 
-w /etc/security/
 
-w /etc/security/
   
===システムコールを監査する===
+
=== システムコールを監査する ===
The audit framework allow you to audit the syscalls performed with the {{ic|-a}} option.
 
   
  +
{{ic|-a}} オプションをつけると、システムコール呼び出しを監査できます。
A security related rule is to track the {{ic|chmod syscall}}, to detect file ownership changes :
 
  +
  +
セキュリティに関連したルールの例として、{{ic|chmod システムコール}} を追跡し、ファイル所有権の変更を検出する例:
   
 
auditctl -a entry,always -S chmod
 
auditctl -a entry,always -S chmod
   
For a list of all syscalls : man syscalls
+
全てのシステムコールのリスト: {{man|2|syscalls}}
   
A lot of rules and posibilities are available, see man auditctl and man audit.rules
+
たくさんのルールと方法が考えられます。{{man|8|auditctl}} {{man|7|audit.rules}} を参照してください。
  +
  +
=== 不要なメッセージをフィルタリングする ===
  +
  +
ノイズの多い auditd メッセージがシステムログに溢れないようにするために、一部の auditd メッセージを除外するルールを追加できます:
  +
  +
{{hc|/etc/audit/rules.d/quiet.rules|2=
  +
-A exclude,always -F msgtype=SERVICE_START
  +
-A exclude,always -F msgtype=SERVICE_STOP
  +
-A exclude,always -F msgtype=BPF
  +
-A exclude,always -F exe=/usr/bin/sudo
  +
}}
  +
  +
次のように変更を確認し (必要に応じて修正)、{{ic|/etc/audit/audit.rules}} を再生成することを忘れないでください:
  +
  +
# augenrules --check
  +
# augenrules --load
  +
  +
== ログを検索する ==
   
==ログを検索する==
 
 
audit フレームワークにはシステム上で発生したイベントを調べるためのツールがいくつか含まれています。
 
audit フレームワークにはシステム上で発生したイベントを調べるためのツールがいくつか含まれています。
   
===PIDを指定する===
+
=== PID を指定する ===
  +
 
特定の PID に関係するイベントを検索するには {{ic|ausearch}} を使います:
 
特定の PID に関係するイベントを検索するには {{ic|ausearch}} を使います:
   
78行目: 98行目:
 
このコマンドを実行すると、ルールに応じて記録されたイベントの中から PID 1 (systemd) に関係するものすべてを表示します。
 
このコマンドを実行すると、ルールに応じて記録されたイベントの中から PID 1 (systemd) に関係するものすべてを表示します。
   
===キーの使い方===
+
=== キーの使い方 ===
  +
 
イベントを管理するためにキーを使うことが推奨されます。
 
イベントを管理するためにキーを使うことが推奨されます。
   
89行目: 110行目:
 
# ausearch -k KEY_pwd
 
# ausearch -k KEY_pwd
   
===異常を探す===
+
=== 異常を探す ===
The {{ic|aureport}} tool can be used to quicly report any anormal event performed on the system, it include network interface used in promiscous mode, process or thread crashing or exiting with ENOMEM error etc.
 
   
  +
{{ic|aureport}} を使うと異常なイベントの発生を素早く報告させることができます。異常なイベントとは、ネットワークインターフェイスがプロミスキャスモードに設定された、プロセスまたはスレッドが ENOMEM エラーで異常終了した、などです。
The easiest way to use {{ic|aureport}} is :
 
  +
  +
{{ic|aureport}} の一番簡単な使い方は :
   
 
# aureport -n
 
# aureport -n
   
  +
aureport を使ってカスタムレポートを生成することもできます。{{man|8|aureport}} を参照してください。
aureport can be used to generate custom report, see man aureport.
 
   
==どのファイル・システムコールを監査すべきか==
+
== どのファイル・システムコールを監査すべきか? ==
Keep in mind that each audit rule added will generate logs, so you must be ready to treat this amount of information.
 
Basically, each security-related event/file must be monitored, like ids, ips, anti-rootkits etc.
 
On the other side, it's totally useless to track every write syscall, the smallest compilation will fill your logs with this event.
 
   
  +
ルールを追加するとログの量も増えます。その情報量が処理できる範囲内でなければならないことを忘れないで下さい。基本的に、セキュリティに関係したイベント・ファイルは監視しなければなりません。ids、ips、anti-rootkits などです。逆に、全ての write システムコールを追跡することはまったく無意味です。ちょっとコンパイルしただけでログが溢れてしまうでしょう。
More complex set of rules can be set up, performing auditing on a very fine-grained base. If you want to do so, the man pages of auditctl are worth-reading.
 
   
  +
粒度を非常に小さくして複雑なルールセットを構成することもできます。もしそうしたい場合は {{man|8|auditctl}} の man ページは読む価値があります。
==他のホストからのログを収集する==
 
  +
The audit framework has an plugin system which provides the possibility to send local logfiles to an remote auditd.
 
  +
== 他のホストからのログを収集する ==
  +
  +
audit フレームワークはプラグインシステムを備えており、それによりローカルのログファイルをリモートの auditd に送ることができます。
   
 
=== ログファイルを送信する ===
 
=== ログファイルを送信する ===
  +
To send your logfiles to an remote host you need the {{ic|audisp-remote}} plugin which comes automatically with the {{Pkg|audit}} package.
 
  +
ログファイルをリモートホストに送るには、{{ic|audisp-remote}} プラグインが必要です。これは {{Pkg|audit}} パッケージにより自動的にインストールされます。このパッケージを有効にするには:
Activate the plugin:
 
 
{{hc|head=/etc/audisp/plugins.d/au-remote.conf|output=
 
{{hc|head=/etc/audisp/plugins.d/au-remote.conf|output=
 
active = yes
 
active = yes
119行目: 141行目:
 
}}
 
}}
   
  +
そしてログの送り先になるリモートホストを設定します:
and set the remote host where the logs should be send to:
 
   
 
{{hc|head=/etc/audisp/audisp-remote.conf|output=
 
{{hc|head=/etc/audisp/audisp-remote.conf|output=
129行目: 151行目:
   
 
=== ログファイルを受け取る ===
 
=== ログファイルを受け取る ===
  +
To make audit listen for remote audispds you just need to set the tcp options:
 
  +
リモートの audispds からのメッセージを受信できるようにするには、tcp オプションをセットするだけです:
 
{{hc|head=/etc/audit/auditd.conf|output=
 
{{hc|head=/etc/audit/auditd.conf|output=
 
tcp_listen_port = 60
 
tcp_listen_port = 60
 
tcp_listen_queue = 5
 
tcp_listen_queue = 5
 
tcp_max_per_addr = 1
 
tcp_max_per_addr = 1
##tcp_client_ports = 1024-65535 #optional
+
##tcp_client_ports = 1024-65535 #任意
 
tcp_client_max_idle = 0
 
tcp_client_max_idle = 0
 
}}
 
}}
   
  +
これで設定した'''全部の'''ホストのログが受信する auditd のログファイルに書き込まれるようになります。
Now you can view the logs of '''all''' configured hosts in the logfiles of the recieving auditd.
 
  +
  +
== ログローテート ==
  +
  +
{{ic|SIGUSR1}} を auditd デーモンに送信します。
  +
  +
# pkill -USR1 -x auditd
  +
  +
== トラブルシューティング ==
  +
  +
=== auditd のログが仮想コンソールに流入する ===
  +
  +
Auditd を有効にしていないユーザーの場合、{{ic|1=loglevel=4}} より高いカーネルデバッグメッセージを使用すると、仮想端末上にセキュリティ通知がフラッディングされる可能性があります。
  +
  +
これらのメッセージは {{ic|auditd.service}} を [[有効化]] することで沈黙させることができます。
  +
  +
代替ソリューションは次のとおりです:
  +
  +
* ログレベルを下げる
  +
* [[カーネルパラメータ]] {{ic|1=audit=0}} を使用して auditd ログを無効にします。
  +
  +
詳細については、[https://github.com/systemd/systemd/issues/15324 GitHub の systemd issue 15324] を参照してください。

2024年1月19日 (金) 17:02時点における最新版

Linux の audit フレームワークは CAPP (Controlled Access Protection Profile) に準拠した監査システムであり、システム上のセキュリティに関係した(または無関係な)イベントを収集できます。audit を使うことにより、システム上で行われた動作を追跡できるようになります。

Linux audit はシステム上で何が起きているかを詳細に分析できる手段であり、システムをよりセキュアにするために役に立ちます。しかしそれ自体がなにかセキュリティを強化するものではありません。つまり、それ自体が悪意のあるコードや様々な悪用からシステムを守ってくれるものではありません。そうではなく、これらの問題を追跡し、セキュリティ対策を施すための情報を audit は提供します。

audit フレームワークはカーネルが報告するイベントを受信し、ログファイルに書き込みます。

ノート: audit フレームワークとコンテナとの互換性は Linux 3.15 で修正されました。[1] を参照してください。ただし、ネームスペース ID のサポートがまだ進行中であるため、audit レコードの解釈が難しい場合があります。[2] を参照してください。

インストール

カーネルによる audit サポートは、linux(4.18以降)、linux-lts(4.19以降)、linux-zen(4.18以降)、および linux-hardened で利用できます。 カスタムカーネルの場合、CONFIG_AUDIT を有効にする必要があります。 カーネルパラメータとして audit=1 を設定すると、ブート時に auditd を有効にできます。

ユーザースペースのサポートについては、auditインストールし、auditd.service起動有効化します。

ノート: audit を完全に無効にし、audit メッセージがジャーナルに表示されないようにするには、カーネルパラメータ として audit=0 を設定と、systemd-journald-audit.socketマスク のどちらか(または両方)を実行します。

audit フレームワークは auditd デーモンから設定されます。アプリケーションやシステムの動作によりカーネルの audit インターフェイスが発動し、audit インターフェイスが生成した audit メッセージを auditd が書き込みます。

このデーモンはいくつかのコマンドとファイルにより制御されます:

  • auditctl : その場でデーモンの挙動をコントロールします。ルールを追加するなど
  • /etc/audit/audit.rules : ルールや auditd のパラメータを記述します
  • aureport : システムの動作レポートを生成します
  • ausearch : イベントを検索します
  • auditspd : イベント通知をディスク上のログに書き込む代わりに他のアプリケーションに中継するデーモンです
  • autrace : プロセスをトレースするためのコマンド。straceに似ています
  • /etc/audit/auditd.conf : ログに関する設定ファイルです

ルールの追加

ルールを追加する前に注意しなければならないのは、audit フレームワークは非常に饒舌で、ルールを実際に運用する前に注意深くテストする必要があることです。実際、たった1つのルールにより2,3分でログを溢れてしまうこともあり得ます。

ファイルとディレクトリへのアクセスを監査する

audit フレームワークの一番簡単な使い方は、特定のファイルへのアクセスをログに記録することです。それには -w オプションを使います。一番簡単なルールの例として passwd ファイルへのアクセスを追跡する例:

# auditctl -w /etc/passwd -p rwxa

フォルダへのアクセスを追跡するには:

# auditctl -w /etc/security/

最初のルールは /etc/passwd への読み込み r、書き込み w、実行 x、属性変更 a を追跡します。2番目のルールは /etc/security/ への全てのアクセスを追跡します。

有効なルールのリストを表示するには:

# auditctl -l

全てのルールを削除するには:

# auditctl -D

ルールが正しく動作することを確認したら、それを /etc/audit/audit.rules に書きます:

-w /etc/audit/audit.rules -p rwxa
-w /etc/security/

システムコールを監査する

-a オプションをつけると、システムコール呼び出しを監査できます。

セキュリティに関連したルールの例として、chmod システムコール を追跡し、ファイル所有権の変更を検出する例:

auditctl -a entry,always -S chmod

全てのシステムコールのリスト: syscalls(2)

たくさんのルールと方法が考えられます。auditctl(8)audit.rules(7) を参照してください。

不要なメッセージをフィルタリングする

ノイズの多い auditd メッセージがシステムログに溢れないようにするために、一部の auditd メッセージを除外するルールを追加できます:

/etc/audit/rules.d/quiet.rules
-A exclude,always -F msgtype=SERVICE_START
-A exclude,always -F msgtype=SERVICE_STOP
-A exclude,always -F msgtype=BPF
-A exclude,always -F exe=/usr/bin/sudo

次のように変更を確認し (必要に応じて修正)、/etc/audit/audit.rules を再生成することを忘れないでください:

# augenrules --check
# augenrules --load

ログを検索する

audit フレームワークにはシステム上で発生したイベントを調べるためのツールがいくつか含まれています。

PID を指定する

特定の PID に関係するイベントを検索するには ausearch を使います:

# ausearch -p 1

このコマンドを実行すると、ルールに応じて記録されたイベントの中から PID 1 (systemd) に関係するものすべてを表示します。

キーの使い方

イベントを管理するためにキーを使うことが推奨されます。

イベントの検索を容易にするために、ルールに -k オプションをつけます:

# auditctl -w /etc/passwd -p rwxa -k KEY_pwd

するとキー KEY_pwd を使ってイベントを検索できるようになります。次のコマンドにより /etc/passwd に関係するイベントだけを表示できます:

# ausearch -k KEY_pwd

異常を探す

aureport を使うと異常なイベントの発生を素早く報告させることができます。異常なイベントとは、ネットワークインターフェイスがプロミスキャスモードに設定された、プロセスまたはスレッドが ENOMEM エラーで異常終了した、などです。

aureport の一番簡単な使い方は :

# aureport -n

aureport を使ってカスタムレポートを生成することもできます。aureport(8) を参照してください。

どのファイル・システムコールを監査すべきか?

ルールを追加するとログの量も増えます。その情報量が処理できる範囲内でなければならないことを忘れないで下さい。基本的に、セキュリティに関係したイベント・ファイルは監視しなければなりません。ids、ips、anti-rootkits などです。逆に、全ての write システムコールを追跡することはまったく無意味です。ちょっとコンパイルしただけでログが溢れてしまうでしょう。

粒度を非常に小さくして複雑なルールセットを構成することもできます。もしそうしたい場合は auditctl(8) の man ページは読む価値があります。

他のホストからのログを収集する

audit フレームワークはプラグインシステムを備えており、それによりローカルのログファイルをリモートの auditd に送ることができます。

ログファイルを送信する

ログファイルをリモートホストに送るには、audisp-remote プラグインが必要です。これは audit パッケージにより自動的にインストールされます。このパッケージを有効にするには:

/etc/audisp/plugins.d/au-remote.conf
active = yes
direction = out
path = /usr/bin/audisp-remote
type = always
format = string

そしてログの送り先になるリモートホストを設定します:

/etc/audisp/audisp-remote.conf
remote_server = domain.name.or.ip
port = 60
##local_port = optional
transport = tcp

ログファイルを受け取る

リモートの audispds からのメッセージを受信できるようにするには、tcp オプションをセットするだけです:

/etc/audit/auditd.conf
tcp_listen_port = 60
tcp_listen_queue = 5
tcp_max_per_addr = 1
##tcp_client_ports = 1024-65535 #任意
tcp_client_max_idle = 0

これで設定した全部のホストのログが受信する auditd のログファイルに書き込まれるようになります。

ログローテート

SIGUSR1 を auditd デーモンに送信します。

# pkill -USR1 -x auditd

トラブルシューティング

auditd のログが仮想コンソールに流入する

Auditd を有効にしていないユーザーの場合、loglevel=4 より高いカーネルデバッグメッセージを使用すると、仮想端末上にセキュリティ通知がフラッディングされる可能性があります。

これらのメッセージは auditd.service有効化 することで沈黙させることができます。

代替ソリューションは次のとおりです:

詳細については、GitHub の systemd issue 15324 を参照してください。