AIDE, Advanced Intrusion Detection Environment

Aide, è un file integrity checker, ovvero un software che verifica l'integrità dei file del sistema, confrontandoli con una loro immagine generata precedentemente. Tale confronto viene eseguito verificando gli hash dei file monitorati, poiché ogni modifica di un file causa la modifica del relativo hash.
L'utilità di un tool come Aide è evidente se si considera quale scocciatura sarebbe calcolare e verificare gli hash manualmente per ogni file, oppure crearsi una serie di shellscript ad hoc per eseguire queste operazioni.
L'installazione, su Debian, può essere portata a termine semplicemente con un apt-get install aide, in modo da risolvere anche eventuali dipendenze, come la libreria libmhash per esempio.
La configurazione del programma è definita nel file /etc/aide/aide.conf.
Un possibile esempio di configurazione è la seguente :
database=file:/var/lib/aide/aide.db
database_out=file:/var/lib/aide/aide.db.new
database_new=file:/var/lib/aide/aide.db.new
gzip_dbout=yes
report_url=stdout
report_url=file:/var/log/aide/aide.log
# binari e librerie
BINLIB = p+i+n+u+g+s+b+m+c+sha1+md5
# file di configurazione
CONF =  i+n+u+g+s+b+m+c+sha1+md5
# log
LOGS = p+u+g
# risorse da monitorare
# Kernel
/boot            BINLIB
# binari
/bin            BINLIB
/sbin            BINLIB
/usr/bin        BINLIB
/usr/sbin        BINLIB
/usr/local/bin    BINLIB
/usr/local/sbin    BINLIB
# librerie
/lib            BINLIB
/usr/lib        BINLIB
/usr/local/lib    BINLIB
# files configurazione
/etc        CONF
# logfiles
/var/log    LOGS

