it-swarm.dev

Esempio di configurazione auditd semplice?

Auditd è stato raccomandato in una risposta a Registrazione comandi Linux?

L'installazione predefinita su Ubuntu sembra quasi non registrare nulla. Ci sono diversi esempi che ne derivano (capp.rules, nispom.rules, stig.rules) ma non è chiaro quale sia l'impatto sulle prestazioni di ciascuno, né quale tipo di ambiente o ipotesi sarebbe più adatto a ciascuno.

Quale sarebbe il miglior punto di partenza per implementare auditd su un server web? Ciò include un file audit.rules, le impostazioni per consentire l'invio del flusso del registro di controllo a una macchina remota in tempo reale e il più semplice degli strumenti per vedere cosa è stato registrato.

Quindi, che ne dici di una tipica macchina desktop?

Aggiorna: dannysauer nota che per motivi di sicurezza è importante iniziare con l'obiettivo e sono d'accordo. Ma il mio intento principale è spark qualche spiegazione più utile sull'uso di questo strumento, e vedere un esempio funzionante di esso in azione, insieme alle implicazioni di prestazioni e archiviazione, ecc. Se questo esiste già e me lo sono perso, ti preghiamo di indicarlo. In caso contrario, sto suggerendo di creare un esempio per uno degli scenari più comuni (ad es. web server semplice, che esegue il tuo stack preferito), dove l'obiettivo potrebbe essere quello di conservare le informazioni in caso di irruzione per aiutare a rintracciare per scoprire dove è iniziata la penetrazione. Se esiste un obiettivo più adatto o raggiungibile per l'uso in ad esempio una piccola impresa senza un significativo personale IT, che sarebbe di aiuto.

48
nealmcb

Auditd è uno strumento di monitoraggio straordinariamente potente. Come può testimoniare chiunque l'abbia mai visto, l'usabilità è la principale debolezza. L'impostazione di qualcosa come auditd richiede molta riflessione approfondita su esattamente che cosa è che necessita di un controllo sul sistema specifico in questione. Nella domanda che hai deciso su un server Web come nostro sistema di esempio, il che è positivo poiché è specifico.

Per ragioni di ipotesi, supponiamo che esista una divisione formale tra i server Web test/dev e i server Web di produzione in cui gli sviluppatori Web svolgono tutto il loro lavoro sui sistemi test/sviluppo e le modifiche all'ambiente di produzione vengono eseguite in una distribuzione controllata.

Quindi, facendo queste ipotesi piuttosto grandi e concentrandoci sul sistema di produzione, possiamo metterci al lavoro. Guardando la raccomandazione auditd nel benchmark CIS per RHEL5 possiamo iniziare a costruire il seguente set di regole suggerito:

-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

Ciò causerà la scrittura dei log ogni volta che il sistema rmdir, unlink, stime o setrlimit chiama le uscite. Questo dovrebbe farci sapere se qualcuno tenta di eliminare i file o jigger con i tempi. Abbiamo anche impostato controlli di file specifici sui file che definiscono gruppi, utenti, password e accesso Sudo. Invece di guardare le chiamate di sistema per ognuna di quelle, verrà scritto un registro di controllo ogni volta che uno di questi file è:

  1. aperto con le modalità O_WRONLY o O_RDWR
  2. un attributo è cambiato

Poiché abbiamo già ipotizzato che stiamo parlando di un server Web di produzione, consiglierei di aggiungere la riga:

-w /var/www -p wa

Questo guarderà in modo ricorsivo tutti i file sotto il /var/www albero delle directory.

Ora possiamo vedere il motivo dell'assunto "ambiente controllato" fatto in precedenza. Tra il monitoraggio di tutti i file nella radice Web, nonché tutti gli eventi unlink o rmdir, ciò potrebbe essere proibitivo in un ambiente di sviluppo. Se siamo in grado di anticipare le modifiche al filesystem, come ad esempio durante le finestre di manutenzione o gli eventi di distribuzione, possiamo più ragionevolmente filtrare questo rumore.

Combinando tutto questo in un unico file coerente, vorremmo /etc/audit/audit.rules sembra

# 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

Aggiornamento: questo articolo è una bella spiegazione delle regole di auditd e fornisce esempi per ogni evento che potresti voler registrare:

HOWTO_configure_the_auditing_of_the_system_auditd


Dai un'occhiata alla segnalazione di bug qui:

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

Forniscono un file di esempio molto lungo che contiene molte importanti modifiche che potrebbero essere apportate a un sistema. Copiato di seguito per comodità (con lievi modifiche):

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

Ti stai avvicinando in qualche modo alla domanda nel modo sbagliato. Devi decidere cosa vuoi registrare e scoprire come registrarlo. Generare un sacco di file di registro è fantastico e tutto, ma se non li guardi mai o non sai cosa stai cercando, perdi solo tempo e spazio.

Quando si decide cosa registrare, è necessario identificare il comportamento a cui tieni, quindi scoprire come registrare tale attività. Un buon modo per iniziare a farlo sarebbe leggere AppArmor e sfogliare la pagina man auditctl . quindi scopri quali chiamate di sistema sono disponibili imparando a programmare per Unix e identifica le chiamate che potrebbero essere di interesse. È davvero un'impresa piuttosto grande. So che questa è una risposta un po 'glib e non fornisce "ecco uno script Shell che registrerà tutto ciò che ti interessa sul tuo server" - ma il motivo per cui quelle risposte non esistono è che, beh, ogni situazione è diversa quindi non è possibile dare una risposta "taglia unica".

Nel posto (certamente grande) in cui lavoro, abbiamo un intero team di persone che si dedicano solo alla registrazione del sistema, per non parlare dei vari team di amministrazione e sicurezza che contribuiscono. Questo non è un piccolo argomento. : /

11
dannysauer