Product SiteDocumentation Site

14.3. Supervisione: prevenire, rilevare, dissuadere

Il monitoraggio è parte integrante di ogni politica di sicurezza per svariati motivi. Tra questi, il fatto che l'obiettivo della sicurezza non è solitamente limitato soltanto alla garanzia della confidenzialità dei dati, ma include anche assicurare la disponibilità dei servizi. È quindi d'obbligo verificare che tutto funzioni come previsto, e rilevare in maniera tempestiva ogni comportamento anomalo o variazione nella qualità del servizio erogato. L'attività di monitoraggio permette di evidenziare tentativi di intrusione e permette di reagire rapidamente prima che si possa arrivare a gravi conseguenze. Questa sezione passa in rassegna alcuni strumenti che possono essere usati per monitorare molti degli aspetti di un sistema Debian. Pertanto completa la sezione dedicata al monitoraggio dei sistemi generici in Capitolo 12, Amministrazione avanzata.

14.3.1. Monitorare i log con logcheck

Il comando logcheck monitora i file di log ogni ora per impostazione predefinita. Invia messaggi di log inconsueti via email all'amministratore per analisi più approfondite.
La lista dei file monitorati è salvata in /etc/logcheck/logcheck.logfiles; i valori predefiniti funzionano bene se il file /etc/syslog.conf non è stato completamente stravolto.
logcheck lavora in uno di tre modi più o meno dettagliati: paranoid, server e workstation. Il primo è molto prolisso, e dovrebbe essere usato solo per server specifici come i firewall. Il secondo modo (predefinito) è consigliato per la maggior parte dei server. L'ultimo è progettato per le workstation, ed è ancora più conciso (filtra maggiormente i messaggi).
In tutti e tre i casi, logcheck probabilmente dovrà essere personalizzato escludendo alcuni messaggi extra (a seconda dei servizi installati), a meno che l'amministratore non voglia veramente ricevere ammassi orari di lunghe e noiose email. Poiché il meccanismo di selezione dei messaggi è piuttosto complesso, il file /usr/share/doc/logcheck-database/README.logcheck-database.gz è una lettura consigliata, anche se impegnativa.
Le regole applicate possono essere suddivise in varie tipologie:
  • quelle che qualificano il messaggio come un tentativo di intrusione (memorizzato in un file nella directory /etc/logcheck/cracking.d/);
  • quelle che cancellano tale qualifica (/etc/logcheck/cracking.ignore.d/);
  • quelle che classificano il messaggio come un allarme di sicurezza (/etc/logcheck/violations.d/);
  • quelle che cancellano questa classificazione (/etc/logcheck/violations.ignore.d/);
  • infine, quelle che si applicano ai rimanenti messaggi (considerati come eventi di sistema).
Un evento di sistema è sempre segnalato a meno che una regola in una directory /etc/logcheck/ignore.d.{paranoid,server,workstation}/ stabilisca che l'evento debba essere ignorato. Le sole directory prese in considerazione sono esclusivamente quelle corrispondenti ad un livello di prolissità maggiore o uguale alla modalità di funzionamento selezionata.

14.3.2. Attività di monitoraggio

14.3.2.1. In tempo reale

top è uno strumento interattivo che mostra l'elenco dei processi attualmente in esecuzione. L'ordinamento predefinito è basato sull'utilizzo corrente del processore e può essere ottenuto con il tasto P. Altri tipi di ordinamento sono per occupazione di memoria (tasto M), per tempo totale di processore (tasto T) e per identificatore di processo (tasto N). Il tasto r permette il renice di un processo, cioè la variazione della sua priorità.
Quando il sistema sembra essere sovraccarico, top è uno strumento fondamentale per capire quali processi competono per il tempo di processore o consumano troppa memoria. In particolare, spesso è interessante controllare se il processo che utilizza le risorse corrisponde realmente ad un servizio che la macchina mette a disposizione. Un processo sconosciuto in esecuzione con utente www-data dovrebbe subito saltare all'occhio ed essere controllato, dato che potenzialmente potrebbe essere l'istanza di un programma installato ed eseguito nel sistema attraverso la vulnerabilità di un'applicazione web.
top è uno strumento molto flessibile e le pagine del manuale riportano i dettagli di come modificarne la visualizzazione e adattarla alle abitudini e bisogni personali.
Gli strumenti grafici gnome-system-monitor e qps sono simili a top e forniscono più o meno le stesse caratteristiche.

