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:

# apt-get install logcheck

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 e group: adm.

Se si effettua l’istallazione manuale bisogna ricordarsi di creare prima l’utente “logcheck”, ad esempio:

# useradd -c “Utente logcheck” -d /var/lib/logcheck <  -s /bin/false logcheck

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:

DATE=”$(date +’%Y-%m-%d %H:%M’)”

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”.

SENDMAILTO=”[email protected]”

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/syslog
/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 e group: adm sarà necessario che come minimo i file di log abbiano:

-rw-r—  1 root adm  6088 Mar 20 15:18 <file di log>

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:

# /etc/cron.d/logcheck: crontab entries for the logcheck package
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
[email protected]
@reboot         logcheck    if [ -x /usr/sbin/logcheck ]; then 
     nice -n10 /usr/sbin/logcheck -R; 
fi
2 * * * *       logcheck    if [ -x /usr/sbin/logcheck ]; then 
     nice -n10 /usr/sbin/logcheck; 
fi
# EOF

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:

0,15,30,45 * * * *  logcheck if [ -x /usr/sbin/logcheck ]; then 
     nice -n10 /usr/sbin/logcheck; 
fi

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:

<host> <data> <tipo> Events

ad esempio:

cobalt 2005-03-19 19:24 System Events

dove: host è il nome della macchina su cui lavora logcheck; data è la la data del report e tipo il tipo di evento, che può essere System (report riguardante delle vicende del sistema, per esempio 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 può essere questa:

Security Events =-=-=-=-=-=-=-=
Mar 14 07:53:05 cobalt sshd[4617]: input_userauth_request: illegal user jordan
Mar 14 07:53:05 cobalt sshd[4617]: Failed password for illegal user jordan from 216.32.84.202 port 36462 ssh2
Mar 14 07:53:08 cobalt sshd[4618]: input_userauth_request: illegal user michael
Mar 14 07:53:08 cobalt sshd[4618]: Failed password for illegal user michael from 216.32.84.202 port 36517 ssh2
….
Mar 14 07:53:05 cobalt sshd[4617]: Illegal user jordan from 216.32.84.202
Mar 14 07:53:05 cobalt sshd[4617]: error: Could not get shadow information for NOUSER
Mar 14 07:53:06 cobalt sshd[4617]: Received disconnect from 216.32.84.202: 11: Bye Bye
Mar 14 07:53:08 cobalt sshd[4618]: Illegal user michael from 216.32.84.202
Mar 14 07:53:08 cobalt sshd[4618]: error: Could not get shadow information for NOUSER
Mar 14 07:53:08 cobalt sshd[4618]: Received disconnect from 216.32.84.202: 11: Bye Bye

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:

System Events
=-=-=-=-=-=-=
Mar 16 11:40:48 cobalt sshd[3918]: Connection closed by 218.108.29.74

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.