web-dev-qa-db-ja.com

簡単なサンプルのauditd設定?

Auditd への回答で推奨 Linux command logging?

Ubuntuのデフォルトのインストールでは、ほとんど何も記録されないようです。いくつかの例(capp.rules、nispom.rules、stig.rules)が付属していますが、それぞれのパフォーマンスへの影響や、どのような環境や想定がそれぞれに最も適しているかは明確ではありません。

たとえば、Webサーバーにauditdを展開するための最適な開始点は何ですか?これには、audit.rulesファイル、監査ログストリームをリモートマシンにリアルタイムで送信できるようにする設定、ログに記録された内容を確認する最も簡単なツールが含まれます。

次に、典型的なデスクトップマシンはどうですか?

更新:dannysauerは、セキュリティのためには目標から始めることが重要であると述べ、同意します。しかし、私の主な目的はsparkこのツールの使用法のいくつかのより有用な説明であり、動作する例を見るパフォーマンスとストレージへの影響などとともに、実際にそれを実行しています。それがすでに存在し、私がそれを逃した場合は、それを指摘してください。存在しない場合は、より一般的なシナリオの1つ(例:a)の例を作成することをお勧めします。侵入の発生時に情報を保存して、ペネトレーションがどこから始まったのかを追跡できるようにすることを目的とする可能性のある、シンプルなWebサーバー)。ここで使用するのにより適切または達成可能な目標がある場合たとえば、重要なITスタッフのいない中小企業でも、それは役立ちます。

48
nealmcb

Auditdは、非常に強力な監視ツールです。これを見たことのある人なら誰でも証明できるように、使いやすさが最大の弱点です。 auditdのようなものを設定するには、正確にwhatについてかなり綿密に検討する必要があります。これは、問題の特定のシステムの監査が必要なことです。質問では、例のシステムとしてWebサーバーを選択しましたが、これは具体的であるため優れています。

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

したがって、これらのかなり大きな仮定を行い、本番システムに焦点を当てれば、作業に取り掛かることができます。 RHEL5のCISベンチマーク で監査済みの推奨事項を確認すると、次の推奨ルールセットの構築を開始できます。

-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アクセスを定義するファイルに特定のファイル監視を設定します。それらのシステムコールを調べる代わりに、これらのファイルのいずれかが次のいずれかになるたびに監査ログが書き込まれます。

  1. o_WRONLYまたはO_RDWRモードで開かれる
  2. 属性が変更された

実稼働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
41
Scott Pack

更新:この記事は、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
14
dberm22

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

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

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

11
dannysauer