it-swarm-eu.dev

Einfaches Beispiel für eine auditd-Konfiguration?

Auditd wurde in einer Antwort auf Linux-Befehlsprotokollierung? empfohlen

Die Standardinstallation unter Ubuntu scheint kaum etwas zu protokollieren. Es gibt mehrere Beispiele, die damit einhergehen (capp.rules, nispom.rules, stig.rules), aber es ist nicht klar, wie sich die einzelnen auf die Leistung auswirken würden und für welche Art von Umgebung oder Annahmen sie sich am besten eignen würden.

Was wäre der beste Ausgangspunkt für die Bereitstellung von auditd auf einem Webserver? Dazu gehören eine Datei audit.rules, Einstellungen zum Senden des Überwachungsprotokolldatenstroms an einen Remotecomputer in Echtzeit und das einfachste Tool zum Anzeigen der Protokollierung.

Wie wäre es mit einem typischen Desktop-Computer?

Update: dannysauer merkt an, dass es aus Sicherheitsgründen wichtig ist, mit dem Ziel zu beginnen, und ich stimme zu. Meine Hauptabsicht ist es jedoch, spark einige weitere nützliche Erklärungen für die Verwendung dieses Tools) und ein funktionierendes Beispiel zu sehen. Wenn dies bereits vorhanden ist und ich es verpasst habe, weisen Sie bitte darauf hin. Wenn nicht, schlage ich vor, ein Beispiel für eines der häufigsten Szenarien zu erstellen (z. B. a einfacher Webserver, auf dem ein Stapel Ihrer Wahl ausgeführt wird), bei dem das Ziel möglicherweise darin besteht, Informationen im Falle eines Einbruchs aufzubewahren, um herauszufinden, wo die Penetration begonnen hat. Wenn es ein geeigneteres oder erreichbares Ziel für die Verwendung in gibt zB ein kleines Unternehmen ohne bedeutendes IT-Personal, das würde auch helfen.

48
nealmcb

Auditd ist ein außerordentlich leistungsfähiges Überwachungswerkzeug. Wie jeder, der es sich jemals angesehen hat, bezeugen kann, ist die Benutzerfreundlichkeit die Hauptschwäche. Das Einrichten von so etwas wie auditd erfordert eine Menge gründlicher Überlegungen darüber, was genau auf dem betreffenden System geprüft werden muss. In der Frage haben Sie sich für einen Webserver als unser Beispielsystem entschieden, was gut ist, da es spezifisch ist.

Nehmen wir aus Gründen der Argumentation an, dass es eine formale Trennung zwischen Test-/Entwicklungswebservern und Produktionswebservern gibt, bei denen Webentwickler ihre gesamte Arbeit an den Test-/Entwicklungssystemen ausführen und Änderungen an der Produktionsumgebung in einer kontrollierten Bereitstellung vorgenommen werden.

Wenn wir also diese ziemlich großen Annahmen treffen und uns auf das Produktionssystem konzentrieren, können wir uns an die Arbeit machen. Wenn wir uns die auditd-Empfehlung im CIS-Benchmark für RHEL5 ansehen, können wir mit dem Aufbau des folgenden vorgeschlagenen Regelsatzes beginnen:

-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

Dies führt dazu, dass Protokolle immer dann ausgeschrieben werden, wenn die Systemaufrufe rmdir, unlink, stime oder setrlimit beendet werden. Dies sollte uns wissen lassen, ob jemand versucht, Dateien oder Jigger mit der Zeit zu löschen. Wir haben auch spezielle Dateiüberwachungen für die Dateien eingerichtet, die Gruppen, Benutzer, Kennwörter und Sudo-Zugriff definieren. Anstatt Systemaufrufe für jeden dieser Dateien zu betrachten, wird jedes Mal ein Überwachungsprotokoll geschrieben, wenn eine dieser Dateien entweder:

  1. wird mit den Modi O_WRONLY oder O_RDWR geöffnet
  2. ein Attribut wird geändert

Da wir bereits davon ausgegangen sind, dass es sich um einen Produktionswebserver handelt, würde ich empfehlen, die folgende Zeile hinzuzufügen:

-w /var/www -p wa

Dadurch werden alle Dateien im Verzeichnisbaum /var/www Rekursiv überwacht.

Jetzt können wir den Grund für die früher getroffene Annahme einer "kontrollierten Umgebung" sehen. Zwischen der Überwachung aller Dateien im Webstamm sowie aller Unlink- oder RMDIR-Ereignisse kann dies in einer Entwicklungsumgebung unzulässig laut sein. Wenn wir Änderungen am Dateisystem antizipieren können, z. B. während Wartungsfenstern oder Bereitstellungsereignissen, können wir dieses Rauschen vernünftiger herausfiltern.

Wenn wir all dies zu einer einzigen, zusammenhängenden Datei kombinieren, soll /etc/audit/audit.rules So aussehen

# 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

Update: Dieser Artikel ist eine nette Erklärung der auditd-Regeln und enthält Beispiele für jedes Ereignis, das Sie möglicherweise protokollieren möchten:

HOWTO_configure_the_auditing_of_the_system_auditd


Schauen Sie sich den Fehlerbericht hier an:

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

Sie enthalten eine sehr lange Beispieldatei, die viele wichtige Änderungen enthält, die an einem System vorgenommen werden können. Zur Vereinfachung unten kopiert (mit geringfügigen Änderungen):

## 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

Sie nähern sich der Frage etwas falsch. Sie müssen entscheiden, was Sie protokollieren möchten, und herausfinden, wie Sie dies protokollieren können. Das Generieren einer Reihe von Protokolldateien ist cool und alles, aber wenn Sie sie nie ansehen oder nicht wissen, wonach Sie suchen, verschwenden Sie nur Zeit und Platz.

Wenn Sie entscheiden, was protokolliert werden soll, müssen Sie das Verhalten identifizieren, das Sie interessiert, und dann herausfinden, wie diese Aktivität protokolliert wird. Ein guter Weg, dies zu tun, wäre, über AppArmor zu lesen und die Manpage auditctl zu lesen. Erfahren Sie dann, welche Systemaufrufe verfügbar sind, indem Sie lernen, für Unix zu programmieren, und identifizieren Sie die Aufrufe, die von Interesse sein können. Es ist wirklich ein ziemlich großes Unterfangen. Ich weiß, dass dies eine glatte Antwort ist und nicht "hier ist ein Shell-Skript, das alles protokolliert, was Sie auf Ihrem Server interessiert" - aber der Grund, warum diese Antworten nicht existieren, ist, dass jede Situation anders ist Daher ist es nicht möglich, die Antwort "Einheitsgröße" zu geben.

An dem (zugegebenermaßen großen) Ort, an dem ich arbeite, haben wir ein ganzes Team von Mitarbeitern, die sich ausschließlich der Systemprotokollierung widmen - ganz zu schweigen von den verschiedenen Administrations- und Sicherheitsteams, die dazu beitragen. Dies ist kein kleines Thema. : /

11
dannysauer