GNU/Linux >> Linux の 問題 >  >> Linux

auditd 構成の簡単な例

Auditd は非常に強力な監視ツールです。これを見たことのある人なら誰でも証明できるように、使いやすさが主な弱点です。 auditd のようなものを設定するには、正確に何を深く考える必要がありますか? 問題の特定のシステムで監査が必要なのはそれです。質問では、例のシステムとして Web サーバーを選択しました。

議論のために、テスト/開発 Web サーバーと本番 Web サーバーの間に正式な区分があり、Web 開発者がテスト/開発システムですべての作業を行い、本番環境への変更が制御された展開で行われると仮定しましょう.

これらのかなり大きな仮定を行い、生産システムに焦点を当てて、作業に取り掛かることができます。 RHEL5 の CIS ベンチマークでの auditd の推奨事項を見ると、次の推奨ルールセットの構築を開始できます。

-a exit,always -S unlink -S rmdir
-a exit,always -S stime.*
-a exit,always -S setrlimit.*
-w /etc/group -p wa 
-w /etc/passwd -p wa 
-w /etc/shadow -p wa 
-w /etc/sudoers -p wa
-b 1024
-e 2

これにより、rmdir、unlink、stime、または setrlimit システム コールが終了するたびに、ログが書き出されます。これにより、誰かがファイルを削除しようとしたり、時間をかけてジガーしようとした場合に通知されます。また、グループ、ユーザー、パスワード、および sudo アクセスを定義する特定のファイル ウォッチをファイルに設定します。これらの各ファイルのシステム コールを確認する代わりに、これらのファイルのいずれかが次のいずれかになるたびに anaudit ログが書き込まれます。

<オール>
  • O_WRONLY または O_RDWR モードで開かれた
  • 属性が変更された

    • 実動 Web サーバーについて話しているという仮定を既に行っているので、次の行を追加することをお勧めします:

    -w /var/www -p wa

    これにより、/var/www の下にあるすべてのファイルが再帰的に監視されます。 ディレクトリ ツリー。

    これで、以前に行われた「制御された環境」の仮定の理由がわかります。 Web ルート内のすべてのファイルと、すべてのリンク解除または rmdir イベントを監視する間、これは開発環境では非常にノイズが多くなる可能性があります。メンテナンス期間中や展開イベント中など、ファイルシステムの変更を予測できる場合は、このノイズをより合理的に除外できます。

    これらすべてを 1 つの一貫したファイルに結合するには、/etc/audit/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 1024

-a exit,always -S unlink -S rmdir
-a exit,always -S stime.*
-a exit,always -S setrlimit.*
-w /var/www -p wa
-w /etc/group -p wa
-w /etc/passwd -p wa
-w /etc/shadow -p wa
-w /etc/sudoers -p wa

# Disable adding any additional rules - note that adding *new* rules will require a reboot
-e 2

    更新:この記事は、auditd ルールの優れた説明であり、ログに記録する可能性のある各イベントの例を示しています:

    HOWTO_configure_the_auditing_of_the_system_auditd

    ここでバグレポートをチェックしてください:

    https://github.com/gds-operations/puppet-auditd/pull/1

    彼らは、システムに加えられる可能性のある多くの重要な変更を含む非常に長いサンプル ファイルを提供します。便宜上以下にコピーします (わずかな変更を加えて):

    ## Remove any existing rules
-D

## Buffer Size
## Feel free to increase this if the machine panic's
-b 8192

## Failure Mode
## Possible values are 0 (silent), 1 (printk, print a failure message),
## and 2 (panic, halt the system).
-f 1

## Audit the audit logs.
## successful and unsuccessful attempts to read information from the
## audit records; all modifications to the audit trail
-w /var/log/audit/ -k auditlog

## Auditd configuration
## modifications to audit configuration that occur while the audit
## collection functions are operating.
-w /etc/audit/ -p wa -k auditconfig
-w /etc/libaudit.conf -p wa -k auditconfig
-w /etc/audisp/ -p wa -k audispconfig

## Monitor for use of audit management tools
-w /sbin/auditctl -p x -k audittools
-w /sbin/auditd -p x -k audittools

## special files
-a exit,always -F arch=b32 -S mknod -S mknodat -k specialfiles
-a exit,always -F arch=b64 -S mknod -S mknodat -k specialfiles

## Mount operations
-a exit,always -F arch=b32 -S mount -S umount -S umount2 -k mount
-a exit,always -F arch=b64 -S mount -S umount2 -k mount

## changes to the time
##
-a exit,always -F arch=b32 -S adjtimex -S settimeofday -S stime -S clock_settime -k time
-a exit,always -F arch=b64 -S adjtimex -S settimeofday -S clock_settime -k time

## Use stunnel
-w /usr/sbin/stunnel -p x -k stunnel

## cron configuration & scheduled jobs
-w /etc/cron.allow -p wa -k cron
-w /etc/cron.deny -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /etc/cron.daily/ -p wa -k cron
-w /etc/cron.hourly/ -p wa -k cron
-w /etc/cron.monthly/ -p wa -k cron
-w /etc/cron.weekly/ -p wa -k cron
-w /etc/crontab -p wa -k cron
-w /var/spool/cron/crontabs/ -k cron

## user, group, password databases
-w /etc/group -p wa -k etcgroup
-w /etc/passwd -p wa -k etcpasswd
-w /etc/gshadow -k etcgroup
-w /etc/shadow -k etcpasswd
-w /etc/security/opasswd -k opasswd

