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

提供: ArchWiki
ナビゲーションに移動 検索に移動
(→‎インストール: 英語版 2019-01-02T18:18:15 より訳出。and/or ってどう訳したらええんや？)
(トラブルシューティングを翻訳して追加)
 
(2人の利用者による、間の3版が非表示)
2行目: 2行目:
 
[[Category:ロギング]]
  
[[Category:ロギング]]
 
[[en:Audit framework]]
  
[[en:Audit framework]]
−
Linux の audit フレームワークは CAPP ([[Wikipedia:Controlled Access Protection Profile|Controlled Access Protection Profile]]) に準拠した監査システムであり、システム上のセキュリティに関係した（または無関係な）イベントを収集できます。audit を使うことにより、システム上で行われた動作を追跡できるようになります。
 +
Linux の audit フレームワークは CAPP ([[Wikipedia:Controlled Access Protection Profile|Controlled Access Protection Profile]]) に準拠した監査システムであり、システム上のセキュリティに関係した(または無関係な)イベントを収集できます。audit を使うことにより、システム上で行われた動作を追跡できるようになります。
   
 
Linux audit はシステム上で何が起きているかを詳細に分析できる手段であり、システムをよりセキュアにするために役に立ちます。しかしそれ自体がなにかセキュリティを強化するものではありません。つまり、それ自体が悪意のあるコードや様々な悪用からシステムを守ってくれるものではありません。そうではなく、これらの問題を追跡し、セキュリティ対策を施すための情報を audit は提供します。
  
Linux audit はシステム上で何が起きているかを詳細に分析できる手段であり、システムをよりセキュアにするために役に立ちます。しかしそれ自体がなにかセキュリティを強化するものではありません。つまり、それ自体が悪意のあるコードや様々な悪用からシステムを守ってくれるものではありません。そうではなく、これらの問題を追跡し、セキュリティ対策を施すための情報を audit は提供します。
8行目: 8行目:
 
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 フレームワークを使わないでください。
  
−
* audit フレームワークはシステムのパフォーマンスに影響を与える可能性があります。}}
  
   
−
==インストール==
 +
== インストール ==
  +
−
カーネルによる 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}} を設定すると、ブート時に監査を有効にできます。
  
  +
カーネルによる 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 を有効にできます。
   
 
ユーザースペースのサポートについては、{{Pkg|audit}} を [[インストール]]し、{{ic|auditd.service}} を[[起動]]・[[有効化]]します。
  
ユーザースペースのサポートについては、{{Pkg|audit}} を [[インストール]]し、{{ic|auditd.service}} を[[起動]]・[[有効化]]します。
19行目: 18行目:
 
{{Note|audit を完全に無効にし、audit メッセージがジャーナルに表示されないようにするには、[[カーネルパラメータ]] として {{ic|1=audit=0}} を設定と、{{ic|systemd-journald-audit.socket}} を [[マスク]] のどちらか(または両方)を実行します。}}
  
{{Note|audit を完全に無効にし、audit メッセージがジャーナルに表示されないようにするには、[[カーネルパラメータ]] として {{ic|1=audit=0}} を設定と、{{ic|systemd-journald-audit.socket}} を [[マスク]] のどちらか(または両方)を実行します。}}
   
−
audit フレームワークは auditd デーモンから構成されます。アプリケーションやシステムの動作によりカーネルの audit インターフェイスが発動し、audit インターフェイスが生成した audit メッセージを auditd が書き込みます。
 +
audit フレームワークは auditd デーモンから設定されます。アプリケーションやシステムの動作によりカーネルの audit インターフェイスが発動し、audit インターフェイスが生成した audit メッセージを auditd が書き込みます。
   
 
このデーモンはいくつかのコマンドとファイルにより制御されます:
  
このデーモンはいくつかのコマンドとファイルにより制御されます:
30行目: 29行目:
 
* {{ic|/etc/audit/auditd.conf}} : ログに関する設定ファイルです
  
* {{ic|/etc/audit/auditd.conf}} : ログに関する設定ファイルです
   
−
==ルールの追加==
 +
== ルールの追加 ==
  +
 
ルールを追加する前に注意しなければならないのは、audit フレームワークは非常に饒舌で、ルールを実際に運用する前に注意深くテストする必要があることです。実際、たった1つのルールにより2,3分でログを溢れてしまうこともあり得ます。
  
ルールを追加する前に注意しなければならないのは、audit フレームワークは非常に饒舌で、ルールを実際に運用する前に注意深くテストする必要があることです。実際、たった1つのルールにより2,3分でログを溢れてしまうこともあり得ます。
   
−
===ファイルとディレクトリへのアクセスを監査する===
 +
=== ファイルとディレクトリへのアクセスを監査する ===
  +
 
audit フレームワークの一番簡単な使い方は、特定のファイルへのアクセスをログに記録することです。それには {{ic|-w}} オプションを使います。一番簡単なルールの例として passwd ファイルへのアクセスを追跡する例:
  
