Esempio di configurazione auditd semplice?

45

Auditd è stato consigliato in una risposta a Linux command logging?

L'installazione predefinita su Ubuntu sembra quasi non registrare nulla. Esistono diversi esempi (capp.rules, nispom.rules, stig.rules), ma non è chiaro quale sarebbe l'impatto sulle prestazioni di ciascuno, né quale tipo di ambiente o ipotesi sarebbero più adatti per ciascuno.

Quale sarebbe il miglior punto di partenza per la distribuzione di auditd su, diciamo, un server web? Ciò include un file audit.rules, le impostazioni per consentire l'invio del flusso del log 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 un tipico computer desktop?

Aggiornamento : dannysauer nota che per sicurezza è importante iniziare con l'obiettivo e sono d'accordo. Ma il mio intento principale è quello di dare alcune utili spiegazioni sull'uso di questo strumento, e vedere un esempio funzionante di esso in azione, insieme con le implicazioni di prestazioni e archiviazione, ecc. Se questo esiste già e io lo mancate, per favore indicatelo. In caso contrario, sto suggerendo di creare un esempio per uno degli scenari più comuni (ad esempio un semplice web server, che gestisce il tuo stack di scelta), in cui l'obiettivo potrebbe essere quello di preservare le informazioni in caso di intrusione per aiutare rintracciare per scoprire dove è iniziata la penetrazione. Se esiste un obiettivo più adatto o raggiungibile da utilizzare, ad es. una piccola azienda senza un significativo personale IT, che sarebbe di aiuto anche.

    
posta nealmcb 18.06.2011 - 19:26
fonte

3 risposte

38

Auditd è uno strumento di monitoraggio straordinariamente potente. Come chiunque abbia mai guardato, può attestare l'usabilità è la principale debolezza. L'impostazione di qualcosa come auditd richiede un pensiero molto approfondito su esattamente che è che necessita di controllo sul sistema specifico in questione. Nella domanda che hai deciso su un server web come il nostro sistema di esempio, che è buono dal momento che è specifico.

Per ragioni di discussione, supponiamo che esista una divisione formale tra i server web di test / dev e la produzione server Web in cui gli sviluppatori Web eseguono tutto il loro lavoro sui sistemi test / dev e modifiche alla produzione l'ambiente è fatto in una distribuzione controllata.

Quindi, facendo queste ipotesi piuttosto grandi e concentrandoci sul sistema di produzione, possiamo metterci al lavoro. Guardando la raccomandazione auditd in CIS benchmark 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 escono le chiamate di sistema rmdir, unlink, stime o setrlimit. Questo dovrebbe fateci sapere se qualcuno tenta di cancellare file o jigger con i tempi. Abbiamo anche creato specifici file di orologi su file che definiscono gruppi, utenti, password e accesso sudo. Invece di guardare le chiamate di sistema per ognuna di esse il registro di controllo verrà scritto ogni volta che uno di questi file è:

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

Poiché abbiamo già assunto l'ipotesi che stiamo parlando di un server Web di produzione, ti consiglio di aggiungere la riga:

-w /var/www -p wa

Questo guarderà in modo ricorsivo tutti i file sotto l'albero della directory /var/www .

Ora possiamo vedere la ragione per l'ipotesi di "ambiente controllato" fatta in precedenza. Tra il monitoraggio di tutti i file in la web root, così come tutti gli eventi unlink o rmdir, potrebbero essere proibitivamente rumorosi in un ambiente di sviluppo. Se possiamo anticipare le modifiche al filesystem, come durante la manutenzione di windows o distribuire eventi, possiamo filtrare più ragionevolmente fuori questo rumore.

Combinando tutto questo in un unico file coerente vorremmo /etc/audit/audit.rules per assomigliare

# 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
    
risposta data 12.07.2011 - 23:10
fonte
13

Aggiornamento: questo articolo è una buona spiegazione delle regole di audit e fornisce esempi per ciascun evento che potresti voler registrare:

HOWTO_configure_the_auditing_of_the_system_auditd

Controlla la segnalazione di bug qui:

link

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
    
risposta data 10.01.2014 - 20:16
fonte
11

In qualche modo ti stai avvicinando alla domanda nel modo sbagliato. Devi decidere cosa vuoi registrare e scoprire come registrarlo. Generare un sacco di file di registro è bello e tutto, ma se non li guardi mai o non sai cosa stai cercando, ti fa perdere tempo e spazio.

Quando decidi cosa registrare, devi identificare il comportamento che ti interessa e poi scoprire come registrare tale attività. Un buon modo per iniziare a fare questo è leggere su AppArmor e leggere le auditctl pagina man. quindi scopri quali chiamate di sistema sono disponibili apprendendo 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 'approssimativa e non fornisce "ecco uno script di shell che registrerà tutto ciò che ti interessa sul tuo server" - ma la ragione per cui queste risposte non esistono è che, beh, ogni situazione è diversa quindi non è possibile dare una risposta "taglia unica".

Nel luogo (immensamente grande) in cui lavoro, abbiamo un intero team di persone dedicate esclusivamente al logging del sistema, per non parlare dei vari team di amministratori e sicurezza che contribuiscono. Questo non è un piccolo argomento. : /

    
risposta data 23.06.2011 - 01:17
fonte

Leggi altre domande sui tag