## monitor usage of passwd
-w /usr/bin/passwd -p x -k passwd_modification

#Monitor for use of tools to change group identifiers
-w /usr/sbin/groupadd -p x -k group_modification
-w /usr/sbin/groupmod -p x -k group_modification
-w /usr/sbin/addgroup -p x -k group_modification
-w /usr/sbin/useradd -p x -k user_modification
-w /usr/sbin/usermod -p x -k user_modification
-w /usr/sbin/adduser -p x -k user_modification

## login configuration and information
-w /etc/login.defs -p wa -k login
-w /etc/securetty -p wa -k login
-w /var/log/faillog -p wa -k login
-w /var/log/lastlog -p wa -k login
-w /var/log/tallylog -p wa -k login

## network configuration
-w /etc/hosts -p wa -k hosts
-w /etc/network/ -p wa -k network

## system startup scripts
-w /etc/inittab -p wa -k init
-w /etc/init.d/ -p wa -k init
-w /etc/init/ -p wa -k init

## library search paths
-w /etc/ld.so.conf -p wa -k libpath

## local time zone
-w /etc/localtime -p wa -k localtime

## kernel parameters
-w /etc/sysctl.conf -p wa -k sysctl

## modprobe configuration
-w /etc/modprobe.conf -p wa -k modprobe

## pam configuration
-w /etc/pam.d/ -p wa -k pam
-w /etc/security/limits.conf -p wa  -k pam
-w /etc/security/pam_env.conf -p wa -k pam
-w /etc/security/namespace.conf -p wa -k pam
-w /etc/security/namespace.init -p wa -k pam

## GDS specific secrets
-w /etc/puppet/ssl -p wa -k puppet_ssl

## postfix configuration
-w /etc/aliases -p wa -k mail
-w /etc/postfix/ -p wa -k mail

## ssh configuration
-w /etc/ssh/sshd_config -k sshd

## changes to hostname
-a exit,always -F arch=b32 -S sethostname -k hostname
-a exit,always -F arch=b64 -S sethostname -k hostname

## changes to issue
-w /etc/issue -p wa -k etcissue
-w /etc/issue.net -p wa -k etcissue

## this was to noisy currently.
# log all commands executed by an effective id of 0 aka root.
-a exit,always -F arch=b64 -F euid=0 -S execve -k rootcmd
-a exit,always -F arch=b32 -F euid=0 -S execve -k rootcmd

## Capture all failures to access on critical elements
-a exit,always -F arch=b64 -S open -F dir=/etc -F success=0 -k unauthedfileacess
-a exit,always -F arch=b64 -S open -F dir=/bin -F success=0 -k unauthedfileacess
-a exit,always -F arch=b64 -S open -F dir=/sbin -F success=0 -k unauthedfileacess
-a exit,always -F arch=b64 -S open -F dir=/usr/bin -F success=0 -k unauthedfileacess
-a exit,always -F arch=b64 -S open -F dir=/usr/sbin -F success=0 -k unauthedfileacess
-a exit,always -F arch=b64 -S open -F dir=/var -F success=0 -k unauthedfileacess
-a exit,always -F arch=b64 -S open -F dir=/home -F success=0 -k unauthedfileacess
-a exit,always -F arch=b64 -S open -F dir=/srv -F success=0 -k unauthedfileacess

## Monitor for use of process ID change (switching accounts) applications
-w /bin/su -p x -k priv_esc
-w /usr/bin/sudo -p x -k priv_esc
-w /etc/sudoers -p rw -k priv_esc

## Monitor usage of commands to change power state
-w /sbin/shutdown -p x -k power
-w /sbin/poweroff -p x -k power
-w /sbin/reboot -p x -k power
-w /sbin/halt -p x -k power

## Make the configuration immutable
-e 2

    あなたはやや間違った方法で質問に近づいています。何をログに記録するかを決定し、それをログに記録する方法を見つける必要があります。大量のログ ファイルを生成するのはすばらしいことですが、ログ ファイルを見たり、探しているものがわからなかったりすると、時間とスペースが無駄になります。

    何をログに記録するかを決定するときは、関心のある動作を特定し、そのアクティビティをログに記録する方法を見つける必要があります。これを開始する良い方法は、AppArmor について読んで、auditctl の man ページを熟読することです。次に、Unix 向けのプログラミングを学習することで、利用可能なシステム コールを学習し、関心のあるコールを特定します。それは本当にかなり大きな事業です。私はこれが少しばかげた答えであり、「これはあなたがサーバー上で気にかけていることすべてを記録するシェルスクリプトです」を提供していないことを知っています - しかし、それらの答えが存在しない理由は、まあ、すべての状況が異なるからですそのため、「フリーサイズ」という答えを出すことはできません。

    私が働いている (確かに大規模な) 場所には、システム ロギングのみを専門とするチーム全体がいます。もちろん、さまざまな管理者やセキュリティ チームが貢献しています。これは小さなトピックではありません。 :/


    Linux

    1. 簡単なPHPメールテスト

    2. Magento2データベース構成ファイル

    3. シンプルなコマンドライン計算機？

    1. Loggedfs構成ファイルの構文？

    2. 簡単な例で独自の Linux カーネル モジュールを作成する方法

    3. Magento 2 Rabbitmq 構成

    1. Apache HTTP サーバー – 最も一般的に使用される構成ディレクティブ

    2. Linux OS サービス「auditd」

    3. mdadm:UUIDによるディスク構成