Nelle prime tre righe vengono definiti rispettivamente file da utilizzare come database nei confronti, il file generato da aide in fase di inizializzazione o aggiornamento, ed il file da confrontare con aide.db quando viene utilizzata l'opzione --compare.
All'interno del file sono state definite le tre seguenti regole per il monitoraggio:
BINLIB: verifica se sono avvenuti cambi di permessi, del numero di inode, numero dei link simbolici verso il file, proprietario o gruppo associato, dimensione del file, numero dei blocchi, data di modifica del file e data di modifica dell'inode. Vengono inoltre valutati sia gli hash md5 che sha1 del file.
Con ogni probabilità il calcolo di un singolo hash sarebbe più che sufficiente, vista la difficoltà di collisioni, ma io preferisco essere paranoico. Calcolando due hash si può avere la ragionevole certezza che un file che abbia mantenuti inviariati tali valori non sia stato modificato: è praticamente impossibile che due sequenze di bytes differenti possano generare la stessa coppia di hash md5 e sha1.
Tale regola viene utilizzata per la verifica dell'integrità dei programmi contenuti nelle directory /bin, /sbin, /usr/sbin, /usr/bin, /usr/local/bin, /usr/local/sbin e delle diverse librerie in /lib, /usr/lib e /usr/local/lib. Oltre che per queste directory, vi si fa ricorso anche per /boot, in modo da potere verificare eventuali modifiche o manomissioni all'immagine del kernel o della System.map.
CONF: esegue gli stessi controlli regola BINLIB, ad eccezione della modifica dei permessi. Questa scelta è stata dettata dalla volontà di evitare l'eccessivo numero di falsi positivi nella directory /etc ottenuti con tale regola.
Alcuni files come /etc/motd, /etc/mtab (l'elenco delle partizioni montate), /etc/adjtime (file di configurazione per l'aggiustamento dell'orologio hardware) ed /etc/network/ifstate (contiene lo stato delle interfacce di rete) vengono scritti ad ogni avvio del sistema. Quindi in caso di reboot della macchina sarà necessario tenere presente questo fatto, poichè aide segnalerà la loro modifica.
Volendo sarebbe possibile escludere tali file dal monitoraggio, ma presumendo di controllare un server che non debba venga spento o riavviato frequentemente, ho consentito di monitorare anch'essi.
LOGS: verifica solo i cambi di permessi, gruppo e proprietario. Utilizzando tale direttiva per i log di sistema, si è evitato di controllare anche variazioni di dimensione, hash e data dell'ultima modifica. In caso contrario,si finirebbe con il ricevere continuamente degli alert relativi alle modifiche dei files di log, che vengono comunque effettuate regolarmente ed in maniera del tutto legittima.

Creato il file di configurazione deve venire inizializzato il database da usare come immagine iniziale del sistema con il comando aide --init. Con il file di configurazione riportato viene creato il file /var/lib/aide/aide.db.new, contenente l'hash di tutti i file indicati tra le risorse da monitorare, oltre a diverse altre informazioni quali proprietari, permessi, date di modifica ecc, a seconda delle regole specificate.
Poichè nel file di configurazione è stato indicato aide.db come database è necessario anche un cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db, visto che il database generato si chiamava aide.db.new.
Per verificare l'integrità dei file monitorati è sufficiente impartire il comando aide --check. Esso confronta lo stato attuale del sistema con quanto memorizzato in aide.db. In caso di discrepanze vengono mostrate a video le differenze rilevate, come cancellazione o creazione di nuovi files, modifiche dei permessi, cambio di valori dei checksum e così via.
Una funzionalità simile è quella dell'opzione --compare, che esegue però un confronto tra i due database aide.db e aide.db.new.
Perchè il controllo dell'integrità possa funzionare correttamente, senza impazzire con una marea di falsi allarmi, è fondamentale ricordarsi di aggiornare il database aide.db ad ogni installazione/update di qualche software, od alla modifica di qualche file di configurazione. In caso contrario, sebbene le modifiche effettuate siano state legittime, Aide rileverebbe delle differenze rispetto alla precedente immagine del sistema, segnalandole in modo opportuno.
Per l'aggiornamento del database si può utilizzare l'opzione update: aide --update.
Anche in questo caso Aide genererà un file chiamato aide.db.new, che dovrà essere copiato al posto del precedente aide.db.
Infine, per automatizzare l'operazione di controllo del filesystem sarà sufficiente inserire il comando aide --check in un un cronjob.

Per quanto possa essere utile uno strumento del genere per rilevare modifiche ed intrusioni, essendo il database utilizzato per i confronti memorizzato sulla macchina, un eventuale attacker potrebbe generare una nuova immagine dei file del sistema e sostituirla al vecchio database.
Una soluzione abbastanza semplice al problema potrebbe essere la copia del database su un CD od un DVD, ed eseguire i confronti con quest'immagine, che non potrebbe venire manomessa. Questo sistema può essere adatto finchè si debba monitorare una sola macchina, o comunque un numero ristretto. In caso contrario la procedura sarebbe un po' troppo macchinosa.
Un'alternativa a questo approccio, potrebbe essere la copia del database tramite il comando scp su di un secondo sistema. Nel mio caso, paranoid è il nome della macchina da monitorare, e stargazer quella dove memorizzare le immagini.
Volendo effettuare connessioni ssh e copie tramite scp all'interno di uno shellscript, anziché utilizzare l'autenticazione tramite password si può fare ricorso a un meccanismo con chiave asimmetrica.
Per evitare di utilizzare l'utente root, inoltre, su entrambe le macchine si potrebbe creare un apposito utente chiamato rfc.
Sull'host stargazer effettuato il login come utente rfc, creare una coppia di chiavi tramite il comando ssh-keygen -t dsa, memorizzandole nella directory /home/rfc/.ssh.  Durante la generazione delle chiavi non deve essere specificata alcuna password, altrimenti si avrebbe sempre il problema della richiesta della stessa all'interno degli shellscript.
La chiave pubblica id_dsa.pub deve poi essere copiata su paranoid con il comando scp /home/rfc/.ssh/ida_dsa.pub rfc@paranoid: . Non avendo ancora inserito tale chiave tra quelle autorizzate per il server paranoid, sarà necessario inserire la password dell'utente rfc alla richiesta.
A questo punto, su paranoid inserire la chiave  copiata tra quelle autorizzate all'interno del file /home/rfc/.ssh/authorized_keys2, tramite il comando cat id_dsa.pub >> /home/rfc/.ssh/authorized_keys2.
In questo modo l'utente rfc sarà in grado di connettersi ed eseguire comandi sull'host paranoid senza  l'inserimento di alcuna password. Sarebbe anche opportuno che tale chiave e la directory ove essa è memorizzata avessero i privilegi minimi possibili, rispettivamente 600 e 700.
In modo da consentire il login ssh per il solo utente rfc dall'host stargazer verso paranoid, devono essere modificate come segue alcune righe del file /etc/ssh/sshd_config dell'host paranoid:
Protocol 2
ListenAddress 192.168.1.4
PermitRootLogin no
PermitEmptyPasswords no
AllowUsers [email protected]

Come si può vedere dallo stralcio del file di configurazione viene indicato il protocollo 2, ed il server ssh è in ascolto esclusivamente sull'indirizzo IP 192.168.1.4 . Tra le altre opzioni vengono negati l'accesso diretto via ssh dell'utente root, e la possibilità di usare password vuote (da non confondersi con le password che possono essere associate alle chiavi private degli utenti).
Tramite l'ultima direttiva, ovvero AllowUsers, viene consentito l'accesso al solo utente rfc dall'host stargazer, il cui indirizzo IP e' 192.168.1.2.
Per cercare di garantirsi una maggiore sicurezza, consentendo l'accesso ssh esclusivamente dall'host stargazer, è stato inoltre utilizzato tcpwrapper (tcpd) per lasciare passare solo connessioni da indirizzi IP ritenuti affidabili.
Per utilizzare il wrapper si può avviare il server ssh venisse tramite il superdemone inetd, aggiuntendo la seguente riga in /etc/inetd.conf :
ssh    stream    tcp    nowait    root    /usr/sbin/tcpd    /usr/sbin/sshd    -i
Ssh indica il servizio, stream il tipo di socket, tcp il protocollo, nowait indica al server di non aspettare che venga rilasciato il socket per rimettersi in ascolto sulla relativa porta, root il nome dell'utente con cui gira sshd, /usbr/sbin/tcpd il tcpwrapper e sshd il demone del servizio ssh. Viene inoltre indicata opzione -i per il demone sshd,  indispensabile, poiché indica che esso viene avviato tramite il superdemone inetd.
Venendo eseguito il demone ssh tramite inetd sarebbe il caso di rimuovere anche tutti i link simbolici ad esso relativi nelle varie cartelle /etc/rcX.d con il comando update-rc.d -f ssh remove.
L'ultimo passo nella configurazione del wrapper tcp è la modifica dei file /etc/hosts.deny ed /etc/hosts.allow, aggiungendo rispettivamente le seguenti righe :
#hosts.deny
sshd: ALL

#hosts.allow
sshd: 192.168.1.2    stargazer.localdomain

In questo modo tcpd filtrerà tutte le connessioni al servizio ssh, consentendo l'accesso ssh su paranoid esclusivamente dall'host stargazer.localdomain il cui indirizzo IP è 192.168.1.2.
Perchè queste nuove impostazioni possano avere effetto sarà necessario riavviare il superdemone inetd: /etc/init.d/inetd restart.
Apportate queste modifiche creare il seguente shellscript /usr/bin/rfc_create_db.sh:
#!/bin/bash
HOST_NAME="paranoid"
aide --init    
mv /var/lib/aide/aide.db.new /home/rfc/$HOST_NAME.aide.db
chmod 600 /home/rfc/$HOST_NAME.aide.db
chown rfc /home/rfc/$HOST_NAME.aide.db
chgrp rfc /home/rfc/$HOST_NAME.aide.db
Esso ha il compito di creare un'immagine del stato attuale dei files del sistema tramite l'opzione --init di aide, e copiarla sotto la directory /home/rfc, impostando rfc come gruppo e proprietario del file, e settando i permessi in lettura e scrittura esclusivamente per il proprietario.
Poichè l'opzione --init di aide non può essere utilizzata da un semplice utente, bisogna consentire l'esecuzione dello script precedente tramite sudo, aggiungendo nel file /etc/sudoers di paranoid, la seguente riga:
rfc    paranoid = NOPASSWD: /usr/bin/rfc_create_db.sh

Come si può notare è presente anche l'opzione NOPASSWD, per non richiedere l'immissione della password, poiché il comando verrà richiamato all'interno dello shellscript remotefc.sh presente su stargazer:
#!/bin/bash
# =================  remotefc.sh ====================
# ======= Remote File check == Andrea Beretta =======
# ===================================================
# Thanks to : Remote Filesystem Checker by Claudio Panichi

if [ -z $2 ]; then
  echo "ERRORE : hostname non specificato"
  echo "Usage: $0 {update|get|compare} hostname"
  exit 1
fi
case "$1" in
  update)
    ssh rfc@$2 sudo rfc_create_db.sh
    cp /home/rfc/$2.aide.db /home/rfc/$2.db.bak.$(date +%d-%m-%Y)
    scp rfc@$2:/home/rfc/$2.aide.db /home/rfc
    ssh rfc@$2 rm -f /home/rfc/$2.aide.db
  ;;
  get)
    ssh rfc@$2 sudo rfc_create_db.sh
    scp rfc@$2:/home/rfc/$2.aide.db /home/rfc/$2.aide.db.new
    ssh rfc@$2  rm -f /home/rfc/$2.aide.db
  ;;
  compare)
    aide -c /home/rfc/$2.aide.conf --compare | mail -s " File Integrity Check on $2" [email protected]
  ;;
  *)
    echo "Usage: $0 {update|get|compare} hostname"
    exit 1
  ;;
