Logcheck: scoprire le intrusioni attraverso i file di log

Introduzione

Salvo rare eccezioni, qualunque attacco ad un sistema informatico
si svolge attraverso una fase preparatoria. Questa è necessaria per
l'attaccante per conoscere il sistema, trovare le falle e studiare
il metodo migliore per violarlo.

In questa fase l'attaccante è in posizione di svantaggio, infatti
rischia di essere scoperto e non accorgersene neanche. Una volta penetrato,
invece, è l'attaccante ad avere tutti i vantaggi, una volta penetrato,
se non è uno sprovveduto può fare di tutto, a maggior ragione se riesce
a guadagnare privilegi di root, per cui è necessario scoprirlo
prima!

Affinchè ciò sia possibile l'amministratore del sistema attaccato deve avere preso tutta una serie di precauzioni. Tra i tanti possibili interventi tesi a rafforzare il sistema vi è il monitoraggio delle varie attività, interne ed esterne. In questo campo si va da strumenti estremamente sofisticati e complessi come gli IDS (Introduction Detection System, tipo Snort per Linux), a strumenti molto più semplici ed immediati come gli analizzatori dei file di log. Ovviamente i primi offrono una protezione ben maggiore, ma richiedono mezzi e competenze molto superiori ai secondi.

Ovviamente, visto che i file di log in genere sono file di testo potrebbero essere consultati manualmente, leggendoli riga per riga, ma di fatto questo per un "sysadmin" è praticamente impossibile, soprattutto se si ha più di una macchina da controllare. Molto meglio disporre di applicativi che ci sottopongano solo le entry importanti.

Tra i vari tools per l'analisi dei file di log, ve ne è uno molto
semplice e veloce: Logcheck

Si tratta di script Perl e Bash che sono in grado di effettuare un'analisi dei file di log tenendo conto di una serie di regole di filtraggio e soprattutto memorizzando le entry già analizzate, in modo da non ripetere le segnalazioni. I report possono essere inviati via mail all'amministratore.

Installazione

Se usate una distribuzione Debian e derivate basterà digitare:

altrimenti si possono scaricare i sorgenti da qui http://alioth.debian.org/project/showfiles.php?group_id=30198.

Dopo di che basterà digitare:

# tar -xzvf logcheck-<versione>.tar.gz
# cd logcheck-<versione>
# make

Non è necessario il classico comando "make install" in quanto l'installazione avviene semplicemente come detto.

Si tenga presente che l'istallazione effettuata su una Debian tramite apt-get crea un utente "logcheck" appartenente al gruppo "adm", questo consente di fare girare logcheck con privilegi ridotti e allo stesso tempo di consentirgli la lettura dei file di log, che in genere in tale distribuzione hanno owner: root group: adm

Se si effettua l'istallazione manuale bisogna ricordarsi di creare prima l'utente "logcheck", ad esempio:

Configurazione

I file su cui intervenire sono i seguenti:

• /etc/logcheck/logcheck.conf
• /etc/logcheck/logcheck.logfiles
• /etc/logcheck/header.txt e /etc/logcheck/footer.txt
• /etc/cron.d/logcheck

Il file /etc/logcheck/logcheck.conf

Questo è il file di configurazione principale che consente di regolare
il comportamento di logcheck. Le opzioni più importanti sono le seguenti:

consente di impostare il formato della data che comparirà nell'oggetto della mail di avviso, per cambiarlo basta intervenire nella stringa tra gli apici singoli. Ad esempio per avere una data in formato italiano possiamo scrivere: '%H:%M %d/%m/%Y'.

REPORTLEVEL="server"

consente di impostare il livellodi accuratezza del filtro su tre livelli in maniera crescente:

1. workstation
2. server (default)
3. paranoid

Il sistema di filtro lavora in parte al contrario, nel senso che si
analizzano tutte le stringhe che riportano le keywords indicate nei
file contenuti nelle directory "cracking.d" e "violation.d"
e si escludono da quelle selezionate quelle che rispondono ai criteri
riportati nelle espressioni regolari contenute nei file inseriti
nelle directory "ignore".

