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:
- workstation
- server (default)
- 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="shishii@shishii.com"
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
MAILTO=shishii@shishii.com
@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.