esac
exit 0  

Questo script può eseguire le seguenti tre funzioni:
update: viene effettuata una connessione via ssh come utente rfc verso l'host indicato dal secondo parametro dello script ($2), e tramite sudo eseguito  rfc_create_db.sh su tale host.
Una volta eseguito questo script, sulla macchina da cui si esegue remotefc.sh (nel mio caso stargazer), viene fatto un backup del precedente database, copiata la nuova versione tramite scp e, sempre  via ssh, rimosso dalla macchina remota (paranoid).
In questo modo nella directory /home/rfc dell'host stargazer compariranno i file paranoid.aide.db e paranoid.db.bak.gg-mm-yy. Questa funzione deve essere eseguita ogni volta dopo gli update e le modifiche della macchina monitorata.

get: viene utilizzata per “scaricare” dall'host remoto l'immagine attuale dei file del sistema. Le operazioni eseguite sono pressoche' identiche a quelle dell'opzione update, con l'unica differenza nella copia del file. Infatti, nella copia con scp, il file viene copiato con un nome differente (nomehost.aide.db.new) per non sovrascrivere il database precedente, già presente in /home/rfc (nomehost.aide.db) di stargazer.

compare: esegue il confronto tra i due database nomehost.aide.db e nomehost.aide.db.new, sfruttando l'opzione --compare di aide. Viene inoltre usata una pipe, per inviare una mail all'amministratore di sistema, contenente il risultato del confronto.