audit フレームワークの一番簡単な使い方は、特定のファイルへのアクセスをログに記録することです。それには {{ic|-w}} オプションを使います。一番簡単なルールの例として passwd ファイルへのアクセスを追跡する例:
   
57行目: 58行目:
 
-w /etc/security/
  
-w /etc/security/
   
−
===システムコールを監査する===
 +
=== システムコールを監査する ===
  +
 
{{ic|-a}} オプションをつけると、システムコール呼び出しを監査できます。
  
{{ic|-a}} オプションをつけると、システムコール呼び出しを監査できます。
   
64行目: 66行目:
 
auditctl -a entry,always -S chmod
  
auditctl -a entry,always -S chmod
   
−
全てのシステムコールのリスト: {{man|2|syscalls}}。
 +
全てのシステムコールのリスト: {{man|2|syscalls}}
   
 
たくさんのルールと方法が考えられます。{{man|8|auditctl}} と {{man|7|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
   
−
===異常を探す===
 +
=== 異常を探す ===
  +
 
{{ic|aureport}} を使うと異常なイベントの発生を素早く報告させることができます。異常なイベントとは、ネットワークインターフェイスがプロミスキャスモードに設定された、プロセスまたはスレッドが ENOMEM エラーで異常終了した、などです。
  
{{ic|aureport}} を使うと異常なイベントの発生を素早く報告させることができます。異常なイベントとは、ネットワークインターフェイスがプロミスキャスモードに設定された、プロセスまたはスレッドが ENOMEM エラーで異常終了した、などです。
   
98行目: 120行目:
 
aureport を使ってカスタムレポートを生成することもできます。{{man|8|aureport}} を参照してください。
  
aureport を使ってカスタムレポートを生成することもできます。{{man|8|aureport}} を参照してください。
   
−
==どのファイル・システムコールを監査すべきか？==
 +
== どのファイル・システムコールを監査すべきか? ==
  +
 
ルールを追加するとログの量も増えます。その情報量が処理できる範囲内でなければならないことを忘れないで下さい。基本的に、セキュリティに関係したイベント・ファイルは監視しなければなりません。ids、ips、anti-rootkits などです。逆に、全ての write システムコールを追跡することはまったく無意味です。ちょっとコンパイルしただけでログが溢れてしまうでしょう。
  
ルールを追加するとログの量も増えます。その情報量が処理できる範囲内でなければならないことを忘れないで下さい。基本的に、セキュリティに関係したイベント・ファイルは監視しなければなりません。ids、ips、anti-rootkits などです。逆に、全ての write システムコールを追跡することはまったく無意味です。ちょっとコンパイルしただけでログが溢れてしまうでしょう。
   
 
粒度を非常に小さくして複雑なルールセットを構成することもできます。もしそうしたい場合は {{man|8|auditctl}} の man ページは読む価値があります。
  
粒度を非常に小さくして複雑なルールセットを構成することもできます。もしそうしたい場合は {{man|8|auditctl}} の man ページは読む価値があります。
   
−
==他のホストからのログを収集する==
 +
== 他のホストからのログを収集する ==
  +
 
audit フレームワークはプラグインシステムを備えており、それによりローカルのログファイルをリモートの auditd に送ることができます。
  
audit フレームワークはプラグインシステムを備えており、それによりローカルのログファイルをリモートの auditd に送ることができます。
   
 
=== ログファイルを送信する ===
  
=== ログファイルを送信する ===
  +
 
ログファイルをリモートホストに送るには、{{ic|audisp-remote}} プラグインが必要です。これは {{Pkg|audit}} パッケージにより自動的にインストールされます。このパッケージを有効にするには:
  
ログファイルをリモートホストに送るには、{{ic|audisp-remote}} プラグインが必要です。これは {{Pkg|audit}} パッケージにより自動的にインストールされます。このパッケージを有効にするには:
 
{{hc|head=/etc/audisp/plugins.d/au-remote.conf|output=
  
{{hc|head=/etc/audisp/plugins.d/au-remote.conf|output=
116行目: 141行目:
 
}}
  
}}
   
−
そしてログの送り先になるリモートホストを設定します：
 +
そしてログの送り先になるリモートホストを設定します:
   
 
{{hc|head=/etc/audisp/audisp-remote.conf|output=
  
{{hc|head=/etc/audisp/audisp-remote.conf|output=
126行目: 151行目:
   
 
=== ログファイルを受け取る ===
  
=== ログファイルを受け取る ===
  +
 
リモートの audispds からのメッセージを受信できるようにするには、tcp オプションをセットするだけです:
  
リモートの audispds からのメッセージを受信できるようにするには、tcp オプションをセットするだけです:
 
{{hc|head=/etc/audit/auditd.conf|output=
  
{{hc|head=/etc/audit/auditd.conf|output=
136行目: 162行目:
   
 
これで設定した'''全部の'''ホストのログが受信する auditd のログファイルに書き込まれるようになります。
  
これで設定した'''全部の'''ホストのログが受信する 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 を参照してください。

「https://wiki.archlinux.jp/index.php?title=Audit_フレームワーク&oldid=35863」から取得