Copyright © 2001-2002 Gian Luca Matteucci
Please freely copy and distribute (sell or give away) this document in any format. It's requested that corrections and/or comments be forwarded to the document maintainer.
Use the information in this document at your own risk. I disavow any potential liability for the contents of this document. Use of the concepts, examples, and/or other content of this document is entirely at your own risk.
All copyrights are owned by their owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark.
Naming of particular products or brands should not be seen as endorsements.
You are strongly recommended to take a backup of your system before major installation and backups at regular intervals.
La versione aggionata di questo documento è disponibile in formato HTML o come sorgente SGML all'URL http://www.gmatte.net/pub/MY-HOWTO/.
Fino a che non troverò il tempo di tradurre in inglese questo HowTo, dubito che a qualcuno possa venire in mente di tradurlo. ;-)
Ogni eventuale commento può essere inviato al mio indirizzo: gianluca (at) gmatte (dot) net.
Una delle prime cose che un cracker fa dopo essere riuscito ad assumere il controllo di un sistema è, di solito, consiste nell'installare un qualche strumento per poter, in futuro, accedere liberamente al sistema e sostituire alcuni comandi per nascondere all'admin ogni sua attività. Alcuni di questi posono essere ps, top e altri che ora non mi vengono in mente. Altra usanza piuttosto diffusa è quella di sostituire i demoni standard con troian horse, sempre con lo scopo di ottenere libero accesso al sistema in futuro. Gli sniffer sono un'altra delle cose più comuni che si possono trovare su una macchina che ha subito un intrusione. Ovviamente tutto questo vale solo nel caso in cui il cracker sia riuscito ad ottenere i privilegi di root.
È molto difficile per l'admin sapere se e cosa è stato modificato dall'intruso. Un semplice portscan ci può dire se c'è qualche porta aperta che non dovrebbe esserlo, ma se il cracker avesse modificato, per esempio, sendmail, in questo modo non ce ne accorgeremmo.
Se non avete voglia o non potete seguire le indicazioni di questo How-To, potete utilizzare software come Tripwire, che potete trovare su www.tripwire.com. L'utilizzo di questo software esula dagli scopi di questo documento, quindi non si faranno altri riferimenti.
Tutto quello che ci serve è il comando md5sum che, nella Slackware, si trova nel pacchetto txtutils.
Per il resto utilizzeremo dei semplici shell script per sh.
Se vogliamo controllare cosa è stato modificato dopo un'intrusione, abbiamo bisogno inanzitutto di un riferimento sicuro con il quale fare un confronto. Le varie distribuzioni forniscono, insieme ad ogni pacchetto, un checksum che puo' essere utilizzato per verificare se il pacchetto in nostro possesso (preso, magari, dal CD di una rivista o masterizzato da un amico) corrisponde all'originale.
Questo procedimento verifica l'integrità del pacchetto, non dei singoli file che lo compongono, quindi non è adatto ai nostri scopi.
La prima cosa da fare è decidere quali file tenere d'occhio. Potremmo decidere di controllare tutti i file del nostro sistema, ma questa non è una buona idea per svariati motivi, fra i quali:
Per creare il checksum md5 di un file è sufficiente dare il comando:
md5sum file1
ottenendo come output qualcosa del tipo
d23b066e4cee929cd14b6e28236ed0c9 file1
oppure possiamo passare a md5sum un elenco di file:
md5sum *
ottenendo
356442aef07977a03d87c78b6b62adf0 file1 631056d771a0dfb2f04297b481af3039 file2 d23b066e4cee929cd14b6e28236ed0c9 file3 a05d0618a5491d02b8c9a5dcfc537f6d file4 7dff9ed4b09840d1bd87ef48d18ddf9f file5 b49d728330bf133c5483d634304397b3 file6
Dal momento che non penso ci sia qualcuno tanto masochista da generare a mano tutti i checksum, vediamo come si può automatizzare il procedimento.
Scriviamo in un normale file di testo un elenco di file o gruppi di file dei quali vogliamo generare il checksum:
/bin/* /boot/vmlinuz* /etc/fstab /etc/hosts.allow /etc/hosts.deny /etc/inetd.conf /etc/lilo.conf /etc/login.access /etc/login.defs /etc/securetty /etc/serial.conf /etc/services /sbin/* /usr/bin/* /usr/local/admin/* /usr/local/sbin/* /usr/sbin/*e salviamolo, per esempio, come
/etc/fsichk.confquindi scriviamo un semplice shell script che generi i checksum md5 leggendo i dati da questo file:
#! /bin/sh
CONFIG_FILE=/etc/fsichk.conf
CHECKSUM_FILE=/usr/secure/checksums
for i in `cat $CONFIG_FILE`; do
if [ ! -d $i ]; then
/usr/bin/md5sum $i >>$CHECKSUM_FILE;
fi;
done;
I checksum generati saranno salvati nel file indicato da CHECKSUM_FILE.
Può sembrare scontato, ma concedetemi qualche byte per sottolineare che tutto quello che abbiamo fatto fino ad ora risulterebbe un'inutile perdita di tempo se lasciassimo il file con i checksum sul sistema che vogliamo tenere sotto controllo. Inutile che il file sia leggibile solo da root, dal momento che stiamo considerando l'eventualità che l'intruso sia riuscito a acquisire i privilegi di root.
La cosa migliore da fare sarebbe salvare il file in un floppy e conservarlo in un luogo fisicamente sicuro. E se il server si trovasse chiuso in un rack a qualche centinaio di km di distanza dal SysAdmin? Questa è la mia situazione e ho pensato di risolvere il problema salvando il tutto su di un floppy, proteggendolo dalla scrittura e inserendolo nel drive del server. In questo modo il floppy può essere montato normalmente, anche da remoto, nel momento in cui si vuole verificare l'integrità dei file controllati (come spiegato nel prossimo capitolo).
Qualche fanatico potrebbe obiettare che, mentre io dormo beatamente a 300 km di distanza, un malintenzionato potrebbe raggiungere il server, estrarre il floppy e alterarne il contenuto. Questo è assolutamente vero, così come è vero che potrebbe anche smontare l'hard disk e farci tutto quello che gli pare. Difendersi da attacchi che prevedano un accesso fisico alla macchina implica delle problematiche che non possono essere affrontate (e tantomeno risolte) con gli strumenti proposti in questo documento ed esulano quindi dai suoi scopi. Se avete necessità di questo tipo, provate a chiedere all' N.S.A. se vi può ospitare il server. ;-)
Nella malaugurata ipotesi che qualcuno sia riuscito a violare il nostro sistema (o che abbiamo il sospetto che ciò possa essere avvenuto), possiamo utilizzare le informazioni raccolte in precedenza per cercare di scoprire quali parti (più o meno vitali) del sistema sono state compromesse.
Quest'operazione è addirittura più semplice di quelle descritte nel paragrafo precedente, poichè è lo stesso md5sum a venirci incontro; possiamo lanciare:
md5sum -c CHECKSUM_FILEdove
CHECKSUM_FILE rappresenta il file all'interno del quale abbiamo memorizzato i dati ricavati nel paragrafo precedente.
Quello che otterremo, sarà un report del tipo:
/etc/fstab: FAILED /etc/hosts.allow: OK /etc/hosts.deny: OK /etc/inetd.conf: OK /etc/lilo.conf: OK /etc/login.access: OK /etc/login.defs: FAILED /etc/securetty: OK /usr/sbin/ypset: OK /usr/sbin/zdump: OK /usr/sbin/zic: OK md5sum: WARNING: 2 of 11 checksums did NOT match
Una verifica di questo tipo potrebbe essere eseguita anche periodicamente, attraverso un cron, per esempio tutti i giorni: il report verrebbe inviato per mail al sistemista.
In tutta questa procedura emerge, però il vecchio interrogativo: "chi controlla il controllore?", che tradotto significa: "chi ci garantisce che lo stesso md5sum non sia stato troianizzato?". La risposta è semplice: nessuno.
Una possibile soluzione consiste nel salvare una copia sicura del binario di md5sum (che, nella Slackware, si trova in /usr/bin/md5sum) sullo stesso supporto che contiene i checksum (e che abbiamo auto cura di rendere non scrivibile).
Io tengo una copia dei binari a rischio sul floppy descritto qui sopra e monto quest'ultimo su /usr/secure/.
ToDo
Dal momento che questa è solo la seconda versione di questo HowTo, non ci sono ancora FAQ. :-P
Nell'utopistica speranza che questo documento possa servire a qualcuno (magari in via preventiva, non voglio gufare a nessuno), invito chiunque avesse proposte e/o critiche costruttive (*) a contattarmi via email.
(*): critica costruttiva: dicasi critica costruttiva, quella critica che non consista nella semplice asserzione: "quello che hai scritto fa pena", ma in un discorso più articolato nel quale vengano argomentate le critiche e vengano proposte delle alternative.