Intrusion detection e analisi dei log

Intrusion Detection Systems (IDS) su Linux

Le attività e i campi di applicazione di un Intrusion Detection System sono vari, al punto che spesso vengono gestiti da diversi software, che nel loro insieme provvedono ad accorgersi dei tentativi di attacco o scansione di un sistema, prevedere meccanismi di notifica (Email, log, Sms) e reazione secondo eventi anche proattivi in grado di bloccare sul nascere le comunicazioni con IP da cui arrivano pacchetti ostili.
L'evoluzione naturale di un IDS relativo ad un singolo host è il Network Intrusion Detection System (NIDS) che monitora il traffico di una intera rete.

I meccanismi di individuazione di attività sospette sono diversi, ma generalmente si concentrano su:
- Verifica dei log di sistema o di specifici programmi per individuare attività anomale;
- Controllo dell'integrità dei file locali, modifiche sospette possono essere sintono di una avvenuta irruzione;
- Monitoring dei pacchetti destinati all'host, sia per reagire a pattern di attacco noti che per accorgersi di un port scan da remoto, generalmente prologo di un tentativo di intrusione.

Il mondo OpenSource offre una moltitudine di strumenti utili per questi scopi, si va da piccoli programmi per specifiche attività a sistemi più complessi di qualità evolute.
Per essere veramente efficace, l'implementazione di sistemi di Intrusion Detection oltre a richiedere un sostanzioso intervento sistemistico per la configurazione e la customizzazione del software usato, deve essere tale da permettere una rapida analisi: troppi log e mail di notifica sono alla lunga controproducenti e inutili se a questo non segue un controllo effettivo.
Segue un breve elenco di alcuni dei programmi più noti per le attività di Intrusion Detection.

LOG ANALYZERS
Sono programmi che monitorano le entry nei file di log di sistema e possono essere configurati per eseguire date operazioni in presenza di determinate righe di log.
E' bene che agiscano in tempo reale, dal momento che dopo una intrusione una delle prime occupazioni di un hacker è quella di cancellare le tracce eventualmente lasciate sui log vari.
In questa categoria possono rientrare:
Swatch http://swatch.sourceforge.net/ - Può monitorare in tempo reale ogni tipo di file. E' in Perl e richiede alcuni moduli generalmente non installati di default e scaricabili da CPAN, nei file di configurazione si settano le regole di pattern matching dei log e i comportanti da adottare.
Logsurfer - http://www.cert.dfn.de/eng/logsurf/ - Ha caratteristiche simili a Swatch ma presenta alcuni miglioramenti, tra cui la possibilità di correlare gli output di diversi log e, al contempo, propone un file di configurazione più complesso (è consigliabile ispirarsi agli esempio di conf esistenti).
LogWatch - http://www.logwatch.org/ - Installato di default su alcune distribuzioni Linux come RedHat monitora diversi tipi di log, secondo impostazioni configurabili e genera i relativi alert e report.
Logcheck - Prodotto da Psionic, recentemente acquisita da Cisco. Non ha più un home page ufficiale.