14.3.2.2. Storico

Il carico del processore, il traffico di rete e lo spazio libero su disco sono informazioni che variano costantemente. Mantenere uno storico della loro evoluzione spesso è utile nel determinare esattamente come viene utilizzato un computer.
Esistono molti strumenti dedicati a questo compito. La maggior parte può recuperare dati via SNMP (Simple Network Management Protocol) al fine di centralizzare l'informazione. Un ulteriore beneficio è che si possono recuperare dati da elementi di rete che non necessariamente sono computer generici, come ad esempio switch di rete o router dedicati.
Questo libro si occupa di Munin in dettaglio (vedere Sezione 12.4.1, «Impostazione di Munin») come parte del Capitolo 12: «Amministrazione avanzata». Debian fornisce anche un altro strumento simile, cacti. La sua installazione è leggermente più complessa, poiché si basa solo su SNMP. Pur disponendo di un'interfaccia web, capire i concetti coinvolti nella configurazione richiede ancora qualche sforzo. Leggere la documentazione (/usr/share/doc/cacti/html/index.html) è considerato un prerequisito.

14.3.3. Rilevare le modifiche

Una volta che il sistema è installato e configurato, a meno di aggiornamenti di sicurezza, la maggior parte dei file e directory rimangono statici, dati a parte. È allora interessante fare in modo che i file realmente non possano cambiare: ogni variazione inattesa dovrebbe perciò catturare la nostra attenzione. Questa sezione presenta alcuni strumenti che permettono di monitorare i file e di avvisare l'amministratore quando si verificano cambiamenti non previsti (o semplicemente di elencarli).

14.3.3.1. Controllo dei pacchetti: debsums e i suoi limiti

debsums è uno strumento interessante perché permette di rilevare quali file installati sono stati modificati (potenzialmente da un autore di un attacco), anche se questo dev'essere preso con le pinze. Primo, perché non tutti i pacchetti Debian forniscono le impronte digitali richieste da questo programma (quando esistono si trovano in /var/lib/dpkg/info/pacchetto.md5sums). Promemoria: l'impronta digitale è un valore, spesso numerico (anche se in notazione esadecimale), che contiene una specie di firma del contenuto di un file. Questa firma è calcolata con un algoritmo (MD5 oppure SHA1 sono gli esempi più diffusi) che garantisce con buona probabilità che anche il più piccolo cambiamento nel contenuto del file porti ad una variazione nell'impronta digitale; è conosciuto come «effetto valanga». Ciò permette di usare un'impronta numerica semplice per verificare se il contenuto di un file è stato alterato. Questi algoritmi non sono reversibili; in altre parole, per la maggior parte di questi, conoscere un'impronta digitale non permette di ricavarne il contenuto corrispondente. Recenti progressi matematici sembra abbiano però indebolito la sicurezza di questi principi, ma il loro uso finora non è stato messo in discussione, dal momento che sembra ancora piuttosto difficile creare contenuti differenti con la stessa impronta digitale.
Oltretutto, i file md5sums vengono memorizzati nei dischi fissi; un autore minuzioso di un attacco perciò aggiornerà questi file in modo che contengano le nuove impronte per i file modificati.
Il primo inconveniente può essere evitato chiedendo a debsums di basare i suoi controlli su un pacchetto .deb invece di affidarsi al file md5sums. Ma questo richiede di scaricare preventivamente i corrispondenti file .deb:
# apt-get --reinstall -d install `debsums -l`
[ ... ]
# debsums -p /var/cache/apt/archives -g
È anche interessante notare che, nella configurazione predefinita, debsums genera automaticamente i file md5sums mancanti quando un pacchetto viene installato tramite APT.
Il secondo problema può essere evitato in maniera analoga: il controllo viene semplicemente basato su un file .deb vergine. Poiché ciò implica di avere tutti i file .deb dei pacchetti installati, ed essere sicuri della loro integrità, la soluzione più semplice è di appoggiarsi ad un mirror Debian. Questa operazione talvolta può essere lenta e noiosa, e non dovrebbe essere una tecnica proattiva da utilizzare sempre e in modo automatico.
# apt-get --reinstall -d install `grep-status -e 'Status: install ok installed' -n -s Package`
[ ... ]
# debsums -p /var/cache/apt/archives --generate=all
Da notare che questo esempio utilizza il comando grep-status del pacchetto dctrl-tools, che non è installato in modo predefinito.