Come si può notare dallo script, quando viene invocato aide su stargazer non viene utilizzato il file /etc/aide.conf, ma il file $2.aide.conf. Lo script può infatti venire utilizzato per monitorare diverse macchine, e per ognuna di esse nella directory /home/rfc della macchina preposta al controllo devono essere presenti il file di configurazione ed i rispettivi database, distinguibili per il prefisso con l'hostname nel nome del file. Nel mio caso, controllando l'integrità dei file dell'host paranoid il file di configurazione utilizzato deve essere paranoid.aide.conf.
Tale file è necessario solo per l'esecuzione del confronto, infatti la generazione dei database viene effettuata sulle macchine remote, e nel mio caso è la copia del file /etc/aide.conf usato su paranoid, con l'unica differenza nei percorsi ai file dei database e del file di log:
    database=file:/home/rfc/paranoid.aide.db
    database_out=file:/home/rfc/paranoid.aide.db.new
    database_new=file:/home/rfc/paranoid.aide.db.new
    report_url=stdout
    report_url=file:/home/rfc/log/paranoid.aide.log

Per eseguire il controllo dell'integrità dell'host paranoid, quindi, debbono essere eseguite le seguenti operazioni:
- Creazione e copia del database iniziale dell'host paranoid con il comando /home/rfc/remotefc.sh update paranoid. Tale comando deve essere ripetuto ad ogni aggiornamento o modifica del software o dei file di configurazione della macchina, in modo da avere l'originale utilizzato per i confronti aggiornato.
- Download del database che rappresenta l'immagine attuale dell'host remoto con il comando /home/rfc/remotefc.sh get paranoid.
Confronto dell'ultimo database scaricato con l'originale, tramite /home/rfc/remotefc.sh compare paranoid.