Indirizzo a cui inviare le mail con i report.

Il file /etc/logcheck/logcheck.logfiles

Qui vanno elencati i file di log che vogliamo tenere sotto controllo
indicandoli uno per riga con il loro path completo, ad esempio:


/var/log/auth.log
/var/log/sulog

Bisogna assicurarsi che tali file siano leggibili al proprietario
di logcheck o al suo gruppo. Quindi se logcheck gira sotto owner:
logcheck group: adm

I file /etc/logcheck/header.txt e /etc/logcheck/footer.txt

Tramite questi due file possiamo impostare un'intestazione ed una chiusura
per il corpo della mail di report che arriverà all'amministratore.

Il file /etc/cron.d/logcheck

Questo file sostituisce l'inserimento in crontab per l'azionamento
temporizzato di logcheck, di default ha questo contenuto:

Per prima cosa vengono settate le due variabili d'ambiente "PATH"
e "MAILTO", ed è importante adattare la seconda in modo da essere
informati anche per gli eventuali malfunzionamenti.

La prima entry (@reboot...) dice al sistema di azionare logcheck subito dopo ogni riavvio.

La seconda entry (2 * * * *) dice al sistema di azionare logcheck
ogni ora al secondo minuto, quindi alle 00,02 alle 01,02 ecc.. Se
si volesse che logcheck fosse eseguito ogni quarto d'ora si può scrivere:

Report

Fatto quanto sopra avremo il nostro bell'analizzatore di log in funzione
e cominceranno ad arrivarci delle mail che avranno un oggetto di questo
tipo:

ad esempio:

cobalt 2005-03-19 19:24 System Events

dove: host data tipo
fermata e avvio servizi, ecc. che non necessariamente riguardano la
sicurezza), Security (report che riguardano direttamente la sicurezza, ma che non necessariamente costituiscono sintomo di attacco), Attack (eventi che indicano un attacco in corso).

Una tipica mail che segnala un Security Event

Si tratta di un tentativo di attacco al demone sshd tramite dizionario
condotto tramite un programma scritto in Perl chiamato "sshd_sentry.pl",
che ha anche una parte server "sshd_sentry_server.pl". Questo
tipo di attacco in genere viene lanciato alla cieca in rete alla ricerca
di qualche macchina a cui l'amministratore ha consentito di avere
degli account tipici con password prevedibili.

Questo non è un attacco molto pericoloso, ma comunque testimonia del
fatto che la presenza della nostra macchina è stata avvertita, per
cui bisognerà aumentare l'attenzione.

Più preoccupante potrebbe essere un messaggio del genere:

Cosa potrebbe significare? Potrebbe darsi che qualcuno ha effettuato una connessione tramite
ssh alla nostra macchina e l'ha chiusa prima ancora di loggarsi, oppure
potrebbe significare che è entrato nella macchina, ha fatto qualcosa,
ha cancellato i log presenti che indicavano la sua presenza, ed è
uscito, per cui è rimasta registrata solo quest'ultima operazione.

Ad ogni modo è opportuno, in entrambe i casi, segnalare all'ISP che
ha fornito l'IP in questione la cosa, infatti potrbbe trattarsi di
un cliente che sta abusando del servizio fornito, oppure di un server
"bucato" sotto il controllo dell'attaccante.

Conclusioni

Un analizzatore di log non è la panacea della sicurezza... tutt'altro...
è solo un inizio, ma se settato ed usato accortamente, magari abbinato
ad altri metodi di osservazione, come ad esempio l'attivazione del
logging di iptables, può essere utile per prevenire degli attacchi
di basso profilo, che comunque sono di gran lunga i più numerosi.
Per la mia esperienza oltre il 90% dei tentativi di penetrazione
sono fatti da lamer e script kiddies tramite l'uso di programmi e
script automatizzati, che tendono a "sparare nel mucchio" tanto
prima o poi una macchina senza nessuna protezione la trovano.