14.3.3.2. Monitorare i file: AIDE

Lo strumento AIDE (Advanced Intrusion Detection Environment) permette di verificare l'integrità dei file e rileva tutti i cambiamenti rispetto ad una immagine valida archiviata del sistema. Questa immagine viene memorizzata in un database (/var/lib/aide/aide.db) contenente le informazioni significative di tutti i file del sistema (impronte digitali, permessi, data e ora e così via). Questo database viene generato inizialmente con aideinit; esso viene poi utilizzato su base giornaliera (dallo script /etc/cron.daily/aide) per verificare che non sia cambiato nulla di significativo. Quando viene rilevata una modifica, AIDE la elenca nei file di log (/var/log/aide/*.log) e invia i risultati via email all'amministratore.
Sono presenti molte opzioni in /etc/default/aide per modificare il comportamento del pacchetto aide. La configurazione vera e propria di AIDE viene memorizzata in /etc/aide/aide.conf e /etc/aide/aide.conf.d/ (in realtà, questi file vengono utilizzati da update-aide.conf per generare /var/lib/aide/aide.conf.autogenerated). La configurazione indica quali proprietà di quali file devono essere controllate. Per esempio, il contenuto dei file di log cambia regolarmente, e tali cambiamenti possono essere ignorati fino a quando i permessi di questi file rimangono invariati, ma sia il contenuto che i permessi dei programmi eseguibili devono rimanere costanti. Anche se non molto complessa, la sintassi della configurazione non è del tutto intuitiva, ed è quindi consigliato leggere la pagina di manuale aide.conf(5).
Una nuova versione del database è generata giornalmente in /var/lib/aide/aide.db.new; se tutte le variazioni raccolte sono legittime, viene usato per sostituire il database di riferimento.

14.3.4. Rilevare intrusioni (IDS/NIDS)

snort (nel pacchetto Debian con lo stesso nome) è un NIDS: un Network Intrusion Detection System. La sua funzione è quella di mettersi in ascolto sulla rete e cercare di rilevare tentativi di infiltrazione o atti ostili (inclusi attacchi «denial of service»). Tutti questi eventi vengono raccolti e inviati su base giornaliera all'amministratore attraverso un riassunto delle ultime 24 ore.
La configurazione consiste nel descrivere l'intervallo di indirizzi che la rete locale ricopre. In pratica, questo intervallo individua l'insieme degli obiettivi del potenziale attacco. Altri parametri importanti vengono configurati tramite dpkg-reconfigure snort, compresa l'interfaccia di rete da monitorare. Questa spesso sarà eth0 per una connessione Ethernet, ma esistono altre possibilità come ppp0 per una connessione ADSL o PSTN (Public Switched Telephone Network, le care vecchie connessioni dialup), oppure anche wlan0 per alcune schede di rete wireless.
Il file di configurazione di snort (/etc/snort/snort.conf) è molto corposo, e i ricchi commenti inclusi descrivono ogni direttiva in ampio dettaglio. Per trarne vantaggio al meglio è necessario leggerlo tutto e poi adattarlo al singolo caso. Per esempio, indicare quali macchine ospitano quali servizi riesce a ridurre il numero di episodi che snort riporterà, visto che un attacco «denial of service» su una macchina desktop è molto meno critico rispetto ad uno su un server DNS. Un'altra interessante direttiva permette di memorizzare la corrispondenza tra indirizzi IP e MAC (questi ultimi identificano univocamente una scheda di rete), così da poter rilevare gli attacchi di ARP spoofing attraverso i quali una macchina compromessa cerca di mascherarsi come un'altra, ad esempio un server cruciale.