Tutte le operazioni elencate devono essere eseguite sull'host stargazer senza dovere ricorrere all'utente root, ma sempre con l'utente rfc. Durante la comparazione aide mostrerà a video alcuni messaggi di warning, legati ad alcuni privilegi mancanti, ma essi non andranno comunque ad inficiare l'operazione di confronto tra i due database.
L'ultimo passo da eseguire nella configurazione del sistema, è l'inserimento delle operazioni di download e confronto dei database all'interno di un cronjob sull'host stargazer, automatizzando in questo modo l'esecuzione del tutto.
Ad esempio, per eseguire il controllo tutte le notti alle 3:15, l'utente rfc  potrebbe inserire i seguenti cronjob con il comando crontab -e:
15  3    * * *   /home/rfc/remotfc.sh get paranoid
25  3    * * *   /home/rfc/remotefc.sh compare paranoid

Per testare il sistema, si può provare a creare un'immagine iniziale del sistema da monitorare ed eseguire un confronto con il database scaricato dopo l'inserimento di un nuovo utente.
Nel mio caso, come risultato di tale confronto nel file di log /home/rfc/log/paranoid.aide.log sono state riportate le seguenti informazioni, che evidenziano appunto l'avvenuta modifica dei files coinvolti nell'operazione di inserimento del nuovo utente:
AIDE found differences between the two databases!!
Start timestamp: 2005-11-08 17:00:18
Summary:
Total number of files=2792,added files=0,removed files=0,changed files=9

Changed files:
changed:/etc
changed:/etc/passwd
changed:/etc/group
changed:/etc/passwd-
changed:/etc/shadow
changed:/etc/group-
changed:/etc/gshadow-
changed:/etc/shadow-
changed:/etc/gshadow
Detailed information about changes:

File: /etc
   Mtime    : 2005-11-12 18:51:57               , 2005-11-12 18:56:52              
   Ctime    : 2005-11-12 18:51:57               , 2005-11-12 18:56:52              

[...]

File: /etc/shadow-
   Size     : 745                               , 803                              
   Mtime    : 2005-11-11 19:28:25               , 2005-11-12 18:51:57              
   Ctime    : 2005-11-11 19:31:12               , 2005-11-12 18:56:43              
   MD5      : gFQqjCTXrRRmOj6fB0iZUg==          , qckc5NrpvPcd6nSmue7bpg==          
   SHA1     : D0zAJY/qjzye0LMU60czES+ANNM=      , R0BzpcRHmA9ggVoc2/n2d/YsnWc=      

[...]

Inoltre, l'utente root dell'host stargazer ha email dal subject File Integrity Check on paranoid, che riporta le medesime informazioni memorizzate nel file di log.

Privacy Policy