System auditing su Linux con auditd
In questo articolo viene presentata una prima introduzione ad auditd: il più importante demone presente su Linux per il monitoring del proprio sistema. Quella che segue è una breve spiegazione del funzionamento logico del sistema di auditing, del demone e delle sue configurazioni più comuni.
Cos’è una syscall
Quando si parla di sistemi operativi Linux è importante conoscere la differenza tra due modalità principali per i processi: il supervisor-mode e lo user-mode.
La prima, supervisor-mode, permette al processo a cui è assegnata di eseguire operazioni macchina interfacciandosi più direttamente con le risorse fisiche — e.g. CPU e memoria. Questa modalità, per i sistemi a kernel monolitico come Linux, è assegnata solamente al sistema operativo e l’allocazione della memoria viene confinata in quello che viene comunemente chiamato kernel-space, non accessibile da processi in modalità diverse dal supervisor-mode.
L’esecuzione di tutti gli altri processi che vi stanno attorno, avviene invece in user-mode. Analogamente al caso delle applicazioni in supervisor-mode, anche quelle in user-mode dispongono di una zona riservata di memoria detta user-space. Per effettuare operazioni di basso livello — come l’allocazione di memoria o la scrittura su disco, che significa anche la creazione o distruzione di processi — è necessario far passare la richiesta da un processo con i privilegi più alti (cioè in supervisor-mode) attraverso una chiamata detta system call o syscall.
Questa divisione netta delle responsabilità assegnate ai processi Linux permette un maggior livello di sicurezza e facilita il compito di monitorare in maniera dettagliata tutte le azioni effettuate da processi in user-mode tramite l’intercettazione delle chiamate di sistema.
Auditd
Audit System è un tool Linux sviluppato da Red Hat che si occupa di intercettare tutte le
chiamate di sistema e di passarle a un suo demone, auditd, configurabile dall’utente. Dal momento che viene in parte eseguito a livello di kernel, riesce a dare informazioni su qualsiasi attività in corso, purchè mediata da una system call. Questa capacità gli permette quindi di monitorare ogni operazione che avviene all’interno del nostro sistema, che sia essa un semplice accesso ad un file o l’intero traffico di rete.
Oltre ad ascoltare, è possibile configurare il demone auditd in modo che scriva un log ogni volta che viene invocata una determinata syscall. Questa capacità lo rende uno strumento di logging molto potente; in particolare, vista la quantità di informazioni che è in grado di fornire, è il sistema di log a cui si appoggia SELinux.
Auditd per la sicurezza
Oltre a permettere il corretto funzionamento di SELinux, è possibile configurare auditd per tenere sotto controllo determinate operazioni. In particolare, nei suoi utilizzi più comuni viene utilizzato per due principali funzioni: monitorare cambiamenti a file di sistema, o monitorare le syscall che si occupano di cambiare parametri vitali per il sistema, come l’ora o le informazioni sulla rete.
Monitorare cambiamenti a file di sistema
Se si vuole tenere in sicurezza un sistema, è ad esempio importante monitorare la creazione di nuovi utenti e l’assegnazione dei relativi privilegi. Un cambiamento inaspettato in queste due configurazioni potrebbe significare che c’è stata una qualche compromissione.
Su Linux, le informazioni relative agli utenti vengono salvate in semplici file, come /etc/shadow e monitorarne l’accesso in scrittura ed i cambiamenti di permessi, fornisce informazioni importanti sul grado di protezione che si sta fornendo al sistema.
Altri esempi di file che può essere importante monitorare sono le configurazioni dei servizi principali e gli script che gestiscono rete e interfacce. Prima fra tutti per importanza, nei sistemi dove è attivo SELinux, è la sua configurazione contenuta in /etc/selinux/.
Monitorare syscall che si occupano di cambiare parametri vitali
Oltre ai file di configurazione, molti parametri di sistema possono essere modificati in runtime ed è quindi consigliato monitorarne le modifiche ascoltando direttamente le chiamate di sistema che se ne occupano. Fra i più importanti, figurano ancora una volta i cambiamenti alle informazioni sulla rete — mediati ad esempio dalle chiamate setdomainname e sethostname — e quelle all’ora del sistema — mediate da chiamate come adjtimex, settimeofday e clock_settime.
L’elenco completo delle chiamate lo si trova in
man 2 syscalls
Come configurare auditd
Auditd ha due principali file di configurazione: /etc/auditd.conf e /etc/audit.rules. Mentre nel primo sono presenti le configurazioni più generiche, nel secondo ci sono le regole riguardo alle azioni da monitorare.
Come descritto nei punti precedenti, auditd due si interessa di avvenimenti principali: gli accessi ai file e le syscall. Nel file /etc/audit.rules è possibile specificare quando, in occorrenza di una di queste evenienze, si vuole che venga creato un evento — a cui viene poi fatta corrispondere un’entrata nei log.
Per capire la sintassi base che si usa per specificare queste direttive bastano i due seguenti comandi:
-a exit,always -S [syscall] -w [percorso_file] -p [azione]
Il primo significa che viene sempre creato un evento all’uscita della syscall [syscall], mentre il secondo ne crea uno ogni volta che viene eseguita una azione di lettura, scrittura, esecuzione o modifica degli attributi sul file o sulla cartella [percorso_file].
Inoltre, per facilitare poi la consultazione dei log creati, è possibile aggiungere in coda a ciascuna di queste regole l’opzione:
-k [key]
che raggruppa tutte le regole a cui è applicata sotto la chiave desiderata.
Quello che segue è un esempio di configurazione su un sistema a 64 bit multi-lib:
# 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 # Modifiche ai file che contengono informazioni sugli utenti # (per sistemi che non si appoggiano a ldap): sotto la flag user_identity -w /etc/group -p wa -k user_identity -w /etc/passwd -p wa -k user_identity -w /etc/shadow -p wa -k user_identity ####### Monitorare i cambiamenti dei parametri più importanti del sistema ##### # Parametri di rete: sotto la flag local_network -a always,exit -F arch=b32 -S setdomainname -S sethostname -k local_network -a always,exit -F arch=b64 -S setdomainname -S sethostname -k local_network -w /etc/sysconfig/network -p wa -k local_network -w /etc/hosts -p wa -k local_network # Data e ora: sotto la flag time_change -a always,exit -F arch=b32 -S adjtimex -S settimeofday -S clock_settime -k time_change -a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime -k time_change -w /etc/localtime -p wa -k time_change # Makes the auditd configuration immutable -e2
Dove è importante notare che ogni chiamata di monitoring viene specificata due volte: una per le chiamate tramite librerie a 32 bit, e l’altra per quelle a 64.
Per un sistema a 32 bit, per ottenere gli stessi risultati, basterà ovviamente limitarsi alle entrate con arch=b32.
Consultare i log
Una volta configurato auditd per loggare gli eventi interessanti, esistono diverse alternative per consultarne il risultato. A meno che non venga specificato diversamente, i log di auditd vengono salvati in /var/log/audit/audit.log e il primo ovvio metodo per consultare gli eventi loggati, è quindi quello di andare a leggere direttamente i raw log qui presenti.
Dal momento che, specie nel caso in cui vi siano più regole presenti, questo file risulta spesso fitto ed è difficile isolare le syscall legate a singoli eventi di cui si vuole indagare, è possibile utilizzare il comando ausearch per un parsing dei log.
Grazie a questo tool, è infatti possibile filtrare i log specificando diverse opzioni, ricordando che ogni flag consecutiva specificata viene letta come un “and” logico.
Le più comuni sono: la chiave, cioè la direttiva specificata con il -k nelle regole descritte nella sezione precendente, gli orari per delimitare l’intervallo entro il quale cercare gli eventi, lo user id e il pid legati alla chiamata.
Nel caso non si stiano cercando eventi specifici, risulta utile utilizzare il comando aureport che fornisce riassunti degli eventi loggati dal demone più leggibili, grazie ai quali è più semplice identificare gli eventi sospetti specifici da approfondire poi con ausearch.