A prescindere dal meccanismo di controllo dei log utilizzato, alcuni accorgimenti rendono l'operazione più efficace:
- Loggare, se possibile, su una macchina remota, in modo tale da impedire la manipolazioni dei log dopo un'intrusione;
- Nel definire le regole di log checking seguire una policy di logging di tutto tranne dei messaggi noti: definire delle regole di esclusione di righe di log lecite; definire regole per l'inclusione di speciali e noti eventi sospetti; includere tutto il resto (righe di log ignote o non previste).
- NON eseguire i programmi di log check come utente root, eventuali stringhe maligne nei log potrebbero generare risultati incontrollabili;
- Allo stesso modo, non visualizzare i log da un terminale potenzialmente sensibile ad un "TERMINAL EMULATOR ATTACK" tramite caratteri escape che vengono mal utilizzati o interpretati da certi terminali (Per dettagli: http://www.digitaldefense.net/labs/papers/Termulation.txt)

FILE INTEGRITY CHECKERS
Una volta fatta con successo un'intrusione, oltre a guardarsi intorno e cercare di capire dove si trova, un hacker che vuole mantenere l'accesso e la possibilità di rientrare nel sistema provvede ad cancellare le proprie tracce dai log, ad installare trojan e programmi che aprano nuovi accessi remoti, controllino le attività degli amministratori (packet sniffers, key loggers...) servano per attacchi successivi, lanciati dall'host già violato. Queste attività sono facilitate e in parte automatizzate da rootkit dedicati ma, in ogni caso, lasciano tracce sul sistema: nuovi file copiati, log e binari modificati, cancellazioni ecc.
Gli strumenti di Integrity Check aiutano ad individuare simili manipolazioni e generalmente registrano cambiamenti nella data di creazione o modifica di un file, alterazioni dei permessi, degli attributi o dello contenuto di file di configurazione, binari di comandi più o meno comuni, testi di log ecc.
Tripwire - http://www.tripwire.org - E' uno dei primi, più evoluti e utilizzati sistemi di Integrity Check.  Oltre alla versione OpenSource ne esistono complementi proprietari che facilitano l'integrazione e la centralizzazione dei dati da diversi sistemi remoti, rendendo più agevole il monitoraggio di molti host.
Aide - http://www.cs.tut.fi/~rammer/aide.html - Si presenta come l'alternativa completamente Free a Tripwire, ha una logica simile e prevede controlli della stessa natura tramite una varietà di algoritmi di checksum.
Integrit - http://integrit.sourceforge.net/ - Altra promettente e performante alternativa a Tripwire che si presta ad essere integrata in un sistema di monitoring che utilizza diversi strumenti.
Chkrootkit - http://www.chkrootkit.org - E' una serie di script dedicati alla individuazione di rootkit noti. Oltre a controllare lo stato di alcuni binari esegue controlli di altra natura (verifica sul proc filesystem ecc.), ma non va considerato come una soluzione generica.

Una caratteristica comune di questi e altri Integrity Checkers è quella di creare una snapshop preliminare dello stato dei file di un host "pulito", adattare la configurazione per il proprio specifico sistema, eliminare controlli che producono eccessivi false-positive (troppi warning tendono ad essere ignorati) e schedulare periodicamente un check dello stato attuale del sistema rispetto allo snapshot iniziale.
In tutti i casi ci sono alcune precedure di base che è giusto seguire per migliorare la sicurezza e l'affidabilità di simili strumenti:
- Copiare i database di snapshot su un sistema remoto o comunque un mezzo non scrivibile dall'host a cui si riferiscono;
- Considerare che un checksum non è infallibile ed esistono metodi per mantenere lo stesso checksum in un file modificato (quantomeno per md5, l'algoritmo più utilizzato in questi casi);
- Controllare effettivamente i log generati e rifinire gradualmente la configurazione per evitare segnalazioni errate, falsi positivi, per file che vengono modificati a causa di normali attività sul sistema.  

PORT SCANS DETECTORS
Preludio ad ogni tentativo di intrusione è quasi sempre un network scanning remoto, con cui l'attaccante cerca di individuare le porte aperte sui sistemi bersaglio. Nonostante le tecniche di port scanning siano piuttosto evolute (nmap, per esempio, permette almeno 6 diversi tipi di scanning, più o meno "stealth") esistono sistemi per individuarle e, quindi, sapere prima ancora di subire l'attacco, quali IP remoti stanno raccogliendo informazioni sui propri sistemi.
Sebbene ogni cracker accorto cercherà di non eseguire alcuna operazione di probing o hacking, direttamente dal proprio IP, sapere da quali indirizzi può provenire una minaccia è sempre utile.
I programmi più noti per individuare un port scanning sono:
ScanLogD - http://www.openwall.com/scanlogd/ Viene eseguito come un demone, costantemente in monitoraggio di collegamenti a porte TCP locali. Utilizza dei metodi per evitare disservizi o problemi nel gestire tentativi di DOS e discriminare dei veri e propri scan da attività più innocue.
PortSentry - Anch'esso progetto della Psionic di cui non esiste più un Home ufficiale, prevede meccanismi di detection anche di stealth scan, con la possibilità di bloccare tutti gli accessi dagli indirizzi che eseguono scan o azioni ostili.

In genere un semplice port scan detector ha funzioni limitate e può essere sostituito con migliore efficacia da un NIDS in grado di individuare, oltre a normali port scan una varietà di attività di rete sospette.

NIDS, IDS, HIDS
Il mondo OpenSource offre una discreta varietà di NIDS, HIDS (Host Intrusion Detection Systems) e IDS che, però, generalmente difettano nelle interfacce di reporting e gestione, oltre che nella facilità di installazione, per le quali molte alternative commerciali offrono soluzioni più evolute.
Snort - http://www.snort.org - E' il progetto NIDS più noto nella comunità OpenSource. Seppur di non banale gestione e con un sistema di reporting piuttosto grezzo, viene utilizzato come base da molti altri prodotti che ne estendono le funzionalità migliorando la gestione e i meccanismi di reporting. Le policy di packet matching sono costantemente aggiornate sulla base di nuove vulnerabilità.
Tamandua - http://tamandua.axur.org/ - E' un progetto relativamente poco conosciuto ma interessante, è possibile convertire le regole scritte per Snort sul database di Tamandua e sono previste tutte le features tipiche di un NIDS.
Prelude - http://www.prelude-ids.org/ - E' un interessante ibrido fra un NIDS e un HIDS, che presenta sia sensori per il traffico di rete che sensori per il singolo host. Vanta prestazioni superiori a SNORT e una buona modularità.

Un buon NIDS è un ottimo strumento per avere un'idea della variegata fauna di pacchetti che arrivano ad una rete pubblica e, se ben configurato, può indubbiamente troncare sul nascere molti tentativi di intrusione.
Alcune raccomandazioni di massima valgono per ogni NIDS:
- Selezionare con cura le regole di packet matching, cercando di evitare falsi positivi troppo verbosi o relativi a rischi molto relativi (il logging di ogni PING ai nostri sistemi è assolutamente inutile).
- Tenere ragionevolmente aggiornate le regole di matching, appoggiandosi ai database online.
- Tenere in un luogo particolarmente protetto la macchina centrale, se esistono diverse sonde nella rete, o comunque quella in cui i dati vengono raccolti ed elabotati.
- Controllare con costanza le segnalazioni di warning e minacce, avendo la pazienza di rifinire le proprie configurazioni per evidenziare solo gli eventi più significativi.
- Non esagerare a implementare, o quantomeno verificare con regolarità, meccanismi proattivi che bloccano ogni comunicazione con IP da cui arrivano pacchetti molesti. Questi IP possono venire spoofati e un soggetto ostile può creare una sorta di auto DOS attack, facendo bloccare al nostro IDS comunicazioni con normali e validi indirizzi IP.

Effetti e sintomi di una intrusione

Gli strumenti di Intrusion Detection disponibili sul mercato automatizzano controlli e operazioni che possono essere saltuariamente eseguite a mano o tramite strumenti inizialmente pensati per altri scopi.

I mezzi e i modi con cui ci si può accorgere della avventua intrusione in un sistema possono essere vari:
Picchi di banda, di solito in uscita, non spiegabili. Tramite strumenti come MRTG è possibile visualizzare velocemente il traffico generato da un host nel corso del tempo (giorni, settimane, mesi, anni). Questi grafici possono evidenziare con un colpo d'occhio, eventuali attività di rete anomale, in quanto a quantità. Sta poi all'ammnistratore approfondirne i motivi, che possono essere assolutamente legittimi.
Rapida occupazione di spazio su disco, che può essere dovuto ad un DOS attack che mira a saturare i log di sistema o all'uso di una macchina violata come repository per warez (software copiato, materiale pornografico... ) di varia natura. In questo caso parallelamente all'ocupazione di spazio su disco, è plausibile un aumento dell'occupazione di banda.
Defacing di un sito, è il modo più rapido e definitivo per individuare un'intrusione (e farsi individuare). I motivi per cui qualcuno possa cercare di modificare l'home page di un sito sono vari (rappresaglia ideologica o politica, semplice esibizionismo, scherno...), gli effetti sono spesso deleteri per l'immagine di chi gestisce il sito ma dal punto di vista tecnico questo risparmia agli amministratori il rischio di avere per ulteriore tempo una macchina violata su cui un intrusore può fare quello che vuole.
Comportamenti anomali del sistema, di varia natura. Possono essere malfunzionamenti o "cose strane" e inusuale che accadono sul sistema o su alcuni suoi processi. Possono avere svariate cause: malfunzionamenti hardware (problemi di disco, memoria, processore, bus ecc), software (bug, implementazioni errate) o anche essere dovuti ad una intrusione (binari modificati, trojan, modifiche al sistema).
Blocco di un processo o del sistema. Può capitare che per motivi non chiari il sistema vada in crash o un singolo processo che magari gestisce un servizio pubblico muoia. Quando accade di solito si riavvia la macchina o il processo e si ritorna a fare altro. Quando accade, in realtà, è il caso di provare ad analizzare i motivi del problema. Anche in questo caso possono essere dovuti al malfunzioanmente dell'hardware, ad un bug di un programma o anche essere conseguenza di un attacco che può anche essere andato a buon fine.
Modifica o cancellazione di log. Se ci si accorge di un simile evento (tipicamente tramite programmi di Integrity Check, ma anche con casuali osservazioni manuali o utilizzo di comandi come last o lastlog) dovrebbero subito scattare un po' di allarmi nella nostra mente e le relative verifiche. Un log è fatto per incrementare costantemente di dimensioni, senza subire modifiche nei suoi contenuti precedenti.
Notifica di amministratori di sistemi remoti che rileva attività ostile da parte dei nostri IP. In questo caso l'intrusore potrebbe utilizzare i nostri sistemi per sferrare attacchi o scan su altri sistemi in rete. Gli IP che risultano ostili sono i nostri (con le potenziali complicazioni legali del caso) per cui è necessario intervenire e verificare in fretta.
Il proprio IP è segnalato su DShield. Un ottimo strumento per verificare se un proprio IP risulta fra quelli da cui sono sferrati attacchi in rete è il sito DSHIELD, è una sorta di Distributed Intrusion Detection System, in cui sono raccolti i log degli IDS di chi contribuisce al progetto e vengono segnalati gli indirizzi IP da cui arrivano la maggior parte degli attacchi.
Esiste una comoda pagina in cui si può inserire un indirizzo IP e visualizzarne varie informazioni tra cui se è stato origine di attività ostile: http://www.dshield.org/ipinfo.php  
Nuovi utenti sul sistema, che non ci sono familiari, sono sicuramente un sintomo che dovrebbe sollevare più di un sospetto. I nomi degli utenti possono essere sfacciati (r00t, 0wn3d, dud3) o più camuffati (bins, lpr) ma se hanno a disposizione una shell che non dovrebbero avere e, soprattutto, se non si conosce il motivo della loro presenza, bisogna subito allertarsi e verificare. Non è detto che un cracker abbia bisogno di crearsi un nuovo utente per tornare sul sistema, ma se succede è evidente dimostrazione di una avvenuta intrusione.
Interfacce di rete promiscue indicano nella maggior parte dei casi che qualcuno sta provando a sniffare il traffico di rete e, per individuare anche i pacchetti non direttamente indirizzati alla macchina locale, mettono l'interfaccia di rete in "promiscuous mode". Analogamente una doppia entry nella arp cache con lo stesso IP che risulta appartenere a 2 diversi Mac Address, è sintono di una probabile attività non lecita di arp spoofing.

Logwatch: Installazione e configurazione

Logwatch è uno degli strumenti di log monitoring più interessanti fra quelli disponibili nel panorama opensource:
- E' modulare, permettendo customizzazione, adattamente ed estensioni;
- Si installa facilmente e su alcune distribuioni è operativo ed efficace senza alcuna necessità di configurazione post-installazione

La sua modalità di funzionamento non è in real-time: quando viene eseguito processa i log e invia una mail di report (di default a root), per cui si presta ad essere crontabbato, con tutte le limitazioni, in termini di sicurezza, del caso: se un intrusore fa in tempo a modificare i log e cancellare le sue tracce, LogWatch non si accorge di nulla. Si accorge però di tentativi di Intrusione, di attività sul sistema (anche legittime, di cui comunque è bene avere traccia) e di eventi anomali.

INSTALLAZIONE
Logwatch è composto fondamentalmente da script Perl e file di configurazione, non richiede ricompilazioni o adattamenti particolari a seconda della piattaforma, se non la configurazione sulla posizione e i nomi dei file di log.
Se si installa tramite RPM, LogWatch è immediatamente operativo e non richiede ulteriori interventi di configurazione. Installa i seguenti file:
[root@socrate /]# rpm -ql logwatch
/etc/cron.daily/00-logwatch E' un link simbolico a /etc/log.d/scripts/logwatch.pl, che di fatto è il programma vero e proprio, che quindi viene eseguito ogni giorno (comando logwatch senza particolari argomenti)
/etc/log.d La directory che contiene tutto "il mondo logwatch"
/etc/log.d/conf Directory che contiene i file di configurazione
/etc/log.d/conf/logfiles Directory che contiene le configurazioni per i singoli tipi di log
/etc/log.d/conf/logfiles/cron.conf [...]
/etc/log.d/conf/logwatch.conf File di configurazione generale, imposta tutti i parametri standard che vengono usati quando il comando logwatch viene lanciato senza argomenti
/etc/log.d/conf/services Directory che contiene le configurazioni per i tipi di servizi
/etc/log.d/conf/services/automount.conf [...]
/etc/log.d/logwatch Link al programma logwatch: /etc/log.d/scripts/logwatch.pl
/etc/log.d/logwatch.conf Link al file di configurazione: /etc/log.d/conf/logwatch.conf
/etc/log.d/scripts Directroy che contiene tutti i script Perl di logwatch e i suoi moduli
/etc/log.d/scripts/logfiles directory che contiene script per la gestione di file di log specifici
/etc/log.d/scripts/logfiles/samba [...]
/etc/log.d/scripts/logwatch.pl Il programma logwatch vero e proprio. Il fatto che esista il link /usr/sbin/logwatch fa in modo che possa essere evocato semplicemente scrivendo "logwatch"
/etc/log.d/scripts/services Directory con i filtri modulari per il parsing di specifici servizi
/etc/log.d/scripts/services/automount [...]
/etc/log.d/scripts/shared Directory che contiene i filtri comuni per tutti i servizi e tipi di log
/etc/log.d/scripts/shared/applystddate [...]
/usr/sbin/logwatch Link al programma logwatch: /etc/log.d/scripts/logwatch.pl
/usr/share/doc/logwatch-2.6 Directory con la Documentazione ufficiale
/usr/share/doc/logwatch-2.6/CHANGES [...]
/usr/share/man/man8/logwatch.8.gz Pagine del man di logwatch

Se si ha a disposizione il tar.gz di logwatch, l'installazione è ugualmente semplice:
- Scompattare il tarball;
- Copiare tutto il contenuto della directory creata in /etc/log.d (Se si cambia la directory di default, si deve cambiare la variabile $BaseDir all'inizio di logwatch.pl;
- Editare, se si vuole il file di configurazione generale logwatch.conf;
- Crontabbare, secondo la frequenza che si desidera, l'esecuzione di logwatch.pl (senza particolari argomenti).

CONFIGURAZIONE
Il file di configurazione generale /etc/log.d/logwatch.conf è piuttosto chiaro e prevede alcune opzioni interessanti, che possono essere sovrascritte dalla riga di comando. Seguono le impostazioni di default, che vanno bene in molti casi:
LogDir = /var/log Directory di default dove risiedono i log
MailTo = root A chi vengono inviate le mail di logwatch, può essere un utente locale o un normale indirizzo email
Print = No Se settato a Yes, l'output di logwatch viene visualizzato a schermo invece di essere inviato via mail
# Save = /tmp/logwatch Se impostato, l'output viene salvato sul file indicato invece di essere inviato via mail
# Archives = Yes Specifica se cercare anche nei file di log archiviati (anche gzippati) come /var/log/messages.1 o /var/log/messages.1.gz
Range = yesterday Indica su quale periodo fare l'analisi dei log: "All" analizza tutti i log (in questo caso si consiglia di impostare "Archives = Yes", "Yesterday" si riferisce ai log del giorno prima (utile quando si crontabba un esecuzione notturna), "Today" si riferisce alle righe di log relative al giorno corrente.
Detail = Low Livello di dettaglio dei report. Può essere "Low", "Med", "High"
Service = All Definisce per quali servizi verificare i log. Può essere "All" o uno o più servizi, da scrivere su più righe, come "pam_pwdb" e "ftpd-messages"
# LogFile = messages Specifica un singolo file di log da analizzare. Se "Service = All" vengono comunque analizzati tutti i log

UTILIZZO
La modalità di utilizzo tipica è l'esecuzione in crontab del semplice comando logwatch (su varie distribuzioni è un link simbolico /etc/log.d/scripts/logwatch.pl) che si basa sulle impostazioni generali nel file di configurazioni. Per test o controlli straordinari si possono comunque passare alcuni argomenti alla command line:

logwatch --print --detail High --archives --range All
Stampa a video (--print) invece che inviare via mail, con il massimo dettaglio (--detail High), includendo anche i log archiviati (--archives) tutti i messaggi di ogni data (--range All)

logwatch --save logwatch.txt --range Today
Salva sul file logwatch.txt (--save logwatch.txt) l'output relativo alla giornata corrente (--range Today), usando per gli altri paramentri le impostazioni definite nel file di configurazione.

Installazione SNORT

Snort è uno dei numerosi strumenti di rilevazione del traffico di rete per individuare e segnalare intrusioni.

Snort è stato progettato per funzionare in 3 modi differenti:
-Sniffer intercetta i pacchetti che viaggiano nella rete e li visualizza in console.
-Packet Logger salva su disco locale i pacchetti
-Network Intrusion Detection analizza il traffico di rete attraverso delle regole customizzabili ed esegue operazioni configurabili in caso di corrispondenza.

INSTALLAZIONE DI SNORT

L'installazione base di SNORT prevede come unico requisito di sistema la presenza delle libpcap (librerie per la cattura di pacchetti).

[root@GIOVE snort-1.9.0]# ./configure
loading cache ./config.cache
checking for a BSD compatible install... (cached) /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) yes
........

[root@GIOVE snort-1.9.0]# make
cd . && /root/snort/snort-1.9.0/missing autoheader
.....

[root@GIOVE snort-1.9.0]# make install
Making install in src
make[1]: Entering directory `/root/snort/snort-1.9.0/src'
.......

Snort è ora installato sul sistema in /usr/local/bin/snort.

[root@GIOVE snort]# snort -?
Initializing Output Plugins!

-*> Snort! <*-
Version 1.9.0 (Build 209)
By Martin Roesch ([email protected], www.snort.org)
USAGE: snort [-options] <filter options>

Utilizzo di SNORT come SNIFFER

SNORT può essere utilizzato come un normale packet sniffer per visualizzare il traffico di rete.

snort [-opzioni] < filtri >
Come ogni sniffer è possibile creare filtri in modo da monitorare solo certi tipi di pacchetti o interfacce.

Con snort -v  (verbose mode) si visualizzano gli header dei pacchetti, con snort -dev
si visualizzano sia i dati che gli header dei pacchetti.

[root@GIOVE root]# snort  -v
Initializing Output Plugins!
Log directory = /var/log/snort

Initializing Network Interface eth0

        --== Initializing Snort ==--
Decoding Ethernet on interface eth0

        --== Initialization Complete ==--

-*> Snort! <*-
Version 1.9.0 (Build 209)
By Martin Roesch ([email protected], www.snort.org)
03/04-11:47:04.995500 10.0.5.16:22 -> 10.0.5.95:33227
TCP TTL:64 TOS:0x10 ID:26313 IpLen:20 DgmLen:132 DF
***AP*** Seq: 0x14F186E3  Ack: 0x13A910FF  Win: 0x25B0  TcpLen: 32
TCP Options (3) => NOP NOP TS: 51224596 4732590
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

03/04-11:47:04.995841 10.0.5.16:22 -> 10.0.5.95:33227
TCP TTL:64 TOS:0x10 ID:26314 IpLen:20 DgmLen:132 DF
***AP*** Seq: 0x14F18733  Ack: 0x13A910FF  Win: 0x25B0  TcpLen: 32
TCP Options (3) => NOP NOP TS: 51224596 4732590
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Utilizzo di SNORT come PACKET LOGGER

Attraverso le opzioni del comando snort è possibile salvare su disco i pacchetti catturati da snort per poterli analizzare  in un tempo successivo.

snort -dv -l /var/log/snort
dove /var/log/snort è una directory. Al suo interno verranno create diverse sottodirectory, con nomi corrispondenti agli indirizzi IP trovati nei pacchetti analizzati.

Nel caso su operi su reti ad alta velocità con l'opzione -b si imposta un logging più veloce (formato di tcpdump):
snort -dv -l /var/log/snort -b

con l'opzione -h (home network) si definisce la network di cui loggare i pacchetti:
snort -dev -l /var/log/snort -h 192.168.0.0/24

Utilizzo di SNORT come NIDS

Un NIDS (Network Intrusion Detection Systems) è un sistema di monitoring di traffico di rete, volto ad individuare pattern di pacchetti potenzialmente ostili in risposta ai quali possono essere eseguite determinate azioni (notifica via mail, chiusura di una connessione, logging su un database ecc.).
Snort presenta vari modi per essere configurato come NIDS.

Innanzitutto prevede 3 tipi principali di regole:
-ALERT invia messaggi ad ogni infrazione;
-PASS non considera il pacchetto;
-LOG visualizza/scrive le informazioni del pacchetto;

Lo standard di Snort è stampare a video i messaggi di alert ma è possibile utilizzare altre modalita':
-full, visualizza l'intero messaggio
-fast, logging rapido dei messagggi
-unsock, invio dei messaggi ad un socket unix
-syslog, scrittura dei messaggi nel syslog di sistema
-smb messages, invio di messaggi di alert ad altri host tramite samba
-none, non invia nessun messaggio

Per le opzioni full,fast,unsock e none è necessario anteporre il comando -A mentre con -s i messaggi di alert vengono inviati al syslog. Per abilitare a Snort l'invio di messaggi tramite il samba client, una sorta di Winpopup, è necessario aggiungere l'opzione "--enable-smbalerts" in fase di installazione di Snort.

snort -c snort.conf -l /var/log/snort -h 192.168.0.0/24
salva i log nella dir /var/log/snort prendendo in considerazione la rete 192.168.0.0/24

snort -c snort.conf -b -h 192.168.0.0/24 -M HOSTS
salva i dati in modalità tcpdump (meno informazioni ma più veloce), invia gli alert alle workstation windows

snort -c /etc/snort.conf -l /var/log/snort -h 10.1.0.0/24 -aIe -D
mostra i pacchetti ARP, aggiunge il nome interfaccia al log, mostra il layer secondario del pacchetto e con -D agisce come demone senza occupare una shell

Introduzione e installazione di Tripwire

Tripwire è un tipo di Intrusion Detection System, il suo lavoro è quello di verificare lo stato di determinati file rispetto ad uno stato di partenza (baseline). Una modifica non prevista di questo stato può essere indice della compromissione del sistema e della manipolazione non autorizzata di comandi, log o file di configurazione.
Esistono due versioni di Tripwire, una commerciale ed una Open Source.

Come punto di partenza Tripwire crea un database con all'interno una "fotografia" dei file del sistema in uno stato che iniziale che viene considerato sicuro. D'ora in poi Tripwire sarà in grado di controllare se ci sono state modifiche (nel contenuto, nella data di modifica, nei permessi, negli attributi...) o cancellazioni dei file presi in considerazione informando l'amministratore di sistema attraverso un rapporto.
Se le modifiche sono legittime, perchè dovute a normale attività del sistema, l'amministratore può aggiornare la baseline del database di Tripwire inglobando il nuovo status, altrimenti se le modifiche non vengono ritenute valide l'amministratore può immediatamente verificare quali componenti sono stati alterati.
Tripwire permette inoltre di criptare i suoi file di configurazione rendedoli modificabili solo attraverso l'inserimento di password creata in fase di installazione.
Sono richieste due password:
- la site password, di carattere generale, utilizzata per il file di configurazione e policies; può essere utlizzata per altre macchine esportando il file site.key
- la local password per il file database e i report

INSTALLAZIONE
Installazione di Tripwire tramite rpm:
[root@giove root]# rpm -ivh tripwire-2.3.1-14.i386.rpm
Preparing...                ########################################### [100%]
   1:tripwire               ########################################### [100%]

Directory create:
/var/lib/tripwire ---> directory in cui verranno memorizzati i rapporti e il database di sistema
/etc/tripwire     ---> si trovano i file di configurazione e le key di codifica

Post-Install
Per completare l'installazione è necessario eseguire lo script  twinstall.sh (nella dir /etc/tripwire/) il quale crea le password dei file di configurazione e produce le key di codifica  
[root@giove tripwire]# ./twinstall.sh

----------------------------------------------
The Tripwire site and local passphrases are used to
sign a variety of files, such as the configuration,
policy, and database files.

Passphrases should be at least 8 characters in length
and contain both letters and numbers.

See the Tripwire manual for more information.

----------------------------------------------
Creating key files...

(When selecting a passphrase, keep in mind that good passphrases typically
have upper and lower case letters, digits and punctuation marks, and are
at least 8 characters in length.)
# Richiede l'inserimento della site password
Enter the site keyfile passphrase:
......
# Richiede l'inserimento della local password
Enter the local keyfile passphrase:
Verify the local keyfile passphrase:

FILE di CONFIGURAZIONE
I file di configurazione sono:
tw.cfg (criptato) vengono memorizzati i dati riguardanti la locazione dei file di configurazione e i paramentri per l'invio di email (twcfg.txt file di esempio non criptato).

tw.pol (criptato) file in cui viene specificata la modalità di funzionamento di Tripwire e le policy di controllo. Sono elencati i file da monitorare e il livello di "criticità" a loro assegnato (twpol.txt è un esempio non criptato).

INIZIALIZZAZIONE del SISTEMA
I file di configurazione e dati di Tripwire sono per sicurezza criptati, la loro modifica è possibile attraverso comandi che creano un file di testo relativo al file da modificare.

- Modifica del file tw.cfg:
[root@GIOVE tripwire]# twadmin --print-cfgfile > conf.txt
In questo modo viene creato il file conf.txt dove saranno leggibili i parametri di configurazione di Tripwire.

Per validare le modifiche effettuate sul file è necessario creare il nuovo file di configurazione specificando la "site key":
[root@GIOVE tripwire]# twadmin --create-cfgfile --site-keyfile /etc/tripwire/site.key conf.txt
Please enter your site passphrase:
Wrote configuration file: /etc/tripwire/tw.cfg
Le modifiche al file di configurazione sono ora attive.

- Creare il file tw.pol (file delle policies):
Prima di modificare le policy di tripwire bisogna creare il file da editare utlizzando il file tw.pol standard:
[root@GIOVE tripwire]# twadmin --print-polfile tw.pol > polfile.txt

Ora è possibile editare il file polfile.txt secondo le proprie necessità. Per rigeneraere il tw.pol definitivo si usa il comando:
[root@GIOVE tripwire]# tripwire --create-polfile polfile.txt

- Creare il database di sistema
Nel database di sistema verranno introdotti tutte le voci riguardanti i file da controllare secondo il file di configurazione tw.pol
[root@GIOVE tripwire]# tripwire --init
Please enter your local passphrase:
Incorrect local passphrase. # Ops!
Please enter your local passphrase:
Parsing policy file: /etc/tripwire/tw.pol
Generating the database...
*** Processing Unix File System ***
Performing integrity check...
Nel caso alcuni file specificati in tw.pol non esistono il comando visualiza messaggi di errori
### Warning: File system error.
### Filename: /var/lock/subsys/portmap
### No such file or directory
### Continuing...
### Warning: File system error.
### Filename: /var/lock/subsys/httpd
### No such file or directory
.....
# la locazione del file database è definita nel file di configurazione tw.cfg
Wrote database file: /var/lib/tripwire/GIOVE.twd
The database was successfully generated.

Tripwire è ora configurato, inizializzato e pronto per essere eseguito ed eventualmente schedulato per eseguire dei report sulle modifiche dei file del sistema:
[root@GIOVE tripwire]# tripwire --check

/etc/tripwire/tw.pol

tw.pol è il file delle regole di Tripwire criptato.

Con il seguente comando si crea una copia del file in formato testo:
[root@GIOVE tripwire]# twadmin  -m p > twpol.txt

Una volta modificato twpol.txt ad hoc ecco i comandi per implementare le modifiche:
- nel caso in cui si voglia ricreare il file (opzione che necessita la rinizializzazione del database):
[root@GIOVE tripwire]# twadmin -m P twpol.txt
Please enter your site passphrase:
Wrote policy file: /etc/tripwire/tw.pol

- nel caso in cui si voglia aggiornare il file:
[root@GIOVE tripwire]# tripwire -m p twpol.txt                                            
Parsing policy file: /etc/tripwire/twpol.txt
Please enter your local passphrase:
Please enter your site passphrase:
======== Policy Update: Processing section Unix File System.
======== Step 1: Gathering information for the new policy.
[...]
======== Step 2: Updating the database with new objects.
======== Step 3: Pruning unneeded objects from the database.
Wrote policy file: /etc/tripwire/tw.pol
Wrote database file: /var/lib/tripwire/GIOVE.twd

/etc/tripwire/tw.cfg

tw.cfg è il file di configurazione criptato di Tripwire.

twadmin -m f > twcfg.txt è il comando per creare una copia del file in formato testo. Dopo la sua modifica è possibile ricreare il file tw.cfg con twadmin -m F -S /etc/tripwire/site.key twcfg.txt

[root@GIOVE tripwire]# cat twcfg.txt
# Dichiarazione della locazione degli eseguibili e dei file di configurazione
ROOT                   = /usr/sbin
POLFILE                = /etc/tripwire/tw.pol
DBFILE                 = /var/lib/tripwire/$(HOSTNAME).twd
REPORTFILE             = /var/lib/tripwire/report/$(HOSTNAME)-$(DATE).twr
SITEKEYFILE            = /etc/tripwire/site.key
LOCALKEYFILE           = /etc/tripwire/$(HOSTNAME)-local.key
# Percorso dell'editor utilizzato per interagire con tripwire
EDITOR                 = /bin/vi
# Se vera lascerà la password in memoria il minor tempo possibile
LATEPROMPTING          = false
# Impostazione per evitare il ripetersi di entry all'interno del report
LOOSEDIRECTORYCHECKING = false
# Non invia mail nel caso non siano state trovate violazioni nel check
MAILNOVIOLATIONS       = true
# Livello di dettagli nell'email; max 4
EMAILREPORTLEVEL       = 4
# Livello di dettagli nel file report; max 4
REPORTLEVEL            = 4
# Metodo di invio mail: connessione a un SMTP remoto o SENDMAIL locale
MAILMETHOD             = SMTP
# Opzioni in caso si scelga SMTP come metodo
SMTPHOST               = mail.dominio.it
SMTPPORT               = 25
# Caso metodo SENDMAIL: comando da eseguire per inviare email
#MAILPROGRAM            = /usr/sbin/sendmail -oi -t
# Inserisce nel syslog tutti i messaggi di tripwire
SYSLOGREPORTING        = false

/etc/cron.daily/tripwire-check

Tripwire-check è lo script inserito, durante l'installazione tramite RPM su distribuzioni Linux basate su RedHat, nel cron per effettuare ogni giorno un controllo Tripwire del sistema.

#!/bin/sh
HOST_NAME=`uname -n`
if [ ! -e /var/lib/tripwire/${HOST_NAME}.twd ] ; then
        echo "****    Error: Tripwire database for ${HOST_NAME} not found.    ****"
        echo "**** Run "/etc/tripwire/twinstall.sh" and/or "tripwire --init". ****"
else
#verifica del file di configurazione ed esecuzione del check con invio del report via email tramite l'opzione --email-tripwire
        test -f /etc/tripwire/tw.cfg &&  /usr/sbin/tripwire --check --email-report
fi

L'indirizzo e-mail del destinatario deve essere specificato nel file tw.pol che contiene anche tutte le regole per il controllo dei file locali.

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=&quot;paranoid&quot;
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.