「Audit フレームワーク」の版間の差分
Kusanaginoturugi (トーク | 投稿記録) (序文のNoteを英語版 2019-01-02T18:18:15 から訳出) |
(トラブルシューティングを翻訳して追加) |
||
(同じ利用者による、間の2版が非表示) | |||
2行目: | 2行目: | ||
[[Category:ロギング]] |
[[Category:ロギング]] |
||
[[en:Audit framework]] |
[[en:Audit framework]] |
||
− | Linux の audit フレームワークは CAPP ([[Wikipedia:Controlled Access Protection Profile|Controlled Access Protection Profile]]) に準拠した監査システムであり、システム上のセキュリティに関係した |
+ | 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 レコード |
+ | {{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] を参照してください。}} |
− | ==インストール== |
+ | == インストール == |
+ | |||
− | カーネルによる 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}} を[[起動]]・[[有効化]]します。 |
||
17行目: | 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 フレームワークは auditd デーモンから設定されます。アプリケーションやシステムの動作によりカーネルの audit インターフェイスが発動し、audit インターフェイスが生成した audit メッセージを auditd が書き込みます。 |
このデーモンはいくつかのコマンドとファイルにより制御されます: |
このデーモンはいくつかのコマンドとファイルにより制御されます: |
||
28行目: | 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 ファイルへのアクセスを追跡する例: |
||
55行目: | 58行目: | ||
-w /etc/security/ |
-w /etc/security/ |
||
− | ===システムコールを監査する=== |
+ | === システムコールを監査する === |
+ | |||
{{ic|-a}} オプションをつけると、システムコール呼び出しを監査できます。 |
{{ic|-a}} オプションをつけると、システムコール呼び出しを監査できます。 |
||
62行目: | 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}} を使います: |
||
76行目: | 98行目: | ||
このコマンドを実行すると、ルールに応じて記録されたイベントの中から PID 1 (systemd) に関係するものすべてを表示します。 |
このコマンドを実行すると、ルールに応じて記録されたイベントの中から PID 1 (systemd) に関係するものすべてを表示します。 |
||
− | ===キーの使い方=== |
+ | === キーの使い方 === |
+ | |||
イベントを管理するためにキーを使うことが推奨されます。 |
イベントを管理するためにキーを使うことが推奨されます。 |
||
87行目: | 110行目: | ||
# ausearch -k KEY_pwd |
# ausearch -k KEY_pwd |
||
− | ===異常を探す=== |
+ | === 異常を探す === |
+ | |||
{{ic|aureport}} を使うと異常なイベントの発生を素早く報告させることができます。異常なイベントとは、ネットワークインターフェイスがプロミスキャスモードに設定された、プロセスまたはスレッドが ENOMEM エラーで異常終了した、などです。 |
{{ic|aureport}} を使うと異常なイベントの発生を素早く報告させることができます。異常なイベントとは、ネットワークインターフェイスがプロミスキャスモードに設定された、プロセスまたはスレッドが ENOMEM エラーで異常終了した、などです。 |
||
96行目: | 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= |
||
114行目: | 141行目: | ||
}} |
}} |
||
− | そしてログの送り先になるリモートホストを設定します |
+ | そしてログの送り先になるリモートホストを設定します: |
{{hc|head=/etc/audisp/audisp-remote.conf|output= |
{{hc|head=/etc/audisp/audisp-remote.conf|output= |
||
124行目: | 151行目: | ||
=== ログファイルを受け取る === |
=== ログファイルを受け取る === |
||
+ | |||
リモートの audispds からのメッセージを受信できるようにするには、tcp オプションをセットするだけです: |
リモートの audispds からのメッセージを受信できるようにするには、tcp オプションをセットするだけです: |
||
{{hc|head=/etc/audit/auditd.conf|output= |
{{hc|head=/etc/audit/auditd.conf|output= |
||
134行目: | 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(4.18以降)、linux-lts(4.19以降)、linux-zen(4.18以降)、および linux-hardened で利用できます。 カスタムカーネルの場合、CONFIG_AUDIT
を有効にする必要があります。 カーネルパラメータとして audit=1
を設定すると、ブート時に auditd を有効にできます。
ユーザースペースのサポートについては、audit を インストールし、auditd.service
を起動・有効化します。
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
を 有効化 することで沈黙させることができます。
代替ソリューションは次のとおりです:
- ログレベルを下げる
- カーネルパラメータ
audit=0
を使用して auditd ログを無効にします。
詳細については、GitHub の systemd issue 15324 を参照してください。