Forensic - Incident Response Analisys - Computer Forensics Forensic Italian Italiano.pdf 3f1j5z

Iritaly Italian Incident Response Project Version 1.0 beta Released in Milano, June 10, 2003 www.iritaly.org IRItaly: premessa IRItaly (Incident Response Italy) è un progetto nato presso il Dipartimento di Tecnologie dell'Informazione dell'Università Statale di Milano, Polo Didattico e di Ricerca di Crema. Audience. Lo scopo principale è informare e sensibilizzare la comunità tecnico/accademica italiana, le aziende piccole e grandi, forze dell’ordine, magistratura, gli attori privati e pubblici in relazione alle tematiche presentate in seguito. IRItaly non ha l’obiettivo di costituire la reference guide per la gestione degli incidenti. Il progetto ha il mero fine di introduzione alla problematica dell’Incident Response, ovviamente anche dal punto di vista operativo e della sicurezza informatica di base. La bibliografia di riferimento è al termine del presente paper. Il progetto si sviluppa in due parti fondamentali: la prima, documentale, che fornisce istruzioni dettagliate e ad ampio spettro. La seconda, elettronica, consta di un CDRom bootable. I temi affrontati riguardano le problematiche relative ad attacchi informatici, in particolare i sistemi di difesa, Computer e Network Forensics sulla gestione degli incidenti e le modalità per il recupero dei dati.

Pagina 1 di 334

Per quanto concerne le procedure di risposta ad incidenti informatici, vengono definite ed illustrate le best practices per le analisi da effettuare sulle macchine vittime (conosciuta anche come Post Mortem Analysis), in modo da poter rintracciare gli episodi di hacking, e comprendere le modalità dell’attacco. Il tutto è finalizzato a dare una valida risposta all’intrusione, che deve costituire un companion alle politiche di sicurezza che si presumono già esistenti all’interno dell’organizzazione. Tale risposta deve essere intesa come la possibilità di effettuare un hardening dei sistemi più consapevole ed efficace, che permetta di ridurre la possibilità di futuri attacchi. Non deve invece essere intesa come la generazione di un contro-attacco verso il presunto attaccante. Tutte le attività fin’ora descritte sono effettuate ponendo una particolare attenzione nella modalità di individuazione, conservazione ed eventuale utilizzo in sede di contenzioso disciplinare o giudiziario delle fonti di prova. Il metodo di stesura del presente documento è di tipo incrementale. In alcuni casi potrebbe sembrare al lettore di assistere ad una ripetizione di concetti all’interno del documento. In realtà essa è voluta e finalizzata all’integrazione di un concetto già trattato con un “overhead” di ulteriori informazioni.

Disclaimer/Licenza Il progetto IRItaly ha mera finalità informativa. Le informazioni ivi contenute non costituiscono alcun vincolo per il lettore e vengono fornite come sono¸ cioè testate, per quanto nelle facoltà degli operatori, con la massima attenzione. Il fruitore del presente documento e del relativo CD si assume tutte le responsabilità relative al loro utilizzo; gli operatori del progetto declinano qualsiasi responsabilità oggettiva e soggettiva su eventuali danni materiali e immateriali scaturenti dall'utilizzo del presente documento. L’utilizzo del presente Documento e del CDRom presume l’accettazione incondizionata del presente disclaimer. Vi invitiamo a leggere la parte di LICENZA posta al termine di questo documento. IRItaly aderisce al piano di licenza GNU.

IRItaly: generalità Il filo conduttore del documento è l’insieme di azioni che dovrebbero essere intraprese in caso di intrusione informatica, compresa la fase preparatoria. Esso è infatti costituito da differenti capitoli, ognuno dei quali effettua un’analisi approfondita di tali momenti, ossia: IR Start Phase la fase preparatoria di incident response, Information Gathering (l’analisi delle informazioni disponibili che la caratterizzano), Evidence Gathering (la raccolta e la conservazione delle informazioni ad essa associate - le fonti di prova-), Sanitize: l’eliminazione degli strumenti utilizzati per guadagnare e mantenere l’accesso illecito alla macchina (rootkit), Recovery il ripristino dei sistemi alle condizioni di normale operatività. Vengono dunque fornite informazioni dettagliate riguardanti: la gestione dei differenti file system, le procedure di backup dei dati, le operazioni necessarie per effettuare le immagini dei dischi fissi e di i removibili, Pagina 2 di 334

la gestione di comunicazioni elettroniche sicure, gli algoritmi di crittografia e le relative implementazioni, gli strumenti di analisi, acquisizione e tutela dei file di log. Il documento contiene, infine, una proposta per una modulistica uniforme, volta ad organizzare al meglio le attività, agevole o l’interazione tra organizzazioni che analizzano l’incidente avvenuto, o tra differenti target coinvolti nell’attacco. In particolare si presenta un Report per la gestione degli incidenti informatici e la Chain of Custody, documento utile per tenere traccia di tutte le informazioni riguardanti le fonti di prova. Il CDRom può essere utilizzato per effettuare un primo riconoscimento della configurazione e dello stato dei computer compromessi1. Gli strumenti presenti offrono la possibilità di effettuare l’analisi dei dischi, generare una loro immagine ed effettuare accertamenti sui log, in modo da poter compiere un’analisi di primo livello dell’incidente avvenuto. Per maggiori informazioni sul contenuto del CDRom vi invitiamo a prendere visione del Ree file ivi contenuto. Sia che il fruitore del progetto abbia intenzione di utilizzare il CDRom allegato sia che voglia approfondire e/o creare la sua libreria, è opportuno che prenda conoscenza delle procedure di Validazione. Con questo termine si indicano tutti quei processi aventi valore legale e/o operativo, finalizzati alla verifica delle funzionalità degli strumenti che vengono utilizzati in laboratorio e/o valutati per un impiego generale. La validazione può essere effettuata internamente o data in outsourcing. Nel primo caso sarà cura dell’utente individuare i parametri operativi. Tra i più importanti segnaliamo: il corretto licensing di prodotto, eventuali riscontri di validazione durante procedimenti penali e/ o civili effettuati a livello internazionale e/o nazionale2 , la certificazione del dello strumento effettuata da siti ufficiali del vendor e/o delle organizzazioni no profit la verifica (eventuale, a dire il vero) della presenza o meno di vulnerabiltà tali da inficiare il processo di esame e/o di acquisizione dei dati nella fase preliminare dell’investigazione e via dicendo. Le operazioni di validazione dovrebbero essere effettuate sempre ogni qualvolta si decida di adottare un nuovo tool e dovrebbero essere internamente documentate. In ordine all’opportunità di inserimento delle procedure di validazione all’interno dei verbali e/o dei report esistono opinioni contrastanti. Ci sono operatori, infatti, che predicano detto inserimento in ogni documentazione (report o affini) altri, invece, che ritengono sufficiente la compilazione di un documento interno che venga richiamato ed utilizzato in caso di necessità. Solitamente, comunque, le discussioni relative alla validazione degli strumenti non sono legate ai tools in sé ma alla loro origine (licensing, originalità, integrità, ).

IRItaly: Next Step L’obiettivo che il progetto intende perseguire è duplice e riguarda sia la manutenzione del documento /CDRom, sia il loro update, sia l’immissione di nuovi contenuti. L’obiettivo è quello di aggiungere altre parti al documento, che conterranno la definizione di operazioni e altro. Vi invitiamo, a tal proposito, a visitare la pagina web, continuamente aggiornata. 1

Il Cdrom sarà reso disponibile a partire dal 10 settembre 2003. Nel frattempo siete invitati a testare la parte di boot disponibile nella zona di www.iritaly.org. 2 Detti riscontri sono di solito ottenibili direttamente dal produttore, dai centri di discussione o dalle riviste tecnico/scientifiche

Pagina 3 di 334

Acknowledgement Questo progetto non sarebbe mai stato realizzato se lo spirito di abnegazione delle 12 persone che trovate a fine pagina non avesse padroneggiato. Ci sono stati dei momenti in cui gli impegni lavorativi ed universitari (a vario livello) hanno messo a dura prova il nostro tempo e la nostra vita privata. Per questo ritengo opportuno ringraziare: Un particolare ringraziamento va anche a Pierangela Samarati del Polo di Ricerca di Crema/DTI. È anche grazie alla sua impagabile disponibilità che questo progetto ha visto la luce. Desideriamo ringraziare altresì Ernesto Damiani e Sabrina De Capitani Di Vimercati, sempre del DTI. Il loro o ha avuto un ruolo fondamentale. IRItaly incoraggia i da parte di utenti, sviluppatori, legali e law enforcement. Questo o può avvenire sia segnalando qualsiasi input all’indirizzo , sia adottando il documento all’interno della propria reference list. In poco tempo IRItaly diventerà il chapter italiano di un progetto opensource mondiale sulla Forensic/Incident Response. L’obiettivo è quello di garantire la massima integrazione tra letteratura, best practices e vita operativa. Se la Vostra azienda/organizzazione vuole are IRItaly partite dal nostro logo sul Vostro sito. Vi autorizziamo, senza alcuna ulteriore richiesta, a posizionarlo sul Vs. Web. L’unica cosa che vi chiediamo è una notifica. sul documento e sul CDRom sono davvero bene accetti. Il team di integrazione del CDRom, in particolare, sarà felice di accogliere le vostre richieste/suggerimenti e critiche costruttive. Se operate nel settore del Law Enforcement (Forze di Polizia e Magistratura) vi preghiamo di contattarci. Tra i progetti futuri ci sono dei capitoli e delle checklist riservate a voi. Se operate nel settore legale, siete i benvenuti. Tra i futuri enhancement del progetto c’è l’inserimento di alcuni paragrafi di riferimento al nostro ordinamento giuridico. IRItaly assicura l’assoluto riconoscimento di credit per l’apporto fornito al progetto. Buon lavoro a Tutti. Dario Forte, CFE – IRItaly Project Founder.

Pagina 4 di 334

Definizione delle procedure e delle politiche da attuare in risposta ad un’intrusione Indice IRItaly: premessa ...................................................................................................................................... 1 1. IR Start: Preparazione della risposta all’intrusione..................................................................... 12 1.1 Verifica della disponibilità di media adeguati per i backup ed il ripristino dei sistemi.......... 12 1.1.1 Backup Preventivi ........................................................................................................... 12 1.1.2 Backup di Indagine ......................................................................................................... 13 1.1.3 Realizzazione dell’immagine.......................................................................................... 18 1.1.4 Integrità e disponibilità delle fonti di prova.................................................................... 19 1.1.5 i Utilizzabili (Media) .......................................................................................... 19 1.2 Definizione di un sistema adeguato di comunicazione protetta.............................................. 26 1.2.1 E-Mail ............................................................................................................................. 26 1.2.2 Telefonia Fissa ................................................................................................................ 28 1.2.3 Telefonia Mobile............................................................................................................. 38 1.2.3.1 Tacs ............................................................................................................................. 38 1.2.3.2 Gsm ............................................................................................................................. 39 1.2.3.3 GPRS e UMTS............................................................................................................ 40 1.3 Creazione di un toolkit sw/hw ............................................................................................... 42 1.3.1 Tools di analisi dei dischi ............................................................................................... 42 1.3.1.1 Disk Investigator ......................................................................................................... 42 1.3.1.2 Autopsy v1.6 ............................................................................................................... 43 1.3.1.3 Test Disk v4.2 ............................................................................................................. 44 1.3.1.4 Wipe ............................................................................................................................ 44 1.3.1.5 Task v1.5..................................................................................................................... 44 1.3.1.6 Biew ............................................................................................................................ 44 1.3.1.7 StegDetect v0.5 ........................................................................................................... 45 1.3.1.8 Mac- Robber v1.0 ....................................................................................................... 46 1.3.1.9 Glipse v4.1 .................................................................................................................. 46 1.3.1.10 TCT 1.11 ................................................................................................................ 47 1.3.1.11 Dumpel.................................................................................................................... 48 1.3.1.12 Strace NT ................................................................................................................ 48 1.3.2 Tools analisi della rete .................................................................................................... 49 1.3.2.1 Ethereal v.0.9.6 ........................................................................................................... 49 1.3.2.2 Snort v.1.9.0 ............................................................................................................... 51 1.3.2.3 TTraceroute ............................................................................................................. 54 1.3.2.4 Hogwash...................................................................................................................... 56 1.3.2.5 Tdump 3.7 .............................................................................................................. 57 1.3.2.6 Ttrace 6.2.0............................................................................................................. 60 1.3.2.7 Chkrootkit 0.39a ......................................................................................................... 63 1.3.2.8 SSLdump 0.9b3........................................................................................................... 64 1.3.2.9 p0f ............................................................................................................................... 65 1.3.3 Tools immagini dei dischi .............................................................................................. 66 1.3.3.1 Creazione dell’immagine dei dischi in ambiente Unix............................................... 66 Pagina 5 di 334

1.3.3.2 Creazione dell’immagine dei dischi in ambiente Windows........................................ 68 1.3.4 Gestione del dump della ram ......................................................................................... 73 1.3.4.1 Dump della memoria fisica in ambiente Windows..................................................... 73 1.3.4.2 PMDUMP ................................................................................................................... 75 1.3.4.3 DD 3.16.2.................................................................................................................... 75 1.4 Verifiche di configurazione e disponibilità sui sistemi di test e le reti ................................... 76 1.4.1 Configurazione dei sistemi di test, dei possibili target dell’esame forense e di analisi.. 76 1.4.1.1 Considerazioni sull’hardware di una Forensic Workstation ....................................... 76 1.4.1.2 Considerazioni sul software di una Forensic Workstation.......................................... 77 1.4.1.3 Software originali e controllo di autenticità................................................................ 77 1.4.1.4 Cenni sul MD5 ............................................................................................................ 78 1.4.1.5 Antivirus ..................................................................................................................... 79 1.4.1.6 Security scanner .......................................................................................................... 79 1.4.1.7 Sniffer.......................................................................................................................... 79 1.4.1.8 Tool per la copia bit-a-bit del file system ................................................................... 79 1.4.1.8.1 DD........................................................................................................................... 80 1.4.1.8.2 Image MASSter Solo .............................................................................................. 80 1.4.2 Configurazione delle reti................................................................................................. 81 1.4.2.1 Omogeneità delle architetture ..................................................................................... 81 1.4.2.2 “robuste” ..................................................................................................... 81 1.4.2.3 SSH – Protocolli robusti per applicazioni di sicurezza............................................... 82 1.4.2.4 SSL e SHTTP – Comunicazioni crittate ..................................................................... 83 1.4.2.5 Antivirus ..................................................................................................................... 86 1.4.2.6 Firewall ....................................................................................................................... 86 1.4.2.7 Configurazione............................................................................................................ 86 1.4.2.8 Tecnologie per sistemi di firewall............................................................................... 87 1.4.2.9 Vulnerabilità e possibili contromisure ........................................................................ 88 1.4.2.10 Web Server (Microsoft IIS / Apache) ..................................................................... 88 1.4.2.11 Script CGI ............................................................................................................... 89 1.4.2.12 RPC (Remote Procedure Calls)............................................................................... 89 1.4.2.13 DataBase ................................................................................................................. 89 1.4.2.14 SNMP e configurazione di default.......................................................................... 90 1.4.2.15 BIND....................................................................................................................... 90 1.4.2.16 Meccanismi di autenticazione................................................................................. 90 1.4.2.17 Condivisione di file e informazioni via NetBios, NFS ........................................... 91 1.4.2.18 Internet Explorer, LAN Manager, Windows Scripting Host .................................. 91 1.4.2.19 SSH, FTP, LDP, Sendmail...................................................................................... 91 1.4.3 Algoritmi di hash ............................................................................................................ 92 1.4.3.1 MD5 (Message Digest Algorithm 5) .......................................................................... 92 1.4.3.2 SHA (Secure Hash Algorithm) ................................................................................... 92 1.4.3.3 MD5 library................................................................................................................. 92 1.4.3.4 Creazione di alcuni semplici file e utilizzo di MD5 per calcolare il checksum crittografico basato sui loro contenuti......................................................................................... 93 1.4.3.5 Confronto col programma “sum”................................................................................ 94 1.4.3.6 Implementazioni.......................................................................................................... 95 1.4.3.7 md5deep ...................................................................................................................... 95 1.4.3.8 CRC32 vs MD5........................................................................................................... 96 1.4.4 Live system analysis ....................................................................................................... 99 Pagina 6 di 334

2.

Information gathering sui sistemi potenzialmente compromessi.............................................. 101 2.1 Isolare i sistemi compromessi ............................................................................................... 101 2.1.1 Isolare i sistemi ............................................................................................................. 101 2.1.1.1 Generalità .................................................................................................................. 101 2.1.1.2 Precauzioni nello smontaggio del disco.................................................................... 103 2.1.2 Forensics e Linux .......................................................................................................... 103 2.1.2.1 Organizzazione dell’analisi....................................................................................... 104 2.1.2.2 Determinazione della struttura del disco................................................................... 105 2.1.2.3 Preparazione di un disco per l’immagine.................................................................. 105 2.1.2.4 Creazione dell’immagine di un disco compromesso ................................................ 106 2.1.2.5 Mount di un’immagine dopo il restore ..................................................................... 107 2.1.2.6 Mount di un’immagine utilizzando il loopback device ............................................ 107 2.1.2.7 Utilizzo dei moduli ................................................................................................... 107 2.1.2.8 File Hash ................................................................................................................... 108 2.1.2.9 L’analisi .................................................................................................................... 109 2.1.2.10 Effettuare la lista dei file....................................................................................... 109 2.1.2.11 Fare la lista dei file per tipo .................................................................................. 109 2.1.2.12 Visualizzare i file .................................................................................................. 110 2.1.2.13 Ricerca di spazio non allocato e slack space......................................................... 110 2.1.2.14 Gestire dischi di grandi dimensioni ...................................................................... 111 2.2 Correlation: cercare segnali di intrusione su altri sistemi ..................................................... 114 2.2.1 Sistemi che appartengono allo stesso range di indirizzi IP.......................................... 114 2.2.2 Sistemi che si trovano nello stesso segmento di rete .................................................... 114 2.2.3 Sistemi che sono nello stesso dominio “trusted” .......................................................... 114 2.2.4 Sistemi che hanno almeno un servizio di rete in comune ............................................. 115 2.2.5 Sistemi che hanno lo stesso sistema operativo.............................................................. 115 2.2.6 Sistemi che condividono file e informazioni ................................................................ 115 2.3 Log analysis sull’output dei firewall, router e network monitor.......................................... 116 2.3.1 Introduzione .................................................................................................................. 116 2.3.2 Timestamping................................................................................................................ 116 2.3.3 Event collection............................................................................................................. 117 2.3.4 Modifiche apportate ai software di sistema e ai file di configurazione ........................ 118 2.3.5 Modifiche ai dati ........................................................................................................... 118 2.3.6 Tool e dati lasciati dall’intruder nel sistema ................................................................. 119 2.3.7 Analisi dei log file......................................................................................................... 119 2.3.8 Ricerca della presenza di un network sniffer ................................................................ 121 2.3.9 Ricerca di altri sistemi compromessi all’interno della rete........................................... 121 2.3.10 Ricerca di sistemi implicati o compromessi in siti remoti ............................................ 121 2.3.11 Log parsing tool ............................................................................................................ 122 2.4 Green circle: identificazione dell’attacco ad un sistema..................................................... 124 2.4.1 Monitoraggio ed ispezione delle attività di rete alla ricerca di anomalie. ................... 126 2.4.1.1 Analisi e investigazione delle notifiche di meccanismi di alert dedicati alla rete (come e-mail, voice-mail, o sms)......................................................................................................... 126 2.4.1.2 Analisi e investigazione dei report di errore di rete .................................................. 127 2.4.1.3 Analisi delle statistiche delle prestazioni della rete ed investigazione di anomalie.. 127 2.4.1.4 Identificazione del traffico di rete inatteso, insolito, o sospetto e le possibili implicazioni............................................................................................................................... 127 Pagina 7 di 334

2.4.2

Monitorare ed ispezionare le attività di sistema alla ricerca di comportamenti sospetti 129 2.4.2.1 Analisi ed investigazione delle notifiche che provengono da meccanismi di altert specifici per i sistemi (come e-mail, voice-mail o sms)............................................................ 130 2.4.2.2 Analisi ed investigazione dei rapporti di errore provenienti dal sistema.................. 130 2.4.2.3 Analisi delle statistiche delle prestazioni di sistema ed investigazione di eventuali anomalie. 130 2.4.2.4 Monitoraggio continuo dell’attività dei processi (fin dove è possibile) ................... 131 2.4.2.5 Identificazione di qualsiasi comportamento dei processi che possa essere definito inaspettato, non usuale o sospetto e le possibili implicazioni................................................... 131 2.4.2.6 Identificazione di qualsiasi comportamento degli utenti che sia inaspettato, insolito o sospetto e le possibili implicazioni ........................................................................................... 132 2.4.2.7 Identificazione di altri comportamenti inaspettati, insoliti o sospetti e le loro possibili implicazioni............................................................................................................................... 133 2.4.2.8 Esecuzione periodica del mapping della rete e degli strumenti di scanning per comprendere cosa può essere portato alla conoscenza degli intrusi che utilizzano questi sistemi 134 2.4.2.9 Esecuzione periodica degli strumenti di scanning delle vulnerabilità su tutto il sistema volte alla verifica della presenza di vulnerabilità note.............................................................. 134 2.4.3 Ispezione dei file e delle directory alla ricerca di modifiche inaspettate .................. 134 2.4.3.1 Stabilire priorità ed orari ........................................................................................... 135 2.4.3.2 Verifica dell'integrità delle directory e dei file secondo un programma prestabilito 135 2.4.3.3 Identificazione di qualsiasi modifica inattesa, insolita o sospetta effettuata ai file o alle directory e le possibili implicazioni ................................................................................... 135 2.5 Analisi delle operazioni di un attacker durante una violazione ............................................ 137 2.5.1 Introduzione .................................................................................................................. 137 2.5.2 Attività 1: manomissione dei log file............................................................................ 138 2.5.2.1 I Log Analyzers......................................................................................................... 138 2.5.2.2 Come rendere sicura l’attività di logging.................................................................. 139 2.5.3 Attività 2: garantirsi accessi futuri ................................................................................ 139 2.5.3.1 Installazione di Rootkits............................................................................................ 139 2.5.3.2 Controllo file system................................................................................................. 140 2.5.3.3 File Integrity checkers............................................................................................... 143 2.5.4 Attività 3: installazione trojan e backdoors................................................................... 146 2.5.4.1 IDS: Intrusion Detection System .............................................................................. 146 3. Evidence Gathering................................................................................................................... 149 3.1 Raccolta delle informazioni utili relative ad un’intrusione................................................... 149 3.1.1 Perché è importante....................................................................................................... 149 3.1.2 Collezionare tutte le informazioni concernenti l'intrusione .......................................... 149 3.1.3 Analizzare tutte le informazioni a disposizione per caratterizzare un’intrusione......... 150 3.1.4 Esaminare i log generati da firewall, network monitor e router ................................... 152 3.1.5 Identificare gli attacchi portati per guadagnare l’accesso al sistema compromesso..... 153 3.1.6 Identificare le operazioni effettuate dall’intruso durante l’accesso al sistema ............. 153 3.1.7 Proteggere la chain of custody per ogni fonte di prova ................................................ 154 3.1.8 Contattare le forze dell’ordine ...................................................................................... 154 3.1.9 Considerazioni sulle politiche aziendali ....................................................................... 154 3.1.10 Tool utili per la ricerca dei segnali di un’intrusione ..................................................... 155 3.2 Raccolta delle fonti di prova ................................................................................................. 160 Pagina 8 di 334

3.2.1 Sviluppo di metodologie ............................................................................................... 160 3.2.1.1 Preparazione.............................................................................................................. 161 3.2.1.2 Trasportare il computer in un posto sicuro ............................................................... 161 3.2.1.3 Documentare la configurazione hardware del sistema ............................................. 162 3.2.1.4 Shutdown del computer ............................................................................................ 162 3.2.1.5 Documentare tutto..................................................................................................... 163 3.2.1.6 Preparazione.............................................................................................................. 163 3.2.1.7 Sistema operativo e versione..................................................................................... 163 3.2.1.8 Valutazione dei virus ................................................................................................ 164 3.2.1.9 Effettuare un Bitstream Backup degli hard disks e dei floppy disks ........................ 164 3.2.1.10 Autenticare matematicamente i dati su tutti i dispositivi di memorizzazione ...... 165 3.2.1.11 Documentare la data e l’ora del sistema ............................................................... 165 3.2.1.12 Effettuare una lista delle parole chiave cercate..................................................... 166 3.2.1.13 Valutare i file di swap di Windows....................................................................... 166 3.2.1.14 Valutare lo slack space.......................................................................................... 166 3.2.1.15 Valutare gli spazi non allocati (file cancellati) ..................................................... 167 3.2.1.16 Cercare le parole chiave nei files, slack space e spazi non allocati ...................... 167 3.2.1.17 Documentare i nomi, le date e l’ora dei files ........................................................ 167 3.2.1.18 Identificare le anomalie di file, programmi e unità di memorizzazione ............... 167 3.2.1.19 Partizioni dell’hard disk ........................................................................................ 168 3.2.1.20 Valutare le funzionalità dei programmi ................................................................ 168 3.2.1.21 Documentare la “sentenza”................................................................................... 168 3.2.1.22 Tenere copie dei software usati............................................................................. 169 3.2.1.23 Licenze software ................................................................................................... 169 3.3 Conservazione delle fonti di prova ....................................................................................... 170 3.3.1 Introduzione .................................................................................................................. 170 3.3.2 Conservazione dei i fisici.................................................................................. 170 3.3.2.1 Imballaggio ............................................................................................................... 170 3.3.2.2 Trasporto ................................................................................................................... 172 3.3.2.3 Conservazione........................................................................................................... 173 3.3.3 Trattamento e custodia dei log ...................................................................................... 174 3.3.4 Policies aziendali relative alla conservazione delle fonti di prova .............................. 174 3.3.5 Chain of Custody (CoC) ............................................................................................... 175 3.3.6 Aspetti legali ................................................................................................................. 175 3.3.6.1 Rapporti con il Law Enforcement............................................................................. 175 3.3.6.2 Legislazione .............................................................................................................. 176 4. Sanitize: eliminazione degli strumenti utilizzati per l’intrusione ............................................. 178 4.1 Modifica delle sui sistemi ove sia stata riscontrata un’intrusione ............................ 179 4.1.1 : vulnerabilità e policy ................................................................................... 179 4.1.2 Modifica e organizzazione............................................................................ 191 4.2 Reinstallazione completa dei sistemi compromessi.............................................................. 194 4.2.1 Quando è utile reinstallare completamente il sistema................................................... 194 4.2.2 Operazioni preliminari .................................................................................................. 194 4.2.2.1 Verifica dei file di backup......................................................................................... 195 4.2.2.2 Formattazione del disco fisso.................................................................................... 197 4.2.2.3 Calcolo dello spazio disco......................................................................................... 204 4.2.2.4 Partizionamento ........................................................................................................ 205 4.2.3 Installazione del sistema operativo ............................................................................... 207 Pagina 9 di 334

4.2.3.1 Installazione dei driver aggiornati............................................................................. 207 4.2.3.2 Installazione delle patch di sistema (linux update, windows update) ....................... 207 4.2.4 Installazione delle applicazioni..................................................................................... 207 4.2.4.1 Installazione delle patch............................................................................................ 208 4.2.5 Settaggio delle policy di sicurezza................................................................................ 208 4.2.6 Settaggio delle impostazioni di rete .............................................................................. 208 4.2.7 Test del sistema (penetration/vulnerability test) ........................................................... 209 4.2.7.1 Nessus ....................................................................................................................... 209 4.2.8 Conclusioni ................................................................................................................... 209 4.3 Rimozione di tutti i programmi utilizzati per realizzare l’intrusione e di tutte le modifiche determinate dall’intrusione e Reinstallazione dei programmi eseguibili e dei file binari dai i di distribuzione originali. .................................................................................................................. 210 4.3.1 Punti chiave per la rilevazione dell’intrusione su sistemi UNIX.................................. 210 4.3.2 Punti chiave per la rilevazione dell’intrusione su sistemi Windows NT ...................... 212 4.3.3 Ripristino post intrusione .............................................................................................. 214 4.3.4 i per il recupero di un sistema UNIX o NT compromesso .................................... 214 4.3.4.1 Individuazione file modificati durante l’intrusione .................................................. 214 4.3.4.2 Individuazione dati modificati .................................................................................. 215 4.3.4.3 Individuazione dati e tool usati dall’intruso.............................................................. 216 4.3.4.4 Chkrootkit ................................................................................................................. 217 4.3.4.5 Tripwire..................................................................................................................... 219 4.3.4.6 LSOF......................................................................................................................... 223 4.4 Determinare se sussitono vulnerabilità nella rete e correggerle ........................................... 225 4.4.1 Introduzione .................................................................................................................. 225 4.4.2 Definizioni .................................................................................................................... 225 4.4.3 Port scan........................................................................................................................ 225 4.4.4 Nmap............................................................................................................................. 227 4.4.5 Nessus ........................................................................................................................... 227 4.4.5.1 Installazione in sistemi Unix..................................................................................... 230 4.4.5.2 Utilizzo di Nessus ..................................................................................................... 231 4.4.5.3 Creazione e rimozione degli utenti ........................................................................... 231 4.4.5.4 Configurazione avanzata del server .......................................................................... 232 4.4.5.5 Avvio di nessus server .............................................................................................. 232 4.4.5.6 Impostazione e uso del client .................................................................................... 233 4.4.5.7 Nessus funzionalità avanzate .................................................................................... 237 4.5 Migliorare gli strumenti di protezione per limitare l’esposizione dei sistemi e della rete.... 239 4.5.1 WINDOWS................................................................................................................... 239 4.5.1.1 Internet Information Services (IIS) ........................................................................... 239 4.5.1.2 Microsoft Data Access Components (MDAC) – Remote Data Services.................. 240 4.5.1.3 Microsoft SQL Server............................................................................................... 240 4.5.1.4 NETBIOS – Condivisioni di rete non protette in Windows ..................................... 241 4.5.1.5 Accesso anonimo – Null session............................................................................... 242 4.5.1.6 Autenticazione LAN Manager – Hashing LM debole .............................................. 243 4.5.1.7 Autenticazione generica di Windows – senza o con deboli 244 4.5.1.8 Internet Explorer ....................................................................................................... 245 4.5.1.9 Accesso remoto al Registro ...................................................................................... 245 4.5.1.10 Windows Scripting Host ....................................................................................... 246 Pagina 10 di 334

4.5.2 UNIX............................................................................................................................. 246 4.5.2.1 Remote Procedure Call ............................................................................................. 246 4.5.2.2 Web Server Apache .................................................................................................. 248 4.5.2.3 Secure Shell (SSH).................................................................................................... 249 4.5.2.4 Simple Network Management Protocol (SNMP) ..................................................... 250 4.5.2.5 File Transfer Protocol ............................................................................................... 252 4.5.2.6 Servizi R – Relazioni di Trust................................................................................... 254 4.5.2.7 Line Printer Daemon (LPD)...................................................................................... 255 4.5.2.8 Sendmail.................................................................................................................... 255 4.5.2.9 BIND/DNS................................................................................................................ 256 4.5.2.10 Autenticazione generica di Unix – senza o con deboli 258 4.5.3 Porte vulnerabili............................................................................................................ 259 4.5.4 Il Firewall...................................................................................................................... 261 4.6 Migliorare i sistemi di Intrusion Detection per avere segnalazioni migliori. ....................... 263 4.6.1 Introduzione .................................................................................................................. 263 4.6.2 IDS: Richiami ............................................................................................................... 263 4.6.2.1 Funzionalità base degli IDS ...................................................................................... 263 4.6.2.2 IDS e Firewalls ......................................................................................................... 264 4.6.3 Modelli di classificazione degli IDS............................................................................. 265 4.6.3.1 Classificazione in base alla fonte delle informazioni................................................ 266 4.6.3.2 Classificazione in base al momento dell'analisi delle informazioni ......................... 270 4.6.3.3 Classificazione in base alla tipologia di analisi ........................................................ 272 4.6.3.4 Il o successivo nell'evoluzione degli IDS: IPS e Honeynets.............................. 280 4.6.4.1 NIDS – Punti critici della rete................................................................................... 284 4.6.4.2 NIDS - Tecniche di elusione..................................................................................... 289 4.6.4.3 Errori – Falsi positivi e falsi negativi........................................................................ 303 APPENDICE A................................................................................................................................. 320 Incident Response Italy CD (basato su F.I.R.E.) release 1.0, 10 Dicembre 2003 ........................ 320 APPENDICE B ................................................................................................................................. 328 Principi legali di comportamento nella corretta acquisizione delle prove nel c.d. “incident response”....................................................................................................................................... 328

Pagina 11 di 334

1.

IR Start: Preparazione della risposta all’intrusione

1.1

Verifica della disponibilità di media adeguati per i backup ed il ripristino dei sistemi Le operazioni che riguardano i backup ed il salvataggio dei dati si possono suddividere in due parti distinte: quella che riguarda i backup effettuati prima dell’evidenziarsi dell’intrusione (preventivi) e quella riguardante i backup da effettuarsi dopo la rilevazione dell’intrusione stessa (di indagine).

1.1.1

Backup Preventivi Fanno parte delle normali procedure operative che si differenziano a seconda dell’azienda, del processo o della piattaforma utilizzata; essi possono comprendere, ad esempio, full backup effettuati settimanalmente dei quali l’ultimo del mese salvato come backup mensile, con associati periodi di ritenzione variabili. Questi salvataggi generalmente possono contenere tutta una molteplicità di dati riguardanti l’azienda, incluse le e-mail oppure i log files riferite a certe date e queste sono informazioni che possono essere estremamente utili o sensibili. I backup avendo come unico scopo quello di archiviare un particolare albero di directory o di singoli file vengono fatti dai tool come una semplice copia del file e viene quindi tralasciato volontariamente il modo in cui il file si trova fisicamente sul disco. Questa particolarità fa sì che un backup di questo genere non sia utilizzabile in caso di forensics in cui la disposizione fisica dei file all’interno di un disco può essere di importante aiuto per l’analisi. Nel considerare tali categorie di dati assume fondamentale importanza la verifica dell’esistenza delle policy di backup e del relativo contenuto che può comprendere le seguenti informazioni: Tipologia di files dei quali si effettuano i backup Frequenza con la quale i backup sono effettuati Strumenti HW/SW utilizzati Modalità utilizzata (backup fisico, logico, incrementale, snapshot, per singoli file, ecc.) Responsabilità dell’effettuazione delle operazioni di backup Luogo di custodia, le operazioni da effettuarsi per il trasferimento in esso dei i e le regole in atto per la loro custodia Modalità di verifica dell’integrità e della coerenza dei dati archiviati mirata a sostenere la loro conformità rispetto ai dati originali Avvenimenti per i quali è prevista l’attivazione di procedura di restore e relativi soggetti che possono autorizzare tali operazioni: verifica che sia prevista una procedura di emergenza che permetta di accedere ai backup in tempi estremamente veloci. L’importanza di questi backup è da riferirsi rispetto a due fattori: Analisi delle informazioni relative all’intrusione – ci possono essere state, nel periodo immediatamente precedente all’intrusione vera e propria, delle azioni effettuate dall’intruder che hanno lasciato traccia sui sistemi e che possono essere d’ausilio all’attività di indagine al fine di risalire alle modalità di intrusione e agli autori; queste preziose informazioni possono essere state cancellate dall’intruder stesso al momento dell’attacco vero e proprio al fine di Pagina 12 di 334

rendere il più possibile trasparente agli occhi dell’analista il proprio operato (generalmente in questo caso per potere successivamente garantirsi l’accesso al sistema compromesso) e quindi non essere più presenti al momento dell’evidenziazione dell’intrusione (oppure essere semplicemente operazioni mirate alla distruzione del sistema). Può anche essere il caso che la compromissione del sistema sia tale da non poter ricostruire lo stato dello stesso con le sole informazioni a disposizione: è per questo che si possono utilizzare i backup per ricostruire il sistema all’ultimo stato conosciuto; Ripristino dei sistemi compromessi post-attacco – una volta isolato il sistema interessato e svolte le attività relative all’acquisizione delle prove, viene dato il benestare a riprendere le normali attività svolte dal sistema (salvo disposizioni diverse); a seconda dello stato di compromissione è necessario ripristinare il sistema e i dati ad esso correlati con le informazioni più recenti possibili che possono essere ricavate sia dallo stato del sistema al momento dell’isolamento dalla rete e dall’utente finale, sia dai backup effettuati in precedenza. Il ripristino di un sistema non deve essere mirato al solo restore dei dati relativi all’ultimo backup creato ma deve cercare di essere il più possibile correttivo. E’ sicuramente necessario e doveroso, una volta eseguito il ripristino e prima di riconnetterlo in rete, dedicare del tempo alla ricerca di aggiornamenti software relativi alle macchine in questione. Di conseguenza è necessario installare, sempre che ve ne siano, tutte la patch trovate. Queste operazioni sono di importanza primaria se si vuole diminuire la possibilità che si verifichino incidenti della stessa natura; questo perché se si tratta di un problema a livello di configurazione (di servizi o policy di sicurezza) l’analisi di tali problemi può richiedere molto tempo per lo studio e la correzione, per cui queste operazioni sono da considerarsi utili per ripristinare in tempi veloci il sistema per non interrompere a lungo il processo produttivo dell’azienda. 1.1.2 Backup di Indagine Per effettuare le opportune indagini sulla compromissione del sistema è necessario raccogliere fonti di prova allo scopo di essere analizzate dalle autorità competenti e, affinché ci sia una bassa probabilità che le prove vengano contaminate, questa attività deve essere effettuata il più presto possibile dopo che è stata rilevata l’intrusione. È indispensabile che, quando si effettua questa attività, venga assicurata l’integrità e la sicurezza dello stato del sistema in oggetto e che quindi non venga introdotta alcuna alterazione ai dati residenti nel sistema medesimo. Il miglior approccio a questa pratica è quello di utilizzare tool per effettuare l’immagine dei dischi in modalità “bit by bit” ovvero tool che copiano tutti i bit di un determinato disco nell’immagine finale (Fig. 1). L’immagine creata da questi tool è chiamata Bitstream Image. Alcuni di questi tool non si preoccupano di interpretare il file system del disco che si sta acquisendo (l’immagine che creano è detta raw image), mentre altri tool più sofisticati si occupano di analizzare anche il tipo di file system per rendere ancora più sicura l’acquisizione. Esistono anche particolari strumenti hardware che garantiscono che durante la fase di acquisizione non avvengano operazioni di scrittura sul media che si sta importando. Esistono ulteriori sistemi hardware autonomi che permettono di collegare direttamente il dispositivo da acquisire allo strumento in questione al fine di dare ulteriori garanzie sull’integrità dell’immagine generata. Gli strumenti software usati generalmente permettono di acquisire da qualunque tipo di o magnetico/ottico. L’importanza dell’uso di strumenti che permettano di creare una Bitstream Pagina 13 di 334

Image è di rilevante importanza per chi andrà poi a svolgere un’attività di forensics sui dati contenuti nell’immagine.3

Figura 1: Hard Disk. Tipico esempio di media da acquisire

I file system più noti in cui lo specialista di forensics/incident response potrebbe imbattersi sono molti, anche se nella realtà non lo sono. Ogni file system ha le sue peculiarità i propri vantaggi e problemi. Eccone un lista abbastanza esaustiva: FAT: La “File Allocation Table” è stata introdotta dal sistema operativo DOS 1.0. E’ un file system molto semplice che non è altro che una singola lista concatenata di clusters. Ne esistono due versioni, FAT12 (per i floppy disk) e FAT16 (per gli hard disk). Il nome dei file ha una dimensione fissa di 8 caratteri per il nome e 3 per l’estensione VFAT: Estensione di FAT12 e FAT16 introdotta da Windows 95 al fine di gestire nomi di file più lunghi. FAT32 : introdotta con Windows 95 Seconda Edizione e Windows98. Corregge qualche problema con la FAT. Riduce lo spazio inutilizzato tra i files. HPFS (High Performance File System) : Fu introdotto da IBM/Microsoft con il sistema operativo OS/2. E’ un file system a “inode”. NTFS (New Technology File System): E’ il file system nativo di Windows NT. Assomiglia a HPFS ma ha in più alcune caratteristiche per quanto riguarda la sicurezza come il controllo d’accesso. E’ un file system a “unicode” ovvero ogni carattere è di 16 bit. EXT2FS (Second Extended File System): File system nativo di Linux. E’ a “inode”. E’ formato da blocchi che solitamente sono di 1 Kbyte. EXT3FS: Evoluzione di EXT2 anche se con stesse prestazioni. Introduce il concetto di Journaled File System (tiene traccia delle operazioni che vengono fatte sui file) REISERFS: è un file system utilizzato su Linux basato su alberi bilanciati ad alta velocità. Grazie alle sue caratteristiche le situazioni in cui si verificano le prestazioni peggiori sono molto minori paragonate agli altri file system attualmente in circolazione. Permette di gestire con alte prestazioni files di tutte le dimensioni e in modo sensibilmente migliore per i piccoli archivi. E’ in 3

A tal proposito si tenga conto che un’alternativa alla Bitstream Image “pura” è costituita dalla cosiddetta Forensic Image, cioè una riproduzione comunque totale e completa del disco origine ( slack space compreso) ma con una dimensione diversa sul media di destinazione, dovuta ad overhead di riconoscimento del file proprietario generato e all’eventuale utilizzo di software di compressione. Comunque sia le cautele di integrity checking rimangono invariate.

Pagina 14 di 334

grado di guadagnare il 6% di spazio non essendoci più una zona di disco di dimensioni fissate per l’allocazione degli inode. E’ un journaled file system, ovvero permette di non perdere attimi preziosi dovuti ai lunghi tempi di attesa imposti dal tool “fsck” per la verifica della consistenza del file system ogni qualvolta si verifica un guasto (caduta di tensione o malfunzionamento) che potrebbe portare il file system in uno stato inconsistente. Nell’ultima versione stabile è in grado di gestire fino a 232-3 files con dimensione massima fino a 260 byte. Con blocchi da 4 Kbyte può gestire un file system di dimensioni massime pari a 16 Terabyte. Altri file system di minore importanza che possono essere citati sono: BeFS FFS (Fast File System) AMIGA FFS BSD NFS (Networked File System) AFS (E rew File System) RFS (Remote File System) XFS (SGI File System)

Figura 2: File system Unix

Tornando alle tecniche di acquisizione possiamo dire che l’immagine dei dischi è anche uno degli approcci per effettuare i backup. A tal proposito va ricordato che, con gli strumenti convenzionali come Ghost, se non diversamente specificato, la procedura di backup copia solo i file e non i dati d’ambiente; quest’ultima è un’area dove possono essere trovati le più importanti fonti di prova. Per esempio, in Windows i dati d’ambiente sono memorizzati negli swap file mentre gli Unix usano una partizione dedicata ai dati d’ambiente. Pertanto, qualora si dovesse optare per l’utilizzo di Ghost in un’immagine post mortem, si rammenti di operare con istruzioni forensic related. Spesso un’ulteriore fonte di prova può essere trovata all’interno dello “slack space” (composto da “file slack” e “RAM slack”). Quando in un file system che usa cluster di 32 Kbyte scrive files che hanno una dimensione non multipla della grandezza del cluster, l’ultimo cluster usato non viene riempito totalmente e non può nemmeno essere destinato ad altri file. Lo spazio che intercorre tra Pagina 15 di 334

la fine dei dati utili del file e la fine del cluster è detto appunto “slack space”. In pratica si tratta di spazio di scarto che non viene usato dal sistema ma che però viene utilizzato in modo improprio per nascondere files. Lo “slack space” totale è la somma di tutti gli “slack space” relativi a ogni file. Sapendo che spesso su un sistema ci sono migliaia di file possiamo facilmente immaginare a quanto possa ammontare lo “slack space” totale.

Figura 3: Componenti dell’Hard Disk che possono contenere informazioni utili

Altre potenziali fonti di prova possono venire trovate all’interno dello spazio non allocato di un file system; quest’ultimo potenzialmente può contenere file integri, parti di file, directory, file temporanei (compresi gli spool files) che sono creati e cancellati da diversi computer, applicazioni e sistemi operativi (Fig. 3). Questo è uno di motivi per cui le forensics analysis hanno bisogno di immagini “bit by bit” dell’intera superficie del disco, quindi relative anche allo spazio non ancora allocato o apparentemente non allocato. Spesso nello spazio non allocato si trovano file di notevole importanza per l’indagine che sono stati precedentemente cancellati dal sistema operativo e che non sono stati più sovrascritti. Tornando ai tool di acquisizione, atteso che un accertamento di computer forensics viene effettuato sulle copie e non sugli originali, una caratteristica che devono possedere tali strumenti è quella di non alterare le prove reali, ovvero: l’integrità dell’originale deve essere garantita. Ma anche qualora fossero state predisposte le opportune copie, è necessario essere certi che le copie stesse non subiscano alterazioni di contenuto nel corso dell’indagine; per far questo si deve predisporre un meccanismo di verifica che permetta di essere certi che le prove (e le loro copie) non siano state alterate o danneggiate: lo strumento migliore è quello di creare un hash dell’immagine prodotta. Un algoritmo di hashing partendo da una sequenza di dati di lunghezza qualsiasi, come ad esempio tutto il contenuto di un disco, genera un’altra sequenza di dati molto più corta, detta appunto hash il cui contenuto è strettamente dipendente dai dati iniziali. La caratteristica degli algoritmi di hashing e sulla quale si concentra la loro utilità è che se i dati in ingresso vengono cambiati anche minimamente l’hash ricalcolato è completamente differente da quello creato prima della modifica dei dati. Esistono molti algoritmi per la generazione degli hash. I più importati e usati sono SHA-1 (Secure Hash Algorithm, RFC 3174) e MD5 (Message-Digest Algorithm, RFC 1321). L’unico problema di tali algoritmi non è tanto quello di giungere a un Pagina 16 di 334

hash da cui sia impossibile risalire ai dati originali ma quello di evitare la collisione dei risultati ovvero rendere il più univoco possibile il rapporto tra i dati d’ingresso e l’hash generato. Ci sono molti strumenti sia freeware che commerciali che permettono di generare hash di file. Per esempio un tool incluso in F.I.R.E. (Forensic e Incident Response Environment – il CDRom a base dell’allegato di IRItaly) permette di generare immagini di dischi e relativa hash del file creato. Qui sotto è riportato un esempio di generazione di immagine di un floppy e relativo hash.

Figura 4: edd

Il tool in questione si chiama dcfldd (oppure edd, enhanced dd). Questo software è stato creato appositamente per F.I.R.E. e si tratta di uno strumento che estende le potenzialità di dd (il tool base) con una feature che permette la creazione di un hash di tipo MD5 relativo all’immagine del disco che si va a generare. In base alle opzioni è possibile (come in questo caso) creare l’hash in un file di output a parte. E’ in grado di rilasciare anche degli hash relativi a sottoparti del disco (o in generale del flusso di dati in ingresso) specificando la dimensione della finestra di hash ovvero specificando ogni quanti dati creare un hash. Un altro comodo strumento freeware per la generazione degli hash è Hashish. Questo strumento ha il solo scopo di generarlo in base a un file di ingresso o anche una semplice stringa. La potenzialità di questo strumento è data dalla quantità degli algoritmi implementati. Questi sono gli algoritmi implementati nell’ultima versione disponibile: SHA-1, SHA-256, SHA-384, SHA-512 MD2, MD5 HAVAL, HAVAL-3, HAVAL-4, HAVAL-5 RIPEMD-160 Tiger Panama Hash CRC-32 Sapphire Hash E’ senza dubbio uno strumento completo e di facile uso utilizzando una GUI. Non è nemmeno da sottovalutare il fatto che è portabile sia su piattaforme Windows che Linux/Unix. Ancora un altro strumento freeware che può essere utile è MD5 Summer. E’ un applicativo per Windows 9x, NT, ME, 2000 e XP con interfaccia grafica o a linea di comando che permette di Pagina 17 di 334

creare hash MD5 di file. E’ un applicativo interessante essendo compatibile con Linux GNU MD5Sum sia per l’output che genera sia per i file di input che può leggere. Una feature molto comoda di questo software è la possibilità di creare hash dei files contenuti in un intero albero di directory ricorsivamente e naturalmente verificare di conseguenza gli hash generati in ato. 1.1.3

Realizzazione dell’immagine Esistono alcune linee guida che indicano come predisporre l’ambiente elaborativo all’effettuazione delle immagini. Nella maggior parte dei casi, la macchina viene consegnata spenta all’operatore di incident response. In altri, invece, viene messa a disposizione ancora accesa ma scollegata dalla rete. Nel primo caso, comunque, il computer non deve venire se non da personale addestrato allo scopo: in caso contrario potrebbe verificarsi una modifica di taluni dati della macchina e questo potrebbe danneggiare le indagini. Ad ogni modo, in caso di dubbio, la regola fondamentale è “se la macchina viene trovata spenta, deve rimanere tale, se trovata accesa deve rimanere accesa; il tutto fino a nuovo ordine”. Ciò detto, è necessario proteggere accuratamente il o originale (p.e. mettere in writeprotect i i che lo permettono). L’immagine del o si effettua tramite tool software, descritti più avanti, creando un’immagine “bit by bit”, come accennato in precedenza. Il metodo da usarsi preferibilmente è quello di utilizzare una stazione di lavoro “trusted” per l’acquisizione, anche nel caso si tratti di un singolo hard disk o di un floppy/cd. Oppure, se le condizioni lo permettono, si può effettuare il boot del computer oggetto dell’indagine non dall’hard disk come di solito avviene, ma da un floppy disk (drive “A”); il computer parte con un sistema operativo minimale che contiene programmi aggiuntivi e driver che fanno sì che il computer riconosca un device di memorizzazione esterno come un hard disk removibile; quindi verrà avviato dal floppy di boot un programma che effettuerà l’immagine dell’hard disk (o degli hard disk, se sono più di uno) sul device esterno; questa include non solo i file visibili sull’hard disk originale ma anche altri che normalmente sono nascosti, le parti di disco che contengono le informazioni da cui sono ricavati i dettagli delle directory (nome dei file, dimensioni, data e timestamp) e anche certi altri frammenti di file precedentemente cancellati e non ancora ricoperti da altri. Il file “immagine” stesso non può essere facilmente letto ed esaminato ma, effettuando il procedimento contrario su un secondo computer con caratteristiche simili al primo, può essere creato un esatto clone del disco originale, comprensivo di file nascosti e dei frammenti di file. Si può effettuare anche un’ulteriore copia dello stesso originale che può essere utilizzata come controllo in maniera simile a come vengono le testimonianze dalle forze di polizia. Le immagini sono copiate su CD-ROM che sono i Write Once Read Many che non possono essere alterati. A titolo di informazione preliminare si tenga quindi presente che: Il drive di destinazione dell’immagine deve essere sottoposto a wiping. La procedura consiste nell’azzeramento del contenuto dell’hard disk, su tutta la sua consistenza. Per effettuare ciò esistono degli strumenti ad hoc tra cui Wipe, che viene descritto nel paragrafo 1.3.1.4. Si tenga presente che l’operazione di wiping deve essere documentata nel report di analisi forense, a prescindere dal fatto che quest’ultimo sia o meno collegato ad un’operazione di incident response. Si consiglia di effettuare un wiping una volta terminato l’esame precedente; in ogni caso deve essere effettuato (e documentato) prima della successiva acquisizione.

Pagina 18 di 334

1.1.4

Integrità e disponibilità delle fonti di prova Abbiamo accennato alla necessità, successivamente alla rilevazione dell’intrusione, di non effettuare operazioni sul computer oggetto dell’indagine e di effettuare il più presto possibile le immagini dell’hard disk. Può anche succedere che la rilevazione dell’intrusione da parte del soggetto attaccato non sia tempestiva rispetto all’attacco vero e proprio e che, quindi, un certo numero di operazioni sui dati e sul sistema possano essere state effettuate nel frattempo dagli utenti finali; inoltre i i interessati possono essere di diverso tipo (hard disk, tape, floppy-disk, PDA, CD, ecc.) a seconda della complessità dell’architettura e della rete. Elenchiamo di seguito alcuni elementi che possono, più di altri, inficiare l’integrità e la disponibilità delle fonti di prova, allo scopo di valutare l’attendibilità di queste nel momento in cui si decide di utilizzarle e di effettuare, quindi, l’immagine del media: a) l’utilizzo di data compression, deframmentazione di dischi e programmi di ottimizzazione; b) il o il trasferimento di file di grosse dimensioni (p.e. immagini .JPG) che sovrascrivono rapidamente i cluster non utilizzati; c) l’uso di programmi che sovrascrivono settori di disco con stringhe di “0” (p.e. Wipe-info di Norton Utilities); d) il riutilizzo di nastri di backup; e) l’installazione di nuovo software applicativo; f) la configurazione di sistemi operativi e di partizioni; g) la cancellazione di temporary internet files, browser history e cookie; h) la modifica del time clock del computer; queste azioni, se effettuate, potrebbero alterare, cancellare o modificare in maniera importante le prove da recuperare.

1.1.5

i Utilizzabili (Media) I i per creare le immagini devono essere scelti in base ad alcuni criteri: • Dimensioni dei dischi da copiare – i media su cui effettuare le copie devono essere capienti sufficientemente per contenere l’immagine dei dischi origine; Si consiglia, ove possibile, usare un drive di destinazione con una misura superiore almeno del 25% del source drive. • L’integrità da preservare – la copia effettuata deve essere protetta da successive scritture; • La durata del materiale con il quale è composto il o – il materiale con il quale è costruito il media deve fornire adeguate garanzie di durabilità nel tempo per essere conservato a fronte del prolungarsi delle indagini o per poter essere archiviato opportunamente; L’uso delle buste antistatiche è fortemente consigliato. • La diffusione della tecnologia atta a leggere/scrivere il o – la tecnologia di lettura/scrittura deve essere sufficientemente diffusa da garantire l’accesso ai dati contenuti nei media anche a distanza di tempo dal momento della creazione dell’immagine. Pagina 19 di 334

Per quanto riguarda le tecnologie delle unità di memorizzazione, vengono descritte di seguito le caratteristiche di quelle più diffuse dalle quali si possono evincere i requisiti sopra indicati: •

HARD DISK4: sono apparecchiature sulle quali vengono memorizzate i sistemi operativi, i software applicativi e i dati, sotto vari formati, che gli utenti finali creano. Gli hard disk sono di diverse tipologie: i più comuni sono IDE, altri sono SCSI, Fiber Channel oppure FireWire. Tutte le tipologie operano nel medesimo modo; essi sono suddivisi in partizioni, in grado di accedere direttamente ai dati e hanno la capacità di associare il file alla localizzazione fisica. A livello hardware, il disco è composto di tracce, cilindri e settori; quando un disco è formattato le tracce fisiche sono predisposte in modo che i dati possano essere memorizzati in esse. I settori sono porzioni di tracce e di solito sono segmentati in multipli di 512K. A livello logico la modalità in cui i file sono organizzati dipende dal particolare sistema operativo utilizzato, di cui i più importanti per i nostri scopi sono Windows, Unix e Linux (Fig. 5).

Figura 5: Componenti principali dell’Hard Disk

Una volta che il sistema operativo è installato, i cluster possono essere organizzati raggruppando logicamente i settori fisici insieme; un cluster è la più piccola unità di memorizzazione che il sistema operativo può utilizzare per memorizzare un file e ciascun cluster deve essere riempito completamente: in altre parole non possiamo avere un cluster che è solo parzialmente pieno. La struttura di file basato su architettura Windows-DOS è normalmente un gruppo di partizioni che mappa logicamente la lettera di un disco come “A”, “C”, ecc.; la struttura di file basata su Unix e Linux hanno anch’esse partizioni, ma utilizzano il concetto di file system. •

4

DISCHI RIGIDI REMOVIBILI: Sino ad alcuni anni fa, tra le unità disco di grossi sistemi (supermini, mainframe) erano comuni le unità a disco rigido removibile (removable harddisk); tali unità permettevano l'intercambiabilità dei piatti nella medesima unità di letturascrittura. L'operatore poteva cambiare i pacchi di dischi (i cosiddetti "padelloni") mettendo così in linea dei i removibili ad accesso diretto. Questo genere di dispositivo è scomparso dai moderni grossi sistemi mentre a livello di personal computer si sono diffuse unità in grado di leggere dischi removibili di piccolo diametro, costituiti da piatti rigidi da 5", 3.5" e 2.5", racchiusi in una custodia di plastica, con capacità di centinaia di megabyte e un tempo d'accesso medio paragonabile a quello dei dischi fissi. Dispositivi di questo tipo sono consigliabili nelle situazioni in cui ci sia necessità di memorizzare grosse quantità di dati

Al momento in cui scriviamo, la grandezza massima di un Disco è di 500 Gb.

Pagina 20 di 334

senza necessariamente conservarne costantemente l'accesso in linea e come dispositivo per compiere copie di sicurezza (backup). Non esistono standard, e i diversi prodotti utilizzano tutti soluzioni proprietarie. Tra i più diffusi dispositivi di questo tipo vi sono gli Zip e i Jaz della Iomega, i Bernoulli e i Syquest. •

DISCHI OTTICI: un disco ottico (optical disk) è un dispositivo costituito da un piatto rigido sul quale viene proiettato un raggio laser; sulla superficie del piatto i bit sono scritti in modo che il tipo di riflessione della luce laser sia differente per i valori zero e per i valori uno. Quella dei dischi ottici è una tecnologia recente (metà degli anni '80) e in forte evoluzione. I suoi vantaggi sono molti, tra questi: a) una densità di memorizzazione, a parità di superficie, potenzialmente molto superiore rispetto alla tecnologia magnetica; b) maggior sicurezza: grazie alla lettura tramite laser, le testine non si avvicinano mai a più di 1 mm dal disco; inoltre ditate e polvere non modificano considerevolmente le caratteristiche di riflessione, i campi magnetici non influiscono, ecc.; c) maggiore durata nel tempo non essendoci rilevanti problemi di ossidazione dei i; d) possibilità di produzione di copie mediante stampa, in particolare per quanto riguarda i CD-ROM. I principali tipi di dischi ottici e le relative tecnologie sono descritte di seguito: WORM (Write Once Read Many): il disco è realizzato con un materiale di memorizzazione (tellurio o polimeri opachi) racchiuso in un sandwich di piatti in plastica; la scrittura consiste nella «bruciatura» di un minuscolo punto (pit), e la presenza o assenza (land ) del foro creato da tale microbruciatura determina le proprietà di riflessione del o e quindi il valore del bit. Non esiste ancora una standardizzazione per questi prodotti: un disco scritto da un dispositivo di un certo tipo difficilmente può essere letto da un altro. Esistono dischi nei diametri di 5, 8, 12 e 14 pollici. La capacità di un disco WORM varia da 300 a 700 Mbyte per lato per dischi da 5". MO (Magneto Optical): i dischi magneto-ottici sono costituiti da un sandwich di policarbonato o vetro e materiale magnetico, ruotano a velocità angolare costante e i dati sono organizzati in tracce e settori. Il loro funzionamento sfrutta due leggi fisiche: la temperatura di Curie e l’effetto di rotazione di Kerr. La scrittura avviene immergendo l'intera superficie del disco in un campo magnetico e riscaldando con un laser (della potenza di circa 40 mW) i punti che devono essere scritti. Quando il laser porta la superficie oltre la temperatura di Curie il materiale, solo in quel punto, assume una polarità magnetica pari a quella del campo in cui è immerso. Il resto della superficie rimane inalterato. Si osservi quindi che la scrittura è magnetica ma la densità è maggiore rispetto a quella ottenibile con testine magnetiche perché determinata dalla capacità di localizzazione del raggio laser. Per evitare di dover effettuare la scrittura in due tempi (per esempio prima gli 1, poi si inverte il campo magnetico e si scrivono gli 0) e per ridurre i consumi energetici e la complessità del sistema (dopo aver scritto gli 1, il laser va soltanto dove si devono scrivere gli 0), la Sony ha realizzato un sistema magneto-ottico in cui, mentre la testina laser scalda uno dietro l'altro tutti i punti della traccia dalla parte superiore, un piccolo induttore genera un campo magnetico della polarità opportuna sul lato opposto. Tale sistema è utilizzato nel MiniDisc, nato come o musicale digitale ma adatto anche alla registrazione dati. La lettura di un disco magneto-ottico avviene osservando la rotazione della polarizzazione del raggio laser di lettura (di minor potenza di quello di scrittura) quando viene riflesso dalla superficie del Pagina 21 di 334

disco. L'effetto di rotazione di Kerr provoca una rotazione in due versi opposti a seconda della magnetizzazione della superficie. I dischi magneto-ottici usano il formato da 5", hanno un tempo d'accesso non eccezionale (15-17 millisecondi) ma un buon tempo di trasmissione (ruotano a circa 3600 giri); un disco riscrivibile è utilizzabile continuamente per almeno 10 anni. Phase change: i dischi a variazione di fase sono realizzati con un sandwich di materiali il più importante dei quali è uno strato, spesso circa 200 ångström, di tellurio o selenio; come i dischi magneto-ottici ruotano a velocità angolare costante e i dati sono organizzati in tracce e settori. Ciascun bit viene scritto come spot utilizzando un raggio laser di 8 o 18 mW, che trasforma il punto rispettivamente in una zona cristallino o amorfa; la lettura avviene proiettando un raggio di bassa potenza che viene riflesso con intensità diversa a seconda che il punto si trovi in stato cristallino o amorfo. I dischi a cambiamento di fase sono riscrivibili direttamente (non richiedono una cancellazione e successiva scrittura come i magneto-ottici). Esistono in commercio lettori in grado di utilizzare sia dischi WORM sia dischi a variazione di fase. CD-R (CD-Recordable), sono CD registrabili un'unica volta a costi contenuti ma con un costo per copia superiore rispetto ai CD-ROM. Sono composti da dischi di policarbonato che racchiudono un foglio centrale d'oro ricoperto di pittura traslucida che si comporta come la parte land dei CD. La registrazione consiste nel bruciare punti nello strato di pittura, simulando i pit. Il master e il dispositivo di masterizzazione hanno un costo oggi contenuto, mentre i i vergini e registrabili hanno un costo molto superiore a quello di una copia di un CD-ROM stampato. Tuttavia, sono estremamente convenienti per tutte le esigenze di realizzazione di copie singole, prototipi di CD-ROM e archiviazione di dati. Nei CD-R è possibile registrare le informazioni in più momenti successivi (sessioni). Le sessioni sono separate da spazi detti gap che sprecano, tuttavia, una grande quantità di spazio. I dispositivi di lettura (drive) che ano più registrazioni sono detti multisessione. CD-RW (CD-ReWritable), detti a volte CD-E (CD-Erasable) sono gli ultimi arrivati sul mercato: sono cancellabili e riscrivibili. Usano la tecnologia del phase-change e hanno un ambito di utilizzo analogo a quello degli altri tipi di dischi ottici con il vantaggio di usare un drive unico compatibile con i CD-ROM e i CD-R. DVD (Digital Video Disc o Digital Versatile Disc): hanno lo stesso diametro di un CD-ROM ma sono una tecnologia più recente, molto più veloci (equivalente a una 9x nella prima versione realizzata, ma le successive vanno ben oltre) e molto più capienti. Sono disponibili in tre diverse versioni, come i CD: DVD-ROM, DVD-R (recordable) e DVD-RAM ma in più possono prevedere una gamma di capacità che varia da 4.7 GB della versione base a una faccia e strato singolo ai 17 GB della versione doppia faccia e doppio strato. Come nei CD, la codifica del dato avviene per alternanza di pit e land ma la lunghezza minima del pit è di 0.4 µm, la metà rispetto a un CD. Anche la spaziatura tra giri successivi della spirale di memorizzazione è inferiore rispetto ai CD: 0.74 µm. Per leggere i pit più piccoli, il meccanismo usa una luce laser rossa con lunghezza d'onda da 635 a 650 nanometri (la stessa usata dai lettori di codici a barre). Come i CD, i DVD possiedono uno strato di materiale riflettente sotto uno strato di policarbonato. Nei DVD a doppio strato, un secondo strato semi-riflettente viene posto sopra allo strato completamente riflettente e il laser è in grado di leggere entrambi (lo strato semi-riflettente, tuttavia, raggiunge una capacità massima di 3.8 GB contro i 4.7 di quello completamente riflettente). I DVD possono essere registrati su entrambi i lati, su singolo o doppio strato. I DVD-R sono analoghi ai CD-R: uno strato di Pagina 22 di 334

sostanza organica che può essere "bruciata" permette la registrazione (un'unica volta). Analoghi ai CD-E sono i DVD-RAM, basati su tecnologia phase-change. Sia i DVD-R, sia i DVD-RAM raggiungono capacità massime inferiori ai DVD-ROM. Una delle maggiori innovazioni dei DVD consiste nel fatto che possono impiegare dispositivo sia CAV (velocità angolare costante, come dei dischi magnetici organizzati in tracce concentriche), sia CLV (velocità lineare costante sull'unica traccia a spirale). Sin qui si è trattato del «formato fisico»: circa, invece, il «formato logico», i DVD usano uno standard chiamato UDF (Universal Disc Format) che è un sottoinsieme dello standard ISO-13346 per lo scambio di dati utilizzabile con diversi sistemi operativi (DOS, Windows, MacOS, Unix e OS/2). •

TECNOLOGIE A NASTRO: un o ricoperto di sostanza magnetica, in genere ossido di ferro, scorrendo sotto una testina di registrazione, offre via via a questa, aree interpretabili come celle di informazioni binarie. I nastri magnetici hanno il vantaggio di essere chiusi in un involucro di plastica che li protegge dalla polvere e dagli agenti esterni. Attualmente i nastri più usati sono i cosidetti "streamer" che possono arrivare ad avere una capacità di memoria di più GB e una velocità di trasferimento di 200 Kb/s. Questi streamer sono usati principalmente per copie di sicurezza. La testina di registrazione consiste in un traferro sul quale e' avvolto a spirale un filo conduttore. Inviando corrente su questo filo, il suo percorso a spirale genera un campo magnetico che ha una delle due direzioni possibili a seconda del verso con cui a la corrente. Il campo magnetico induce una magnetizzazione permanente sull'areola di superficie magnetica sottostante; e l'areola rimane magnetizzata in quel verso anche quando non si trova più in prossimità del campo magnetico stesso. L'informazione binaria si potrà perciò recuperare anche dopo molto tempo con il procedimento inverso: sulla testina si rileva il verso della corrente indotta in prossimità del campo magnetico dell'areola. Le due operazioni di invio del segnale necessarie alla registrazione e alla ricezione del segnale per il rilevamento si chiamano rispettivamente scrittura e lettura. Il o magnetico e' un o "recuperabile". Infatti si possono modificare gli stati di magnetizzazione delle celle di memoria con il dispositivo di lettura/scrittura, poiché la scrittura magnetizza la superficie nel verso voluto indipendentemente dallo stato di magnetizzazione preesistente. Uno stesso o può così essere riutilizzato per conservare nuove informazioni quando le precedenti non servono più. Le singole celle di superficie vengono offerte alle testine per la scrittura-lettura mediante il movimento della superficie stessa. Il dispositivo di lettura-scrittura e' quindi fisso e sotto le testine scorre la superficie magnetica. L'individuazione dei singoli bit avviene mediante un segnale di sincronismo di durata temporale pari a quella del aggio di corrente sull'avvolgimento relativo a ciascun bit. I principali tipi di i a nastro magnetico e le relative tecnologie sono descritte di seguito: BOBINE: Le capacità dei nastri a bobina sono molto variabili, dai 50Mb ai 1,2Gb. I nastri a bobina sono strutturati a tracce parallele per poter così trasmettere un intero byte contemporaneamente e suddivise in due gruppi a funzioni separate: uno per la lettura e l'altro per la scrittura del nastro. Su ogni traccia e' impressa una sequenza di 0 e 1 in modo che la lettura vericale produca 8 bit più uno di controllo. Ad intervalli regolari, lungo ogni traccia, un ulteriore bit viene utilizzato per controlli incrociati di consistenza L'ultimo bit sarà uguale ad 1 se negli altri 8 il numeri di 1 sarà dispari, altrimenti 0. Il controllo incrociato consente di Pagina 23 di 334

individuare con sicurezza il singolo errore, dandoci le esatte coordinate. Gli errori possono essere causati da diversi eventi. Quelli più ricorrenti sono quelli di danneggiamento del nastro dovuti a casualità o a strappi di partenza o di arrivo del nastro stesso. Per questo motivo i registratori di bobine sono muniti di rulli trascinatori e di dispositivi di aspiramento nastro. Le testine di lettura vengono posizionate dopo quelle di scrittura, nel senso del o, in modo da controllare la correttezza di registrazione durante la fase di scrittura. A diverse dimensioni di nastro corrispondono diverse prestazioni. I nastri più grandi e più robusti permettono maggiori accelerazioni e decelerazioni essendo più resistenti alla rottura, rispetto al nastrino della cassetta, e sono più affidabili. Per quanto riguarda i tempi di accelerazione e decelerazione si e' pensato di inserire degli spazi vuoti tra un blocco di informazioni e un altro di modo che sfruttando lo spazio vuoto il nastro abbia tempo di arrivare alla velocità giusta per poter leggere il blocco seguente. Vantaggi E' conveniente l'uso delle bobine per la velocità di trasferimento dati, per l'alto numero di informazioni immagazzinate con scarso ingombro e per il basso costo delle bobine stesse, che sono riutilizzabili, anche se lo sfregamento delle testine di lettura e scrittura sulla superficie del nastro ne comporta il deterioramento nel tempo. Svantaggi Sono le probabili alterazioni della magnetizzazione, se le bobine non vengono conservate in un ambiente adatto, e soprattutto l'accesso obbligatoriamente sequenziale alle informazioni. NASTRI A CASSETTA: i nastri a cassetta hanno capacità più modeste, vanno fino a 105Mb, rispetto ai nastri a bobina. Inoltre hanno una sola traccia che si snoda avanti ed indietro lungo tutto il nastro. Avendo una sola testina i tempi di accesso sono lunghissimi e gli strappi di partenza o arrivo sono molto frequenti. Ciò significa che questi nastri oltre ad essere molto lenti sono pure poco sicuri. Questo tipo di nastri si rifà ai cosiddetti streamer. Tali sistemi sono ideati per essere usati su sistemi informatici personali o comunque di piccole o medie dimensioni dove lo spazio non e' molto ed i costi devono essere contenuti. Gli streamer vengono quindi inseriti direttamente nell'unità centrale insieme ai lettori per floppy e ad eventuali lettori CD. Riguardo agli streamer e' bene ricordare che vi sono molti tipi di lettori a nastro e di cassette differenti. DAT: I nastri di derivazione Digital Audio Tape sono nastri di derivazione audio, sono molto sottili ed utilizzano pratiche cassette di piccole dimensioni (simili alle musicassette). La testina di lettura-scrittura non è fissa come nei nastri a bobina o a cassetta, ma è mobile e ruota velocemente segnando il nastro diagonalmente. Si ottiene che la velocità di scorrimento del nastro rispetto alla testina può essere mantenuta ad alti livelli (più alta e' la velocità di scorrimento, più bit si possono memorizzare per unità di lunghezza). Al tempo stesso, la velocità di scorrimento delle bobine del nastro non richiede di essere particolarmente elevata (per evitare l'usura meccanica del nastro e' meglio avere una bassa velocità di avvolgimento delle bobine). Tali nastri possiedono altissime capacità, dai 1,2GByte (circa un miliardo di Byte) dei modelli più economici (costo di circa un paio di milioni di vecchie lire), ai 4GByte per i modelli più Pagina 24 di 334

professionali (costo che si aggira sui 20 milioni). Questi ultimi comprimono i dati ancor prima di memorizzarli sul nastro per decomprimerli in fase di lettura.

Pagina 25 di 334

1.2

Definizione di un sistema adeguato di comunicazione protetta In caso di intrusione o di attacco è necessario aver negoziato preventivamente con i gruppi di intervento specialistico un sistema di comunicazione che sia sicuro, veloce e separato dalle risorse danneggiate. In fase di definizione delle policy potrà essere quindi deciso di utilizzare delle tipologie di mezzo definite offline. Tutti i soggetti coinvolti in queste comunicazioni devono essersi preventivamente accordati sulle modalità di comunicazione e di reciproca autenticazione. Le procedure di risposta all’attacco devono anche tenere presente che persino l’atto di comunicazione tra due persone, specialmente se determina un incremento del traffico quotidiano e se è crittato, può indicare all’attaccante che è stato scoperto. Per questo motivo, può essere utile non utilizzare le e-mail, ma mezzi alternativi, come il fax o il telefono. Di base questo significa che, nell’organizzazione di un piano di Incident Response, deve essere prevista la compilazione di una list da utilizzare, che comprenda anche i contatti relativi alle Forze dell’Ordine ed ai legali. Se i meccanismi di comunicazione sono basati sulla crittografia, un ulteriore aspetto da considerare è la manutenzione e l’autenticazione delle chiavi. Questo sta a significare che si deve accertare la fonte da cui otteniamo la chiave, per essere sicuri che non sia stata compromessa o addirittura sostituita. Se il numero di soggetti con cui si è in relazione è elevato, questo lavoro potrebbe essere molto dispendioso. In questi casi ci si può affidare ad una Certification Authority (CAs), oppure si può decidere di verificare solo le chiavi di soggetti esterni alla nostra organizzazione. Nel caso in cui non si riesca a comunicare utilizzando Internet o la intranet aziendale, conviene ricorrere a metodi alternativi, come connessioni dirette via modem, per mantenere almeno un contatto con i settori critici. E’ comunque consigliabile inserire in un report tutte le comunicazioni di questo genere. Segue un’analisi delle possibili modalità di comunicazione: •

Paragrafo 1.2.1 1.6.1 E-mail (Regole generali, Crittografia (PGP)

•

Paragrafo 1.2.2 Telefonia fissa (Regole generali, Chat (IRC,mIRC, ICQ), Telefax, NetMeeting e Cuseeme, Voice-Over-IP, Crittografia (PGPfone, Speak Freely, VoiceWeaver)

•

Paragrafo 1.2.3 Telefonia Mobile (Regole generali. TACS, GSM, GPRS e UMTS)

1.2.1

E-Mail Regole generali L’obiettivo è riuscire a comunicare in modo protetto anche a seguito di intrusioni accertate sui sistemi di messaggistica. Questa scelta, pur essendo comunque intrinsecamente rischiosa, deve essere contemplata come possibile.

Pagina 26 di 334

Risulta preferibile non generare traffico sulla rete locale, ma utilizzando una macchina isolata; è quindi opportuno inviare e-mail da un computer “sicuro”, esterno alla rete che è stata compromessa. Eventualmente si potrebbe creare a priori un dedicato alla comunicazione con i gruppi di intervento. Inoltre, al fine di impedire all’attaccante di sniffare il traffico sulla rete, e di garantire l’identità del soggetto con cui si sta comunicando, è consigliabile utilizzare una tecnica crittografica (PGP). Crittografia (PGP) PGP è un software di crittografia per la posta elettronica e la protezione dei file. Il suo utilizzo è gratuito per uso privato e a pagamento se si vogliono avere maggiori funzionalità. E’ possibile effettuare il dell’eseguibile da Internet, all’indirizzo http://www.pgpi.com ( PGP, GPG e tool vari). Al momento della sua istallazione, viene richiesto di immettere un identificativo e una phrase che servirà a limitare l’utilizzo della chiave privata ai soli conoscitori della phrase stessa.

Figura 6: PGP Key Generation Wizard

A questo punto viene generata una coppia di chiavi: •

la chiave privata dovrà essere salvata sulla macchina e su un o esterno alla macchina, per garantirne il mantenimento anche in seguito a guasti o malfunzionamenti. Essa dovrà essere mantenuta privata e non dovrà essere presente sulle altre macchine;

•

la chiave pubblica, invece, andrà scambiata con tutti i gruppi di intervento. Per evitare che il setup di questi fondamentali parametri debba essere svolto velocemente e senza i dovuti controlli, è importante che le chiavi vengano generate e scambiate prima dell’intrusione, nel momento in cui vengono definite le modalità di comunicazione.

Pagina 27 di 334

Per una corretta comunicazione con i gruppi di intervento è quindi necessario essere in possesso di: •

una coppia di chiavi relativa all’organizzazione di cui si fa parte (una pubblica e una privata);

•

le chiavi pubbliche di tutti i soggetti con cui dovremo scambiare messaggi in caso di attacco. A seguito dell’intrusione, tutte le e-mail in partenza dalla macchina dovranno essere firmate e crittate con PGP. In questo modo verrà anche generato un codice hash che permetterà al destinatario di controllare che l’e-mail non abbia subito modifiche durante il viaggio. Tutte le e-mail ricevute, invece, andranno decrittate e la firma digitale dovrà essere verificata ogni volta. Per avere ulteriori informazioni riguardanti l’utilizzo di questo software, fare riferimento alla “Guida pratica a PGP”, recuperabile all’indirizzo http://www.pgpi.org/docs/g_pgp952.htm.

1.2.2

Telefonia Fissa Regole generali Nella telefonia fissa esiste un range di intercettazioni di natura illecita sui quali le Autorità competenti non hanno visibilità. Per questo motivo, nelle procedure di Incident Response, è consigliabile, se si opera su segmenti di reti IP, cifrare il traffico telefonico. Il metodo più economico, sicuro ed efficiente di effettuare telefonate cifrate consiste nel munirsi di un apposito software per PC (supponendo di possedere già modem, scheda sonora, microfono e cuffie). Il software si occupa di digitalizzare la voce proveniente dal microfono in dati che vengono poi compressi, crittati e trasmessi via modem. La voce diventa quindi una sequenza di bit che, dopo compressione e cifratura, è pronta per essere inviata al nostro interlocutore (vedi tabella 1, 2).

Voce Microfono Digitalizzazione Compressione

Pagina 28 di 334

Crittazione Trasmissione Tabella 1: Invio della voce sulla rete

Ricezione Decrittazione Decompressione Cuffie Voce

Tabella 2: Ricezione della voce dalla rete

Questi programmi sono molto più efficaci dei vecchi scrambler: forniscono la possibilità di crittare le telefonate con sistemi di crittografia robusta, non decifrabile da chi non è in possesso della chiave necessaria, se non disponendo di un potente computer dedito per anni soltanto alla decrittazione. In alcuni casi nemmeno molti anni di lavoro-macchina sono sufficienti, il che rende questi algoritmi computazionalmente sicuri. Disponendo di una connessione alla rete è inoltre possibile evitare telefonate a lunga distanza, collegandosi al più vicino Internet provider e inviando i pacchetti direttamente all’indirizzo IP dell’interlocutore, e viceversa. Se da un lato il meccanismo funziona e grazie al crittosistema utilizzato la riservatezza è assicurata, dall’altro le telefonate via Internet lasciano un po’ a desiderare in fatto di qualità audio e velocità di risposta. Chat (IRC, mIRC, ICQ) Il problema principale in IRC (Internet Relay Chat) è che il proprio IP è visibile per chiunque: è infatti possibile avere informazioni sullo e sul server a cui si sta connettendo semplicemente effettuando un /whois nick. Inoltre, attraverso il comando /dns nick è possibile ricavare l’indirizzo IP del client. Utilizzando questo tipo di tecnologia è quindi possibile essere soggetti a differenti tipologie di attacchi D.o.S., tra cui: Pagina 29 di 334

•

Bonk

•

Land

•

Teardrop

•

Click

•

Ssping

•

WinNuke

•

ICMP Flood

•

Smurf

•

Ping Pattern

•

SYN Flood

•

Bloop (Flushot)

•

Igmp (Pimp/Kod)

Esistono differenti client IRC, a seconda del sistema operativo utilizzato (vedi tabella 3). Sistema Operativo Windows UNIX MacOS

Programma Chat mIRC xchat Ircle

URL ( http://www.mirc.com ) ( http://www.xchat.org ) ( http://www.ircle.com )

Tabella 3

Per quanto riguarda mIRC (vedi fig. 7), oltre ai pericoli derivanti da IRC, ne aggiunge altri: •

il client senza uso di script è di per sé sicuro: nella peggiore delle ipotesi sono stati trovati bug che mandavano in crash il solo client, senza pericolo per il resto del sistema;

•

gli script sono sempre stati la sede di backdoor e, considerando anche i file .EXE allegati, di trojan e virus.

Pagina 30 di 334

Figura 7: mIRC in funzionamento

Con queste premesse, possiamo individuare delle regole per utilizzare questo strumento cercando di correre meno rischi possibili: •

Non usare script di cui non se ne conosce il codice e la provenienza con sicurezza. Poche linee di malicious code all’interno di uno script possono rendere il proprio sistema in balia dell’attaccante. Quest’ultimo potrebbe violare la privacy attraverso la lettura dei messaggi e la registrazione delle azioni compiute; oltre a questo il sistema diventerebbe altamente vulnerabile per la possibile esecuzione di comandi dannosi (ad es. format);

•

Nascondere il proprio IP. Con questa logica nasce in alcuni server non ircnet il mode+x, che permette di nascondere agli altri (eccetto ircop) il proprio IP. In questo modo, si rende il proprio sistema meno vulnerabile ad attacchi del tipo D.o.S. o spoofing;

•

Usare un socks server come relay. Configurando il proprio client IRC in questo modo, sarà possibile chattare collegandosi attraverso il socks e nella chat apparirà come proprio IP quello del socks server. In questo modo tutti gli attacchi rivolti a voi e ranno verso il socks server (solitamente una macchina *nix più stabile in rete). Usare socks "aperte al pubblico" non è permesso su tutti i server IRC: alcuni server prima di permettere il collegamento del client verificano lo stato della porta T 1080 per impedire, in caso affermativo, la connessione (il socks server infatti è in ascolto sulla 1080). Trovare Socks aperte al pubblico non è difficile: ci sono in circolazione scripts per mIRC che eseguono una scansione dei canali alla ricerca di porte 1080 in ascolto. Per quanto riguarda ICQ (vedi Fig. 8), continuano ad esistere tutti i problemi legati alla visibilità del proprio IP e alla possibilità di ricevere file infetti. A queste vulnerabilità, già discusse in precedenza, si aggiunge l’estrema semplicità del protocollo e del software, estremamente insicuri. Pagina 31 di 334

Risulta quindi possibile, utilizzando questo strumento, essere soggetti ad attacchi di vario tipo, tra cui: • Spoofing del proprio indirizzo IP; • Esecuzione di codice arbitrario da parte della propria macchina attraverso un buffer overflow; • Blocco del proprio sistema attraverso un D.o.S.

Figura 8: ICQ

NetMeeting e Cuseeme Netmeeting (vedi fig 9) è un software gratuito, reperibile attraverso: •

Alcune versioni di Windows;

•

CD di installazione di Internet Explorer;

Per avere la versione più aggiornata, è consigliabile scaricarlo all’indirizzo http://www.microsoft.com/windows/netmeeting. Il suo utilizzo è finalizzato alla trasmissione e ricezione di immagini real video a colori e suoni in diretta, attraverso una qualsiasi rete compatibile con il protocollo T/IP (quindi reti LAN, VPN ed Internet). La trasmissione dei dati avviene attraverso scambio bidirezionale di pacchetti.

Pagina 32 di 334

Figura 9: NetMeeting

Grazie ai nuovi standard di compressione CODEC dei dati, con una banda ante di soli 56K effettivi (quella di un comune modem analogico su linea telefonica tradizionale PSTN) consente una più che buona qualità video, con soglia di refresh (movimento dell'immagine) anche inferiore ad un secondo, e una definizione (in assenza di movimenti costanti e rapidi dei soggetti o degli oggetti ripresi) che può arrivare ad essere molto soddisfacente. Quest'ultimo fattore dipende molto anche dalla qualità della webcam utilizzata per le riprese. Lascia invece a desiderare l'aspetto audio, che è il primo a risultare poco affidabile in caso di banda insufficiente. A questo problema (e anche per ottimizzare lo streaming video) si rimedia comunemente bloccando da entrambe le parti la trasmissione audio (che impegna una quantità consistente di banda ante anche quando la qualità acustica è scadente) e si utilizza un'altra linea telefonica (ad es. GSM) per comunicare oralmente. Per queste ragioni, si consiglia di utilizzare Netmeeting più per le sue funzioni video che audio, eventualmente integrandolo con una normale telefonata su altra linea. Per ovviare al problema dell'interconnessione diretta dei PC via Internet (servirebbe conoscere e digitare tutte le volte l'indirizzo IP del computer corrispondente) Microsoft ha messo a punto da anni uno standard definito ILS (Internet Locator Server) che consta di numerosi server presenti nel WEB e dedicati a questa funzione "ponte" fra i vari PC. I server ILS registrano all'atto della connessione gli estremi dell'utente di Netmeeting, ma soprattutto memorizzano l'IP del computer utilizzato, consentendo una localizzazione certa e automatica senza necessità di conoscere ogni volta l'IP del computer da chiamare. Data la dinamicità dell’indirizzo IP, i server ILS pubblici svolgono anche un prezioso servizio pratico, poiché consentono di rintracciare sempre l'utente tramite uno name fisso (nickname), facilmente individuabile e memorizzabile, senza doversi preoccupare di conoscere l'IP del computer da chiamare. Pagina 33 di 334

Netmeeting mette in diretta connessione via Internet due PC tramite i relativi IP, con la possibilità (opzionale) di condividerne le risorse: lo standard di sicurezza di questo sistema è quindi relativamente modesto, sebbene incrementato nelle versioni più recenti. Netmeeting ha già presentato in ato gravi falle nella sicurezza, risolte di volta in volta da Microsoft. Per un utilizzo sicuro di questo software si raccomanda: •

L'installazione dell'ultima versione disponibile;

•

L’utilizzo della crittografia base;

•

La scelta della modalità protetta;

•

L’utilizzo di un firewall (test hanno dimostrato che Zone Alarm Pro non influisce sul corretto funzionamento di NetMeeting).

In ogni caso, è bene non attivare questo sistema se si prevede di dover trattare immagini critiche o che implichino problemi di sicurezza alle cose o alle persone, inclusi i dati presenti nel computer utilizzato. Netmeeting è comunque sempre un prodotto Microsoft su T/IP, quindi anche il miglior grado possibile di sicurezza rientra in uno standard decisamente limitato. L'alternativa professionale a quanto sopra è Cuseeme (vedi fig. 10) della Cusoft.

Figura 10: Cuseeme

Sviluppato nel 1993 dalla Cornell University, Cuseeme è un prodotto efficace e completo, ma dal costo non proprio ridotto; è basato su un principio simile ai server ILS di Netmeeting, nel caso specifico denominati reflectors. Consente una più vasta e completa definizione dei parametri di funzionamento, ma soprattutto consente di connettere audiovideo fino a 12 utenti in contemporanea; questa funzione, peculiare di Cuseeme, è però pressoché inutile nel caso di connessioni a 56K. Cuseeme è perfettamente compatibile anche con lo standard ILS e con Netmeeting di Microsoft. Telefax Le comunicazioni a mezzo fax presentano gli stessi inconvenienti delle normali telefonate su linea fissa: i dati sono trasmessi in chiaro e si prestano a facili intercettazioni. Se ne sconsiglia pertanto l’utilizzo per attività di Computer Forensics. In ogni caso, se l’utilizzo di questa tecnologia si rendesse necessario, è utile munirsi di apparecchi, oggi in commercio, che crittano i dati in fase di trasmissione e li decrittano in Pagina 34 di 334

fase di ricezione; con una soluzione di questo tipo, sia il mittente che il destinatario devono essere in possesso dell’apparecchio. Lo stesso risultato può essere ottenuto tramite l’utilizzo di programmi fax per PC, che sfruttano la connessione diretta via modem e permettono la crittazione dei dati trasmessi. Voice-Over-IP Il VoIP è una tecnica di comunicazione basata sulla suddivisione della voce in pacchetti IP, che vengono trasmessi sul cavo fino alla destinazione sfruttando la rete Internet o attraverso un collegamento diretto (Point-To-Point). Il funzionamento è identico a quello delle normali reti che utilizzano i protocolli T/IP e UDP/IP. Applicata al traffico vocale questa tecnica non dà risultati soddisfacenti: i pacchetti non arrivano nell’ordine con cui sono stati spediti e la loro attesa e ricomposizione può causare fastidiosi ritardi nella comunicazione. È probabile che questo problema si risolverà quando verrà incrementata la banda di trasmissione dei pacchetti voce. Questa tecnologia risulta a tutt’oggi assai poco diffusa e comunque poco pratica per svolgere attività di Computer Forensics; ne sconsigliamo pertanto l’utilizzo, almeno finché i prezzi dei telefoni IP (oggi molto elevati) non si saranno allineati con gli altri prodotti di telefonia fissa. Crittografia (PGPfone, Speak Freely, VoiceWeaver) Parliamo ora di alcuni programmi utilizzati per cifrare le conversazioni su Internet. PGPfone è un software il cui copyright appartiene a Philip Zimmermann, già noto quale autore del PGP. Informazioni su questo prodotto sono rintracciabili al sito www.pgpi.org. Il programma è distribuito nelle versioni per Windows e Macintosh: non è previsto il o per Linux, a tutt’oggi il sistema operativo freeware più diffuso. Il requisito minimo per installare PGPfone è un Pentium o un Power Mac dotato di modem. La caratteristica fondamentale di PGPfone è che non necessita di un canale sicuro per lo scambio della session key prima dell’inizio della conversazione. Le due parti, infatti, negoziano le chiavi che anno per crittare e decrittare le conversazioni usando il protocollo Diffie-Hellman, che non rivela nulla di utile a un eventuale ascoltatore. In ogni caso, come già detto in precedenza, è consigliabile scambiare le chiavi prima che si verifichi un incidente. L’installazione è piuttosto semplice e rende questo programma adatto anche a persone non molto esperte. Ci sono tre tipi di layout, definibili dal menù Window: minimal (essenziale), intermediate (mostra anche compressione e tipo di cifratura) e advanced (con diversi checksum e statistiche). Tutto il resto si setta dal menu Edit -> Preferences, che è a sua volta diviso in tre sezioni: Phone, Modem ed Encryption. Di seguito le caratteristiche di un altro programma per la crittazione delle telefonate: Speak Freely.

Pagina 35 di 334

In italiano può essere tradotto come “Parla liberamente”, ma anche “Parla gratuitamente”: Speak Freely è distribuito gratuitamente al pubblico e i sorgenti sono disponibili su Internet. Quest’ultima caratteristica è particolarmente apprezzata nei programmi di crittografia, in quanto permette di verificare che non contengano backdoor o bug grossolani. Il programma è disponibile per le piattaforme Windows (vedi fig. 11) nonché per Unix (vedi fig. 12). Le richieste hardware non sono particolarmente esose anche se è noto che con un computer veloce e con tanta memoria è possibile eseguire più applicazioni contemporaneamente e lavorare con maggiore comodità.

Figura 11: SpeakFreely in Windows

Figura 12: SpeakFreely per X

Pagina 36 di 334

Pur essendo la telefonia crittata il principale obiettivo di questo software, segnaliamo l’esistenza di una versione senza questa caratteristica, detta “Spook Freely”, nata per essere utilizzata in quelle nazioni in cui crittare le conversazioni è illegale. Speak Freely può funzionare in due modalità: •

Normal, consigliata ai principianti. È necessario premere il tasto destro del mouse quando si parla, ed è buona norma terminare la frase con la parola “o” (“over” in inglese);

•

Voice activated, utile per risparmiare banda di trasmissione. Ciò è possibile in quanto il programma è in grado di rilevare automaticamente se si sta dicendo qualcosa al microfono e in quel caso trasmettere la voce. Quando, invece, si sta in silenzio, la trasmissione viene automaticamente interrotta. Lo svantaggio è che questa opzione richiede una fase di setup più difficoltosa da configurare: è necessario eseguire prima alcune prove e determinare il giusto volume di attivazione della voce. Bisogna infatti far sì che questo non sia troppo basso, perché altrimenti la trasmissione sarebbe sempre attivata dal rumore di fondo; analogamente il livello non deve essere troppo alto, perché altrimenti anche parlando a voce alta non si attiverebbe mai la trasmissione. Da notare che la modalità voice activated non è utilizzabile con le casse, ma solo se si dispone di cuffie: i normali speaker, ricevendo, potrebbero attivare nuovamente il microfono, genere o un equivalente dell’effetto larsen e impedendo in pratica la conversazione.

Con una rete lenta, quale è generalmente Internet, ci può essere un ritardo sostanziale (già due o tre secondi sono fastidiosi) tra la trasmissione e la ricezione. Questo ritardo è particolarmente elevato se la connessione in rete avviene via satellite e/o se la rete è molto congestionata. È consigliabile, quindi, pianificare una fase di test della struttura a priori, in modo da verificare che essa possa funzionare in maniera efficace in caso di esigenza reale. Se Speak Freely è stato un software molto utilizzato negli anni, non è mai stato disegnato per essere un prodotto vendibile al grande pubblico e non è disponibile una versione aggiornata da molti anni (si veda il sito www.speakfreely.org). Per venire incontro a questa crescente esigenza del mercato, StreamComm ha sviluppato il primo prodotto che può aggiungere ad ogni sito web una comunicazione audio gratis e sicura. VoiceWeaver (vedi fig. 13) è uno dei migliori prodotti disponibili per comunicare con altre persone gratuitamente, attraverso internet. Questo prodotto a la comunicazione vocale come un telefono e permette anche di scambiare messaggi testuali, come ogni “instant messenger”.

Pagina 37 di 334

Figura 13: Voice Weaver

Alcune funzionalità aggiuntive sono: •

Facilità di installazione;

•

Crittazione a 2048 bit;

•

Non esistono spese aggiuntive determinate dalla distanza tra mittente e destinatario.

Tale software può essere acquistato sul sito www.voiceweaver.com.

1.2.3

Telefonia Mobile Regole generali Per quel che riguarda la telefonia cellulare, la situazione attuale non è delle più sicure: moltissimi telefonini sono intercettabili con apparecchi radio di basso costo e davvero alla portata di chiunque. Con l’avvento di nuove tecnologie, però, il grado di sicurezza relativo ai dati trasmessi e ricevuti aumenta sempre più.

1.2.3.1 Tacs A partire dal 1990 il nostro paese è stato completamente invaso da celle utilizzate per la telefonia mobile, prima del sistema analogico TACS e poi della rete digitale GSM che per la prima volta ha visto scendere in campo un gestore privato. Queste celle formano una rete che viene utilizzata prevalentemente per il traffico di fonia (il comune traffico telefonico), ma che si può facilmente adattare anche al traffico di dati. La prima analisi si rivolge alla rete analogica TACS. Se per l'utilizzo come rete fonica la qualità raggiungibile è spesso superiore alla sua sorella GSM, la rete TACS non è mai stata progettata per il traffico di dati. Questo difetto è riscontrabile soprattutto nella gestione Pagina 38 di 334

dello scambio di celle in caso di segnale in movimento; per la fonia qualche disturbo audio è accettabile ma per uno scambio di dati attraverso il modem crea molti problemi. Una possibile soluzione potrebbe essere quella di effettuare il traffico dati sulla rete TACS senza muoversi da una cella a un’altra. È una soluzione accettabile, anche se spesso il cambio di cella avviene lo stesso per problemi di saturazione delle frequenze e potremmo dunque vedere la nostra connessione cadere anche se stiamo immobili. A questo si aggiunge la scarsa sicurezza della rete TACS, facilmente intercettabile con un radio scanner sintonizzato sui 900 Mhz. A causa di entrambe queste limitazioni non si può che sconsigliare questo tipo di traffico. 1.2.3.2

Gsm

Il sistema GSM offre vari tipi di traffico digitale essendo interamente basato sulla digitalizzazione dei segnali. Fra i servizi digitali sono ormai famosi i messaggi SMS, che vengono visualizzati sul display del telefono e che possono essere trasmessi tra cellulari della stessa rete o anche tra reti diverse o addirittura arrivare o essere destinati a Internet. Per il traffico dati puro è stato implementato un protocollo di correzione di errore (MNP10) che permette di raggiungere velocità di 9600 baud anche in movimento sulla rete stessa. Questa velocità viene utilizzata sia per fax che per traffico dati, permettendo quindi accessi liberi da filo da quasi tutto il territorio. La rete GSM utilizza un sistema di crittografia dei dati che, a detta dei gestori, mette chiunque al sicuro da intercettazioni. Su questa affermazione c'è molto da obiettare: basti dire che i ponti di collegamento tra le varie celle (sia via radio sia via filo) sono indifesi. Quando è stata lanciata sul mercato, la rete GSM è stata offerta come una rete “sicura”, in cui l’intercettazione delle telefonate da parte di radioamatori, phreaker o anche da parte delle istituzioni, era impossibile. Il servizio di sicurezza offerto dalla rete GSM riguardava la possibilità di crittare il collegamento tra la parte mobile della rete (il nostro telefono) e la BTS (la cella a cui siamo collegati). L’algoritmo utilizzato per crittare i pacchetti di dati contenenti la nostra voce (il GSM utilizza la modulazione digitale GSMK e un algoritmo TDMA per l’accesso simultaneo di più stazioni al canale radio) viene indicato con la sigla A5. Non essendo un prodotto di pubblico dominio, i suoi sorgenti di sviluppo non sono liberamente reperibili. Questo dato induce a una maggiore prudenza e a legittimi dubbi sull’affidabilità dell’algoritmo stesso. La nascita dell’A5 non è espressamente legata alla rete GSM. L’algoritmo venne adottato dopo una lunga battaglia tra i vari paesi appartenenti al consorzio paneuropeo da cui nacque la necessità di creare un sistema di telefonia digitale sicuro e standardizzato. Allo stato attuale esistono degli esperimenti di cracking dell’A5, ma l’algoritmo è ancora giudicato fondamentalmente robusto.

Pagina 39 di 334

1.2.3.3 GPRS e UMTS La tecnologia Gprs è un’evoluzione dello standard Gsm, di cui utilizza la rete di trasporto. Il transito dei dati occupa, quindi, la capacità di trasmissione che il traffico voce Gsm lascia libero nell’unità di tempo. Se la rete Gsm è saturata dal traffico voce, situazione che può verificarsi sovente in alcune fasce orarie, la trasmissione dei dati può subire un vistoso calo di velocità. La rete Umts è, invece, completamente a commutazione di pacchetto e permette al 100% della sua base clienti di ottenere prestazioni accettabili nel trasferimento dei dati. Nella tabella che segue vengono evidenziate le maggiori differenze nelle prestazioni delle due reti. Bandalarga Velocità max teorica Velocità reale* Navigazione su Web Durata reale (1,5Mb) Multimedialità interattiva Streaming audio Streaming video Videotelefonia Qualità video Visualizzazione 3D Livello di interattività Popolazione attiva max** Interfaccia utente dei terminali Applicazioni simultanee (multisession) Memoria terminali Sicurezza transazioni Integrazione satellitare

Gprs

Umts

no 171.2 Kbps 30 Kbps Simile ad un modem analogico

Sì 2 048 Kbps 300 Kbps Simile all’Adsl

400 secondi

40 secondi

No Sì No Sì No A scatti No Near real time 6 000 000 (15%)

Sì Sì Sì Sì Sì Fluida Sì Real time 40 000 000 (100%)

Testo / Grafica

Video / Grafica

No

Sì

> 2 MB Bassa No

< 8 MB Alta Sì

* Parametri di riferimento: Gprs: 4 time slot con velocità max a 40 Kbps e throughput da 30 Kbps – Umts: canali a disposizione da 384 Kbps e throughput da 300 Kbps ** Numero di utenti in grado di collegarsi alla rete in modalità dati

Tabella 4: GPRS e UMTS

Con i nuovi terminali 3G arrivano anche le nuove carte Sim: le Usim (Umts Subscriber Identità Module), che hanno le seguenti caratteristiche: •

sono delle smart card in cui sono stati implementati nuovi parametri di sicurezza delle transazioni;

•

impiegano chiavi di segretezza molto più complesse rispetto a quelle disponibili nelle vecchie Sim Gsm; Pagina 40 di 334

•

funzionano in base al principio di mutua autenticazione dell’utente e della Rete, evitando l’eventualità che false stazioni radio possano carpire le informazioni nella fase di autenticazione in Rete;

•

la memoria è stata ampliata: se nelle Sim si potevano memorizzare al massimo 255 nominativi con un solo numero di telefono associato, con le Usim, oltre ad aumentare il numero dei contatti, ad ognuno di essi si potranno associare più informazioni, come secondo nominativo, numero di telefono e indirizzo e-mail.

Pagina 41 di 334

1.3

Creazione di un toolkit sw/hw

1.3.1

Tools di analisi dei dischi

1.3.1.1

Disk Investigator

http://www.theabsolute.net/sware/dskinv.html (Freeware for Win95, Win98, WinME, WinNT, Win2000, WinXP ) Viene utilizzato per eseguire analisi sui dischi. In particolare è in grado di rilevare file nascosti e recuperare dati cancellati. Il tool bya il Sistema Operativo e legge direttamente i raw drive sectors del disco. Visualizza e cerca raw directories, files, clusters, e system sectors. Consente in oltre di effettuare il wiping dei dischi.

Figura 14: Disk Investigator

Pagina 42 di 334

1.3.1.2

Autopsy v1.6

(GNU General Public License for Unix) http://www.sleuthkit.org/index.php Autopsy è una iniziativa open source alternativa ai normali programmi di forensic WindowsBased. Il tool è un Browser HTML in grado di visualizzare l’immagine di dischi compromessi, è in grado di are sia file system Unix che Windows al fine di rilevare file cancellati, creare time line delle attività sul disco ed eseguire ricerche per parole. É un tool di analisi remota non intrusivo, nessun time stamp dei file viene modificato durante l’analisi. Tutti i file generati da Autopsy sono legati a un valore md5 che può essere verificato durante l’analisi. È possibile effettuare ricerche per inode e visualizzare i file da esso puntati. Autopsy contiene un server HTML scritto in Perl che ne permette l’uso condiviso su più piattaforme compatibili. I client possono accedere a una lista ristretta Acces Control List (ACL) e se necessario crittare il canale di comunicazione con SSH.

Figura 15: Autopsy

Pagina 43 di 334

1.3.1.3

Test Disk v4.2

http://www.cgsecurity.org/index.html?testdisk.html (GNU Public License for Dos, Unix e BSD) Consente di analizzare i dischi compromessi ed effettuarne l’ undelete delle partizioni. I file system ati sono: - FAT12 FAT16 FAT32 - Linux - Linux SWAP (version 1 e 2) - NTFS (Windows NT) - BeFS (BeOS) - UFS (BSD) - Netware - ReiserFS 1.3.1.4

Wipe

http://wipe.sourceforge.net/ (GNU General Public License for Linux, Dos) Esegue una eliminazione completa dei dati presenti su qualsiasi o scrivibile. Il suo funzionamento consiste nel settare a 0 ogni singolo bit presente sul disco, indispensabile per formattare un disco che verrà utilizzato come destinazione di una Forensic analisy. 1.3.1.5

Task v1.5

http://www.atstake.com/research/tools/task/ (IBM Public License Version 1.0 for Linux, Mac OS X ,Open & FreeBSD, Solaris) Progetto Open-Source, per l’analisi completa di file system Windows e Unix. Usato per la forensic di immagini acquisite da sistemi compromessi (Post-Mortem-Analisy), o Live system analisy. Permette di analizzare immagini generate con “dd” (Unix tool), identifica NTFS, FAT, FFS, EXT2FS file system. Può essere usato con Autopsy graphical interface 1.3.1.6

Biew

http://biew.sourceforge.net/en/biew.html (GNU General Public License for DOS, Win32, OS/2, Linux, BeOS, Unix) É un file viewer avanzato in grado di eseguire visualizzazioni binarie, esadecimali e in modalità disassembler per PentiumIV/K7-Athlon/Cyrix-M2, full preview of MZ, NE, PE, LE, LX, DOS.SYS, NLM, ELF.

Pagina 44 di 334

Figura 16: Biew

1.3.1.7

StegDetect v0.5

http://www.outguess.org/detection.php (BSD License for Unix) La steganografia è una scienza o arte in grado di manipolare i formati grafici (Jpeg) sostituendo, all’interno di essi, bit ridondanti con bit contenti informazioni sensibili. StegDect viene usato per rilevare la presenza di informazioni nascoste all’interno di immagini, è in grado di identificare diversi metodi steganografici: - jsteg, - jphide (unix e windows), - invisible secrets, - outguess 01.3b, - F5 (header analysis), - appendX e camouflage Esempio: Pagina 45 di 334

$ stegdetect *.jpg cold_dvd.jpg : outguess(old)(***) jphide(*) dscf0001.jpg : negative dscf0002.jpg : jsteg(***) dscf0003.jpg : jphide(***) [...] $ stegbreak -tj dscf0002.jpg Loaded 1 files... dscf0002.jpg : jsteg(wonderle ) Processed 1 files, found 1 embeddings. Time: 36 seconds: Cracks: 324123, 8915 1.3.1.8

Mac- Robber v1.0

http://www.atstake.com/research/tools/forensic/ (GNU General Public License for Unix) Mac-Robber è un tool di forensic analysis in grado di reperire la data di Accesso, l’Ultima modifica e il cambiamento (MAC) di data da qualsiasi file. Queste informazioni possono essere analizzate con il tool Task al fine di realizzare time line delle attività dei file di un sistema. 1.3.1.9

Glipse v4.1

Glimps (GLobal IMPlicit Search) è un tool Unix in grado di indicizzare ed effettuare ricerche in file system di grosse dimensioni molto rapidamente. a molte delle opzioni di agrep, versione modificata di grep, è in grado di effettuare ricerche consentendo un numero arbitrario di errori nel pattern inserito, a concatenazioni booleane delle query. Per utilizzare glimpse è necessario indicizzare il contenuto delle directory in cui verrà effettuata la ricerca con glimpseindex. Un esempio del suo uso può essere: # glimpseindex - o ~ questo comando genera diversi file che verranno usati da glimpse per effettuare le ricerche all'interno della propria home directory: .glimpse_exclude: contiene la lista di tutti i file che dovranno essere ignorati da glimpse durante la ricerca .glimpse_filter: viene usato per creare dei filtri di ricerca attivati con l'opzione - z .glimpse_filenames: contiene la lista di tutti i file che sono stati indicizzati .glimpse_index: file di indice che associa a ogni lettera una lista di numero di blocchi .glimpse_messages: contiene l'output che viene visualizzato con – w .glimpse_partitions: contiene una partizione dell' indice generato .glimpse_statistics: statistiche riguardanti l'indice generato .glimpse_turbo: da usare solo con le opzioni -b e -o per velocizzare le ricerche Pagina 46 di 334

Glimpse include inoltre un nuovo programma di compressione chiamato cast, che permette di effettuare ricerche anche in file compressi. Semplice esempio dell' uso di glimpse: # glimpse -i -1 'pattern' il comando ricerca nell' indice creato tutte le occorrenze della parola 'pattern' consentendo al massimo un solo errore (-1) e ignorando le maiuscole (-i). # glimpse – F '\.c$' pattern cerca tutte le occorrenze di pattern in tutti i file che finiscono con .c 1.3.1.10

TCT 1.11

Codice sorgente: ftp://tct.earthlink.net/pub/ http://www.porcupine.org/forensics/tct.html http://staff.washington.edu/dittrich/talks/blackhat/blackhat/forensics.html TCT è una collezione di programmi realizzata da Dan Farmer e Wietse Venema che possono essere usati per effettuare un’analisi post mortem di un sistema UNIX. Tools principali : -

grave-robber Usato per la cattura di diverse informazioni solitamente legate alla struttura i-node del sistema operativo.

-

unrm e lazarus Per il recupero di file cancellati e l’analisi e l’analisi di RAM o swap space per l’ analisi di dati nascosti.

-

ils e mactime Necessario per ordinare file o directories di un file system base osi sui tempi di accesso e modifica contenuti nell’ i-node dei file.

-

findkey Recupera chiavi crittografiche da un processo running o da file.

Grave robber analizza il file system usando la funzione stat () per ottenere informazioni dagli inode, mactime ordina i risultati sulla base dei tempi di accesso, modifica e visualizza dimensione, ownership, path e type di ogni file. Da queste informazioni è possibile risalire alle attività svolte dall’ intruder(s) nel sistema come: installazione di trojan horse, backdoors, sostituzione di comandi di sistema, ing di tools, modifiche a librerie o pacchetti installati, creazione di directories nascoste , esecuzione di comandi di sistema, compilazione/linking di programmi. Un gran numero di informazioni non reperibili sui log possono essere ottenute usando mactime. Le versioni differenti di TCT sono state esaminate con i seguenti sistemi: •

Solaris 2,4, 2,5,1, 2,6, 7,0, 8 Pagina 47 di 334

•

FreeBSD 2,2,1, 3,4, 4,4

•

RedHat 5,2, 6,1, 7,3

•

BSD/os 2,1, 4,1

•

OpenBSD 2,5, 3,0, 3,1

•

SunOS 4.1.3_U1, 4,1,4

TCT richiede Perl 5.004 o successiva, anche se Perl 5.000 è probabilmente sufficiente se si usa soltanto il software di raccolta dati e si fa l'analisi su una macchina differente. 1.3.1.11

Dumpel

http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/dumpel-o.asp (for Win95, Win98, WinME, WinNT, Win2000, WinXP) È utilizzato per eseguire il dump di file di log presenti sulla macchina locale o su un server. Il tool genera un file di testo contenente il dump del log. La sintassi è presente nel file html creato dopo l’installazione del programma. Esempi: Per eseguire il dump del system log presente sul server eventserver e creare il file event.out: dumpel -f event.out -s eventsvr -l system

Per eseguire il dump del system log locale e creare il file event.out, ma solo degli eventi di tipo rdr e applicando un filtro sull’event id 2013: dumpel -f event.out -l system -m rdr -e 2013

Per eseguire il dump del log di una applicazione locale e creare event.out, considerando tutti gli eventi eccetto quelli di tipo Garbase: dumpel -f event.out -l application -m garbase -r

1.3.1.12

Strace NT

Visualizza le chiamate di Sistema effettuate da qualsiasi processo. Esempio: [c:\strace] strace notepad 1 133 139 NtOpenKey (0x80000000, {24, 0, 0x40, 0, 0, "\Registry\Machine\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe"}, ... ) == STATUS_OBJECT_NAME_NOT_FOUND 2 133 139 NtCreateEvent (0x100003, 0x0, 1, 0, ... 8, ) == 0x0 3 133 139 NtAllocateVirtualMemory (-1, 1243984, 0, 1244028, 8192, 4, ... ) == 0x0 4 133 139 NtAllocateVirtualMemory (-1, 1243980, 0, 1244032, 4096, 4, ... ) == 0x0 5 133 139 NtAllocateVirtualMemory (-1, 1243584, 0, 1243644, 4096, 4, ... ) == 0x0 6 133 139 NtOpenDirectoryObject (0x3, {24, 0, 0x40, 0, 0, "\KnownDlls"}, ... 12, ) == 0x0 7 133 139 NtOpenSymbolicLinkObject (0x1, {24, 12, 0x40, 0, 0, "KnownDllPath"}, ... 16, ) == 0x0 8 133 139 NtQuerySymbolicLinkObject (16, ... "C:\WINNT\system32", 0x0, ) == 0x0 9 133 139 NtClose (16, ... ) == 0x0

La prima colonna è un identificativo che permette di analizzare le chiamate non immediatamente completate o spezzate in 2 linee. La seconda e la terza colonna rappresentano gli identificativi di processi e thread che eseguono le chiamate di sistema. Successivamente sono elencati: Pagina 48 di 334

1.3.2

•

Il nome della System Call

•

I parametri in ingresso

•

3 punti (…)

•

I parametri in uscita

•

Il codice di ritorno

Tools analisi della rete

Figura 17: Tools analisi della rete

1.3.2.1

Ethereal v.0.9.6

http://www.ethereal.com/ (GNU General Public License (GPL) for Unix, Windows) Ethereal è un programma open source per la cattura e la visualizzazione dei pacchetti in transito in una rete di calcolatori. È in grado di riconoscere più di 350 protocolli di rete diversi. È possibile salvare e visualizzare i contenuti dei pacchetti catturati anche con programmi differenti come tdump. Un esempio di comando sotto Unix: # ethereal -i eth0 -k

Il tool permette di impostare diverse modalità: Filter:

Pagina 49 di 334

vengono filtrati i pacchetti in transito e catturati solo quelli che soddisfano le condizioni impostate. Capture length: consente di catturare solo pacchetti fino a una certa dimensione massima. Capture packets in promiscuous mode: Se abilitata permette di catturare tutti i pacchetti in transito sulla rete e non solo quelli in ingresso o in uscita dal computer. Enable MAC name resolution: Permette di risolvere le corrispondenze IP – MAC address delle schede di rete presenti sulla rete. Enable network name resolution: Consente a ethereal di risolvere gli indirizzi IP in DNS domain name. Il seguente comando permette di catturare tutti i pacchetti da e verso l’host 10.0.0.5 indirizzati alla porta 23 (telnet): # t port 23 and host 10.0.0.5 Per la creazione dei filtri è possibile utilizzare operatori logici: # t port 23 and not host1 0.0.0.5 Una volta effettuata la cattura è possibile effettuare delle ricerche sui pacchetti. Ethereal permette di ricercare specifici frame, un esempio di filtro di ricerca di un frame: ip.addr==10.0.0.5 and

t.flags.syn

in questo modo si cercano le tracce di un hand shake generato dall’ IP 10.0.0.5

Il tool visualizza la lista di tutti i pacchetti catturati, la loro sorgente, la destinazione, il protocollo usato e informazioni aggiuntive. Di ogni singolo pacchetto è possibile avere informazioni più dettagliate come: la porta sorgente/destinazione, il numero di seq del pacchetto, il numero di ack, la lunghezza dell’header la dimensione della window ecc. Un ultimo editor di Ethereal consente la visualizzazione esadecimale del payload di ogni pacchetto.

Pagina 50 di 334

Figura 18: Ethereal

Ethereal è in grado di leggere i pacchetti catturati da altri programmi come: • tdump • snoop e atmsnoop • LanAlyzer • Sniffer (compressed or uncompressed) • Microsoft Network Monitor 1.3.2.2

Snort v.1.9.0

Sito Ufficiale: http://www.snort.org/ (Licenza GPL/Open Source software) Snort è un software che analizza in tempo reale il traffico di rete alla ricerca di eventi che soddisfano la condizione di pattern matching rispetto modelli (pattern) predefiniti di attività sospetta (regola o firma).

Pagina 51 di 334

Quando una corrispondenza viene trovata, snort allerta l'amministratore di rete e produce dei record di log. Caratteristiche principali: leggerezza (eseguibile di circa 250Kb), portabilità (Unix, Linux, Windows, *BSD, HP-UX, IRIX), velocità, configurabilità (semplicità del linguaggio delle regole e delle definizioni dei log), modularità (possibilità di inserire dei plugin). Struttura semplificata di Snort

Figura 19: Snort Architecture

Il funzionamento di Snort si basa sulla presenza di un file di configurazione (snort.conf) e di una serie di file addizionali con estensione rules. Il primo contiene le impostazioni necessarie per il corretto funzionamento del software mentre gli altri compongono complessivamente il database interno delle signatures. In particolare i file rules indicano quali sono le caratteristiche intrinseche che devono avere i pacchetti di rete da catturare ed inoltre specificano se per ciascuno di essi deve essere rilasciato un avvertimento che viene scritto in un altro file denominato alert.ids. Configurazione Si articola in una serie di modifiche da apportare al file snort.conf quali: 1.

l'impostazione delle variabili globali di ambiente;

2.

la configurazione dei preprocessori;

3.

la configurazione dei plugins di output;

4.

la personalizzazione del database interno;

Pagina 52 di 334

1.

valorizzare le variabili HOME_NET, EXTERNAL_NET e DNS_SERVERS: la prima variabile va impostata con l'indirizzo IP assegnato alla interfaccia di rete pubblica del server, la seconda variabile può rimanere invece invariata (equivale ad ANY) mentre la terza è destinata a contenere la lista degli eventuali server dns utilizzati;

2. configurazione dei preprocessori, dipende dal tipo di versione in uso (consultare il manuale e/o le note contenute nel file di configurazione). I preprocessori sono porzioni di codice integrate nel software che assolvono ad un compito ben definito (ad es. la corretta gestione dei pacchetti frammentati o l'impostazione della soglia di sensibilità per il riconoscimento delle attività di scansione delle porte T/UDP); 3. configurazione dei plugins di output, i quali definiscono invece in che modo i dati di log vengono registrati ed anche per quanto riguarda le loro impostazioni è possibile consultare il manuale d'uso o le note contenute nel file di configurazione. 4. personalizzazione del database interno, è il processo più laborioso, richiede una preventiva analisi delle caratteristiche della rete nonché delle effettive esigenze di protezione del server oltre ad un successivo periodo di test e perfezionamento volto a migliorare l'efficienza complessiva del sistema nel riconoscimento delle eventuali intrusioni e nella diminuzione del numero di falsi positivi. Snort può essere usato come packet sniffer (tipo tdump), packet logger o nids, e analizza tre tipi di protocolli: t, udp, icmp. Tipi di alert • messaggi diretti al syslog • file di testo in un percorso specificato dall’utente • messaggi inviati ad un socket Unix • winpopup message per i client Windows che usano il sistema Samba Descrizione regole Le possibili azioni sono: • Alert – genera un alert usando il metodo di alert selezionato, e poi fa il log del pacchetto • Log – fa il log del pacchetto • – ignora il pacchetto • Activate – genera un alert e poi attiva una regola dynamic • Dynamic – rimane inattiva finché non è attivata da una regola activate, poi agisce come un log Gli aggiornamenti delle regole sono scaricabili dal sito ufficiale di snort. Esempio di regola per rispondere alle richieste ICMP: alert icmp any any -> $HOME_NET any (msg:"IDS166 - PING Seer Windows"; content:"|88042020202020202020202020202020|";itype:8;depth:32;) alert icmp any any -> $HOME_NET any (msg:"IDS152 - PING BSD"; content: "|08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17|"; itype: 8; depth: 32;) Uso di Snort con un insieme di regole Pagina 53 di 334

# snort –i eth0 –h 193.205.162.1/24 –c ping.rules –d –l ./log –s –D -d dumps the application layer -h home network -i log location -c rule set name -s log alerts to syslog -i interface to listen on -D run snort as a background process (daemon mode) Messaggi che Snort potrebbe produrre in seguito ad un attacco rilevato con le regole precedenti: Apr 19 11:18:22 [**] IDS152 – PING BSD: 193.205.162.191 -> 193.205.162.192 [**] Apr 19 11:18:23 [**] IDS152 – PING BSD: 193.205.162.191 -> 193.205.162.192 [**] File di log generato da snort: [**] IDS152 – PING BSD [**] 04/19-11:18:22.211702 193.205.162.191:200 -> 193.205.162.1 ICMP TTL:49 TOS:0x0 ID:17933 ID:48507 Seq:0 ECHO 06 28 6D 39 5A C8 04 00 08 09 0A 0B 0C 0D 0E 0F .(m9Z........... 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F ................ 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F !”#$%&’()*+,-./ 30 31 32 33 34 35 36 37 01234567 Pregi snort --->

leggerezza; modularità; codice open source

Difetti snort ---> comuni agli ids, basati sul pattern matching; mancanza di livelli per gli alert 1.3.2.3

TTraceroute

http://michael.toren.net/code/ttraceroute/ (GNU General Public License (GPL) for Unix) TTraceroute è una implementazione di traceroute che usa T. Traceroute è un programma di diagnostica e statistica, viene usato al fine di individuare quale percorso viene seguito dai pacchetti di dati durante la comunicazione tra due computer. In particolare il comando spedisce pacchetti UDP o ICMP ECHO con TTL inizialmente settato a uno che viene incrementato fino a quando la destinazione non è stata raggiunta. Il comando stampa il nome di ogni gateways che genera un ICMP time exceeded message durante il percorso dei pacchetti. In questo modo si è in grado di creare il percorso compiuto dai dati per raggiungere un determinato host. L’uso di firewall che filtrano e bloccano pacchetti UDP e ICMP rende inutile l’uso di traceroute. Pagina 54 di 334

TTraceroute utilizzando quindi il protocollo T rende possibile la generazione del percorso anche in presenza di normali sistemi di filtraggio. TTraceroute non completa mai l’hand shake, nel caso in cui l’host di destinazione risponde con un RST la porta di destinazione è chiusa e la comunicazione viene interrotta. Se risponde con un SYN | ACK la porta è aperta e traceroute fermerà la comunicazione. Lo stesso principio viene usato da nmap se gli viene ato il flag –sS. Sintassi: ttraceroute [-nNFSAE] [-i interface ] [ -f first ttl ] [ -l length ] [ -t tos ] [-m max ttl ] [-p source port ] [-s source address ] [-w wait time ] host[destination port ] [ length ] Esempio di comando Traceroute: www.microsoft.com, classico webserver protetto: $ traceroute -w2 -q1 -f 5 www.microsoft.com traceroute: Warning: www.microsoft.com has multiple addresses; using 207.46.197.100 traceroute to www.microsoft.akadns.net (207.46.197.100), 30 hops max, 38 byte packets 5 baltimore.balt-core.h0-0-45M.netaxs.net (207.106.2.18) 17.560 ms 6 blt-dc.dc-core.h5-0-45M.netaxs.net (207.106.2.2) 27.769 ms 7 core1-core3-fe-1.mae-e.iad.netaxs.net (207.106.31.28) 28.802 ms 8 250.ATM3-0.BR3.DCA6.ALTER.NET (137.39.92.25) 27.934 ms 9 0.so-3-1-0.XL2.DCA6.ALTER.NET (152.63.38.122) 24.210 ms 10 0.so-0-0-0.XR2.DCA6.ALTER.NET (152.63.35.117) 35.693 ms 11 0.so-4-0-0.TR2.DCA6.ALTER.NET (152.63.11.93) 22.170 ms 12 121.at-1-1-0.TR2.SEA1.ALTER.NET (146.188.140.78) 94.099 ms 13 0.so-1-0-0.XL2.SEA1.ALTER.NET (152.63.106.237) 101.325 ms 14 POS7-0.GW4.SEA1.ALTER.NET (146.188.201.53) 91.887 ms 15 microsoftoc48-gw.customer.alter.net (157.130.184.26) 89.536 ms 16 * 17 * 18 *

Esempio di comando TTraceroute: $ ttraceroute -f 5 207.46.197.100 Selected device eth0, address 207.8.132.210, port 1058 for outgoing packets Tracing the path to 207.46.197.100 on T port 80 (www), 30 hops max 5 baltimore.balt-core.h0-0-45M.netaxs.net (207.106.2.18) 9.430 ms 6 blt-dc.dc-core.h5-0-45M.netaxs.net (207.106.2.2) 17.514 ms 7 core1-core3-fe-1.mae-e.iad.netaxs.net (207.106.31.28) 23.256 ms 8 250.ATM3-0.BR3.DCA6.ALTER.NET (137.39.92.25) 30.819 ms 9 0.so-3-1-0.XL2.DCA6.ALTER.NET (152.63.38.122) 26.605 ms 10 0.so-0-0-0.XR2.DCA6.ALTER.NET (152.63.35.117) 38.700 ms 11 0.so-4-0-0.TR2.DCA6.ALTER.NET (152.63.11.93) 31.402 ms 12 121.at-1-1-0.TR2.SEA1.ALTER.NET (146.188.140.78) 93.992 ms 13 0.so-1-0-0.XL2.SEA1.ALTER.NET (152.63.106.237) 105.176 ms 14 POS7-0.GW4.SEA1.ALTER.NET (146.188.201.53) 86.524 ms 15 microsoftoc48-gw.customer.alter.net (157.130.184.26) 85.916 ms 16 207.46.129.51 (207.46.129.51) 84.920 ms 17 microsoft.com (207.46.197.100) [open] 85

Pagina 55 di 334

1.3.2.4

Hogwash

http://hogwash.sourceforge.net/ Hogwash è un analizzatore di pacchetti (firewall basato sulle firme) che interagisce con Snort, però al posto di chiudere porte, permette di creare regole di filtering in base a pattern matching.. Per eseguirlo occorrono due schede di rete: una collegata all’interno, l’altra all’esterno. Linee di comando -e (external interface) interfaccia collegata all’esterno -i (internal interface) interfaccia della scheda di rete collegata all’interno -c (rules file) nome del file delle regole che sarà utilizzato per determinare quali pacchetti sono permessi -C (rules file directory) specifica la directory del file delle regole; utile per l’update remoto dell’insieme delle regole e per tenere le “version history” -n fa funzionare hogwash senza regole; utile per testare la connettività di base -l (log directory) setta la directory di log; senza questa opzione, quella di default è /var/log/snort. La directory deve esistere prima che Hogwash parta -k (stackless control config file) nome del file di configurazione che contiene le chiavi “twofish” che saranno accettate dal canale di controllo stackless -d mette hogwash in modalità demone Tipica linea di comando : hogwash -i eth0 -e eth1 -c /etc/hogwash/stock.rules Pagina 56 di 334

File delle regole Il linguaggio delle regole (o firme) dovrebbe essere familiare per chi ha già usato Snort in ato. Cinque tipi base di regole da poter usare: • • • • •

drop sdrop alert log

significa che il pacchetto è sempre buono, quindi ignora qualsiasi cosa che fa matching; l’uso comune di una rule è per permettere un qualunque traffico tra sviluppatore e analisti. Esempio: t $MYNET any <> any any () drop fa “cadere” il pacchetto e non lo lascia più entrare nella rete. E’ importante usare la drop rules con bassa frequenza di falsi positivi, o potrebbe incidere negativamente sulla rete. Esempio: drop t $EXTERNAL_NET any -> $HOME_NET 23 (msg:"BACKDOOR Telnet Freebsd 3x4x"; flags: A+; content: "LoUSUCKS"; reference: arachnids,519;) sdrop nuovo nella versione 0.2-pre2. Scarta il pacchetto silenziosamente, senza nessun alert o log del pacchetto alert avverte di un certo pacchetto ma non lo fa cadere. Utile per le regole che hanno frequenza di falsi positivi alta. Le alert rules sono utili a testa nuove regole prima della loro messa in opera. Generalmente si fanno funzionare le drop rules come alerts per circa una settimana per vedere quello che si sarebbe lasciato cadere. Poi si può scegliere di commutare le alert in drop rules Esempio: example: alert t $EXTERNAL_NET any -> $HOME_NET 23 (msg:"BACKDOOR Telnet Freebsd 3x4x"; flags: A+; content: "LoUSUCKS"; reference: arachnids,519;) log salva un pacchetto senza dire niente di questo; utili per informazioni su tipi di applicazioni Esempio: log t $EXTERNAL_NET any -> $HOME_NET 21 (content: "site exec"; nocase;) 1.3.2.5

Tdump 3.7

http://www.tdump.org/ Versione di UNIX di un decodificatore di pacchetti, scritto inizialmente da Van Jacobsen per analizzare problemi di performance di T.

Pagina 57 di 334

Effettua l’analisi dei pacchetti su un’interfaccia di rete (tipicamente un Ethernet, in maniera promiscua per leggere tutto il traffico della rete) che soddisfano determinate condizioni di filtro. Prerequisito: diritti di accesso al device driver della scheda di rete. Per eseguirlo è utile porre un ` -i ' switch per specificare quale interfaccia della rete deve essere usata, in questo modo fornisce delle informazioni riassuntive per ogni pacchetto ricevuto o trasmesso sull'interfaccia. Tdump prevede molte importanti opzioni, così come l'abilità di specificare un'espressione per restringere la serie di pacchetti che si desidera studiare. Sintassi: tdump [ -deflnNOpqStvx ] [ -c count ] [ -F file ][ -i interface ] [ -r file ] [ -s snaplen][ -w file] espressione Espressioni filtro: - directions:

src / dst / src or dst / src e dst

- type:

host / net / port / mask

- protocol:

ether / fddi / ip / arp / rarp / decnet / lat sca / moprc / mopdl / t / udp

- special keyword:

gateway / broadcast / less / greater

- boolean operator:

and / or / not

Opzioni: -c

uscire dopo aver ricevuto count pacchetti

-e

stampa il link-level header su ogni linea mostrata

-f

stampa gli indirizzi internet in formato numerico, piuttosto che simbolici

-F

usa un file come ingresso per l’espressione del filtro (ogni altra espressione data sulla linea di comando è ignorata)

-i

per specificare l’interfaccia su cui ascoltare (se tale opzione non è messa, tdump seleziona la prima interfaccia presente nella lista delle interfacce di sistema, escluso il loopback)

-n -N

non converte gli indirizzi (indirizzi di host, numeri di porto, ecc.) in nomi non stampa il nome del dominio dell’host (in questo modo tdump stamperà ‘nic’ invece di ‘nic.ddn.mil’)

-q

output più corti, stampa meno informazioni sui protocolli

-p

l’interfaccia non è messa in modalità promiscua

-r

legge pacchetti da file (i quali sono stati creati con l’opzione -w)

-t

non stampa il timestamp su ogni linea catturata

-tt

stampa un timestamp non formattato su ogni linea

-d

cattura i pacchetti compilandoli secondo l’uscita standard Pagina 58 di 334

-w

scrive il pacchetto catturato in un file (lo standard output è usato se il file è ‘-‘)

-x

stampa ogni pacchetto in esadecimale

Esempi: -

tdump host A tdump dst host A and \ (port ftp or ftp-data\) tdumpport smtp tdump gateway A and \(port ftp or ftp-data\) tdump net 140.123.0.0

tdump -i lo (lo=interfaccia di loopback, è un dispositivo di rete virtuale che permette di riferirsi a se stesso)

Pagina 59 di 334

tdump -i lo -s 200 -x –q

s 200

specifica di catturare 200 byte di ogni pacchetto

-x

specifica di stampare (in esadecimale) l'inizio di ogni pacchetto

-q

fornisce una stampa meno invadente dell'output (mancano i numeri di sequenza e altri dettagli)

Per catturare solo i pacchetti t sull'interfaccia di rete eth0 e destinati alla porta 23 (telnet) e salvare tutto l'output su un file si può digitare: tdump -i eth0 -w file t port 23 Digitando tdump -r file si visualizza l'output in maniera standard. 1.3.2.6

Ttrace 6.2.0

http://irg.cs.ohiou.edu/software/ttrace/.html Tool scritto da Shawn Ostermann per l’analisi dei file di Tdump. Può prendere come input file prodotti da diversi programmi “cattura pacchetti”, incluso tdump, snoop, etherpeek, HP Net Metrix, e WinDump. Può produrre vari tipi di output contenenti informazioni su ogni connessione vista, come il tempo trascorso, byte inviati e ricevuti, ritrasmissioni, RTT (round trip time), throughput e altro ancora. Può anche produrre un certo numero di grafici per ulteriore analisi. Pagina 60 di 334

Ttrace può produrre molti tipi differenti di output, in base agli argomenti che riceve. In primo luogo legge i relativi argomenti dal file "$$HOME/.ttracerc" e poi dalla variabile d’ambiente TTRACEOPTS, infine legge gli argomenti ati da linea di comando . Output Options Ttrace ha 3 forme di output - brief, long, quiet – e ciascuna di esse può essere ulteriormente modificata per customizzare l’output. -b

modo brief : è quello di default. L’output di base include una lista delle connessioni nel dumpfile e quanti pacchetti sono stati trasmessi per ogni connessione;

-l

modo long: output più lungo con informazioni più dettagliate su ogni connessione;

-q

modo quiet: output minimo indispensabile, utile per vedere l’output di ogni modulo;

-n

non risolve gli host o i service names, il programma funziona molto più rapidamente;

-s

stampa solo i nomi corti;

Combinando –l con –W si ottengono report sulla “congestion window” e con –r si hanno le statistiche del RTT incluse nell’output. Graphing Options Ttrace può produrre cinque generi differenti di grafici, a seconda delle opzioni inserite da linea di comando : throughput graphs, RTT sample graphs, diagrammi time-sequence, congestion window graphs, segment size graphs. -l throughput

Pagina 61 di 334

-R

RTT

-S

Time-Sequence

Pagina 62 di 334

1.3.2.7

Chkrootkit 0.39a

http://www.chkrootkit.org/ Tool per controllare la presenza di backdoor e rootkit particolarmente noti; contiene: • • • • • • •

ifpromisc.c: controlla se l’interfaccia è in modalità promiscua; chklastlog.c: controlla cancellazioni in lastlog; chkwtmp.c: controlla cancellazioni in wtmp; check_wtmpx.c: controlla cancellazioni in wtmpx (solo Solaris); chkproc.c: controlla tracce di LKM trojan; chkdirs.c: controlla tracce di LKM trojan; strings.c: sostituzione rapida e approssimativa di stringhe.

Chkrootkit è stato testato su: Linux 2.0.x, 2.2.x e 2.4.x, FreeBSD 2.2.x, 3.x e 4.x, OpenBSD 2.6, 2.7, 2.8, 2.9, 3.0, 3.1 e 3.2, NetBSD 1.5.2 e Solaris 2.5.1, 2.6 e 8.0. Attualmente sono rilevati i seguenti rootkits, worms e LKMs: Solaris rootkit, FreeBSD rootkit, lrk3, lrk4, lrk5, lrk6, t0rn (e t0rn v8), some lrk variants, Ambient's Rootkit for Linux (ARK), Ramen Worm, rh[67]-shaper, RSHA, Romanian rootkit, RK17, Lion Worm, Adore Worm, LPD Worm, kenny-rk, Adore LKM, ShitC Worm, Omega Worm, Wormkit Worm, dsc-rootkit, RST.b, duarawkz, knark LKM, Monkit, Hidrootkit, Bobkit, Pizdakit, t0rn (v8.0 variant), Showtee, Optickit, T.R.K, MithRa's Rootkit, George, SucKIT, Scalper Worm, Slapper Worm (and variants), OpenBSD rk v1, Illogic, SK rootkit, sebek LKM, Romanian rootkit e LOC rootkit.

Pagina 63 di 334

Chkrootkit effettua la ricerca in base a “signatures” note, le quali però possono essere facilmente modificate da un attacker. Poiché chkrootkit non trova automaticamente trojan le cui signatures sono state modificate, lo deve are in modalità expert (-x): in questo modo lo può esaminare le stringhe di binari sospette che possono indicare un trojan. Chkrootkit va eseguito da root: # ./chkrootkit [options] [testname...] Comandi: awk, cut, echo, egrep, find, head, id, ls, netstat, ps, strings, sed, uname Opzioni: -h

mostra l’help

-V

mostra informazioni sulla versione

-l

mostra i testi disponibili

-d

debug

-q

modalità quiet

-x

modalità expert

-r dir

usa dir come root directory

Messaggi d’output: •

"INFECTED": il test ha identificato un comando probabilmente modificato da un rootkit conosciuto;

•

"not infected": il test non ha trovato nessuna rootkit signature nota;

•

"not tested": test non effettuato – può succedere nelle seguenti situazioni: test specifico per l’OS; test che dipende da un programma esterno non disponibile; qualche linea di comando specifica (es. -r ).

1.3.2.8

•

"not found": il comando da testare non è disponibile;

•

"Vulnerable but disabled": comando infettato ma non in uso.

SSLdump 0.9b3

http://www.rtfm.com/ssldump/ Analizzatore di protocollo di rete SSLv3/TLS, identifica le connessioni T sull’interfaccia di rete scelta e tenta di interpretarle come traffico SSLv3/TLS. Quando identifica del traffico SSLv3/TLS, decodifica i record visualizzandoli allo stdout in una Pagina 64 di 334

form testuale. Se provvisto del proprio “keying material”, decritterà le connessioni visualizzando il traffico dati delle applicazioni. SSLdump dipende dalla libreria cattura pacchetti libcap. Alcuni sistemi (es. FreeBSD) ora hanno libcap come parte della loro installazione standard. Compatibilità: FreeBSD, Linux, Solaris e HP/UX, ma dovrebbe lavorare su ogni piattaforma con pcap. Comunque, diversamente da Tdump, SSLdump deve poter vedere entrambi i lati della trasmissione dati, quindi si potrebbero aver problemi ad usarlo con network tap (colleziona copie dei pacchetti provenienti dal device driver di rete e le smista alle applicazioni che sono in ascolto). Ssldump [ -vtaTnsAxXhHVNdq ] [ -r dumpfile ] [ -i interface ] [ -k keyfile ] [ -p ] [ expression ] ssldump -i le0 port 443

per ascoltare il traffico sull’interfaccia le0 porta 443

L’output è inviato allo standard out, SSLdump stampa un’indicazione di ogni connessione T New T connection #3: localhost(3638) <-> localhost(4433) 3 3 3 3 3 3 3 3 3 3 3 3 3 3

1.3.2.9

1 2 3 4 5 6 7 8 9 10 11 12

0.0738 0.0743 0.0743 0.0743 0.0866 0.0866 0.0866 0.0909 0.0909 1.8652 2.7539 5.1861 5.1868 5.1893

(0.0738) (0.0004) (0.0000) (0.0000) (0.0123) (0.0000) (0.0000) (0.0043) (0.0000) (1.7742) (0.8887) (2.4321) (0.0007) (0.0024)

C>S S>C S>C S>C C>S C>S C>S S>C S>C C>S C>S C>S C>S S>C

Hand shake ClientHello Hand shake ServerHello Hand shake Certificate Hand shake ServerHelloDone Hand shake ClientKeyExchange ChangeCipherSpec Hand shake Finished ChangeCipherSpec Hand shake Finished application_data application_data Alert warning close_notify T FIN T FIN

p0f

http://www.stearns.org/p0f/ Tool per determinare il sistema operativo, usa sei campi per il riconoscimento: window size, TTL, opzioni T come (MSS, DF, window scaling, sackOK e NOP). Analizza il traffico tramite pacchetti SYN, può determinare la distanza dell’host remoto e può essere usato come add-on ad un sistema IDS. a Tdump e filtra le espressioni, ha un database personalizzabile per incrementare il riconoscimento di altri OS. Pagina 65 di 334

Testato su Linux 2.0/2.2, FreeBSD, OpenBSD, NetBSD, SunOS e Solaris

Tools immagini dei dischi 5

1.3.3

Come risposta ad una intrusione è necessario disporre di una collezione di strumenti software e device hardware dedicati. Tali strumenti svolgono diverse funzionalità, quali backup e restore, comparazione di file, verifica e comparazione di checksum crittografiche, controllo di configurazione dei sistemi, elenchi di servizi e processi, sistemi di tracciamento dei siti attaccanti e dei loro ISP. Procediamo analizzando i tool che si occupano della preservazione delle fonti di prova tramite la generazione di una loro immagine. 1.3.3.1

Creazione dell’immagine dei dischi in ambiente Unix DD (http://www.rajeevnet.com/hacks_hints/os_clone/os_cloning.html)

Man Page : dd [--help] [--version] [if=file] [of=file] [ibs=byte] [obs=byte] [bs=byte] [cbs=byte] [skip=blocchi] [seek=blocchi] [count=blocchi] [conv={ascii, ebcdic, ibm, block, unblock, lcase, ucase, swab, noerror, notrunc, sync}] DD copia un file (per default dallo standard input allo standard output) con dimensioni predeterminate per i blocchi d'input e di output, effettuando eventualmente delle conversioni su di esso. Legge l'input un blocco alla volta, con la dimensione che è stata specificata per i blocchi d'input (512 byte, per default). Se è presente l'opzione bs=byte, e non viene richiesta nessuna conversione a parte sync, noerror o notrunc, scrive la quantità di dati letta (che potrebbe essere minore di quella richiesta) in un blocco d'uscita separato. Questo blocco d'uscita ha esattamente la stessa lunghezza di quello d'ingresso, a meno che venga specificata l'opzione sync, nel qual caso vengono aggiunti NUL (o spazi, vedi sotto) alla fine dei dati. Altrimenti l'input, letto un blocco alla volta, è elaborato e l'output risultante viene raccolto e scritto in blocchi della dimensione specificata. Il blocco finale di output potrebbe essere più corto. Le opzioni numeriche che seguono (byte e blocchi) possono essere seguite da un moltiplicatore: k=1024, b=512, w=2, c=1 («w» e «c» sono estensioni GNU; «w» non dovrebbe mai essere usata: significa 2 in System V e 4 in 4.2BSD). Si possono moltiplicare due o più di queste espressioni mettendoci una «x» in mezzo. È possibile importare le immagini create con dd nelle più recenti versioni di Encase.

Concetto di Base : 5

Si rammenta che tutte le operazioni di imaging, compresa la descrizione dei tools utilizzati per farlo, devono essere documentate nel report, il quale deve altresì contenere l’indicazione della tipologia di tool utilizzato.

Pagina 66 di 334

‘dd’ esegue una copia bit a bit da una location a un’altra usando la sintassi: dd if=<src> of= dove, <src> e possono essere file, partizioni di file system o un intero hard drive. ‘dd’ non è un network program quindi per poter estendere le caratteristiche di dd a un contesto di rete è possibile usare 'netcat'. Netcat è usato per effettuare connessioni T/UDP a un server ed inoltre è un ottimo tool di diagnostica. Tipicamente Netcat lavora in due modalità Server e Client: server% nc -l -p 30000 client% nc <server> 30000

==> (In attesa sulla porta 30000 su <server> ) ==> (Connessione a <server> sulla porta 30000)

Clonazione di un Sistema Operativo: Assumiamo che (sda) e (sdb) siano due drive presenti sullo stesso sistema. (sda) è il drive contenente il Master OS e (sdb) è il drive (slave drive) sul quale volgiamo clonare sda. La tabella delle partizioni di sda può essere così strutturata: Device Boot /dev/sda1 /dev/sda2 /dev/sda3 autodetect /dev/sda4

Start 1 10 76

End 9 75 467

468

2200

Blocks 72261 530145 3148740

Id 83 82 fd

System HPFS/NTFS Linux swap Linux raid

13920322+

83

Linux

Un metodo semplice per clonare sda su sdb è quello di usare il comando: dd if=/dev/sda of=/dev/sdb in questo modo verrà copiato ogni bit di sda (Master Drive) in sdb (Slave Drive) incluso l’MBR (Master Boot record). Nei casi in cui il drive Master superi i 100GB di dati, la generazione dell’immagine può diventare molto lunga. Per analizzare le partizioni sda può risultare inutile eseguire l’immagine dell’area di swap di Linux. In questi casi è possibile creare la stessa struttura di partizionamento sul drive destinazione sdb e creare le immagini delle sole partizioni utili. Esempio di partizionamento di sdb: Device Boot /dev/sdb1 /dev/sdb2 /dev/sdb3 autodetect /dev/sdb4

Start 1 10 76

End 9 75 467

468

2200

Blocks 72261 530145 3148740

Id 83 82 fd

System HPFS/NTFS Linux swap Linux raid

13920322+

83

Linux

Le dimensioni delle partizioni di sdb devono essere identiche a quelle di sda. Per prima cosa è necessario clonare l’MBR, nel caso di Linux esso può contenere il Bootloader che consente di visualizzare la struttura delle partizioni e di scegliere quella da avviare. L’MBR Pagina 67 di 334

è localizzato nei primi 466 Bytes del disco o della partizione, scelta durante l’installazione di Linux. Il comando di copia dell’MBR: dd if=/dev/sda of=/dev/sdb bs=446 count=1 Se non sussistono particolari condizioni che obbligano la creazione dell’immagine dell’area di Swap, è possibile procedere nel seguente modo: dd if=/dev/sda1 of=/dev/sdb1 ==> clona una partizione NTFS dd if=/dev/sda3 of=/dev/sdb3 ==> clona una partizione RAID-1 che ha un file system ext2 o altri. DCFLDD Versione modificata di dd in grado di calcolare il valore di hash dell’immagine creata. Esempio: # dcfldd –hashwindow=BYTE –hashlog=FILE if=Dev of=dev Hashwindow indica ogni quanti BYTE generare l’hash e Hashlog genera il FILE di testo contenente i valori calcolati.

1.3.3.2

Creazione dell’immagine dei dischi in ambiente Windows DD 3.16.2 http://s.erols.com/gmgarner/forensics/ Questa versione di DD modificata permette di generare l’immagine di qualsiasi dispositivo connesso alla macchina, anche di singoli file o directory. Inoltre viene associato al file creato il relativo codice di Hash (Md5). L’opzione –v (verbose) permette a DD di scrivere le seguenti informazioni sullo stderr. a. Versione del Tool. b. Linea di comando . c. Versione del Sistema operativo. d. Tempo di partenza locale e UTC e. Tempo di fine locale e UTC f. corrente g. Identificatore del drive, numero di serie e sua geometria (se in input c’è un drive); o Identificatore di Volume, numero di serie e sua geometria (se in input c’è un volume). h. Il numero di byte scritti sull’output i. Il valore di hash del file generato j. Warnings o richieste generate dall’input allo . K Risposte date dallo all’input. Sono ate le informazioni relative all’MBR(Master boot Record). Pagina 68 di 334

Un input o output costituito da un volume o un file può essere protetto da scrittura usando l’opzione –lockin, --lockout. Se il volume logico non può essere bloccato DD chiede all’utente se desidera smontarlo, in caso affermativo tutti gli Handles dei file aperti saranno marcati come non validi. Microsoft Windows fa uso frequente delle scritture ritardate per migliorare le prestazioni, questo fatto può compromettere la consistenza dell’immagine generata. Questo fatto ha delle significative implicazioni nel momento in cui si esegue un’analisi basata su Timeline, il Mac time ottenuto per mezzo della funzione ANSI stat() o Win32 GetFileAttributesEx () può non essere il corrente MAC time nel caso in cui il file sia stato modificato ma scritto su disco in un secondo momento. È quindi utile utilizzare dispositivi Hardware o Software che proteggono il volume logico da ogni uso. Alcuni esempi di uso di DD 3.16.2: dd.exe if=\\.\PhysicalDrive0 of=d:\images\PhysicalDrive0.img --md5sum --md5 --md5out=d:\images\PhysicalDrive0.img.md5 dd if=\\?\Volume{87c34910-d826-11d4-987c-00a0b6741049} of=d:\images\e_drive.img –md5sum –md5 md5out=d:\images\PhysicalDrive0.img.md5 dd.exe if=\\.\PhysicalMemory of=d:\images\PhysicalMemory.img bs=4096 --md5sum --md5 -md5out=d:\images\PhysicalMemory.img.md5 dd.exe if=\\.\D: of=d:\images\d_drive.img conv=noerror --sparse --md5sum --md5 – md5out=d:\images\d_drive.img.md5 --log=d:\images\d_drive.log dd.exe if=myfile.txt.gz of=d:\images\myfile.txt conv=noerror,decomp --md5sum --md5 – md5out=d:\images\myfile.txt.img.md5 --log=d:\images\myfile.txt.log dd.exe if=\\.\D: of=d:\images\d_drive.img.gz conv=noerror,comp --md5sum --md5 – md5out=d:\images\d_drive.img.md5 --log=d:\images\d_drive.log

ENCASE http://www.guidancesoftware.com/ Una volta avviato il sistema (boot sequence A,C…) con il comando en.exe si lancia enacase. Encase Dos Version La versione presente in questo cd permette solo l’acquisizione di dischi. Le versioni 3 e 4 di Encase permettono di acquisire un disco tramite cavo cross. Per queste operazioni è necessario disporre dell’EnCase Network Boot disk images, una volta avviato il sistema (boot sequence A,C…) con il comando en.exe si lancia enacase. Usando questa procedura qualsiasi possibilità di scrittura sul disco fisso viene annullata, in quanto tutte le referenze nei file command.com e io.sys vengono sostituite con A:. Pagina 69 di 334

In Encase Dos Version sono presenti tutte le principali modalità di acquisizione, ATA diretta (solo con dispositivi NON SCSI), parallela, in rete. È possibile inoltre generare l’hash del disco da acquisire. Encase Dos version è in grado di avviare un sistema e riconoscerne le schede di rete installate permettendo all’utente di scegliere quale tra queste usare. L’interfaccia grafica richiede di specificare se le NIC devono essere riconosciute in modo automatico o specificate manualmente dall’utente. Il boot disk deve essere caricato su un target Server/Pc/Laptop in modo da consentire a Encase di procedere con l’acquisizione. Network Cross-over Cable Method È necessario impostare la modalità Sever sul Pc avviato in Dos mode.In tal modo la versione Windows di Encase sarà in grado di vedere e utilizzare la connessione con il target. Per iniziare l’acquisizione da Windows avviare Encase e selezionare la modalità Network.

Elenco delle schede di rete ate6: PCI Cards ed: (auto e /or manual loading)

6

SCSI Controller Cards ed: (auto e /or manual loading)

•

3COM 10/100 V.90 Mini-PCI Combo Card

•

AIC-7890/91

•

3COM Etherlink 10/100 with 3XP (3C990)

•

AIC-78XX/AIC-75XX

•

3COM EtherLink III Series

•

AMD PCscsi

•

3COM EtherLink XL Series

•

BusLogic FlashPoint

Alla data di chiusura del presente paragrafo. Si consiglia comunque di consultare la HCL relativa allo strumento.

Pagina 70 di 334

•

ACCTON EN1207D-TX/EN2242A Series

•

BusLogic MultiMaster

•

ACCTON EN5251 Series

•

IBM ServeRAID

•

TEK PCI 10/100 Series

•

Initio INI-9XXXU/UW

•

AMD PCNet Series

•

Initio INI-A100U2W

•

BROADCOM NetXtreme Gigabit

•

Symbios 53C8xx

•

COMPAQ 10/100 e Gigabit

•

COMPAQ Gigabit 6134/6136 (Intel)

•

COMPAQ NetFlex-3

•

D-LINK DFE-530TX+ 10/100 Series

•

D-LINK DFE-550TX 10/100 Series

•

DAVICOM PCI Based Series

•

DIGITAL 2104x/2114x 10/100 Series

•

HP 10/100VG

•

INTEL PRO Series

•

INTEL PRO/1000 Server Series

•

LITE-ON PNIC-10/100 Series

•

MACRONIX MX987xx Series

•

NATIONAL DP83815 10/100 Mahyter Series

•

NETGEAR FA310TX Adapter

•

REALTEK RTL8029 Series

•

REALTEK RTL8139/810X Series

•

SIS 900/7016 SIS900 10/100 Series

•

SMC EtherPower II 10/100 (9432TX)

•

SMC Fast Ethernet 10/100 (1211TX)

•

VIA PCI 10/100Mb Series

PCMCIA Cards ed: (manual loading)

•

3COM 3CCFE574 Family

•

3COM 3CCFE575 Family

•

INTEL 16 BIT Series

•

INTEL 32 BIT Series

•

XIRCOM CE3B-100BTX (non-CardBus)

•

XIRCOM RealPort & Realport2 R2BEM56G-100

Cable: Parallel-port Method L’acquisizione via porta parallela si rende necessaria quando non siano possibili altri metodi, tuttavia, anche se lenta, risulta essere sufficientemente sicura. Per poter realizzare l’acquisizione è necessario spegnere il Pc sospetto e la Forensic Workstation, collegarli via cavo parallelo, avviare il primo usando il disco di boot e digitare al prompt: A:\> EN /S , Pagina 71 di 334

tale direttiva lancia Encase Dos-mode e lo imposta in modalità server. Si avvia la Workstation e si seleziona la modalità di acquisizione parallela nel menù acquisizione. Local: "Drive to Drive" Questa metodologia di acquisizione presuppone il possesso fisico dell’Hard Disk sospetto. Il disco deve essere collegato all’interno della Forensic Workstation facendo particolare attenzione al fatto che se il cavo del bus usato per la connessione è condiviso con l’Hard Disk primario, al momento del Boot potrebbero verificarsi delle scritture sul disco da analizzare, compromettendone l’integrità. Se non si dispone di dispositivi hardware che proteggono il disco da scritture accidentali è necessario utilizzare la versione Dos di Encase presente sul floppy. Una volta avviata l’interfaccia grafica presenta sulla parte alta sinistra dello schermo il dispositivi fisici presenti nel sistema e nella parte destra i volumi fisici presenti su dischi. Se si avvia Encase in questa modalità non saranno visibili le partizioni di tipo NTFS. A questo punto è necessario confermare che l’Hard disk sospetto sia Locked mentre quello destinazione non lo è. Encase suppone tutti i dispositivi Locked per default. Con ADD DEVICE si sceglie il disco corretto da acquisire e Encase parte con la generazione dell’immagine. Encase Windows Version7 La versione Windows di Encase permette lo stesso tipo di acquisizioni della versione Dos. Quindi si può generare l’immagine di un dispositivo (Floppy, Volumi, Disco fisico, Palm Pilot) in locale, via parallela o con una connessione di rete. Durante la fase di preparazione alla generazione dell’immagine Encase richiede di inserire alcune informazioni relative alle operazioni che si stanno compiendo quali: Case number, Evidence Number, Examiner, Current Time. Ogni immagine generata è chiamata Evidence File, si può scegliere se inserire quest’ultimo all’interno di un Case (puntatore a un gruppo di Evidence File) o no. Encase permette inoltre di scegliere una modalità di Preview del dispositivo da acquisire. Tale modalità consente di avere un’anteprima del disco da analizzare senza dover attendere che l’immagine vera e propria sia generata, operazione che può richiedere diverso tempo. Nel momento in cui deve essere generata una immagine bisogna accertarsi che il disco di destinazione sia completamente vuoto. L’utility di Encase, Wipe, è usata a questo scopo. Palm PDA Esiste anche la possibilità di acquisire il contenuto della memoria di un computer palmare. Palms ed •

IIIx, IIIxe

•

V series

7

Si tenga presente che le informazioni generali su questi processi sono relative alla versione 3.22x del prodotto. Al momento in cui si scrive si è a conoscenza di numerosi bug delle versione 4x che devono ancora essere risolti per poter definire quest’ultima versione “stabile”. Si erà quindi ad un’overview sulla 4 quando si avrà certezza della soluzione dei problemi.

Pagina 72 di 334

•

VII series

•

M series

Per prima cosa è necessario impostare il Palmare in console-mode. Inserirlo nella base, collegare il cavo e scrivere nell’area di scrittura del Palmare “graffiti area”: l (in corsivo) seguito da due punti e poi 2.

Figura 20: Impostazione del Palmare in console-mode

Avviare Encase in Windows mode, A questo punto le procedure di acquisizione sono le stese descritte in precedenza. Gestione del dump della ram 8

1.3.4

Allo scopo di proteggere e conservare qualsiasi prova di intrusione o manomissione presente sulla macchina attaccata, oltre alla generazione dell’ immagine del disco potrebbe rivelarsi utile creare un dump della memoria. Questa operazione permette di fotografare lo stato e quindi il contenuto della memoria Ram fin dal primo istante in cui si viene in possesso della macchina da analizzare. Ovviamente il dump deve essere effettuato prima di scollegare, spegnere o riavviare il sistema. Il dump della memoria è soprattutto utile nel momento in cui è necessario realizzare una Forensics Live Analysis, quindi il sistema deve rimanere collegato e operativo e la memoria Ram diventa un punto importante dal quale cominciare la ricerca. La Forensic di un router, per esempio, deve essere realizzata mentre il sistema è ancora attivo e funzionante, lo stato della rete e dei processi ready può essere analizzato dal contenuto della memoria La generazione del dump della memoria fisica può essere rischioso in quanto si tenta di accedere a porzioni di dati sulle quali non si hanno gli adeguati permessi. Una possibile conseguenza di questa può essere la compromissione del TLB (Traslation Lockside Buffer) del processore atto a convertire indirizzi virtuali in reali. Esistono tools sia per ambiente Windows che Unix che generano il Dump della Ram. 1.3.4.1

Dump della memoria fisica in ambiente Windows

Esistono diverse strade per eseguire l’immagine della memoria. Windows 2000 e Windows Xp forniscono un modo semplice per generare il dump, entrambi infatti possono essere configurati in modo tale da generare un file immagine ogni qual volta il sistema va in crash o viene interrotto in

8

Nel presente documento il Dump della Ram e la sua analisi, possono essere eseguiti come ulteriore raffinamento dell’attività di ricerca. Il Dump della Memoria è qualcosa di relativamente difficile e ha bisogno di alcune circostanze soggettive per andare a buon fine. Tuttavia è possibile utilizzarlo per collegare il suo output con altri dati acquisiti all’interno della rete o del gruppo di sistemi compromessi.

Pagina 73 di 334

modo scorretto. Mediante le impostazioni di Startup and Recovery e possibile scegliere tre modalità di dump: • Complete memory dump • Kernel memory dump • Small memory dump (64 KB) Complete memory dump scrive un file contente l’intero contenuto della memoria, se si sceglie questa modalità è necessario disporre di uno spazio su disco pari ad almeno l’intera dimensione della memoria fisica più un Mbyte. Di default il file viene scritto nella directory %SystemRoot%\Memory.dmp. Ogni volta che si genera un dump il precedente viene sovrascritto. Kernel memory Dump esegue il dump solo della memoria kernel, dei processi running in Kernel Mode dei driver in Kernel Mode e la parte relativa all’Hardware Abstraction Layer (Hal). Eventuale memoria non allocata o riservata a mode non viene considerata. Ogni volta che si genera un dump il precedente viene sovrascritto Small memory dump registra solo informazioni utili a risalire alla causa del crash della macchina • Il cosiddetto “stop message” e relativi parametri •

La lista dei driver caricati

•

Processor context (PRCB)

•

Process information e kernel context (EPROCESS)

•

Process information e kernel context (ETHREAD)

•

Lo stack delle chiamate in Kernel-mode

Ogni volta che si genera un dump un nuovo file viene creato. L’utilità di un dump per l’analisi Forense è quello di fotografare l’immagine della memoria senza dover in alcun modo modificare lo stato della macchina. È quindi utile poter realizzare il dump in qualsiasi momento. Abilitando la chiave di registro: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters\CrashOnCtrlScr oll

E riavviato il sistema, si ha la possibilità di utilizzare una combinazione di tasti(Ctrl destr + 2 volte BloccScorr) atta alla generazione di un crash e quindi alla creazione del dump. In genere, i metodi menzionati hanno delle limitazioni nell’ambito di una analisi Forense in quanto la macchina target deve essere, se non precedentemente configurata, riavviata. La applicabilità di queste operazioni deve essere analizzata nel contesto delle policy dell’azienda. Se è necessario analizzare l’uso della memoria di programmi running in Mode può essere utile il tool Debugging Tools for Windows che permette la generazione del dump di porzioni della

Pagina 74 di 334

memoria riservate al processo. Un suo uso potrebbe essere quello di analizzare sospetti malicious code. 1.3.4.2

PMDUMP

(Freeware for Win95, Win98, WinME, WinNT, Win2000, WinXP ) http://ntsecurity.nu/toolbox/pmdump/ Genera il Dump della Ram, relativamente a un processo ready, e scrive il contenuto su un file. Sintassi: pmdump pmdump -l visualizza la lista di tutti i processi ready sulla macchina contraddistinti dal loro PID 1.3.4.3

DD 3.16.2

http://s.erols.com/gmgarner/forensics/ Il dump della memoria con questa versione di DD può essere fatto usando il comando : dd.exe if=\\.\PhysicalMemory of=d:\images\PhysicalMemory.img bs=4096 --md5sum --md5 -md5out=d:\images\PhysicalMemory.img.md5

si raccomanda tuttavia di utilizzare l’ opzione conv=noerror nel caso in cui alcune regioni della memoria non possano essere lette. DD inserirà degli 0 nel file generato in corrispondenza di queste zone.

Pagina 75 di 334

1.4

Verifiche di configurazione e disponibilità sui sistemi di test e le reti

1.4.1

Configurazione dei sistemi di test, dei possibili target dell’esame forense e di analisi. L’importanza di effettuare analisi e test con sistemi “puliti” e non compromessi è rivelata dalle potenziali conseguenze che il mancato rispetto delle procedure di seguito trattate potrebbero avere. Utilizzare sistemi ritenuti non affidabili e sicuri per effettuare test e analisi può esporre questi sistemi a subire ulteriori danni. Inoltre, questo comportamento pregiudicherebbe l’affidabilità dei risultati ottenuti. Come se ciò non bastasse, una Forensic Workstation (FW), magari connessa in rete sulla quale è introdotto del malicious code, potrebbe informare l’intruso dell’esecuzione in corso del test, con conseguenze variabili9. Spesso, inoltre, potrebbe essere necessario effettuare un’analisi direttamente sulla macchina compromessa, addirittura quando quest’ultima è ancora connessa alla rete10. Questo tipo di analisi è denominata Live System Analysis.11 Il problema da affrontare è quindi quello di configurare la FW12 in modo tale da arginare l’avvenuta contaminazione alle singole macchine oggetto dell’attacco, cercando di non rimanerne vittima a propria volta. Configurare adeguatamente una macchina dedicata a operazioni di test e analisi è una grande responsabilità. Avere in dotazione una FW non significa solamente essere dotati di una macchina estremamente potente e veloce. Una FW è una macchina potente ma dotata di un sistema operativo robusto e sicuro, adattato e configurato alle singole circostanze e bisogni in modo tale da garantire un elevato livello di sicurezza e invulnerabilità.

1.4.1.1 Considerazioni sull’hardware di una Forensic Workstation La configurazione hardware ideale di una FW attuale dovrebbe soddisfare almeno i seguenti punti: • • • • • • • • • •

Processore Intel x86 Pentium IV (consigliato dual-processor) 1 GB RAM 50 GB Hard Disk (SCSI) Cassetto estraibile per gli Hard Disk da analizzare DVD-Rom (SCSI) Masterizzatore (SCSI) Unità nastro per i backup o Fast Ethernet Possibilità di connettersi con svariati tipi di media (IEEE1394, USB 2.0, UWSCSI e ATA133) Ulteriori i rimovibili (unità Zip, Jaz e simili)

9

A tal fine si rammenta che una Forensic Workstation deve essere dotata di strumenti di protezione antivirale. Può essere connessa in rete con altre stazioni di lavoro, ma non deve essere connessa con il resto della rete locale e/o con Internet. 10 Questo tipo di operazione si rende necessario quando il target dell’analisi non può essere disconnesso in quanto l’operazione potrebbe impattare, a vario titolo, sulla produttività e sul business dell’ownerdi una particolare risorsa da analizzare. 11 Il concetto di LSA è qualcosa di estremamente complesso ed ha come variabili i dispositivi su cui viene effettuata l’analisi medesima. La prossima release del documento conterrà degli inserti sulla materia. I prospect sono invitati a contribuire. 12 Nel caso specifico, per FW si intende Forensic Workstation.

Pagina 76 di 334

A volte si rende necessario l’uso di una FW mobile ma il suo uso, più che altro per gli elevatissimi costi e le scarse prestazioni raggiungibili, è sconsigliato nella maggior parte dei casi. Un discorso particolare va effettuato per quello che riguarda la gestione e la manutenzione degli Hard Disk. Un Hard Disk usato per effettuare indagini è sottoposto a molto stress, essendo i dischi in continuo movimento. Per questo semplice motivo è consigliato sostituirli ogni due (al massimo tre) indagini. Un ulteriore aspetto da tenere in considerazione e quindi che merita di essere trattato, è l’importanza che rivestono le informazioni su cui si indaga. La possibilità di combinare elementi di un’indagine con informazioni relative ad altre, ci invita alla massima cautela ed al rispetto delle best practices che rammentano l’importanza e la necessità di effettuare il wiping di ogni disco come prima regola d’uso degli stessi in un’indagine. Il wiping più indicato segue le procedure del Department of Defense americano avente come procedura la DOD 5220.22-M. Consiste in un overwrite multiplo di un contenuto di uno stesso file. In questo caso, però, il principio di cui sopra va seguito per tutto il disco. Una volta effettuato il processo di multiple overwriting, conviene utilizzare uno strumento di verifica dell’effettiva cancellazione “di basso livello”, anche un Norton Disk Edit va bene. Ecco come, anche nel caso del wiping, va effettuata una validazione dei risultati ottenuti.

1.4.1.2

Considerazioni sul software di una Forensic Workstation

La configurazione tipica di una FW dovrebbe permettere l’utilizzo dei sistemi operativi più diffusi. Questo vuol dire che è possibile dotarsi di una macchina che permetta dual boot o di più macchine dedicate a sistemi diversi. I principali sistemi operativi diffusi sul mercato sono Windows NT/2000 e Linux ed è, infatti, su questi sistemi che qualsiasi FW dovrebbe poter operare. Dopo aver scelto quale sistema utilizzare, la prima cosa da fare è quella di configurare il sistema in modo tale da renderlo il più sicuro possibile. Questo implica l’installazione e l’aggiornamento del sistema operativo con le ultime patch di sicurezza, la disinstallazione dei pacchetti e la disabilitazione dei servizi non usati o dei quali si è a conoscenza di vulnerabilità non risolte, più o meno gravi. E’ arduo creare un elenco di software indispensabili e talmente generale da essere adatto per ogni sistema. Le best practices, in ogni caso, prevedono l’uso di un antivirus aggiornato, vari editor esadecimali e di testo, di vari debugger ASM, di tools di ricerca (grep e ngrep), tools per l’analisi dei file system, di software di computer forensic dedicati a indagini e recupero dati (molto conosciuti Encase e TCT), test dei sistemi e di sniffing. La scelta di un sistema operativo o dell’altro dipende quindi dalle proprie skills, dalle proprie necessità e dai propri mezzi. Un aspetto che potrebbe avvantaggiare Linux è il fatto che ogni software, compreso Linux stesso, sia open source. 1.4.1.3

Software originali e controllo di autenticità

E’ estremamente importante che sulle proprie macchine siano installati esclusivamente software originali. Un software crackato, ovvero alterato in modo da risultare registrato dall’utente senza che lo sia effettivamente, potrebbe contenere del codice malevolo che può portare a danni Pagina 77 di 334

variabili e non prevedibili a priori13. Si può trattare di codice che può portare a malfunzionamenti del software stesso o a crash di sistema, oppure di cosiddetti spyware, se non di virus effettivi o trojan, che possono attivare delle backdoor cioè abilitare servizi di rete su porte T non convenzionali che permetterebbero di assumere il controllo della macchina stessa tramite accesso remoto. E’ quindi molto importante che si possa attuare una verifica sui software che si acquistano o che si scaricano dalla rete. Per implementare un controllo di autenticità sono stati studiati alcuni meccanismi di checksum o di apposizione di firme digitali. L’algoritmo per il calcolo di un checksum denominato MD5 è diventato uno standard in questo senso. Va detto, a tal proposito, che esistono dei paper scientifici che avvalorerebbero una potenziale (ed altrettanto teorica) debolezza dell’MD5. Tuttavia va ricordato che l’utilizzo del suddetto algoritmo nelle operazioni di forensics è “statico” cioè con pochi riscontri pratici14. Di seguito alcuni dettagli. 1.4.1.4

Cenni sul MD5

L'MD5 è un algoritmo nato per verificare l’integrità dei dati attraverso la creazione di un checksum a 128 bit, calcolato conoscendo unicamente il dato posto in ingresso che può essere di qualsiasi natura e dimensione. Il checksum ottenuto ha un rapporto di biunivocità col dato stesso e lo si potrebbe paragonare alla sua “impronta digitale” o ad una “firma”. Questo non vuol dire che conoscendo il risultato è possibile ottenere nuovamente il dato iniziale, applicando il procedimento inverso. L'algoritmo implementa un hash "a senso unico" e questo significa che il dato in ingresso è per così dire "convertito" in una stringa di caratteri, di lunghezza fissa, chiamata anche message digest. Lo scopo dell'MD5 è, infatti, solamente quello di identificare il dato in sé. E' impossibile che due dati differenti possano ottenere lo stesso checksum, e un messaggio sul quale non si ottiene l'MD5 atteso è sicuramente un messaggio contraffatto. L'algoritmo, sviluppato dal Professor Ronald L. Rivest del MIT, è studiato per essere utilizzato principalmente in applicazioni per l'apposizione di firme digitali, come PGP/GPG, che richiedono un metodo sicuro per la compressione dei dati prima che vengano crittati facendo uso di chiavi private. Basato sul documento RFC 1321 che ne illustra anche la sua implementazione in C, l'MD5 è ormai divenuto uno standard accettato dalla Internet Engineering Task Force (IETF) e ne è stata scritta un’implementazione in molti dei linguaggi più usati: C++, Delphi/Pascal, Javascript, Miva Perl5 e Visual Basic. L'MD5 è il terzo algoritmo creato dal Professor Rivest che implementa il calcolo di un message digest ma tutti (i precedenti erano l'MD2 e l'MD4) presentano una struttura simile, con la semplice differenza che il primo è ottimizzato per sistemi a 8 bit mentre gli ultimi due per l'uso con macchine a 32 bit. L'MD5 si presenta come un estensione del padre, l'MD4, del quale fu dimostrata la velocità ma anche la sua vulnerabilità. Se messi a paragone, l'MD5 non è veloce quanto il suo predecessore ma offre un livello di sicurezza di gran lunga più elevato. 13

Inoltre l’uso di software non “licenziato” corre il rischio di creare delle questioni di nullità nel corso dell’eventuale procedimento penale. 14 In pratica c’è poca interazione con l’esterno, per cui gli attacchi relativi non sono di fatto portabili a questa realtà operativa.

Pagina 78 di 334

L’uso dell’MD5 in un indagine di forensic, in modo particolare, permette di verificare che le fonti di prova raccolte non siano state modificate in seguito all’avvio dell’indagine. 1.4.1.5

Antivirus

Su ogni macchina adibita a test dovrebbe essere installato un antivirus efficace ed aggiornato come illustrato in seguito. 1.4.1.6

Security scanner

Ogni volta che si configura una macchina in rete per essere protetti da attacchi esterni, resta sempre il dubbio se si è fatto tutto ciò che serve o se si è dimenticato qualcosa. I security scanner sono gli strumenti che permettono di eseguire la verifica dei possibili punti deboli che una macchina presenta a fronte di un accesso remoto. Questo tipo di software non dovrebbe mai mancare su una macchina adibita a test. In alternativa una workstation di questo tipo dovrebbe essere comunque stata sottoposta a scansione delle vulnerabiltà più importanti. Esistono diversi programmi che svolgono questi compiti e per trovare degli esempi si può controllare una lista aggiornata all’indirizzo http://www.mycert.mimos.my/resource /scanner.htm dove ne vengono descritti vari. Il primo e più famoso è sicuramente SATAN, acronimo di “Security Tool for Analyzing Networks”. Un altro software che sta riscuotendo un particolare successo per i sistemi Linux è Nessus (www.nessus.org), la cui idea di base è quella di collegarsi ad una macchina, quella che si vuole analizzare, verificare quali sono i servizi accessibili e, per ciascuno, verificare se ne sono stati resi noti problemi di sicurezza. In caso affermativo il programma lo segnala consentendo così all’amministratore di prendere provvedimenti. 1.4.1.7

Sniffer

Altri utili software dei quali si rende necessaria la presenza su una macchina di test sono quelli appartenenti alla categoria degli sniffer, programmi che permettono di monitorare e intercettare il traffico di rete. Ogni messaggio spedito verso una macchina appartenente ad una rete viene ricevuto da tutte le macchine facenti parte della stessa rete, ma è solo la macchina destinatario che verifica di essere l’oggetto della comunicazione e riceve “effettivamente” il messaggio. Gli sniffer si incaricano di leggere tutti i pacchetti che arrivano sull’interfaccia di rete della macchina sulla quale sono installati e di tenerne traccia. Se adottati per motivi amministrativi il loro uso è legale.Permettono infatti, una volta analizzati i file di log da loro creati, di verificare eventuali attività di port scanning o, più in generale, di acquisizione illecita di informazioni riservate. Alcuni sniffer molto usati e conosciuti sono Ethereal, Etercap e TDump/WinDump. L’utilizzo di questi strumenti è anche previsto nel caso in cui si sia optato per tenere collegata alla rete una macchina probabilmente compromessa, al fine di osservare i comportamenti del suo stato attuale. 1.4.1.8

Tool per la copia bit-a-bit del file system

Sono tra i primissimi software ad essere usati durante un’indagine o un test. Il loro uso si rende necessario perché sono gli unici che realizzano una copia “fisica” dei dati presenti in un file Pagina 79 di 334

system. Infatti, quello che interessa in un’indagine di forensic non sono i dati presenti ma quelli che un intruso o un semplice utente malintenzionato potrebbero aver cancellato, nascosto o contraffatto. Alcuni tool che adempiono questo scopo sono DD, Ddrescue e Image MASSter Solo. 1.4.1.8.1 DD DD è nato inizialmente come tool per la copia, la conversione e la formattazione di file testuali UNIX, permettendo all’utente di convertire un file dal set di caratteri EBCDIC ad ASCII e viceversa, trasformare caratteri maiuscoli in minuscoli e così via. DD mette a disposizione dell’utente una lunga lista di opzioni attraverso le quali è possibile lavorare sui file. Lo sviluppo della tecnologia forense ha immancabilmente portato DD a poter operare anche sui i di memoria. DD è una delle utilità nate su e per i sistemi *nix. In quanto tale ha i notevoli pregi di essere installata su ognuno di essi e, come conseguenza diretta, di essere assolutamente gratuito. Per tali motivi è uno dei tool più utilizzati per l’imaging e la copia bit-by-bit di ogni tipo di device a blocchi (dischi, tape, i removibili). DD, come molti altri tool *nix legge i dati in ingresso dal suo standard input e scrive i risultati sul suo standard output. L’uso nel campo forense di DD prevede la copia fisica di un o di memoria e la creazione di un file immagine attraverso un’appropriata linea di comando . Poiché l’uso di questo potente tool non è certo semplice ed immediato, si vuole raccomandare, per gli utenti meno esperti, una elevata dose di cautela. DD permette, infatti, di operare anche su aree “speciali” dei dischi e dei file system. L’uso di DD è particolarmente consigliato proprio per la sua potenza e per il largo successo riscontrato presso la comunità di esaminatori forensi, successo che è simbolo di garanzia e di affidabilità. Un esempio: DD permette, attraverso una linea di comando appropriata, di ottenere direttamente sia l’immagine del disco che l’hash MD5 dell’immagine. Per ulteriori informazioni sulle effettive capacità di DD e la visione di un approfondito test di esse, si può fare riferimento al documento Setup and Test Procedures: dd (GNU fileutils) 4.0.36 Forensic Tests, scaricabile liberamente dal sito del NIST (http://www.cftt.nist.gov). 1.4.1.8.2

Image MASSter Solo

Tra gli strumenti più usati dagli investigatori forensi durante la fase di acquisizione dei media si trova anche Image MASSter Solo: uno strumento hardware che permette di effettuare in modo semplice l’acquisizione di un disco. Image MASSter Solo è un duplicatore di hard drive, utile anche per il cloning di una workstation. E’ molto veloce, tanto da raggiungere un transfer rate di quasi 2GB al minuto nelle ultime versioni ed effettua molti controlli diagnostici e di verifica per assicurare una copia perfetta al singolo bit. IMS si collega direttamente al disco sorgente ma se la fonte da cui dobbiamo estrarre i dati Pagina 80 di 334

non è facilmente accessibile, ad esempio i dischi alloggiati nei notebook, IMS permette l’acquisizione anche tramite porta parallela. E’ inoltre dotato di un vano in grado di alloggiare sia il disco master che il target, proteggendoli da potenziali disturbi elettromagnetici. Un’ulteriore caratteristica che Image MASSter Solo fornisce ai suoi utenti e per i quali è molto apprezzato è la capacità di effettuare il wiping di un disco target, in modo da assicurare che tutti i dati presenti in precedenza siano stati definitivamente rimossi. Alcune versioni di IMS permettono addirittura di effettuare un’acquisizione via rete e, tramite connessioni PCMCIA, di clonare dischi SCSI e memorie FLASH. Proprio per la sua semplicità e per le sue enormi possibilità operative, IMS è molto apprezzato ed usato sia da tanti Forensic Analysts che da amministratori di reti15. 1.4.2

Configurazione delle reti Rendere sicure le proprie infrastrutture di rete si rende necessario per due motivi. Innanzitutto perché si dovrebbe evitare il diffondersi dell’intrusione di cui si è rimasti vittima. Inoltre, perché rimanere vittime di intrusioni mentre si sta eseguendo un analisi o un test, potrebbe provocare seri danni economici e di immagine. Rendere una rete completamente sicura non è mai possibile ma questo non pregiudica il fatto che rendere una rete “il più sicura possibile” sia fattibile, cominciando dallo studio di una funzionale policy di sicurezza. Di seguito sono illustrati alcuni punti sui quali si dovrebbe rivolgere un’attenzione particolare in fase di progettazione e realizzazione della rete.

1.4.2.1

Omogeneità delle architetture

Per poter garantire la sicurezza, la scelta delle architetture da adottare si rivela indispensabile. Quanto più le macchine che verranno collegate alla rete si riveleranno omogenee, tante più saranno le possibilità di garantire un elevato livello di sicurezza. Questo è dovuto in gran parte al fatto che l’amministratore ed eventuali assistenti potranno dedicarsi allo studio di una sola macchina che, una volta raggiunto un certo livello di invulnerabilità, non obbligherà i suddetti allo studio di una macchina diversa che avrà altre vulnerabilità. 1.4.2.2

“robuste”

Configurazioni ottimali possono rivelarsi completamente inutili, se non sono sostenute da una intelligente politica d’uso e creazione delle . Esistono, infatti, programmi che permettono ad un eventuale intruso di scoprire con una relativa facilità alcune , tramite attacchi basati su dizionari, ovvero provando tutte le parole contenute in una lista di parole comuni, oppure tramite attacchi basati sulla forza bruta, ovvero provando ogni possibile combinazione. 15

Una particolare menzione va fatta nei confronti di Open Data Duplicator. Il prodotto è stato terminato pochi mesi orsono e sarà disponibile tra poco nell’ambito del progetto opensource denominato ODESSA – www.openforensics.org. ODD consta di tre componenti. Il primo è un set di Linux boot disks, estrapolati dal progetto TRINUX, che consentono ad un operatore di effettuare un boot da una macchina Intel, PPC, o Sparc in un ambiente trusted. Gli altri componenti sono un’applicazione client/server utilizzate per copiare i contenuti di un file (o device) da una location ad un’altra, feature generalmene usata per effettuare una copia di tipo bit-image o forensic copy di un dispositivo. Un’altra cosa interessante di ODD riguarda il o dei trasferimenti file sia in locale sia in remoto sia via network. Inoltre sono previsti alcuni plugin relativi alle attività più comuni di ricerca ed analsi forense.

Pagina 81 di 334

Se la di determinati servizi “delicati”, o addirittura la dell’utente amministratore, è una parola di uso comune o ha una struttura molto semplice, può essere scoperta in un tempo relativamente breve. E’ ad esempio sconsigliabile l’uso di nomi propri di persone, città, oggetti, date di nascita o numeri di telefono e così via. Ancora peggio se si usasse la identica allo name. La soluzione ideale è l’uso di parole alfanumeriche, contenenti caratteri speciali e mixed-case. Una robusta e facile da ricordare si può creare considerando il testo di una canzone o di una poesia e prendendo le iniziali delle parole, sostituendo alcune di esse con numeri o caratteri speciali graficamente simili (ad esempio S e $ con 5, e A con 4), aggiungendo un carattere speciale e rendendo maiuscola una o due lettere. Ad esempio, considerando la frase “Ci sarò per sempre // Nei tuoi occhi ovunque” si potrebbe ottenere la c$p5nt0O!. Molte volte la precauzione di costruire una complessa può essere resa vana dall’utilizzo di questa in applicazioni che fanno uso di meccanismi di autenticazione in chiaro, quali ftp, telnet, pop3, che non garantiscono alcun tipo di protezione e crittografia. Eventuali attaccanti potrebbero intercettare, tramite sniffing, delle ed è per questo motivo che sono nate applicazioni che proteggono le comunicazioni facendo uso di tecniche di crittografia. 1.4.2.3

SSH – Protocolli robusti per applicazioni di sicurezza

SSH, acronimo di Secure Shell, consente di stabilire una connessione crittata tra due sistemi e permette di instaurare connessioni remote protette, utili per l’amministrazione remota di una macchina ed un eventuale trasferimento di file, reso di fatto sicuro. Tale protocollo, ed in particolare OpenSSH per *nix nella sua implementazione opensource, rimane in ascolto sulla porta T 22 e garantisce elevati livelli di sicurezza grazie all’uso di vari algoritmi di crittografia, quali RSA per l’autenticazione e 3DES o Blowfish per la comunicazione. Ssh è un protocollo di comunicazione nato per rimpiazzare i comandi Berkeley r* (rsh, r, r) e a differenza di questi fornisce una infrastruttura per connessioni crittografate nonché autenticazione forte tra host e host e tra utente e host. Chiude inoltre alcuni noti problemi di sicurezza dei protocolli T/IP come l'IP spoofing (falsificazione dell'indirizzo IP del mittente), il DNS spoofing (falsificazione delle informazioni contenute nel DNS) e il routing spoofing (falsificazione delle rotte intraprese dai pacchetti e instradamento su percorsi diversi). I comandi r* possono essere addirittura rimpiazzati dalle rispettive versioni sicure (ssh, s, s) in maniera trasparente per l'utente. Ogni host su cui è installato ssh possiede una coppia di chiavi RSA (un algoritmo di crittografia a chiave asimmetrica) lunghe 1024 bit, una pubblica ed una privata. In più, ogni utente che utilizza ssh può opzionalmente generare una propria coppia di chiavi RSA. All'atto della connessione, il server comunica al client due chiavi pubbliche: una fissa di 1024 bit che è la vera e propria chiave dell'host e l'altra di 768 bit che viene rigenerata ogni ora. Il client allora genera una sequenza casuale di 256 bit e la codifica con le chiavi pubbliche del server. Da questo momento in poi la connessione viene crittografata con uno degli algoritmi a chiave simmetrica ati da ssh (IDEA, DES, 3DES, Arcfour, Blowfish) e si a alla fase di autenticazione. Ssh può autenticare un utente in vari modi: RhostsAuthentication, RhostsRSAAuthentication, RSAAuthentication, TISAuthentication. Pagina 82 di 334

Come è facile intuire, una comunicazione attraverso ssh avviene più lentamente rispetto ad una comunicazione non crittografata. La velocità della comunicazione dipende dall'algoritmo di crittografia utilizzato. Nel file REE.CIPHERS, presente nella distribuzione standard di ssh, vengono elencate le prestazioni di ogni singolo algoritmo rispetto all'algoritmo "None" (nessuna crittografia) che viene quindi fissato come riferimento. Il CERT16 ha pubblicato un bollettino di sicurezza in cui avverte della presenza di alcune gravi vulnerabilità presenti in alcune implementazioni del diffuso protocollo Secure Shell (SSH). Le falle, scoperte in alcuni noti prodotti basati su SSH, potrebbero consentire ad un aggressore di eseguire da remoto del codice a sua scelta con gli stessi privilegi del processo SSH. Nel caso meno grave, un malintenzionato potrebbe invece dare origine a degli attacchi denial of service. Il CERT spiega che le vulnerabilità, tutte del tipo "buffer overflow", affliggono sia i client che i server SSH e possono essere sfruttate senza necessità per l'eventuale aggressore di autenticarsi sul sistema. Un ulteriore problema di sicurezza concerne l’immissione delle , infatti, se se il campo per immettere la viene lasciato vuoto e viene premuto invio, SSH permetterà a chiunque l'accesso alla macchina. Per ovviare a questo bug la compagnia ha rilasciato una patch, la versione 3.0.1, che risolve questo problema. Secondo gli operatori del settore la cosa grave è nel fatto che su molte piattaforme (come Windows e Unix), i server SSH girano spesso con i massimi privilegi (system o root). OpenSSH, SecureCRT e LSH risultano immuni ai problemi qui riportati, invece, tra i molti software vulnerabili troviamo F-Secure fino alla versione 3.1.0 per UNIX e fino alla versione 5.2 per Windows, le versioni di SSH fino alla 3.2.2 per Windows e UNIX, Putty fino alla versione 0.53, WinS fino alla 2.0.0, e altri di minor diffusione. Le possibili soluzioni da attuare al fine di proteggere i sistemi consistono nell’installare patch o upgrade e imporre restrizioni all’accesso. Per quanto concerne questo ultimo aspetto, è utile limitare l’accesso a SSH server ai soli hosts “trusted” e a quelle reti che utilizzano dei firewall o altri sistemi di filtraggio dei pacchetti. Alcuni SSH servers possono avere la capacità di restringere l’accesso basandosi sugli indirizzi Ip. Effetti simili possono essere realizzati utilizzando T wrappers o altre tecnologie similari. (SSH client può ridurre il rischio di attacchi connettendosi solo a servers “trusted”). Queste soluzioni non permettono di annullare ogni possibile attacco, ma rendono più difficoltosa la realizzazione degli stessi. 1.4.2.4

SSL e SHTTP – Comunicazioni crittate

Per proteggere le comunicazioni sono impiegate diverse misure di sicurezza: per esempio una LAN può scegliere un firewall per proteggersi dall'esterno, quindi controllare gli accessi tramite e chiavi private (come descritto sopra); ma questi sistemi non eliminano del tutto i rischi di attacchi alla privacy. All'esterno della LAN, se questa è collegata ad Internet, i firewalls non difendono da attacchi del tipo "man in the middle". E' per questo motivo che i nuovi server WEB “sicuri”, prodotti da svariate imprese, prevedono un protocollo come SHTTP (Secure HyperText Transfer Protocol), estremamente flessibile rispetto alle esigenze degli utenti riguardo 16

Viene menzionata la specifica circostanza in quanto molte delle piattaforme ivi citate sono in produzione.

Pagina 83 di 334

alle comunicazioni sul WWW, e come SSL (Secure Socket Layer) che invece è più rigido ma più generale, nel senso che offre sicurezza anche per altri protocolli di livello applicazione. Dato che la fiducia è ciò che a gli operatori, sempre più numerosi, che decidono di sviluppare il commercio elettronico usando Internet come mezzo di comunicazione, ne consegue che rinforzare la sicurezza e ridurre le esposizioni ai rischi sono la migliore scelta possibile. SSL è un protocollo a livelli che deve interfacciarsi a livello più basso con un livello di trasporto affidabile come il T ed a livello superiore con un protocollo applicazione, per esempio HTTP, FTP, Telnet etc.; SHTTP aggiunge sicurezza ai messaggi HTTP. Ognuno di questi protocolli può esistere su un sistema indipendemente dalla presenza dell'altro. Sebbene in principio si pensasse che l'uso di SSL escludesse altri provvedimenti come SHTTP, non è così; anzi è bene ribadire che i due protocolli SSL e SHTTP non sono mutuamente esclusivi, piuttosto possono facilmente coesistere in modo complementare interfacciando SHTTP su SSL. Secure Socket Layer è un protocollo che garantisce la privacy delle comunicazioni su Internet; esso permette infatti alle applicazioni client/server di comunicare in modo da prevenire le intrusioni, le manomissioni e le falsificazioni dei messaggi. Il suo scopo primario è quindi quello di fornire riserbo ed affidabilità alle comunicazioni. Il protocollo SSL provvede alla sicurezza del collegamento garantendo tre funzionalità fondamentali: •

Privatezza del collegamento. La crittografia è usata dopo un hand shake iniziale per definire una chiave segreta. Per crittografare i dati è usata la crittografia simmetrica (e.g. DES, RC4, etc.).

•

Autenticazione. L'identità nelle connessioni può essere autenticata usando la crittografia asimmetrica, o a chiave pubblica (per es. RSA, DSS, etc.). I clients, in tal modo, sono sicuri di comunicare con il corretto server, prevenendo ogni interposizione. E' prevista la certificazione sia del server che del client.

•

Affidabilità. Il livello di trasporto include un check dell'integrità del messaggio basato su un apposito MAC (Message Authentication Code) che utilizza funzioni hash sicure (e.g. SHA, MD5, etc.). In tal modo si verifica che i dati spediti tra client e server non siano stati alterati durante la trasmissione.

SSL esamina esplicitamente un numero di attacchi, incluso l'attacco forza bruta, crittoanalisi, replay e “man in the middle”. E’ progettato per agire a livello di rete: ciò significa che non protegge da attacchi agli host, per i quali sarebbe consigliabile proteggersi con un package del tipo Tripwire. I Tripwire usano funzioni hash sicure per assicurare che i documenti non siano cambiati rispetto ad una versione di riferimento protetta in scrittura. L'uso dell'algoritmo RC4 con chiavi di 40 bits può portare problemi; sicuramente può quindi essere reso vano da organizzazioni governative o criminali in modo relativamente semplice. Tuttavia la scelta di RC4 è obbligata dalla legge USA sull'esportazione degli algoritmi di crittografia, anche se ultimamente vi sono delle deroghe.

Pagina 84 di 334

Ci sono diversi punti di SSL che, pur non essendo critici, potrebbero offrire ulteriore sicurezza. Ad esempio nel protocollo SSL Hand shake alcuni dati spediti con il messaggio CLIENT HELLO potrebbero essere spediti in un secondo momento, crittografati. Nel protocollo SSL Record, un errato MAC non dovrebbe far terminare la connessione ma causare una richiesta di ripetizione del messaggio: infatti ci sono pochi attacchi che possono trarre vantaggio dalla duplice spedizione di dati, mentre terminando la connessione si apre la strada agli attacchi basati sul servizio negato; inoltre i numeri di sequenza dovrebbero essere generati in modo casuale invece che ordinatamente. E' importante notare, tuttavia, che questo approccio alla problematica della sicurezza sembra concepito in modo da permettere facili aggiornamenti ed il o a nuovi algoritmi di crittografia, senza stravolgere la struttura di SSL. Le falle in SSL consistono in quattro buffer overflow (tre contenuti nei processi di hand shake di SSLv2 e SSLv3 e uno contenuto nel codice per la rappresentazione ASCII degli interi) e in un bug nelle routine di codifica del parser ASN.1. L'ultima delle vulnerabilità, la meno grave, può essere sfruttata solo per attacchi di tipo DoS. I buffer overflow interessano tutte le versioni di OpenSSL più recenti della 0.9.6.e o, per quanto riguarda le pre-release, più recenti della 0.9.7-beta3. I server che adottano la versione 0.9.6d su sistemi a 32 bit con SSL 2.0 disabilitato non sono invece vulnerabili. Il bug nella codifica ASN.1 riguarda invece tutti i programmi OpenSSL che si avvalgono della libreria ASN.1 per analizzare i dati untrusted, fra cui le varie implementazioni dei protocolli SSL, TLS, S/MIME e PKCS#7. Secure HyperText Transfer Protocol, che è un estensione dell' HyperText Transfer Protocol (HTTP), protocollo di base del World Wide Web. S-HTTP è stato progettato per realizzare connessioni HTTP sicure. S-HTTP fornisce servizi sicuri applicabili per: •

transazioni confidenziali;

•

autenticazione e integrità dei dati;

•

non ripudiabilità dell'originale.

Il protocollo lascia massima flessibilità nella scelta dei meccanismi di gestione della chiave, politiche di sicurezza e algoritmi di crittografia e a opzioni di negoziazione fra le parti per ogni transazione. Non è richiesta la chiave pubblica per il client. SHTTP contiene HTTP, poiché permette ai messaggi di essere incapsulati in vari modi. L'incapsulazione può essere ricorsiva e il messaggio può subire diverse trasformazioni. SHTTP fornisce inoltre linee di testa per funzioni di gestione amministrativa come trasferimento delle chiavi e dei certificati. Le debolezze dell'SHTTP sono simili a quelle dell' SSL, anche se la natura più generica dell'SHTTP lo rende più resistente nei confronti di eventuali attacchi. Il modo di operare dell'SHTTP, con gli attributi di default, lo rende più resistente nei confronti di attacchi replicati, analisi del testo cifrato e al problema “dell'uomo nel mezzo”, anche perché le opzioni possono essere rinegoziate. SHTTP presenta anche dei punti deboli. L'uso dello scambio di chiave in banda, ad esempio, può diventare un problema, se il trasferimento non avviene con le dovute cautele. Inoltre la flessibilità dell'SHTTP permette di non cifrare tutto e una persona poco esperta di sicurezza e crittografia potrebbe non attuare tutte le protezioni necessarie alle sue informazioni, mentre SSL opera secondo una politica di cifrare tutte le informazioni così da assicurarsi tutta la sicurezza possibile. Pagina 85 di 334

1.4.2.5

Antivirus

Sicuramente su ogni macchina dovrà essere installato un sistema di prevenzione da attacchi provenienti da virus conosciuti. Esistono molti software antivirus in circolazione, pertanto la scelta dovrebbe ricadere su quei software che propongono costanti aggiornamenti e codice robusto e sicuro. Le case produttrici di antivirus permettono di effettuare online il degli aggiornamenti, consentendo all’utente di eseguirlo quando lo ritiene più opportuno. Nuovi virus e trojan nascono e muoiono ad un ritmo elevato e pertanto si consiglia di effettuare l’aggiornamento almeno una volta alla settimana. 1.4.2.6

Firewall

E’ indispensabile che una qualunque LAN connessa ad Internet (o, in generale, a reti), sia dotata di firewall. Questi non è altro che un sistema, o insieme di sistemi, che ano e implementano una politica di controllo degli accessi filtrando il traffico di rete diretto alle risorse di una organizzazione. Il suo “compito” è quello di ridurre il traffico, eliminando quello indesiderato, rendere difficile l’acquisizione di informazioni e non permettere l’uso delle risorse protette da utenti non autorizzati. Ovviamente il firewall, affinché svolga la sua funzione, deve essere configurato in modo corretto e deve essere provvisto di politiche d’uso (tecnologie) adeguate. 1.4.2.7

Configurazione

Figura 21: configurazione di rete tipica

Questa è una delle tipiche configurazioni di rete in presenza di un firewall. In questo modo vengono definite tre reti distinte ed evidenziate interazioni tra: •

Internet - Rete DMZ;

•

Rete DMZ – Internet; Pagina 86 di 334

•

Connessione diretta Internet – Rete Interna.

La configurazione, quindi, deve essere realizzata in modo tale da permettere che: •

gli indirizzi IP delle macchine non siano direttamente visibili da Internet;

•

solo i componenti esterni al firewall (es. Border Router) siano direttamente accedibili;

•

solo i componenti della rete DMZ siano accedibili da Internet (attraverso comunicazioni filtrate dalla presenza del firewall);

•

solo i componenti della rete DMZ possano accedere alla rete interna con connessioni sempre filtrate dalle politiche implementate dal firewall.

Una struttura di questo tipo consente di realizzare una separazione in zone di differente grado di sicurezza nella architettura di rete dell’organizzazione. In tal modo è possibile accedere solo ad una parte della nostra rete tramite Internet e quindi proteggere i dati critici. 1.4.2.8

Tecnologie per sistemi di firewall

Le tipologie più diffuse di firewall sono: Static Packet Filtering, Dynamic Packet Filtering e Proxy. La prima tecnologia è utile se configurata su di un router quale primo livello di protezione perimetrale. Inoltre offre protezione solo rispetto a tecniche di attacco banali quali: spoofing, source routing, traffico ICMP, tentate connessioni T. Al fine di proteggere la nostra rete, inoltre, è molto importante definire correttamente le ACL. Quindi, per questi motivi, è utile disporre di un proprio Border Router da gestire che implementerà il filtraggio statico e il meccanismo delle ACL, costituendo il primo livello di protezione della nostra rete. La seconda tecnologia, offre una protezione molto maggiore rispetto alla prima in quanto controlla il traffico anche sulla base di una connection table che mantiene lo stato della connessioni attive. La limitazione principale concerne il fatto che tale tecnica non analizza il traffico rispetto al payload, ma solo attraverso la informazioni contenute negli header. Un’altra limitazione riguarda i protocolli connectionless come ad es. UDP. Tali protocolli vengono,infatti, gestiti in maniera inefficace. Una funzionalità supplementare che ogni firewall dovrebbe fornire è il NAT. Tipicamente viene utilizzata per sfruttare le classi di indirizzi IP riservate e non instradabili (172.16; 10; 192.168) e per mascherare i reali indirizzi IP delle macchine interne alla rete aziendale. Con questa tecnica nasce il problema della gestione delle connessioni in ingresso. Per risolverlo esistono due tecniche principali quali: static NAT e PAT. Un proxy server è un componente che fa da intermediario rispetto al traffico scambiato fra due segmenti di rete. Tipicamente, un proxy viene usato per fornire connessioni ad Internet ad un numero elevato di host interni. In questo modo la connessione ad Internet della rete interna viene effettuata e gestita da un unico componente. Questo opera a livello applicativo, di conseguenza analizza il payload dei pacchetti, offrendo una sicurezza ottimale. Lo svantaggio che presenta riguarda le performance che, ovviamente, risultano potenzialmente molte critiche.

Pagina 87 di 334

1.4.2.9

Vulnerabilità e possibili contromisure

La maggior parte degli attacchi riusciti ai danni dei sistemi operativi deriva da un numero estremamente elevato di vulnerabilità software. Ciò si deve al fatto che coloro che effettuano gli attacchi agiscono in modo opportunistico, ovvero scelgono la strada più semplice e comoda, sfruttando le vulnerabilità più conosciute e impiegando gli strumenti di aggressione più efficaci e diffusi. Contano sul fatto che le aziende spesso non pongono rimedio ai problemi e quindi spesso conducono attacchi indiscriminati, scegliendo gli obiettivi dai risultati di una serie di scansioni in Internet per rilevare i sistemi vulnerabili. La compromissione dei sistemi del Pentagono a seguito dell’episodio di hacking Solar Sunrise e la facile e rapida diffusione dei worm Code Red, NIMDA e Slammer, per fornire solo alcuni esempi, possono essere facilmente collegate allo sfruttamento di alcune vulnerabilità per le quali non sono state tempestivamente applicate le opportune correzioni. Due anni fa, il SANS Institute e il National Infrastructure Protection Center (NIPC) pubblicarono un documento che elencava le dieci vulnerabilità più critiche per la sicurezza in Internet. Da allora migliaia di organizzazioni hanno utilizzato quella lista, e la sua evoluzione a venti vulnerabilità diffusa un anno dopo, come guida per risolvere rapidamente i buchi di sicurezza più pericolosi. Le vulnerabilità che hanno favorito i tre esempi riportati sopra - l’episodio Solar Sunrise del Pentagon e i worm Code Red e NIMDA - sono riportate su quella lista. Questa nuova versione delle “Venti Vulnerabilità più critiche” è in effetti costituita da due liste di dieci: i dieci servizi di Windows le cui vulnerabilità sono più frequentemente sfruttate e i dieci servizi di Unix le cui vulnerabilità sono utilizzate più spesso per condurre un attacco. Sebbene vi siano migliaia di episodi di violazione della sicurezza che ogni anno colpiscono questi sistemi operativi, la stragrande maggioranza degli attacchi portati a termine sono diretti verso uno o più di questi servizi. L’elenco completo, ordinato per servizi, delle vulnerabilità più diffuse e le rispettive istruzioni dettagliate utili per correggere i problemi di sicurezza, si trovano all’indirizzo Internet www.sans.org/top20.htm . Di seguito riportiamo alcune delle vulnerabilità prese da tale elenco. 1.4.2.10

Web Server (Microsoft IIS / Apache)

IIS presenta gravi vulnerabilità nel gestire buffer overflow, richieste malformate, mentre Apache ne presenta nel gestire buffer overflow. Le possibili contromisure sono quindi: •

utilizzare solo le funzionalità e i moduli strettamente indispensabili;

•

installare patch ed eseguirlo come utente non privilegiato, ove possibile.

Un’importante osservazione da fare è che un qualunque web server non può essere considerato sicuro fintanto che non si è garantita la sicurezza di tutte le applicazioni web presenti su di esso (basta un semplice script CGI mal progettato per comprometterlo). Per questo è buona regola: •

isolare un web server in maniera tale che un intruso, prendendone il controllo, non possa facilmente connettersi ad altre macchine critiche della rete; Pagina 88 di 334

•

utilizzare sottoreti dedicate;

•

utilizzare comunicazioni e protocolli ridotti al minimo indispensabile;

•

utilizzare politiche di autorizzazioni stringenti per qualunque connessioni tra un web server e una qualunque altra macchina della rete;

•

utilizzare meccanismi di monitoraggio e di rilevazione degli attacchi (analizzatori di log, intrusion detection system…) ;

•

limitare al minimo le porte applicative disponibili;

•

evitare l’uso di servizi altamente a rischio;

•

non far convivere sulla stessa macchina servizi con grado di rischio molto diverso;

•

evitare meccanismi di controllo remoto se non ben collaudati;

•

evitare le ultime release di sistemi non maturi.

1.4.2.11

Script CGI

Gli script, soprattutto quelli forniti di default come esempi, presentano vulnerabilità, sono facilmente accessibili ed operano con gli stessi privilegi del web server. Le possibili contromisure sono: •

installare patch ed eseguirlo come utente non privilegiato;

•

eliminare tutti gli script non necessari o di esempio;

•

testare a fondo tutti gli script utilizzati in produzione.

1.4.2.12

RPC (Remote Procedure Calls)

Le RPC sono largamente usate per implementare molti servizi di rete quali: gestione remota e file system condivisi (NFS), quindi vengono installate ed abilitate di default. Le vulnerabilità hanno permesso agli intrusi di acquistare diritti di root sulle macchine attaccate, oltre ad essere sfruttate per provocare Denial of Service. Le possibili contromisure sono:

1.4.2.13

•

disabilitare ogni servizio RPC non indispensabile;

•

installare la patch dei produttori per ogni servizio di RPC attivo;

•

impedire le connessioni alle porte RPC critiche (111, 32770-32789) da Internet o da organizzazioni esterne. DataBase

I database contengono le informazioni più critiche, sensibili e di valore di una organizzazione. Solitamente vengono installati su macchine che non operano da web server, ma da questi acceduti (direttamente o meno). Le possibili contromisure sono: Pagina 89 di 334

•

mai permettere un accesso diretto al database via Internet;

•

evitare l’accesso al database direttamente da un Web Server (via cgi, servlet, etc.);

•

utilizzare meccanismi di replica dei dati per isolare ulteriormente i database master;

•

limitare al minimo il numero degli accessi degli operatori interni di una organizzazione;

•

non permettere a tali operatori di accedere con privilegi superiori a quanto sarebbe necessario e sufficiente.

1.4.2.14

SNMP e configurazione di default

Le vulnerabilità riguardano il modo in cui la comunicazione via SNMP viene gestita ed i metodi di autenticazione. Tali vulnerabilità possono permettere sia Denial of Service che il controllo. La “community string” (simile ad una ) spesso è lasciata al valore di default “public”o “private”. Inoltre, molte implementazioni, prevedono di gestione o associati a community string note pubblicamente, o facilmente reperibili. In alcuni casi tali community string non possono essere modificate. Le possibili contromisure risultano quindi essere: •

eliminare il servizio ove non necessario;

•

installare patch;

•

utilizzare community string non di default;

•

impedire l’accesso esterno a questi servizi (porte 161 e 162 T/UDP).

1.4.2.15

BIND

Spesso, questo servizio, è attivo su macchine che non operano da DNS ed è poco protetto. Una volta compromesso viene utilizzato per ulteriori attacchi o per fornire false informazioni. Le contromisure possibili sono: •

disabilitare il servizio (named) se non utilizzato impedendo di lasciare la macchina esposta ad attacchi;

•

installare patch ed eseguirlo come utente non privilegiato;

•

limitare al minimo le funzionalità (es. Zone transfer) e le informazioni (es. Version String);

•

monitorare le attività di rete dei DNS pubblici.

1.4.2.16

Meccanismi di autenticazione

Tutti i meccanismi di interazione tra operatori e computer utilizzano per controllarne l’accesso. I problemi nascono dal fatto che tali sono definite dall’utente stesso e quindi risultano essere estremamente semplici o comunque facilmente “indovinabili”. Alcune delle possibili contromisure derivanti sono: •

impedire l’utilizzo di estremamente semplici; Pagina 90 di 334

•

impedire che le vengano eliminate;

•

impedire che le non vengano mai cambiate;

•

mantenere la segretezza delle ;

•

utilizzare periodicamente degli strumenti chiamati “ scanner” per verificare la qualità delle (utilizzabile solo sotto autorizzazione scritta ed esplicita);

•

utilizzare meccanismi che permettano la scelta della da parte del sistema;

•

utilizzo di sequenze one-time-;

•

proteggere tali in luogo e con modalità sicure;

•

soprattutto: coinvolgere gli utenti stessi attraverso corsi, riunioni e spiegazioni.

1.4.2.17

Condivisione di file e informazioni via NetBios, NFS

Le vulnerabilità sono legate all’implementazione dei meccanismi di condivisione o a configurazioni inappropriate. Ciò può provocare sia l’esposizione di file critici che la possibilità di ottenere il controllo remoto di sistemi. Le contromisure sono: •

limitare le condivisioni solo alle informazioni strettamente necessarie;

•

utilizzare “robuste”;

•

impedire l’accesso esterno a questi servizi;

•

prestare attenzione alla definizione di “trust relationships”.

1.4.2.18

Internet Explorer, LAN Manager, Windows Scripting Host

Internet Explorer, installato di default, presenta vulnerabilità che possono essere sfruttate da un creatore di pagine web appositamente realizzate. LAN Manager è un servizio installato di default anche quando il computer non necessita di tali funzionalità. Windows Scripting Host (WSH) è il meccanismo che viene spesso sfruttato da virus e worm per la diffusione attraverso il mailer di posta Outlook o Outlook Express. Le contromisure risultano essere: •

disabilitare le funzionalità non indispensabili (es: LAN Mng, WSH);

•

installare patch e service pack;

•

evitare le configurazioni di default.

1.4.2.19

SSH, FTP, LDP, Sendmail

Tutti questi servizi, di larghissima diffusione, presentano vulnerabilità legate ai bug (errori di progettazione). Questi forniscono lo strumento per numerose intrusioni. Le contromisure sono: •

disabilitare le funzionalità non indispensabili; Pagina 91 di 334

1.4.3

•

installare patch;

•

progettare l’architettura di rete e la dislocazione dei server in modo tale da confinare gli effetti di una intrusione.

Algoritmi di hash Sono algoritmi one-way che a partire da una stringa di dati di lunghezza arbitraria ne producono una di lunghezza fissa (tipicamente tra 64 e 255 bit) che è caratteristica della stringa data. La stringa, che rappresenta “l’impronta digitale” dei dati in questione, è definita valore di hash o checksum crittografico. La potenza degli algoritmi di hash è dovuta alle loro “forti” proprietà: •

data una stringa di hash è computazionalmente impossibile ricavare la stringa dalla quale è stata generata (altrimenti l’algoritmo non sarebbe più one-way);

•

è computazionalmente impossibile determinare due stringhe che producono la stessa stringa di hash;

•

qualsiasi stringa, sottoposta allo stesso algoritmo un numero infinito di volte, produce sempre lo stesso valore di hash (RIPETIBILITA’).

Ovviamente maggiore è la dimensione dell'hash, maggiore è la protezione dell'algoritmo e la difficoltà di poterlo infrangere. Gli algoritmi di hash maggiormente utilizzati sono: 1.4.3.1 -

MD5 (Message Digest Algorithm 5) RFC 1321 ftp://ftp.rfc-editor.org/in-notes/rfc1321.txt

Sviluppato dal Professore Ronald L.Rivest del MIT, è il successore di MD2, e MD4, algoritmi ormai in disuso. Produce hash di 128 bit da stringhe di lunghezza arbitraria Abbastanza robusto, è largamente usato ed è considerato ragionevolmente sicuro in quanto vi è una possibilità remota di violarlo. Fa parte della gamma di metodologie certificate per la forensics analysis. 1.4.3.2

SHA (Secure Hash Algorithm)

Sviluppato dal NIST (National Institute of Standards And Technology) e dal NSA (National Security Agency), è usato dal governo USA e produce stringhe di hash a 160 bit da stringhe di lunghezza arbitraria. Più performante e robusto di MD5, è abbastanza sicuro ma poco diffuso e utilizzato. 1.4.3.3

MD5 library

Alle funzioni deve essere ato un MD5_CTX che è usato per “contenere” l’MD5 context durante le chiamate multiple di funzione MD5_Update(). Questa libreria contiene anche un numero casuale di routines basate su MD5. Pagina 92 di 334

Normale metodo di utilizzo di questa libreria, che richiede l’inclusione di ‘MD5.h’ MD5_Init(...); MD5_Update(...); ... MD5_Update(...); MD5_Final(...); Le funzioni sono: -

void MD5_Init( MD5_CTX *c);

-

void MD5_Update( MD5_CTX *c; unsigned char *data; unsigned long len);

/* per inizializzare la struttura MD5_CTX */

/* per aggiornare il “message digest context” che viene generato con 'len' byte dal puntatore ai 'data'. Il numero di byte può essere di qualsiasi lunghezza*/ -

void MD5_Final( unsigned char *md; MD5_CTX *c; /* funzione chiamata quando si vuole un’ “impronta” dei dati di MD5_Update, la quale è messa nel ‘md’ array ed è lunga 16 bytes */

-

unsigned char *MD5( unsigned char *d; unsigned long n; unsigned char *md; /* per effettuare un MD5_Init(), seguito da un MD5_Update(), seguito da un MD5_Final(). Il risultato delle operazioni è messo in ‘md’ se non è NULL. Indipendentemente dal valore di ‘md’ l’ “impronta” è restituita dalla funzione; se ‘md’ era NULL l’ ”impronta” restituita viene messa in una struttura statica */

1.4.3.4

Creazione di alcuni semplici file e utilizzo di MD5 per calcolare il checksum crittografico basato sui loro contenuti

http://www.cert.org/security-improvement/implementations/i002.01.html Creazione del file e visualizzazione del contenuto: $ echo 'Hello, World!' > example_1

Pagina 93 di 334

$ cat example_1 Hello, World!

Utilizzo di MD5 per il calcolo del checksum univoco del file: $ md5 example_1 MD5 (example_1) = bea8252ff4e80f41719ea13cdf007273

Copia del file, utilizzo del comando UNIX diff per vedere che non ci sono differenze visibili di contenuto tra il file e la copia, e verifica che non ci sono differenze confrontando l’MD5 checksum dei due file: $ example_1 example_2 $ diff example_1 example_2 $ md5 example_1 example_2 MD5 (example_1) = bea8252ff4e80f41719ea13cdf007273 MD5 (example_2) = bea8252ff4e80f41719ea13cdf007273

Apportando un piccolo cambiamento a uno dei due file, in questo caso una nuova linea di spazio, si nota che l’MD5 checksum del file modificato cambia significativamente: $ echo ' ' >> example_2 $ md5 example_1 example_2 MD5 (example_1) = bea8252ff4e80f41719ea13cdf007273 MD5 (example_2) = e0675e728056818b0392c0c2f5478ff0

1.4.3.5

Confronto col programma “sum”

Il comune programma Unix sum non è un adatto generatore di checksum da usare per verificare l'integrità dei file. Notare nell'esempio seguente come il comando sum produce lo stesso risultato per due file diversi, mentre MD5 produce risultati diversi: $ echo 'Hello, World!' > example_1 $ echo 'World, Hello!' > example_2 $ sum example_1 1139 1 example_1 $ sum example_2 1139 1 example_2 $ md5 example_1 example_2 MD5 (example_1) = bea8252ff4e80f41719ea13cdf007273 MD5 (example_2) = 27da7edf402d602fc5908d8bdd2912

Pagina 94 di 334

1.4.3.6

Implementazioni

C •

implementazione originale del professor Rivest inclusa nell’appendice del rfc1321 ,disponibile anche in tarred & gzipped form

•

L. Peter Deutsch: MD5 in C

•

Colin Plumb, Branko Lankester, Ian Jackson, Galen Hazelwood: md5sum

•

tarred & gzipped form versione 1.02.

•

o MD5 in una collezione di componenti Delphi

•

creata da Paul Johnston (GPL)

•

Petr Kutil e Ivo Truxa

•

modulo Perl creato da Neil Winton, questa Perl Exstension richiede compilazione aggiuntiva

•

http://www.php.net/manual/en/function.md5.php

C++ Delphi Javascript Miva Perl5

PHP

Windows/Visual Basic •

1.4.3.7

Francisco Carlos Piragibe de Almeida has created a DLL with a BAS wrapper module for use in VB projects (19K ) e an ActiveX in-process server wrapper around the original DLL (includes the DLL) (1394K )

md5deep

http://md5deep.sourceforge.net/ MD5deep, scritto da Jesse Kornblum, è un programma cross-platform per calcolare l’md5 su un numero arbitrario di file; funziona su Windows, Linux, FreeBSD, OS X, Solaris, e dovrebbe funzionare sulla maggior parte delle altre piattaforme. Simile al programma md5sum che si trova nel pacchetto di GNU Coreutils, ha le seguenti caratteristiche supplementari:

Pagina 95 di 334

•

funzionamento ricorsivo: md5deep esamina ricorsivamente un’intera directory, calcola cioè l’md5 per ogni file in una directory e per ogni file in ogni sottodirectory;

•

stima del tempo quando processa file molto grossi;

•

modalità confronto: md5deep può accettare una lista di hashes conosciuti e confrontarla con un set di input file. Il programma può visualizzare sia gli input file che “matchano” con gli hashes conosciuti o quelli che non “matchano”.

Esempio di md5deep su Linux: $ md5deep -r /etc ea2ffefe1a1afb7042be04cd52f611a6 /etc/host.conf 25fd7a8a9ec4794960ef198a60f66d22 /etc/hosts.allow 70c943a610198717c827d27356a79ec6 /etc/hosts.deny d41d8cd98f00b204e9800998ecf8427e /etc/motd d36bb294cf19a21eb353b103d29f5375 /etc/wd 30eeb9e940c0c743682da53e41defb15 /etc/skel/.kde/Autostart/Autorun.desktop 68d9a46c4ec07ac828458815d4b3cfad /etc/skel/.kde/Autostart/.directory d19bbbed9d713f97f487b9ed9ec3f62f /etc/skel/.bash_ c03dade4bb0152c9d0b6d871b4c082f4 /etc/skel/.bash_profile Ultima versione rilasciata il 14 Marzo 2003: md5deep-0.16.zip

- Windows binary - MD5 9a98fe2f11ce9801ab4564acebb05581

md5deep-0.15.tar.gz - codice sorgente (compila facilmente su * nix, BSD, OS X e Windows) - MD5 a07715c3344524da1270e9eb39f9b9e1

1.4.3.8

CRC32 vs MD5

forensics@securityfocus http://www.securityfocus.com/archive/104/305235 CRC32

RFC 1510 http://www.ietf.org/rfc/rfc1510.txt

Il CRC-32, progettato per rilevare gli errori di trasmissione, calcola un checksum lungo 4 ottetti basato su un ciclico controllo di ridondanza.

Pagina 96 di 334

L'uso di questo checksum non è raccomandato in quanto un assalitore che usa un attacco plaintext probabilistico sarebbe capace di generare un messaggio alternativo che soddisfa il checksum. Probabilità che due file abbiano lo stesso CRC32 è di 1 su 2^32, cioè 1 su 4 miliardi. MD5 progettato per rilevare delle modifiche (128-bit checksum), ha caratteristiche più robuste legate alla sicurezza. Infatti le stesse tecniche utilizzate per la generazione delle collisioni sull’MD4, nell’MD5 impiegano tempi maggiori dell’ordine di 600 volte. Probabilità che due file abbiano lo stesso MD5 è di 1 su 2^128, cioè 3,4028236692093846346337460743177e+38 (un numero proibitivo); fare una ricerca delle chiavi differenti 2^127 è oltre le risorse di calcolo correnti. La differenza di base sta nel creare un input che abbia un match con un dato fingerprint. Con CRC32 è possibile, mentre NON lo è con MD5, contro il quale nessun attacco pratico è stato trovato. Gli FBI labs usano MD5 per verificare l’integrità delle SafeBack images. Commento al pdf: http://notablecases.vaed.uscourts.gov/1:01-cr-00455/docs/68089/0.pdf Formule hash e metodi “running” hash in uso nella computer forensics community: Cyclical Redundancy Checksum (CRC), Secure Hash Algorithm Version 1 (SHA-1), e il Message Digest Sum, Version 5 (MD5). Attualmente le tecniche CART incorporano CRC e MD5 come metodi di hash. Vanno fatte però alcune distinzioni: CRC va bene per la scoperta di errori, ma per essere sicuri che un disco non sia stato manipolato occorre utilizzare una vera funzione hash one-way. MD5 (e SHA-1) ha la speciale proprietà che non è possibile generare un “testo” dato un valore hash, cosa invece possibile con CRC32. E’ quindi consigliabile l’utilizzo di SHA-1 su MD5, e di MD5 su CRC32. Prima di effettuare qualunque analisi è necessario creare sempre un’etichetta hash MD5 per ogni nuova immagine delle prove, essenziale per garantire che queste non vengano alterate nel corso dell’indagine (tampering) e che l’intero lavoro non sia invalidato per un cavillo legale legato a una defezione.

Pagina 97 di 334

Una volta generato il valore di hash lo si salva su un file di testo che può contenere più valori relativi a più file (HASH SET) Quando si mettono a verbale le acquisizione on site è consigliabile allegare il suddetto file di testo. Pagina 98 di 334

1.4.4

Live system analysis Quando un sistema viene compromesso, si aprono due possibili scenari completamente differenti l’uno dall’altro che costringono il Forensic Analyst a utilizzare tecniche diverse per effettuare un’indagine corretta. Primo scenario: l’amministratore del sistema “vittima” può non essersi accorto in tempo utile dell’avvenuta intrusione e può aver eseguito sulla macchina operazioni di ordinaria amministrazione le quali, per loro natura, alterano le fonti di prova. Secondo scenario: l’amministratore (in altre parti si è visto come ciò sia possibile) ha immediatamente rilevato qualcosa che non andava nel sistema, fermato l’intruso, eventualmente rintracciandolo, e denunciato l’incidente, lasciando nelle mani degli investigatori la macchina, nelle stesse condizioni in cui si trovava durante l’attacco. Una delle operazioni di amministrazione che altera le fonti di prova è, ad esempio, la deframmentazione del file system, che rende inutile ricercare dati utili nello slack space; anche procedere con il reboot della macchina ostacola un’indagine, perché vanifica la possibilità di trovare informazioni nella memoria RAM del sistema, cancellatasi durante l’operazione, e che si sarebbero rivelate vitali ai fini della ricostruzione delle operazioni eseguite dall’hacker. Il secondo scenario si può estendere a tutte quelle situazioni nelle quali la malcapitata vittima necessita che il suo sistema sia sempre attivo. E’ questo il caso di tutte quelle macchine (firewall, router, proxy, DH e Web server ecc.) che forniscono un servizio che si presuppone sia sempre disponibile, a meno di speciali opere di manutenzione. Le best practices prevedono, tra le altre cose, la necessità di disconnettere dalla rete di appartenenza la macchina che ha subito l’intrusione. Questa tecnica, come già trattato, permette di salvaguardare da ulteriori attacchi altri sistemi vulnerabili. Ma, per le ragioni menzionate poco sopra, questa tecnica può venire in contrasto con le necessità dei denuncianti o con le Incident Response Policies dell’azienda attaccata. In questi casi i sistemi, oltre che rimanere accesi per salvaguardare le prove, devono anche rimanere connessi alla rete. Un’indagine svolta in queste particolari condizioni viene distinta con il nome Live System Analysis. Sebbene a prima vista possa sembrare concettualmente più complessa, un’indagine di questo tipo non presenta particolari differenze rispetto alle altre. In tali circostanze, però, oltre che di una grande dose di esperienza nel settore si ha bisogno di un buon piano operativo e di saper prestare molta attenzione ai particolari. Non bisogna dare per scontato tutto quello che può apparire ovvio. Eseguire un comando prima di essersi cautelati sulle possibili conseguenze potrebbe rivelarsi fatale in sede di giudizio o, addirittura, cancellare alcune prove prima che si venga a conoscenza della loro presenza. Prima di iniziare l’indagine bisogna quindi ricordarsi di non riavviare la macchina né di accedere ad essa dalla rete, ma solo da console. E’ importante inoltre registrare tutta la console session (con videocamera o con strumenti appositi messi a disposizione dai terminali) e prendere nota molto spesso dell’ora, ponendo attenzione alla differenza tra orario reale e orario della macchina e documentando eventuali differenze significative. Se il sistema compromesso è un router, bisogna inoltre documentarsi della caratteristiche architetturali e software di tale macchina (memoria Flash o RAM, Startup configuration o Running Configuration, presenza di tabelle dinamiche ecc.)

Pagina 99 di 334

Una volta prese queste precauzioni bisogna seguire attentamente una predeterminata scaletta che, come prima cosa, prevederà la registrazione delle volatile information, ovvero tutte quelle informazioni volatili (coincidenti con la memoria RAM) che in caso di spegnimento, accidentale o voluto, andrebbero perdute e sulle quali si andrà ad indagare ancora prima di tutte le informazioni persistenti (memorie di massa). Registrati questi dati, non eseguire mai comandi di configurazione. Tali programmi non fanno altro che alterare le condizioni della macchina al momento dell’intrusione e sono proprio i dati sui quali viene posta l’attenzione degli addetti all’indagine. Gli unici binari che possono essere eseguiti sono quelli distribuiti attraverso dei CD-ROM, per i quali si è quindi a conoscenza dell’effettiva autenticità. E’ possibile crearsi dei propri CD, riempiendoli di tutti quei software che, a propria discrezione, possono risultare utili durante un’indagine o per il ripristino di un sistema. Esistono anche molti progetti, tra i quali figura anche F.I.R.E. (http://fire.dmzs.com), prodotto dal quale è derivato anche il CD-ROM che accompagna questo documento, che hanno il particolare merito di essere bootable. Dopo aver effettuato tutte le acquisizioni e aver preso ogni precauzione possibile, l’uso di tali CD permette di poter riavviare la macchina in laboratorio, in totale sicurezza. Oltre a tools originali e precompilati, tali CD-ROM sono dotati di un sistema operativo sicuro e “pulito” avviabile direttamente da CD in fase di boot. Riavviare la macchina compromessa con questo metodo permette di operare in un ambiente protetto e di poter agire sulla macchina con i propri software di indagine preferiti senza alterare la macchina. Tali CD possono contenere, ad esempio, degli sniffer (tdump, Ethereal), antivirus, IDS (Snort), software per la ricerca di rootkits nel sistema (Chkrootkit), intere collezioni di software appositamente creati per effettuare indagini (TCT). Alcuni di questi strumenti, il loro uso, le particolarità o la loro configurazione, sono stati descritti in questo documento. La LSA è una delle forme più avanzate di indagine forense. Mentre la maggior parte delle indagini viene svolta offline, in modalità Post Mortem, la LSA è usata in modo meno frequente, particolarmente quando gli attacchi avvengono contro router. In ogni caso, qualsiasi scenario si debba affrontare, valgono alcune semplici regole che richiedono stretta collaborazione tra amministratori e investigatori: esse prevedono il raccoglimento di prove autentiche e immodificabili e, soprattutto, l’effettiva riproducibilità di qualsiasi azione prodotta.

Pagina 100 di 334

2.

Information gathering sui sistemi potenzialmente compromessi

2.1

Isolare i sistemi compromessi

Nel paragrafo “Verifica della disponibilità di media adeguati per i backup ed il ripristino dei sistemi” sono state descritte le problematiche relative ai backup e alla realizzazione delle immagini dei dischi dei sistemi compromessi, e nel paragrafo “Verifiche di configurazione e disponibilità sui sistemi di test e le reti” è stata descritta la configurazione HW/SW di una forensic workstation ideale. 2.1.1

Isolare i sistemi

2.1.1.1

Generalità

Il problema dell’isolamento del sistema compromesso comprende molteplici aspetti. Il primo risale ancora al momento nel quale ci si accorge che è stato perpetrato un attacco e lo staff operativo si domanda quale è l’operazione migliore da farsi. L’azione corrispondente dipende dall’analisi di alcuni fattori: il tipo di sistema, il tipo di macchina, l’importanza dei dati contenuti in essa, i collegamenti in rete, gli ultimi backup effettuati, le necessità di rispettare i livelli di servizio. Tutti questi elementi devono essere analizzati in un tempo molto breve al fine di decidere le azioni che dovranno portare ad effettuare l’analisi di forensics. Non in tutte le situazioni è possibile isolare immediatamente il sistema ed effettuare le azioni successive che fotograferanno il sistema compromesso senza che azioni esterne modifichino i contenuti delle aree di memoria volatile e persistente. In alcuni casi esigenze di servizio e policy aziendali impediscono di scollegare i sistemi dalla rete, oppure i data base in essi contenuti devono continuamente essere aggiornati: queste situazioni risultano essere particolarmente delicate e ogni azione asservita all’analisi di forensics deve essere accuratamente valutata e documentata. In condizioni ottimali, ovvero laddove non si presentino particolari problemi legati al mantenimento del servizio, l’isolamento del sistema comprende innanzitutto un isolamento fisico dell’area nella quale è contenuta la macchina nei confronti di persone estranee alle operazioni da effettuare, al fine di proteggere l’integrità della scena e i i magnetici. A nessuno, salvo il personale incaricato delle procedure di incident response, deve essere permesso di effettuare operazioni sulla macchina compromessa: il rischio è la perdita di preziose informazioni causate da comandi, anche banali e apparentemente inoffensivi, che possono modificare “la scena” all’interno delle memorie e dei log della macchina e la conseguente inammissibilità delle prove in ambito giudiziale. Una delle più difficili decisioni da prendere è quella riguardante lo spegnimento di un sistema in modo che l’integrità dei file non venga compromessa. Nella maggior parte dei casi il tipo di sistema operativo installato è il discriminante rispetto a come effettuare lo spegnimento del computer. Con alcuni di questi, il metodo preferibile è quello di schiacciare il pulsante di spegnimento; con altri sistemi questa brusca operazione potrebbe portare ad un crash dell’hard disk. Inoltre potenziali dati rilevanti ai fini delle indagini potrebbero risiedere, come già detto in precedenza, in aree di memoria che contengono slack file, erased file, Windows swap file , ecc., Pagina 101 di 334

che potrebbero essere facilmente sovrascritti da operazioni di booting o di shutdown di sistema operativo. Nella tabella seguente sono riportate, per i principali sistemi operativi compromessi, le operazioni da effettuare in fase di spegnimento:

Sistema MS DOS

UNIX/Linux

Mac

Windows 3.X/95/98/NT/2000/XP

Procedure di spegnimento •

Fotografare lo schermo e documentare i programmi che sono attivi

•

Staccare la spina dalla presa di corrente

•

Fotografare lo schermo e documentare i programmi che sono attivi

•

Cliccare con il pulsante destro del mouse sul menu

•

Dal menu, cliccare Console

•

Se il prompt non è sullo root, portarsi in tale stato digitando su –

•

Se la di root non è disponibile, staccare la spina dalla presa di corrente

•

Se la di root è disponibile, inserirla. Al segnale # digitare sync;sync;halt ed il sistema effettuerà lo shutdown

•

Staccare la spina dalla presa di corrente

•

Fotografare lo schermo e documentare i programmi che sono attivi

•

Cliccare Special

•

Cliccare Shutdown

•

Una finestra indicherà che è possibile spegnere il sistema

•

Staccare la spina dalla presa di corrente

•

Fotografare lo schermo e documentare i programmi che sono attivi

•

Staccare la spina dalla presa di corrente

Fonte: SANS INSTITUTE : www.sans.org/rr/incident/ircf.php

Pagina 102 di 334

Gli incaricati dell’incident response dovrebbero utilizzare questa tabella salvo nei casi in cui circostanze particolari non richiedano di staccare immediatamente il cavo della corrente dalla U (per esempio laddove ci sia il sospetto dell’esistenza di un programma di auto-distruzione oppure se è in fase di esecuzione la formattazione dei i di memoria); nel caso in cui il sistema sia già stato spento prima dell’intervento degli incaricati dell’incident response, non deve essere effettuato altro tentativo di riaccensione. 2.1.1.2

Precauzioni nello smontaggio del disco

Precedentemente si è già fatta menzione ad alcune caratteristiche e differenziazioni relative ai backup dei sistemi compromessi. Qui di seguito sono forniti alcuni elementi che possono aiutare nel processo di effettuazione di immagine o backup di dischi compromessi: •

•

•

• • •

• • • 2.1.2

Rimuovere l’hard disk interno dalla macchina sospetta ed etichettarla con le seguenti informazioni: o Che disco è stato rimosso (C, D, ecc.) o Che tipo di disco (IDE, SCSI) o Capacità del disco, con una nota circa cilindri, testine e settori Effettuare una fotografia (possibilmente digitale) dei momenti salienti dello smontaggio e dell’etichettatura ricordandosi, una volta effettuate le foto di creare un hash dell’immagine fotografica Imballare accuratamente il disco per il trasporto al luogo dove effettuare le operazioni di backup e analisi, avendo cura di scaricare preventivamente a terra eventuali cariche elettrostatiche accumulate nel disco Verificare che i i da usare per i backup e le immagini siano liberi da virus e siano stati oggetto di operazioni di wiping Assicurarsi che i tool ed i programmi per effettuare l’indagine di forensics montati sulla workstation di test abbiano regolare licenza d’uso Montare ciascun disco su una Forensic Workstation negli slot disponibili. Effettuare i backup (per esempio immagine del disco) o Effettuare almeno quattro copie del disco o Mettere il disco originale ed una copia di backup insieme alle prove o Restituire una copia del backup al proprietario del sistema compromesso o Usare le altre due copie per le analisi di investigazione Sigillare i dischi originali con la copia di backup in appositi contenitori e registrarli nella documentazione Effettuare il restore di uno dei tape di backup su un disco di identica capacità (drive identico, se possibile) Analizzare i dati (in un ambiente controllato) sui dischi sui quali si è effettuato il restore.

Forensics e Linux Le operazioni e le linee guida descritte si concretizzano con diversi strumenti e modalità in funzione dei sistemi operativi, degli strumenti di backup e immagine, degli strumenti di analisi.

Pagina 103 di 334

Qui di seguito viene descritta una procedura di forensics ipotizzando il caso in cui il sistema operativo utilizzato sulla Forensic Workstation sia Linux e che gli strumenti utilizzati per effettuare l’immagine del disco e la relativa analisi siano i comandi e gli strumenti nativi di Linux stesso. Linux è fornito con numerose utilità che creano l’immagine e un analisi base di dischi e drive sospetti in maniera relativamente facile. Questi tool comprendono: •

dd o – comando usato per copiare da un file di input o device ad un file di output o device; crea una bitstream image,

•

cfdisk e fdisk – usato per determinare la struttura del disco,

•

grep – ricerca file (o file multipli),

•

chmod – modifica i permessi di default di un file; usato per inibire i permessi di scrittura su un file immagine,

•

The loop device – permette di effettuare il mount di un’immagine senza doverla riscrivere su un disco,

•

md5sum – crea e salva un hash MD5 di un file o di una lista di file,

•

file – legge le informazioni di testata del file per accertarne il tipo, il nome e l’estensione,

•

xxd – comando di linea per visualizzare il file in formato esadecimale,

•

ghex e khexedit – editor esadecimali Gnome e KDE (per interfacce X Window); entrambi hanno possibilità di ricerca e selezione di byte.

Di seguito sono illustrati una serie di i per effettuare un’analisi utilizzando i tool di Linux. Tutti i comandi possono essere maggiormente approfonditi utilizzando l’output del ”man command”. Per semplicità gli esempi saranno basati sull’utilizzo di un floppy disk creato da una macchina DOS. 2.1.2.1

Organizzazione dell’analisi

L’esempio illustrato può essere esteso ad altri casi più complessi con un supplemento di documentazione. L’output dei vari comandi e le dimensioni delle ricerche sono limitate allo scopo di questo esempio e dalla capacità del floppy disk; quando viene effettuata l’analisi su i di grandi dimensioni, è necessario organizzare l’analisi in modo maggiormente strutturato. Un modo per organizzare i dati potrebbe essere quello di creare una directory sotto la home directory per le “prove” e delle sotto directoy per i singoli casi. mkdir ~/evidence Indirizzando tutti gli output delle analisi in questa directory verranno tenuti tutti i file di output separati da qualsiasi altro e mantenuta l’organizzazione dei casi. Per gli scopi del presente esempio, si ipotizza di essersi loggati come “root”: infatti molti dei comandi qui utilizzati richiedono le abilitazioni di root; in questo modo i file creati e le immagini potranno essere trovate sotto /root/evidence/. Un o supplementare che potrebbe essere fatto è quello di creare uno speciale mountpoint per tutti i dischi da analizzare. Questa è un’altra modalità per separare i sistemi di utilizzo comune Pagina 104 di 334

con quelli di elaborazione delle prove. Si può osservare che poiché l’hardware e il file system di root saranno direttamente accessibili, si avrà la su alla root per eseguire i successivi step di questa analisi. mkdir/mnt/analysis

2.1.2.2

Determinazione della struttura del disco

Sono disponibili due tool per determinare la struttura di un disco collegato al sistema. Per il primo, fdisk, ne discutiamo utilizzando l’opzione –l per avere un numero maggiore di informazioni. Sostituendo la “x” con la lettera corrispondente al drive oggetto dell’analisi, riportiamo il seguente comando ed il conseguente risultato: fdisk –l /dev/hdx Disk /dev/hda: 255 heads, 63 sectors, 1582 cylinders Units = cylinders of 16065 * 512 bytes Device Boot Start End Blocks /dev/hda1 1 255 2048256 /dev/hda2 * 256 638 3076447+ /dev/hda3 639 649 88357+ /dev/hda4 650 1582 7494322+ /dev/hda5 650 1453 6458098+ /dev/hda6 1454 1582 1036161

Id b 83 82 f b b

System Win95 FAT32 Linux Linux swap Win95 Ext'd (LBA) Win95 FAT32 Win95 FAT

Possiamo ridirigere l’output di questo comando in un file per un utilizzo successivo mediante il seguente comando fdisk –l /dev/hdx > fdisk.disk1 Si può osservare che il nome del file di output (fdisk.disk1) è completamente arbitrario e non ci sono regole per quanto riguarda l’estensione; si consiglia però di adottare una convenzione e di documentarla. Si può notare anche che, poiché non si è definito un percorso esplicito per il nome del file, fdisk.disk1 sarà creato nella directory corrente (per esempio, /root/evidence). Il secondo tool che si considera può definirsi come un tool grafico e si chiama cfdisk. Questo tool svolge le stesse funzioni di fdisk, ma è più friendly avendo delle funzionalità di navigazione attraverso menu, permettendo inoltre modifiche al partizionamento: cfdisk/dev/hdx È opportuno ricordare che benché cfdisk sia più facile nell’utilizzo, il suo output non è di tipo formattato per essere rediretto in un file di testo.

2.1.2.3

Preparazione di un disco per l’immagine

Una pratica comune dell’analisi dei dischi in forensics è quella di “pulire” (wipe) un disco prima di effettuare il restore dell’immagine per l’analisi di forensics; questo assicura che qualsiasi dato trovato sul disco su cui si è effettuato il restore proviene dall’immagine e non da residui di dati Pagina 105 di 334

precedenti. Per creare questo effetto, mediante un comando è possibile scrivere tanto “zeri” da riempire l’intero disco di destinazione: dd if=dev/zero of=/dev/hdx bs=4096 Il comando inizia il suo effetto all’inizio del drive e scrive tanti “zero” in ogni settore in tagli da 4096 byte; se vengono specificate dimensioni del blocco più grandi , il processo di scrittura può essere più veloce. Parametri per drive specifici possono essere settati usando il comando hdparm, per le cui specifiche è consigliabile consultare il manuale. Un’altra funzione che può essere utile è quella che dà la possibilità di suddividere le immagini in frazioni di esse, meglio gestibili sia dal punto di vista dell’archiviazione o per essere utilizzate da altri programmi; ad esempio si potrebbe avere un’immagine di 10GB che si vorrebbe suddividere in parti di 640 MB l’una per poterle scrivere su un CD-R: a questo scopo si usa il comando split. Esso lavora normalmente su linee di input (per esempio file di testo), ma se si utilizza l’opzione – b viene forzato il trattamento di file binari e le linee di input vengono ignorate. È possibile specificare la dimensione dei file che si vogliono compreso il prefisso che si preferisce per i file di output; il comando si presenta così: split –b XXm <prefix of output files> dove XX è la dimensione dei file risultanti. Per esempio se si hanno 6GB di immagine chiamata image.disk1.dd, è possibile effettuare lo split in file da 2GB usando il seguente comando split –b 2000m image.disk1.dd image.split. Il risultato sarà di tre file di 2GB, ciascuno chiamato con il prefisso “image.split” seguito dai suffissi “aa”, “ab”, “ac”, e così via: image.split.aa image.split.ab image.split.ac Il processo può essere eseguito al contrario nel caso in cui si voglia riassemblare l’immagine dalle singole parti (per esempio dai singoli CD-R); per fare questo si utilizza il comando cat ridirigendo l’output su un nuovo file; si ricorda che cat semplicemente dirige i file specificati sullo standard output: cat image.split.aa image.split.ab image.split.ac > image.new oppure cat image.split.a* > image.new L’hash MD5 di image.new coinciderà con quello di image.disk1.dd iniziale.

2.1.2.4

Creazione dell’immagine di un disco compromesso

Il comando di un backup standard di un disco sospetto è il seguente: dd if=/dev/fd0 of=image.disk1 bs=512 Questo comando interpreta il floppy disk (/dev/fd0) come file di input (if) e scrive un file di output chiamato image.disk1 nella directory corrente. L’opzione bs specifica il blocksize; questa Pagina 106 di 334

opzione non è generalmente necessaria per la maggior parte dei i (hard drive, ecc.) perché in questi casi il blocksize è gestito direttamente dal kernel di Linux. Un’azione da intraprendere è quella di modificare i permessi di accesso all’immagine da readwrite a read-only: chmod 444 image.disk1 L’opzione 444 dà all’utente l’accesso read-only. Ora che è stato creato il file immagine, è possibile effettuare il restore su un altro disco per l’analisi e la visualizzazione dei dati. Per questo scopo si deve inserire un floppy disk (su cui si è effettuata l’operazione di wipe) e digitare il comando : dd if=image.disk1 of=/dev/fd0 bs=512 È lo stesso comando dd eseguito prima, solo che ha i parametri al contrario: in questo caso si sta prendendo l’immagine e la si sta scrivendo su un altro disco che può essere utilizzato come un backup o come copia di lavoro per l’analisi.

2.1.2.5

Mount di un’immagine dopo il restore

Nell’effettuare il mount del disco per visualizzarne i contenuti, è necessario ricordare, come evidenziato dall’output del precedente comando fdisk, che è un disco DOS formattato da una macchina Win 95: mount –t vfat –o ro,noexec /dev/fd0 /mnt/analysis Con questo comando verrà effettuato il mount del disco su /mnt/analysis. L’opzione “-o ro,noexec” specifica che deve mantenere la caratteristica di read-only e che non devono essere eseguiti programmi binari, al fine di una maggior protezione dei contenuti del disco. Ora con il comando cd su /mnt/analysis è possibile visualizzare il contenuto.

2.1.2.6

Mount di un’immagine utilizzando il loopback device

Un’altra possibilità per visualizzare il contenuto dell’immagine senza utilizzare un altro disco è quella di effettuare il mount usando l’interfaccia loop. Il driver del loop device deve prima essere installato inserendolo nel kernel di Linux. I vari moduli disponibili su Linux sono localizzati in /lib/modules/$KERNEL-VERSION/; sono file oggetto che contengono il codice dei driver richiesti per il device od opzione richiesti (il o al filesystem in Linux è spesso caricato come modulo). Si osserva che la versione corrente del kernel può essere trovata usando il comando uname –r.

2.1.2.7

Utilizzo dei moduli

I moduli sono installati e rimossi dal sistema “al volo” usando i seguenti comandi (come root): insmod

- per inserire il modulo

rmmod

- per rimuovere il modulo Pagina 107 di 334

lsmode

- per fornire la lista dei moduli installati

Il modulo loop (loop.o) viene installato con: insmod /lib/modules/2.2.12-20/kernel/drivers/block/loop.o inserire la versione del kernel

Il comando per verificare che il modulo sia stato correttamente caricato è: lsmod e il suo output dovrebbe essere: Module Loop

Size Used by 7744 0 (unused)

Si noterà che l’output conterrà anche altri driver caricati come moduli dal sistema. Sui sistemi Linux recenti ci sono kernel daemon automatici che gestiscono il caricamento e lo scaricamento dei moduli non appena viene rilevata la richiesta di un modulo che non è installato. Quindi, per il loopback device si à lo stesso comando di mount e le stesse opzioni includendo l’opzione “loop” per indicare che si vuole utilizzare il loop device per effettuare il mount dell’immagine: mount –t vfat –o ro,noexec,loop image.disk1 /mnt/analysis Ora è possibile visualizzare l’immagine come se fosse montato effettivamente il disco.

2.1.2.8

File Hash

Un o importante in qualsiasi analisi è quello di verificare l’integrità dei dati prima e dopo aver completato l’analisi stessa. È possibile utilizzare un hash (CRC, MD5 o SHA) di ciascun file in differenti modi. In questo caso utilizzeremo MD5; MD5 è un generatore di firma che fornisce un “fingerprint” di 128 bit di un file o disco. Non è computazionalmente possibile per qualcuno ricreare un file basato su un hash MD5: questo significa che la coincidenza di due firme MD5 ha come conseguenza due file identici. È possibile effettuare l’hash di un disco cambiando la directory della prova (nell’esempio /root/evidence) ed eseguendo il comando : md5sum /dev/fd0 > MD5.disk1 L’utilizzare un altro percorso permette di salvare la firma in un file distinto e di poterla utilizzare per le verifiche in un secondo momento. Inoltre è possibile utilizzare un hash per ciascun file sul disco utilizzando il comando find e un opzione che permette di eseguire un comando su ciascun file trovato. È possibile utilizzare una lista di hash MD5 per ciascun file sul disco (una volta che sia stato effettuato il mount modificando la directory in /mnt/analysis): cd/mnt/analysis e facendo seguire il comando : find . -type f –exec md5sum {} \; > /root/evidence/MD5.filelist

Pagina 108 di 334

Questo comando, in pratica, dice di “cercare, partendo dalla directory attuale qualsiasi file regolare e di eseguire il comando md5sum su tutti i file trovati ({}). Ridirigere poi l’output su MD5.filelist nella directory /root/evidence (dove sono stati posti i file delle prove)”. È anche possibile usare Linux per effettuare altri tipi di verifiche; per esempio, per stabilire che nulla è stato modificato sul floppy originale, è possibile utilizzare l’opzione –c con md5sum. Se il disco non è stato modificato, il comando ritornerà un “ok”.

2.1.2.9

L’analisi

È possibile ora visualizzare il contenuto del disco di cui si è fatto il restore o dell’immagine della quale si è effettuato il mount. Se si sta lavorando su un sistema X window allora è possibile utilizzare il browser preferito per effettuare le ricerche sul disco. In molti casi i comandi di linea sono molto più utili e potenti al fine della gestione dell’analisi e per questo motivo verranno utilizzati per questo esempio. Per assunto i comandi hanno come mount point /mnt/analysis. Per stampare a video la lista di tutti i file nascosti nella cartella corrente più le cartelle speciali “.” e “..”, si può usare il comando : ls -la | grep “^. ” ls –la mi stampa il contenuto della cartella, grep “^.” mi legge l’output di ls e tiene solo le linee che cominciano con il carattere “.”.

2.1.2.10

Effettuare la lista dei file

Tra le varie possibilità di gestire le liste di file, si propone il comando per cercare i file e ridirigere l’output su un altro file lista: find . -type f –print > /root/evidence/filelist.list Usando successivamente il comando grep –i jpg filelist.list si sarà in grado di selezionare i file con estensione jpg dall’output precedentemente ricavato.

2.1.2.11

Fare la lista dei file per tipo

Cosa fare se si sta cercando file JPEG ma il nome del file è stato modificato oppure l’estensione è errata? È possibile anche eseguire il comando file su ciascun file e verificarne il contenuto: file filename Se il numero di file da verificare è elevato, è possibile utilizzare il comando file su tutti i file di un disco; inoltre, ricordando l’utilizzo fatto del comando find con l’opzione –exec, possiamo utilizzarlo anche nel caso testé presentato: find . -type f –exec file {} \; > /root/evidence/filetype.list Pagina 109 di 334

si può visualizzare la lista con il comando more e se si sta guardando un’immagine in particolare si può allora utilizzare il grep in questo modo: cat /root/evidence/filetype.list | grep image Questo dovrebbe suddividere il contenuto del nostro filetype.list utilizzando cat e producendo l’output attraverso grep.

2.1.2.12

Visualizzare i file

Per i file testo e i file dati si dovrebbe usare cat, more o less per visualizzarne i contenuti: cat filename more filename less filename Il modo verosimilmente migliore per visualizzare i file, comunque, dovrebbe essere mediante l’utilizzo del comando strings, che può essere usato per analizzare la regolarità del testo per qualsiasi file (Excel, ecc.), ed anche per i file binari potrebbe essere interessante scoprire stringhe di testo nascoste. Per trasmettere l’output si potrebbe usare l’opzione less: string filename | less Una volta che è terminata l’esplorazione, è necessario effettuare il demount del disco (o dell’immagine), assicurandosi di essere posizionati nel corretto punto dell’albero: umount /mnt/analysis

2.1.2.13

Ricerca di spazio non allocato e slack space

Il disco restorato (o il loop mounted image) permette il controllo di tutti i file e di tutte le directory. Ma cosa è possibile verificare circa lo spazio non allocato e lo slack space? L’immagine creata, essendo una copia bit a bit, include anche queste aree di disco. Si ipotizzi una situazione in cui una lettera, nella quale si minaccia l’invio di un potente virus nella rete aziendale, è stata ricevuta dalla Direzione e che a seguito di questo fatto è stato sequestrato un floppy disk ad un impiegato dell’azienda sul quale sono ricaduti i sospetti di questa azione. L’analisi si incentra sulla ricerca del testo della lettera in un file cancellato nello spazio non allocato del disco. Una volta effettuate le operazioni propedeutiche già descritte in precedenza (immagine, mount, ecc.) per prima cosa, dalla Forensic Workstation, è necessario posizionarsi sulla directory di lavoro: cd /root/evidence Ora si potrà usare il comando grep per cercare l’immagine di qualsiasi elemento di un’espressione o di modello. Si anno anche alcune opzioni per rendere l’output di grep più fruibile: grep –options <pattern> <search_range> Pagina 110 di 334

Il primo o sarà quello di creare una lista di chiavi di ricerca; si può aprire un editor di testi e costruire questa lista di termini che si vogliono ricercare, per esempio “riscatto”, “€50.000” e “scatenato un virus”, parole che sono contenute nella lettera minatoria. Dopo aver completato la lista è opportuno salvarla in /root/evidence/searchlist.txt, assicurandosi che ciascun termine da ricercare sia su una riga diversa e che non ci siano righe vuote in qualsiasi punto della lista: riscatto €50.000 scatenato un virus Ora è possibile avviare la ricerca con : grep –aibf searchlist.txt image.disk1 > hits.txt Osservando la sintassi del comando precedente possiamo notare che viene chiesto di usare la lista searchlist.txt (opzione –f listfile) come chiave di ricerca in image.disk1, ridirigendo l’output della ricerca stessa in hits.txt al fine di poterlo analizzare in un secondo tempo. L’opzione –a dice a grep di scrivere tutta la riga in cui si è trovata la parola ricercata e non il nome del file da cui provengono, l’opzione –i dice a grep di ignorare il maiuscolo e il minuscolo e l’opzione –b dice a grep di fornire l’offset del byte di ciascuna parola trovata in modo che si possa trovare la posizione in esadecimale con il comando xxd o con un qualsiasi editor esadecimale grafico, come GHex. Il contenuto del file hits.txt può essere visualizzato ed esplorato con i comandi less e more oppure con qualsiasi analizzatore di testo. Pur essendo il comando string ancora il più efficace, in questo caso più semplicemente si à cat per analizzare l’intero contenuto del file sullo standard output: cat hits.txt 75441: verrà richiesto un riscatto in base (…) 75500: ne ho avuto abbastanza della vostra pirateria aziendale e non aspetterò oltre (…) 75767: Non tentate di fare qualcosa e non avvisate la polizia: se lo farete, verrà scatenato un virus che bloccherà la rete e distruggerà le informazioni della clientela (…) Per visualizzare il dato trovato si può quindi utilizzare il seguente comando : xxd –s offset image.disk1 | less

2.1.2.14

Gestire dischi di grandi dimensioni

L’esempio presentato utilizzava un file system su un floppy disk; ma cosa succede quando si ha a che fare con un grosso hard disk? Quando si crea l’immagine dell’hard disk con il comando dd ci sono vari elementi da considerare, come il boot sector, la partition table e le varie partizioni (se definite). Quando si prova ad effettuare il mount di una grossa immagine con il loop device, si verifica l’impossibilità di trovare il file system sul disco perché non sa come riconoscere la partition table. Per superare questo ostacolo (benché non sia comunque efficiente per dischi di grandi dimensioni) si dovrebbero creare immagini separate per ciascuna partizione di disco che si vuole

Pagina 111 di 334

analizzare; ipotizzando che il disco sospetto sia collegato come master device sul canale IDE secondario, si può operare nel seguente modo: dd if=/dev/hdc of=image.disk bs=4096

(disco intero)

dd if=/dev/hdc1 of=image.part1 bs=4096 (prima partizione) Il primo comando fornisce un’immagine dell’intero disco per esigenze di backup, incluso il boot sector e la partition table; il secondo comando fornisce l’immagine della partizione. L’immagine risultante del secondo comando può essere usata per effettuare il mount tramite il loop device. Si osservi che, benché entrambi i dischi contengano lo stesso file system, l’hash MD5 non coincide. Il metodo più efficiente per gestire dischi di grandi dimensioni (effettuando il mount con il loop device) è di effettuare il comando di mount con l’indicazione di saltare i primi 63 settori dell’immagine: questi settori sono utilizzati per contenere informazioni (come il MBR) che non fanno parte di una normale partizione di dati. Ogni settore è 512 byte e quelli considerati sono 63 settori; questo dato ci fornisce un offset di 32.256 byte dall’inizio della nostra immagine alla prima partizione di cui vogliamo effettuare il mount. Otteniamo quanto detto con il comando : mount –t vfat –o ro,noexec,loop,offset=32256 image.disk/mnt/analysis Il risultato è quello di saltare i primi 63 settori dell’immagine e andare direttamente al boot sector della prima partizione, permettendo al comando di mount di lavorare correttamente. Ora che sono state accennate le tecniche per creare immagini di dischi di grandi dimensioni, ci si può domandare che cosa può succedere se si verifica un errore. Si supponga che si stia creando l’immagine di un disco con dd e il comando si interrompa a metà del processo con un errore di lettura; è possibile “istruire” dd a tentare di leggere gli errori incontrati usando l’opzione conv=noerror. In parole semplici è come dire a dd di ignorare gli errori incontrati durante il processo e di leggerli a posteriori; quando si specifica noerror può essere indicato di includere con esso l’opzione sync. Questo garantirà un miglior coerenza e sincronizzazione dell’output con il disco originale e il comando apparirà in questo modo: dd if=/dev/hdx of=image.disk1 conv=noerror,sync In aggiunta alla struttura delle immagini ed alle questioni delle loro dimensioni, è necessario anche fare i conti con l’utilizzo di memoria dei nostri tool; si potrebbe verificare che grep, quando usato come nell’esempio del floppy disk, potrebbe lavorare non come ci si aspetti, con immagini di dimensioni eccessive. Potrebbe risultare un errore come questo: grep: memory exhausted La causa più comune di questo è che grep non effettua la ricerca linea per linea. Quando si scandisce una grossa immagine di disco ci si potrebbe trovare con un enorme numero di bit da leggere prima che grep acceda al newline character; che cosa quindi può succedere quando grep deve leggere 200MB di dati prima della nuova operazione? Non può fare altro che esaurire le risorse. Cosa può succedere se viene forzata la newline? Nell’esempio sopra riportato si sta usando grep per un testo e non è di interesse tutto ciò che non rientra in questa categoria, quindi se si potesse prendere l’input di grep e trasformare i caratteri non-testo in newline, grep non avrebbe problemi. Si noti che modificando l’input a grep non viene modificata l’immagine. Pagina 112 di 334

Per prendere il controllo del flusso in input a grep dal disco immagine e effettuare le modifiche a newline è possibile utilizzare il comando translate: tr ‘[:cntrl:]’ ‘\n’ hits.txt che significa:”traduci tutti i caratteri contenuti nel set di caratteri di controllo ([:cntrl:]) in newlines (\n), manda l’input a tr da image.disk1 e trasmetti l’output a grep, mandando il risultato a hits.txt”. Questo effettivamente modifica il flusso in input a grep.

Pagina 113 di 334

2.2

Correlation: cercare segnali di intrusione su altri sistemi

Prepararsi a gestire l’intrusione osservando il comportamento dei sistemi e delle reti tramite attività di monitoraggio, d’ispezione e di auditing. Queste procedure di preparazione consistono nella raccolta di una vasta collezione di dati essenziali per rilevare comportamenti sospetti ed inaspettati. Le informazioni da raccogliere riguardano performance di sistema e di rete, processi, applicazioni, traffico di rete, attività utente, file e directory. Nel caso siano rilevati un attacco o un’intrusione, occorre sempre controllare tutti quei sistemi “simili” al sistema violato, poiché gli intrusi creano regolarmente più punti d’accesso alla rete nella quale hanno conquistato l’accesso iniziale. Partire pertanto dal target dell’attacco e iniziare la fase di ‘backtracing’ per individuare eventuali tracce sulla rete identificando le cosiddette ‘teste di ponte’ (stepping stones) utilizzate dall’attacker. Controllare, sui sistemi simili a quelli già attaccati, i vari file di log, header e email, con particolare attenzione al problema dello spoofing. In questa fase di ricostruzione delle relazioni tra i vari sistemi coinvolti è quindi molto importante la collaborazione tra i vari amministratori e ISP. Infatti altre organizzazioni possono notificare di aver trovato delle prove che i nostri sistemi sono stati attaccati dai loro sistemi, o viceversa. Il concetto di similitudine tra sistemi può avere significati diversi: 2.2.1

Sistemi che appartengono allo stesso range di indirizzi IP Elevata probabilità di trovare tracce di intrusione su tali sistemi poiché gli intrusi, tramite tool chiamati ‘network scanner’, compiono scansioni ad ampio spettro su grandi classi di indirizzi IP. Infatti gli attacker possono acquisire informazioni sulle classi di indirizzi assegnati tramite servizi pubblici whois disponibili in rete, quali ARIN Web Search (www.arin.net) o RIPE Web Search (www.ripe.net), e compiere così un attacco ai sistemi di una determinata organizzazione.

2.2.2

Sistemi che si trovano nello stesso segmento di rete L’attacco ad un router compromette tali sistemi. Infatti nel caso di “router hacking” è possibile disabilitare router e network, compromettere altri router, byare firewall o IDS.

2.2.3

Sistemi che sono nello stesso dominio “trusted” Spesso i computer sulle reti hanno relazioni di fiducia con altri: prima di eseguire dei comandi, un computer controlla un insieme di file (trust list) nei quali sono specificate quali altre macchine in rete hanno il permesso di eseguire quei comandi. Pertanto se un attacker riesce a “forzare” la sua identità e far credere di utilizzare un “trusted” computer, può guadagnare l'accesso autorizzato ad altre macchine. In caso di attacco quindi controllare tutti quei sistemi presenti nella trust list del sistema attaccato. Pagina 114 di 334

2.2.4

Sistemi che hanno almeno un servizio di rete in comune Il portscanning permette all’intruso di controllare tutte le 65.535 porte di ciascun IP, distinte tra T e UDP, alla ricerca di potenziali vulnerabilità e back-door da sfruttare. Le vulnerabilità note sono in numero enorme e relative sia a servizi di rete tradizionali che ad applicazioni specifiche. Le vulnerabilità dei cosiddetti servizi ‘well-known’ sono quelle maggiormente ricercate: -

vulnerabilità di mail server (SMTP)

-

vulnerabilità di DNS server

-

vulnerabilità di FTP server

-

vulnerabilità di web server (http)

Controllare quindi tutti quei sistemi che utilizzano lo stesso tipo di servizio, soggetto alla determinata vulnerabilità individuata e sfruttata dall’attacker.

2.2.5

Sistemi che hanno lo stesso sistema operativo Ricercare tracce di intrusione su tali sistemi in quanto targets dell’attacker tramite OS Fingerprinting. Attraverso tool come nmap, che utilizzano sequenze di pacchetti anomali non rispondenti alle specifiche del T, si creano reazioni dipendenti dalle singole implementazioni dello stack T. In questo modo si riesce a predire con ottima approssimazione il sistema operativo e acquisire molte altre informazioni propedeutiche all’attacco.

2.2.6 Sistemi che condividono file e informazioni Condivisione di file e informazioni via NetBios (Windows), NFS (UNIX/Linux), AppleShare (Apple): tali condivisioni di file e directory nel caso di una cattiva configurazione possono permettere il controllo remoto del computer. In caso di intrusione controllare tutti quei sistemi che condividono il proprio file system con sistemi compromessi o usano spazio del file system di sistemi compromessi.

Pagina 115 di 334

2.3

Log analysis sull’output dei firewall, router e network monitor

2.3.1

Introduzione Gli attacchi informatici lasciano spesso tracce che possono condurre all’individuazione dei sistemi usati per l’intrusione; queste tracce includono: •

log file e audit file;

•

file utilizzati e lasciati dall’intruso;

•

informazioni relative ai server e ai servizi utilizzati dall’intruso per muoversi attraverso la rete.

In particolare, per identificare le azioni dell’intruso, è possibile: •

analizzare i file di log;

•

utilizzare tool di analisi;

•

comparare i checksum di file conosciuti e fidati con quelli di macchine compromesse.

Avere un sistema di crittografia fidato per la creazione di checksum utili alla comparazione di file è particolarmente importante per scoprire se l’intruso ha apportato modifiche al kernel del sistema operativo. Queste tracce possono essere utilizzate per la ricerca di ulteriori eventi o connessioni sospette con altri sistemi; in questo modo è infatti possibile identificare i sistemi ove l’intruso abbia conquistato l’accesso. I log di firewall, network monitor e router spesso restano inalterati e contengono informazioni importanti anche dopo che un intruso ha ottenuto l’accesso locale (acquisendo i privilegi di amministratore e cancellando i log del sistema per nascondere le informazioni circa il metodo di attacco, l’intrusione stessa e i metodi utilizzati per l’accesso). Questi programmi e periferiche, se opportunamente configurati, registrano le connessioni e il traffico di messaggi generato da un intruso. I log da essi prodotti possono rivelare l’attività dell’intruso. Per esempio, i log dei firewall possono essere configurati per memorizzare informazioni circa il mittente di ogni messaggio, la destinazione e le caratteristiche della connessione, così come la quantità di dati trasmessa. 2.3.2 Timestamping Utilizzando le informazioni a disposizione (data, ora e sistemi attaccati) possono essere rintracciati record nei file di log che rivelano informazioni più dettagliate circa un’intrusione. È importante cercare le relazioni, incluse le connessioni dalla stessa sorgente o verso la stessa destinazione. La costruzione dell’immagine completa può essere complessa. I formati dei log di sistemi differenti non sono compatibili e attualmente non esistono tool che sincronizzano cronologicamente i log prodotti da sistemi differenti. Tuttavia esistono tool di monitoraggio che collezionano informazioni da più sistemi e li rapportano fra di loro. In aggiunta, il fuso orario Pagina 116 di 334

locale e quello utilizzato dal sistema possono differire: protocolli come NTP (Network Time Protocol) possono essere usati per sincronizzare sistemi diversi. Nel caso in cui si scopra che l’intruso ha apportato modifiche alla data è molto importante che l’orologio di sistema non venga alterato o resettato, poiché così facendo si renderebbe l’esame dei file e dei processi di sistema molto più complesso. Si dovrebbero inoltre includere nel report note aggiuntive circa ogni alterazione scoperta, includendo la differenza di ora e la timezone utilizzata. In molti sistemi di log la data è un elemento fondamentale; nella forensics non è importante l’esattezza della data quanto la sincronia della stessa in tutti i file, poiché questa è più difficile da alterare e permette all’analista di ricostruire l’ordine temporale dei fatti. 2.3.3

Event collection Uno dei principali obiettivi dell’auditing è quello di identificare le azioni compiute dall’attaccante nella rete. In particolare analizzeremo: •

modifiche apportate ai software di sistema e ai file di configurazione;

•

modifiche ai dati;

•

tool e dati lasciati dall’intruder nel sistema;

•

analisi dei log file;

•

ricerca della presenza di un network sniffer;

•

ricerca di altri sistemi compromessi all’interno della rete;

•

ricerca di sistemi implicati o compromessi in siti remoti.

Se il programma per la generazione di log colleziona le informazioni in un database, è più facile relazionare le informazioni provenienti da più log. Le operazioni sono inoltre facilitate se la data e l’ora sono sincronizzate tra i vari sistemi. Esistono diverse tipologie di tool e utility che possono essere utilizzate per collezionare i una locazione centralizzata: •

Scripting Possono essere creati script per collezionare log da computer remoti e memorizzarli in una locazione centralizzata. Utilizzando gli script è possibile scegliere quando attivarli utilizzando uno scheduler e quali azioni intraprendere una volta che il log è stato copiato con successo nella locazione centrale.

•

Third-party solutions Sono disponibili molti prodotti di questo tipo che offrono utilità di collezione e analisi centralizzata dei log. Nella scelta del tool è importante valutare la presenza di alcune funzionalità: o di tutti i log di Windows 2000, in particolare di quelli di DNS Server, Directory Service, FRS, applicazioni, sicurezza e sistema. Utilizzo di un database di backend: il tool dovrebbe permettere la memorizzazione dei una struttura che permetta l’ispezione dei log precedenti per l’analisi di trend e la correlazione di eventi tra più server.

Pagina 117 di 334

Funzioni di ricerca e presentazione: il tool dovrebbe permettere la ricerca di eventi specifici basati su precisi criteri. I risultati dovrebbero essere presentati attraverso un documento facilmente leggibile. •

Active detections methods Consiste nell’analizzare il traffico di rete entrante a livello applicativo alla ricerca di payload sospetti o metodi di attacco conosciuti. Se viene ricevuto un pacchetto sospetto, il sistema di monitoraggio generalmente scarta il pacchetto e inserisce una entry nel file di log. Nel caso in cui l’attacco sia molto grave, alcuni sistemi possono anche mandare un messaggio all’amministratore.

2.3.4

Modifiche apportate ai software di sistema e ai file di configurazione Verificare tutti i file binari e di configurazione. Si tenga presente che ogni tool utilizzato sul sistema compromesso per verificare l’integrità di codesti file potrebbe essere stato modificato esso stesso. Si ricordi anche che lo stesso kernel potrebbe essere stato alterato. A causa di ciò, è consigliabile fare il boot da un kernel sicuro e ottenere una copia pulita di tutti i tool che dovranno essere utilizzati nell’analisi dell’intrusione. Ad esempio, sui sistemi Unix è possibile creare un disco di boot e renderlo protetto da scrittura al fine di ottenere un kernel sicuro. Durante l’ispezione dei file di configurazione sui sistemi Unix è consigliabile: •

controllare il file /etc/wd;

•

controllare il file /etc/inetd.conf;

•

se gli “r-command s” (r, rsh, rexec) sono permessi, assicurarsi che questi non siano consentiti nei file /etc/hosts.equiv e in tutti gli .rhosts;

•

controllare i nuovi file SUID e SGID. Il comando per stampare tutti questi file all’interno del filesystem è #find /\( -perm -004000 –o –perm -002000 \) -type f –print

Durante l’ispezione dei file di configurazione sui sistemi NT è consigliabile:

2.3.5

•

controllare la presenza di utenti o gruppi atipici;

•

controllare i cambiamenti del registro che carica i programmi o i servizi all’avvio;

•

controllare le condivisioni non autorizzate e nascoste con il comando net share oppure col Server Manager Tool;

•

controllare i processi che non vengono identificati utilizzando il tool Pulist.exe dall’NT Resource Kit o dall’NT Task Manager.

Modifiche ai dati I dati sui sistemi compromessi sono spesso modificati dagli intrusi. Si consiglia di verificare l’integrità di: •

pagine web; Pagina 118 di 334

2.3.6

•

archivi FTP;

•

file nelle home directory degli utenti;

•

ogni altro file di dati nel sistema.

Tool e dati lasciati dall’intruder nel sistema Gli intrusi generalmente installano dei tool customizzati per continuare a monitorare il sistema o per garantirsi accessi successivi. Le principali categorie di tool sono:

2.3.7

•

Network sniffer;

•

Trojan horse;

•

backdoor;

•

vulnerability exploit;

•

altri (Denial-Of-Service, utilizzo delle risorse computazionali);

•

sistemi di comunicazione con altri sistemi compromessi.

Analisi dei log file L’analisi dei file di log può essere d’aiuto per avere un’idea più chiara di come la macchina è stata compromessa, di ciò che è successo durante l’attacco e di quali host remoti hanno partecipato all’attacco. Si ricordi che, durante l’analisi di un qualunque file di log appartenente a una macchina compromessa, ogni dato può essere stato modificato dall’intruso. Sui sistemi Unix è opportuno controllare il file /etc/syslog.conf per vedere dove Syslog memorizza i messaggi. I sistemi NT generalmente memorizzano qualunque evento in uno dei tre log di NT Events, ciascuno dei quali può essere visto attraverso l’Event Viewer. Altre applicazioni NT possono memorizzare i altre locazioni. Segue una lista di alcuni dei più comuni log file di Unix, la loro funzione e ciò che deve essere analizzato in essi. A seconda di come il sistema è configurato, questi file potrebbero essere presenti o meno: •

/var/log/messages e /var//messages contengono una grande varietà di informazioni; controllare qualunque cosa fuori dall’ordinario e tutti gli eventi occorsi attorno al momento dell’intrusione (IP sospetti rimossi, blocco dell’attività di logging).

•

.bash_history e .sh_history quando un intruder genera un buffer overflow, generalmente altera sh o bash. Nel momento in cui una nuova shell viene caricata viene creata una history nella cartella in cui il server è stato attaccato; con buona probabilità sarà possibile rintracciare il nome dell’host remoto. Pagina 119 di 334

•

logs/*_log (website access log) è importante nel caso di defacement di un sito web o di raccolta di informazioni sensibili da esso. In questo log file è possibile rintracciare l’indirizzo IP dell’attaccante, file ati dall’attacker nella directory htdocs, root o / per verificare la riuscita del defacement. È anche possibile memorizzare i website una directory apposita, in modo che l’intruso non li possa rintracciare (e quindi modificare) con facilità.

•

coredumps solitamente i daemon avviati dagli script SysV Init non eseguono questa funzione di default per motivi di sicurezza; tuttavia spesso gli amministratori avviano i servizi manualmente e questo fa sì che in caso di exploit venga fatto il dump nella directory corrente. Se il server compromesso ha eseguito il comando getpeername, è possibile che l’IP dell’intruso remoto sia memorizzato in una variabile del core dump del processo.

•

proxy server in presenza di un server davanti a tutti gli host, le operazioni di auditing sono generalmente semplificate. I trasparent proxy hanno un log di tutte le connessioni transitate attraverso essi; l’attaccante in molti casi può aggirare questo controllo utilizzando porte non convenzionali e creare una shell, ma non la prima volta che l’exploit viene lanciato.

•

router log di default i router non tengono traccia di ogni connessione, ma se si dispone di un qualche controllo di accesso alla rete è possibile tracciare l’ingresso dell’intruso.

•

xferlog utile nel caso in cui il sistema compromesso abbia un server ftp in funzione; in questo file sono contenuti i log di tutti i trasferimenti ftp. Controllare i tool ati sul sistema dall’intruso e le informazioni ate dal sistema.

•

utmp contiene informazioni in formato binario su ogni utente correntemente loggato. Per accedervi utilizzare il comando who.

•

wtmp è un file binario che contiene le informazioni dei , dei e dei reboot della macchina. Per l’accesso al file è necessario utilizzare un tool (ad esempio last, il cui output contiene una tabella in cui i nomi degli utenti sono associati al time e agli host name dove la connessione è stata originata). Il controllo di questo file per connessioni sospette (ad esempio da host non autorizzati) può essere utile per determinare eventuali altri host che potrebbero essere stati coinvolti e trovare quali del sistema potrebbero essere stati compromessi.

•

secure ogni volta che viene stabilita una connessione con uno dei servizi che usa un t wrapper in esecuzione al di fuori di inetd, un messaggio di log viene aggiunto a questo file. È opportuno controllare le anomalie, come servizi acceduti ma non utilizzati abitualmente o connessioni da host sconosciuti.

Pagina 120 di 334

2.3.8

Ricerca della presenza di un network sniffer Quando un sistema viene compromesso, l’intruso potrebbe installare un programma di monitoraggio della rete (su sistemi Unix) comunemente chiamato sniffer o packet sniffer, col fine di intercettare informazioni relative agli e degli utenti. Con lo stesso scopo, sui sistemi NT sono più comunemente utilizzati programmi di amministrazione remota. Il primo step nel determinare l’eventuale presenza di uno sniffer nel sistema consiste nel controllare se esiste un processo che utilizza un’interfaccia di rete in modalità promiscua. Bisogna tener presente che non è possibile rilevare interfacce in modalità promiscua se la macchina è stata riavviata dal momento della scoperta dell’intrusione o se si sta operando in modalità single . È opportuno tener presente che alcuni network monitor e protocol analyzer legittimi potrebbero settare l’interfaccia di rete sulla modalità promiscua. Per questo motivo la scoperta di un’interfaccia promiscua non significa necessariamente che uno sniffer non legittimo è in esecuzione nel sistema. Un altro aspetto da considerare è che i file di log di uno sniffer tendono ad aumentare velocemente di dimensione; potrebbe quindi risultare comoda un’utility come df per determinare se una parte del filesystem è più grande del previsto. Si ricordi che df è spesso sostituito da un trojan horse nel caso in cui sia stato installato uno sniffer; per questo siate sicuri di ottenere una copia pulita dell’utility prima di utilizzarla. Nel momento in cui si trova uno sniffer installato sul sistema è opportuno esaminare il file di output per determinare quali altre macchine sono a rischio, cioè quali macchine appaiono nel campo destinatario dei pacchetti intercettati. Nel caso in cui le utilizzate siano comuni o le macchine sorgente e destinatario abbiano delle trusted relationship, la macchina sorgente è comunque a rischio. In alcuni casi gli sniffer crittano i loro log; per questo è importante controllare i file che aumentano rapidamente di dimensione. Si tenga anche presente che possono esserci altre macchine a rischio in aggiunta a quelle che appaiono nel log dello sniffer; questo perché l’intruso potrebbe aver ottenuto log precedenti dal sistema o attraverso altri tipi di attacco.

2.3.9

Ricerca di altri sistemi compromessi all’interno della rete È consigliabile controllare tutti i sistemi, non solo quelli di cui si sa con certezza che sono stati compromessi. Durante il controllo si includano tutti i sistemi associati a quello compromesso attraverso servizi di rete condivisi (ad esempio NIS e NFS) o attraverso metodi di trust (come sistemi in hosts.equiv o file .rhosts o server Kerberos).

2.3.10 Ricerca di sistemi implicati o compromessi in siti remoti Durante l’esame dei file di log, dei file di output dell’intruso e di ogni altro file modificato o creato dal momento dell’intrusione, si cerchino anche informazioni che possano far pensare al coinvolgimento di un altro sito nell’intrusione stessa; spesso infatti i siti correlati a quello compromesso sono essi stessi vittime di un attacco. È quindi importante che ogni altra potenziale vittima sia identificata il più presto possibile.

Pagina 121 di 334

2.3.11 Log parsing tool •

Firewall cislog firewall 1.6 fire-waller 1.2 fwanalog fwlogsum fwlogwatch icewatch Ken-McKinlay’s FW-1 parsing tools logren pix2ss.pl pixlog pix-summarize Report-Gen log reporter CheckScan 0.2

•

Ftpd flog

•

Postfix Pflogsumm

•

Sendmail anteater bms fromto-1.5.pl mreport sm.logger.pl smtpstaz

•

System Logs LogWatch

•

Web Server analog nimda detection script webalizer

•

Windows Microsoft Windows Log Event utility monilog NTLast Microsoft Operations Manager

•

Generici ACID (Analysis Console for Intrusion Detection) awk checksyslog colorlogs Pagina 122 di 334

CyberSafe Log Analysis guard lire log_analysis LogSentry LogDog logmuncher logsurfer logtool logtools logwatch private I root-tail SHARP (Syslog Heuristic Analysis and Response Program) SIDS (Statistics –based Intrusion Detection System) swatch syslogscan 0.32 syslog –summary xlogmaster

Pagina 123 di 334

Green circle17: identificazione dell’attacco ad un sistema

2.4

In questa parte di analisi verranno chiarite alcune procedure che dovrebbero essere compiute per poter individuare l’attacco che è stato effettuato verso un sistema. Una delle cosa da fare è cercare i log dei sistemi compromessi, in quanto essi possono rivelare il tipo di attacco effettuato. In dipendenza dalla configurazione del sistema possono essere rilevate differenti tipologie di log, quali ad esempio messaggi relativi ad accessi negati, accessi bloccati a specifici servizi o file ecc. Generalmente, prima di iniziare il vero attacco, gli intrusi tentano un numero di incursioni o di scansioni volte alla ricerca di una particolare vulnerabilità. Dopo aver conquistato l’accesso, un intruso tenta di cancellare tutti i log o solo alcuni specifici valori di log, ciò può far sì che la ricerca dei log possa produrre dei risultai inutili. A volte è possibile scoprire che i log sono stati modificati o cancellati, in questi casi è importante condurre ulteriori analisi per verificare il tipo di intrusione avvenuta e l’entità del danno. Se le informazioni necessarie per scoprire un'intrusione non sono state raccolte e analizzate, non si può determinare quali dati sensibili, sistemi e reti sono stati attaccati e quali violazioni della riservatezza, dell’integrità o della disponibilità sono state compiute. La raccolta di dati generati dalle attività dei sistemi, delle reti, delle applicazioni e degli utenti è fondamentale per analizzare la sicurezza delle patrimonio informativo dell’azienda e per scoprire le tracce di comportamenti sospetti e inattesi. I file di log contengono le informazioni relative ad attività ate. Bisogna identificare il meccanismo di logging e le tipologie di log (di sistema, accesso ai file, processi, rete, specifiche applicazioni...) disponibili per ogni attività e identificare i dati registrati in ogni log. Sistemi differenti forniscono varie tipologie di informazioni relative ai log; alcuni sistemi non raccolgono informazioni adeguate se lasciati alla condizione di default. E’ importante integrare i log generati dai sistemi con meccanismi che controllino le tracce dei tentativi di intrusione. Questi meccanismi devono anche essere in grado di avvisare le parti responsabili dell’accadimento di un evento. Si consiglia di includere meccanismi che: •

monitorino e ispezionino le risorse del sistema in uso

•

monitorino e ispezionino il traffico di rete e le connessioni

•

monitorino e ispezionino gli degli utenti e l’accesso ai file

•

scansionino il sistema alla ricerca di virus

•

verifichino l’integrità dei file e dei dati

•

indaghino il sistema e le reti alla ricerca di vulnerabilità

•

riducano, scansionino, monitorino e ispezionino i file di log

Per poter stabilire un efficace metro di confronto in merito allo stato corrente dei sistemi, è necessario creare un accurato, completo ed affidabile profilo dello stesso sia in fase di implementazione dei sistemi che durante la loro evoluzione. L’informazione che deve essere 17

Il Green Circle è il nastro verde virtuale con il quale viene circoscritta la scena digitale ove è avvenuta la violazione. Le attività post incidente vengono anche definite “post mortem”.

Pagina 124 di 334

raccolta comprende lo stato noto ed atteso per tutte le attività, incluso il traffico di rete, i processi, gli utenti, i file, le directory e l’hardware, in questo profilo devono venire inserite anche le informazioni che caratterizzano il comportamento ato del sistema che può essere derivato dai log di sistema e dagli strumenti di monitoraggio. Questa documentazione affidabile deve essere periodicamente confrontata con lo stato corrente dei sistemi in modo da determinare se esistono degli scostamenti nel comportamento degli asset e per verificare l’integrità dei sistemi. Gli approcci per scoprire le tracce di comportamenti sospetti sono spesso basati sull’identificazione delle differenze tra lo stato operativo corrente e quello precedentemente rilevato e affidabile. Bisogna essere in grado di verificare lo stato corretto ed atteso per ogni risorsa, senza questa informazione, non è possibile determinare in maniera adeguata se qualche cosa è stata aggiunta, cancellata, modificata, persa o rubata. Se non si è in possesso di profili aggiornati, disponibili, affidabili, potrebbe non essere possibile ricostruire le componenti critiche che sono state compromesse. I log file potrebbero essere gli unici documenti che hanno un comportamento sospetto. L’abilitazione errata dei meccanismi di registrazione di questo tipo di informazioni può indebolire o anche eliminare la capacità di determinare se sono avvenuti tentativi di intrusione. I log dovrebbero essere in grado di : •

avvisare in caso di attività sospetta che richiede ulteriori indagini

•

determinare l’estensione dell’attività dell’intruso

•

aiutare nel recupero dei sistemi

•

fornire informazioni utili per procedimenti legali

E’ possibile che i meccanismi di logging e di monitoraggio forniti con i sistemi possano non produrre tutte le informazioni necessarie per scoprire i segni di una intrusione tempestivamente. L'approccio generale per la ricerca di intrusioni può essere così schematizzato: 1. cercare nei sistemi qualsiasi cosa inaspettata o sospetta. 2. indagare qualsiasi cosa che può essere insolita. 3. se durante la ricerca si trova qualche cosa che non è riconducibile all’attività autorizzata, bisogna immediatamente dare inizio alle procedure di risposta ad un’intrusione. Questa procedura sembra abbastanza semplice, ma la sua messa in pratica è un'attività dispendiosa che richiede o continuo e automatizzato oltre ad un impegno amministrativo quotidiano. Si ricordi inoltre che la sequenza di azioni per la scoperta di un’intrusione può cambiare in funzione delle minacce, delle diverse configurazioni di sistema o della modifica dei requisiti di sicurezza. In tutti i casi, è necessario considerare cinque campi di azione principali: •

preparazione adeguata che dovrebbe includere la definizione delle policy richieste e delle procedure necessarie per soddisfare gli obiettivi di business e la preparazione del personale e dei sistemi alla ricerca di intrusioni. Pagina 125 di 334

•

verifica dell'integrità del software da utilizzare per scoprire le intrusioni

•

monitoraggio del comportamento dei sistemi e del traffico sulla rete

•

identificazione delle intrusioni a livello hardware nei sistemi di elaborazione, media contenenti dati offline e dispositivi di output.

•

investigazione dei report generati dagli utenti e da altre fonti affidabili (come un team di Incident Response) ed azioni da intraprendere in caso di accadimenti di attività insolite.

In particolare l’attenzione di questa parte di trattazione sarà focalizzata sul terzo punto (monitoraggio del comportamento dei sistemi ed del traffico sulla rete). Verranno analizzate le operazioni che dovrebbero essere effettuate per: •

monitorare ed ispezionare le attività di rete alla ricerca di comportamenti sospetti

•

monitorare ed ispezionare le attività di sistema alla ricerca di comportamenti sospetti

•

ispezionare file e directory alla ricerca di modifiche inaspettate.

2.4.1

Monitoraggio ed ispezione delle attività di rete alla ricerca di anomalie. L’attività di monitoraggio dei messaggi in transito sulla rete permette di identificare l'attività intrusiva mentre si sta verificando o dopo il suo accadimento. La rapida intercettazione delle attività sospette permette di iniziare tempestivamente le indagini di merito e di minimizzare e contenere il danno. I log del traffico di rete possono contenere prove di attività insolite, sospette o inattese, ed indicano che qualcuno ha compromesso o ha tentato di compromettere un sistema sulla rete. Una attività di ispezione metodica dei log, permette di identificare eventuali ricognizioni di un intruso prima che avvenga l’effettiva intrusione. E’ possibile anche identificare tentativi o intrusioni riuscite poco dopo che sono accadute. Se, però, un intruso ha alterato i file di log, questi dati possono non essere più presenti o non affidabili. Di seguito verranno analizzate alcune pratiche che dovrebbero essere seguite per monitorare al meglio i propri sistemi.

2.4.1.1

Analisi e investigazione delle notifiche di meccanismi di alert dedicati alla rete (come email, voice-mail, o sms)

Questa pratica prevede che vengano tenute sotto costante controllo le notifiche provenienti da: •

Utenti o amministratori effettuate via e-mail e di persona

•

Meccanismi di altert dei sistemi operativi

•

Trap di sistema (system management software traps)

•

Intrusion Detection System (IDS)

•

Meccanismi di alert personalizzati per specifici servizi o programmi

Pagina 126 di 334

2.4.1.2

Analisi e investigazione dei report di errore di rete

Le notifiche di questo tipo provengono in genere da: •

Meccanismi di report di errore dei sistemi operativi

•

Strumenti di filtraggio dei file di log

•

Software di gestione forniti dai vendor o sviluppati ad hoc

•

Meccanismi di personalizzati report di errore per specifici servizi o programmi

I sistemi di report degli errori possono venire spesso configurati dagli amministratori in fase di installazione del sistema, dei servizi, dei programmi e degli strumenti ati. 2.4.1.3

Analisi delle statistiche delle prestazioni della rete ed investigazione di anomalie

Le statistiche sono generalmente prodotte da strumenti forniti dal vendor o sviluppati ad-hoc. Tipicamente le statistiche contengono: •

carico totale del traffico in ingresso e in uscita nel tempo (numero di pacchetti, byte e connessioni) e per evento (servizi attivi)

•

carico del traffico (percentuale di pacchetti, byte e collegamenti) in ingresso ed uscita nel tempo ordinato per protocollo, indirizzo sorgente, indirizzo di destinazione, altri dati dell’header del pacchetto

•

numero di errori su tutte le interfacce di rete

•

confronto fra statistiche delle prestazioni di rete precedenti con statistiche correnti per la stessa fascia oraria

E’ necessario cercare: •

variazioni inattese delle prestazioni fra le statistiche correnti e precedentemente rilevate; per esempio, traffico di rete insolitamente alto o basso in confronto ai livelli medie rilevati per il periodo in esame

•

differenze inaspettate che esistono tra le informazioni precedentemente profilate del traffico di rete e quelle attuali, come: o o o

traffico proveniente da indirizzi inaspettati o che utilizza porte o protocolli non usuali traffico diretto verso indirizzi imprevisti o che utilizza porte o protocolli insoliti volume di traffico eccessivamente elevato o basso per l’ora e il giorno della settimana

•

perdita inaspettata di connettività

•

attività o disponibilità del modem insolita. Un attività anomala del modem può indicare l’accesso di un intruso attraverso punti di entrata trascurati (porte) o l’utilizzo da parte di un intruso di “daemon dialers”.

2.4.1.4

Identificazione del traffico di rete inatteso, insolito, o sospetto e le possibili implicazioni

Nei file di log di rete e in altri meccanismi di raccolta del traffico di rete, è necessario cercare: •

ricognizioni prima di un attacco (probing, scansioni, uso di mapping tools). Queste possono indicare tentativi di identificare la configurazione del sistema (hosts, sistemi Pagina 127 di 334

operativi, topologia della rete, path raggiungibili dall’esterno...) e gli Internet Service Provider (ISP) in uso, con la loro configurazione. •

collegamenti da o per luoghi insoliti. Per esempio, se un server è dedicato ad un solo servizio (come un sito web pubblico), qualsiasi richiesta di connessione all’esterno è sospetta. Tali richieste possono indicare che un intruso ha compromesso il server e lo sta usando per lanciare un attacco verso altri host.

•

violazioni di protocollo. Queste includono bit di opzioni in un pacchetto T invalidi, numeri di sequenza errati in un pacchetto T, flag invalidi in un pacchetto T (ACK prima di SYN), e frammenti errati. Non c'è nessuna buona ragione di violare le specifiche IP, T, ICMP e UDP. Questi tipi di violazioni di protocolli sono spesso il risultato dell’utilizzo da parte di un intruso di un analizzatore di rete nel tentativo di aggirare il firewall ed identificare il tipo di sistemi sulla rete. Può verificarsi un denial-of-service, per esempio, quando l'host di un intruso crea connessioni T half-open, spedendo numerosi pacchetti con il flag SYN senza i corrispondenti pacchetti con il flag ACK.

•

pacchetti con indirizzo sorgente e destinazione esterni alla rete aziendale. Il firewall dovrebbe essere configurato sempre per prevenire ciò. Se accade, può indicare che un intruso ha aggirato il firewall, probabilmente compromettendo il firewall stesso e sta indirizzando il suo traffico attraverso la rete aziendale, cercando di approfittare di relazioni di fiducia a livello network. Può indicare anche la presenza di un intruso interno.

•

pacchetti con un indirizzo sorgente interno che vengono ora originati da una fonte esterna. Questo può indicare un attacco di IP spoofing che ha potuto aggirare il firewall.

•

combinazioni di porte insolite in pacchetti T ed UDP. Questo tipo di traffico potrebbe indicare che un servizio inatteso è attivo sulla rete (come un programma che utilizza backdoor). Potrebbe indicare anche che l'intruso ha aggirato il firewall. Pacchetti con indirizzo sorgente uguale ed una sequenza di porte di destinazione spesso indicano che un intruso sta tentando di scoprire sia la policy del firewall, sia quali servizi sono disponibili sui sistemi.

•

traffico ARP insolito. In una rete switchata, un intruso può alterare la cache ARP su uno o più host così che ogni host sullo stesso segmento può vedere il traffico su quel segmento (simile ad una scheda di rete in modalità promiscua su un segmento Ethernet condiviso). L'intruso può guadagnare poi l’accesso a e ad altre informazioni non crittate spedite sulla rete.

•

traffico di DH/BOOTP insolito. Un intruso può usare un host per la spedizione di risponde DH fasulle e convincere gli altri host che è il loro default gateway. L'host compromesso riceverà poi tutto il traffico diretto verso l’esterno e guadagnerà l’accesso alle informazioni non crittate spedite sulla rete.

•

pacchetti con protocollo o numeri di porte insolite spediti ad indirizzi broadcast. Questo tipo di traffico può indicare un attacco di denial-of-service.

•

un numero insolitamente alto di pacchetti ICMP di tipo “port unreachable” da un solo host. Questo può indicare che un intruso sta effettuando scansioni sull’host in cerca dei servizi disponibili.

•

connessioni effettuate ad orari insoliti Pagina 128 di 334

•

2.4.2

uso insolito di Internet Relay Chat (IRC), un mezzo di comunicazione usato dagli intrusi.

Monitorare ed ispezionare le attività di sistema alla ricerca di comportamenti sospetti In questo paragrafo prenderemo in considerazione le attività che dovrebbero essere effettuate per eseguire al meglio il monitoraggio del sistema indirizzato alla ricerca di qualsiasi tipologia di comportamento che risulti essere “sospetta” o insolita. In questo contesto, le attività di sistema comprendono le prestazioni del sistema, i processi e gli utenti18. I programmi eseguiti in un sistema in genere includono una grande varietà di sistemi operativi, di servizi di rete, di programmi che vengono eseguiti dagli utenti e di applicazioni che hanno scopi precisi come ad esempio i servizi di data base. Ogni programma che viene eseguito in un sistema è rappresentato da uno o più processi. Ogni processo viene eseguito con specifici privilegi, i quali hanno il compito di controllare chi può avere accesso alle risorse, programmi, file e che tipo di operazioni può essere compiuto con essi. Le operazioni che il processo compie durante la sua esecuzione, il modo in cui esse vengono eseguite e le risorse che vengono utilizzate durante l’esecuzione costituiscono il comportamento di esecuzione di un processo. Tutte queste operazioni includono calcoli, operazioni con i file, con i dispositivi, e con altri processi e le comunicazioni via rete con processi che vengono eseguiti su altri sistemi. Le attività che vengono generalmente compiute dagli utenti in un sistema includono il e il , l'autenticazione e le altre operazioni di identificazione, i processi che essi eseguono ed i file ai quali essi accedono. Nel caso in cui venga permesso a terze parti esterne all’azienda (ad esempio a fornitori, clienti, partner, ecc) l’accesso alla rete ed ai sistemi aziendali, si reputa necessario effettuare l’esame dei loro accessi per controllare che tutte le azioni da loro svolte vengano correttamente autorizzate e autenticate. Questa operazione include anche il monitoraggio e la verifica di tutte le loro attività di sistema. E’ necessario verificare costantemente il comportamento dei sistemi, che deve essere conforme a quanto stabilito in fase di implementazione, e quello dei processi, che devono essere riconducibili esclusivamente ad attività autorizzate eseguite dagli utenti, amministratori e a funzioni di sistema. Il rilevamento di prestazioni di sistema anomale e inaspettate può indicare l’utilizzo abusivo e clandestino del sistema per scopi non autorizzati effettuato da un intruso. La causa delle anomalie potrebbe essere un tentativo di attacco rivolto verso alcuni sistemi interni od esterni alla rete aziendale oppure dell’utilizzo di sniffer di rete. Un processo che presenta un comportamento anomalo potrebbe indicare un’avvenuta intrusione all’interno del sistema; gli intrusi potrebbero aver interrotto l’esecuzione di un programma o di un servizio, causando il suo mancato funzionamento, o facendolo funzionare in modo differente da ciò che un utente o un amministratore desidera. Ad esempio, l’interruzione dell’esecuzione di un processo relativo al controllo degli accessi su di un firewall potrebbe far ottenere agli intrusi l’accesso alla rete interna dell’organizzazione colpita, azione questa che verrebbe normalmente impedita dal firewall stesso.

18

nella categoria degli utenti in questo caso vanno inclusi tutti coloro che accedono, amministrano e gestiscono il sistema e hanno codici autorizzati all’accesso

Pagina 129 di 334

Di seguito vengono riportate alcune pratiche che dovrebbero essere seguite per monitorare al meglio i propri sistemi. 2.4.2.1

Analisi ed investigazione delle notifiche che provengono da meccanismi di altert specifici per i sistemi (come e-mail, voice-mail o sms)

Questa pratica è molto simile a quella analizzata precedentemente in riferimento alle notifiche provenienti dai meccanismi di altert specifici per le reti. Si faccia riferimento alla classificazione presente nel paragrafo 2.4.1.1 in questa fase di analisi.

2.4.2.2

Analisi ed investigazione dei rapporti di errore provenienti dal sistema

In questa fase le notifiche che dovrebbero essere analizzate sono molto simili a quelle elencate nel paragrafo relativo all’analisi ed investigazione dei report di errore di rete. Si faccia riferimento alla classificazione presente nel paragrafo 2.4.1.2 in questa fase di analisi. 2.4.2.3

Analisi delle statistiche delle prestazioni di sistema ed investigazione di eventuali anomalie.

Le statistiche relative alle prestazioni del sistema vengono generalmente prodotte da tool forniti dai vendor da strumenti personalizzati che monitorano le prestazioni. Queste statistiche tipicamente includono dati ed informazioni relativi a: •

utilizzo totale delle risorse nel tempo (U, memoria [usata, libera], disco [usato, libero])

•

condizione dei sistemi e dei dispostivi hardware come ad esempio le code di stampa

•

modifiche relative allo stato del sistema, inclusi eventuali shutdown e restart del sistema

•

stato dei file di sistema (dove vengono montati, spazio libero per ogni partizione, file aperti, file più grandi ) nel tempo e in momenti specifici

•

allarmi relativi ai file di sistema (poco spazio libero, troppi file aperti, file che eccedono lo spazio allocato)

•

disk counter (input/output, lunghezze di coda) nel tempo e in momenti specifici

•

disponibilità dell’hardware (modem, schede di rete, memoria)

•

statistiche relative alle prestazioni di sistemi o host specifici (ad esempio, per un server web, queste statistiche possono includere le pagine visitate, le statistiche relative alle connessioni, le richieste degli utenti, pagine più richieste e chi richiede le pagine)

•

confronto tra le statistiche delle performance attuali e precedenti del sistema

Inattesi shutdown, reboot e restart possono indicare la presenza di un Trojan horse che li richiede.

Pagina 130 di 334

2.4.2.4

Monitoraggio continuo dell’attività dei processi (fin dove è possibile)

L’esame dei processi è complesso e dispendioso; il livello al quale si è in grado di identificare processi sospetti dipende principalmente dalla conoscenza di quali processi dovrebbero essere normalmente in esecuzione su di un dato sistema e come essi si dovrebbero comportare. A causa del gran numero di processi e della loro natura mutevole, è molto difficile poterli tenere costantemente e manualmente sotto controllo; in più, l’ammontare e il valore delle informazioni che possono essere raccolte da “un’istantanea” dello stato dei processi può essere limitato. Tutto questo implica la necessità di utilizzare una grande varietà di strumenti di raccolta di informazioni e di meccanismi di monitoraggio per riuscire al meglio nella collezione e nell’analisi dei dati associati ai processi e per poter scovare attività sospette. Un approccio comune utilizzato con sistemi multi utente è quello di preparare console (o terminali su workstation) che mostrino lo stato corrente dei processi e che vengano aggiornati in brevi intervalli. Idealmente, queste console dovrebbero essere direttamente collegate con sistemi dei quali mostrano le informazioni. 2.4.2.5

Identificazione di qualsiasi comportamento dei processi che possa essere definito inaspettato, non usuale o sospetto e le possibili implicazioni

I punti essenziali che dovrebbero essere ricercati sono: •

processi mancanti

•

processi addizionali

•

comportamento insolito di un processo o di utilizzo di una risorsa

•

processi che sono associati ad utenti insoliti

I dati dai file di log e altri dati possono essere utili nell’analisi del comportamento dei processi. Bisognerebbe tenere sotto controllo i dati relativi a: •

utente che esegue il processo

•

momento di inizio del processo, argomenti, nomi di file

•

stato di uscita del processo, durata di tempo, risorse consumate

•

ammontare delle risorse usate (U, memoria, disco, tempo) dagli specifici processi nel tempo; risorse massime consumate da un determinato processo

•

processi di sistema e di utente e servizi eseguiti

•

modalità di inizio di un processo (amministratore, altri utenti, altri programmi o processi), con quali autorizzazioni e privilegi

•

dispositivi utilizzati dagli specifici processi

•

file aperti dagli specifici processi

Di seguito un breve elenco delle anomalie tipiche che dovrebbero essere ricercate: •

processi attivi in momenti inaspettati

•

processi terminati prematuramente Pagina 131 di 334

•

i processi che consumano risorse eccessive (tempo di clock, tempo di U, memoria, disco) possono far presagire l’esistenza di una condizione di denial-of-service o dell’utilizzo di uno sniffer di rete

•

processi insoliti, come cracking, sniffing di pacchetti di rete, o qualsiasi altro processo non dovuto alla attività normale e autorizzata

•

processi con output o argomenti non usuali (per esempio, su sistemi UNIX un processo eseguito come ". /telnetd" invece di "/usr/sbin/telnetd")

•

processi o servizi che sono nuovi, inaspettati o che sono stati precedentemente disabilitati. Questi possono indicare che un intruso ha installato una propria versione di un processo o servizio o, per esempio, sta eseguendo dei servizi IRC, dei servizi web, FTP, ecc per far sì che vengano distribuiti agli altri host i suoi strumenti o file

•

inattivi che stanno generando processi e utilizzando risorse di U

•

qualsiasi comportamento anomalo di input/output

•

processi senza controllo via terminale che stanno eseguendo programmi insoliti

•

un numero insolitamente grande di processi

Bisogna prestare molta attenzione ai processi associati agli Intrusion Detection System e ad altri strumenti di sicurezza, in quanto gli intrusi generalmente compromettono questi sistemi per guadagnare maggiore potere e maggiori informazioni e per generare allarmi esca per distrarre gli amministratori di sistema. 2.4.2.6

Identificazione di qualsiasi comportamento degli utenti che sia inaspettato, insolito o sospetto e le possibili implicazioni

I dati dei file di log e di altri meccanismi di raccolta possono aiutare nell’analisi del comportamento degli utenti. Questi includono : •

informazioni di / (ubicazione, tempo): tentativi riusciti, falliti, tentati con privilegiati

•

informazioni di / relativi a server di accesso remoto che appaiono nei file di log dei modem

•

modifiche dell’identità dell’utente

•

modifiche nello status di autenticazione come ad esempio l’abilitazione di privilegi

•

tentativi falliti di accesso ad informazioni limitate (come file di )

•

log che esaminino il keystroke, ossia le battute dei tasti

•

violazioni delle quote disco dell’utente

Le principali informazioni che vanno ricercate, possono essere così riassunte: •

tentativi di falliti e ripetuti, inclusi quelli che utilizzano privilegiati

•

da ubicazioni o a durate insolite, includendo tentativi inconsueti o non autorizzati di accesso effettuati da server di accesso remoti

•

tentativi insoliti di modifica dell’identità dell’utente Pagina 132 di 334

•

processi insoliti amministrati da utenti

•

accessi insoliti a file, inclusi i tentativi non autorizzati di accesso a file riservati

•

utenti loggati per durate di tempo anomale (sia troppo corte che troppo lunghe)

•

utenti che eseguono comandi inaspettati

•

utenti che lavorano da terminali insoliti

Se si osserva un’attività non usuale associata a particolari utenti, la procedura migliore suggerirebbe di iniziare la raccolta di dati aggiuntivi al fine di ottenere informazioni più dettagliate in relazione alle attività rilevate. La maggior parte dei sistemi multi utente forniscono meccanismi che permettono di verificare tutti i processi associati ad un particolare utente. E’ conveniente allocare sufficienti risorse per salvare i dati raccolti, in quanto il processo di verifica e di correlazione di differenti log di solito genera rapidamente una grande quantità di informazioni. E’ buona norma analizzare spesso i dati raccolti (almeno giornalmente) ed effettuare regolarmente una rotazione dei file di log per minimizzare l’ammontare di informazioni che devono essere analizzate e salvate. 2.4.2.7

Identificazione di altri comportamenti inaspettati, insoliti o sospetti e le loro possibili implicazioni

Se la scheda di rete, presente nel sistema che si analizza, è utilizzata in modalità promiscua19, un intruso può eseguire sniffer di rete e catturare ed altre informazioni sensibili. E’ consigliato effettuare una regolare analisi correlata (determinando perciò l’eventuale relazione esistente tra differenti attività intrusive rilevate sia nella stessa organizzazione che anche all’esterno) durante il processo di scoperta dell’intrusione, perché potrà essere di aiuto nella determinazione dell’estensione totale della compromissione e dell’individuazione delle sue caratteristiche. Se si effettua il logging delle informazioni prodotte dalle patch di vulnerabilità (aggiornamenti di software che correggono o eliminano vulnerabilità), si potrebbe riuscire ad identificare con facilità un modello delle azioni che potrebbero essere compiute dall’intruso. Ad esempio, un tentativo di accesso fallito volto a sondare una vecchia vulnerabilità potrebbe essere seguito da una ricerca con esito positivo di una nuova vulnerabilità che non è stata ancora registrata. La presenza delle informazioni delle patch di vulnerabilità insieme ad altri meccanismi come la verifica dell’integrità possono mettere in guardia in merito al tipo di azioni che possono essere compiute dall’intruso.

19 le schede di rete nella maggior parte dei sistemi in genere operano in modo non promiscuo, il che significa che ignorano i pacchetti non esplicitamente indirizzati ad essa. In modo promiscuo, nessun pacchetto viene ignorato e perciò tutti i pacchetti che attraversano il segmento di rete al quale è connesso il sistema sono letti dalla scheda di rete e sono accessibili dai processi che vengono eseguiti su quel sistema

Pagina 133 di 334

2.4.2.8

Esecuzione periodica del mapping della rete e degli strumenti di scanning per comprendere cosa può essere portato alla conoscenza degli intrusi che utilizzano questi sistemi

Si raccomanda di far girare gli strumenti di mapping e di scanning al di fuori degli orari di lavoro e quando si è presenti in azienda, in quanto questi strumenti possono a volte intaccare i sistemi in modo inaspettato. Bisogna tentare di rendere invisibile, ove possibile, qualsiasi aspetto della topologia della rete e delle caratteristiche dei sistemi soprattutto quelli che non devono essere resi noti agli intrusi. 2.4.2.9

Esecuzione periodica degli strumenti di scanning delle vulnerabilità su tutto il sistema volte alla verifica della presenza di vulnerabilità note

Si raccomanda di far girare gli strumenti di mapping e di scanning al di fuori degli orari di lavoro e quando si è presenti in azienda, in quanto questi strumenti possono a volte intaccare i sistemi in modo inaspettato. E’ necessario eliminare tutte le vulnerabilità identificate da questi strumenti il prima possibile; molte di queste possono essere eliminate aggiornando le impostazioni dei file di configurazione e installando le patch fornite dai vendor. L’utilizzo di strumenti di scanning e di analisi delle è da considerare come parte integrante della valutazione delle vulnerabilità. Queste analisi includono l’identificazione di deboli, o addirittura lasciate vuote, come ad esempio quelle che possono essere facilmente determinate utilizzando attacchi basati sui dizionari o attacchi di forza bruta. 2.4.3

Ispezione dei file e delle directory alla ricerca di modifiche inaspettate In questo paragrafo vengono trattate le attività che dovrebbero essere effettuate per verificare la presenza di modifiche nei file e nelle directory. Questa parte di ricerca è importante in quanto la presenza di file modificati potrebbe indicare ad esempio l’esistenza di trojan horse o più in generale la possibilità che il sistema esaminato sia sotto il controllo di un hacker. Il file system di un sistema contiene una varietà di software e di file di dati. La scoperta di eventuali modifiche inattese nelle directory e nei file, specialmente in quelli ai quali l’accesso è normalmente ristretto, possono indicare una intrusione; essi possono includere modifiche, creazioni o cancellazioni di directory e di file. Il risultato di queste modifiche dipende da differenti fattori tra i quali chi ha effettuato i cambiamenti, dove, quando e come essi sono stati fatti. Nel caso in cui venga permesso a terze parti esterne all’azienda (ad esempio a fornitori, clienti, partner, ecc) l’accesso alla rete ed ai sistemi aziendali, si reputa necessario effettuare l’esame dei loro accessi per controllare che tutte le azioni da loro svolte vengano correttamente autorizzate e autenticate. Questo processo include anche il monitoraggio e la verifica di tutte le directory ed i file più importanti. Gli intrusi spesso creano, sostituiscono, modificano o danneggiano i file presenti nel sistema del quale essi guadagnano l’accesso. Per nascondere la loro presenza nel sistema, è prassi per gli intrusi sostituire programmi con altri da loro creati che svolgono le stesse funzioni, ma che escludono le informazioni che possano rivelare la loro attività illecita. Spesso gli intrusi

Pagina 134 di 334

modificano i file di log di sistema per rimuovere le tracce della loro attività20. Mascherando la loro presenza nei sistemi compromessi, gli intrusi prolungano il tempo di utilizzo dei sistemi per i loro scopi. In molti casi, la presenza degli intrusi nei sistemi compromessi può non venir scoperta per molti mesi dopo l’inizio dell’intrusione stessa. Gli intrusi possono anche creare nuovi file nel sistema. Ad esempio, possono installare backdoor o strumenti utilizzati per guadagnare privilegi di accesso al sistema. Essi possono anche utilizzare lo spazio su disco presente sui sistemi compromessi per salvare gli strumenti o altri tool che utilizzano. I file di dati riservati e i file contenenti informazioni critiche sono gli obiettivi più comuni delle operazioni di modifica o corruzione da parte degli intrusi. Le informazioni pubbliche, ossia accessibili da internet, relative all’organizzazione sono target comuni degli hacker, esistono infatti parecchi casi documentati di defacement di siti di grandi organizzazioni. In seguito verranno analizzate alcune linee guida relative a comportamenti da attuare per cercare eventuali modifiche effettuate ai file. 2.4.3.1

Stabilire priorità ed orari

E’ buona norma esaminare le directory e i file presenti sul sistema e stabilire delle priorità relative alla frequenza di controllo degli stessi. Più i file sono mission-critical, più essi devo essere controllati. Si raccomanda di effettuare il controllo almeno una volta al giorno, preferibilmente all’inizio della giornata lavorativa, per includere ogni processo effettuato durante le 24 ore precedenti. 2.4.3.2

Verifica dell'integrità delle directory e dei file secondo un programma prestabilito

E’ necessario confrontare gli attributi ed i contenuti dei file e delle directory con un campione di riferimento (sia copie complete che con checksum crittografati) per identificare qualsiasi file o directory il cui contenuto o altri attributi siano stati modificati. Si acceda sempre ai dati contenenti dei riferimenti campione direttamente da media di sola lettura e garantiti. Non bisogna mai trasmettere i dati del campione di riferimento attraverso reti non sicure a meno che non si utilizzino meccanismi quali firme digitali o checksum crittografati per verificare l’integrità dei dati. 2.4.3.3

Identificazione di qualsiasi modifica inattesa, insolita o sospetta effettuata ai file o alle directory e le possibili implicazioni

I dati dai file di log e i dati raccolti da altri meccanismi possono essere di aiuto nell’analisi delle modifiche che possono essere effettuate ai file e alle directory. Questi includono: •

checksum crittografate per tutti i file e le directory

•

liste di file, directory e attributi

•

accessi (aperti, creati, modificati, in esecuzione, cancellati), data e ora

20 Queste tipologie di azioni compiute dagli intrusi possono essere realizzate utilizzando strumenti che appartengono a rootkit.

Pagina 135 di 334

•

modifiche alla dimensione, contenuto, protezione, tipologia e ubicazione

•

aggiunte o cancellazioni di file e directory

•

risultati di scansioni di software antivirus

Le principali informazioni che vanno ricercate, possono essere così riassunte: •

accessi, modifiche, cancellazioni inaspettate di file o directory

•

modifiche inaspettate alla protezione o ad access control list di file o directory. L’identificazione di queste modifiche può essere utile, ad esempio, per scovare la creazione di file nelle directory home degli utenti che possono essere utilizzati per accessi backdoor. L’impostazione impropria delle ACL sugli strumenti di sistema potrebbe indicare che un intruso ha trovato ed eseguito degli strumenti di sicurezza che erano stati in precedenza installati dagli amministratori di sistema.

•

modifiche inaspettate delle dimensioni, del contenuto o di altri attributi di file o directory; ciò può indicare che un file o un servizio è stato sostituito con la versione dell’intruso. Un intruso può, abilitando inavvertitamente la funzione di debug, facilmente quadruplicare la dimensione di un file.

•

modifiche inaspettate a file di tali da effettuare la creazione non autorizzata di nuovi e di senza

•

modifiche inaspettate di file di configurazione del sistema o di altre informazioni riservate e sensibili, incluse le regole di filtraggio dei firewall

•

scoperta di file che sono inaspettatamente aperti; ciò può svelare la presenza di sniffer

•

violazione della consistenza dei file di log (modifiche inaspettate della dimensione dei file, scostamenti tra i record dei log)

•

presenza di virus, backdoor, e trojan horses rilevati da strumenti di scanning

I sistemi compromessi che ano interfacce di rete promiscue possono essere utilizzati dagli intrusi per raccogliere informazioni relative ad autenticazioni di host e utenti. Gli sniffer possono catturare keystroke degli utenti, e informazioni relative alle . La presenza di sniffer può essere scoperta cercando la presenza di trojan horse, di processi sospetti, di file ASCII non previsti e di modifiche ai file.

Pagina 136 di 334

2.5

Analisi delle operazioni di un attacker durante una violazione

2.5.1

Introduzione Prima di effettuare qualsiasi operazione, un hacker prende sempre in considerazione il problema di come nascondersi nella rete. Il suo obiettivo è l'anonimato completo ma considera un ottimo risultato rendere il più complicato possibile il compito di chi dovrà rintracciarlo. I metodi più semplici che permettono agli hacker un minimo anonimato e un minimo vantaggio temporale prevedono la connessione tramite diversi proxy o di servirsi delle vulnerabilità di certi servizi e programmi; sono però tecniche che permettono solo di rendere più lungo e complicato il compito dell'investigatore. Dopo aver compromesso una macchina, un hacker cerca di garantirsi la possibilità di effettuare ulteriori accessi in modo tale, eventualmente, da poterla usare per ulteriori attività illecite. Se un sistema è diventato vittima di un'intrusione e se l'obiettivo finale dell'hacker era proprio quella macchina, è probabile che l'intruder abbia installato dei trojan o delle backdoors per provocare dei danni, materiali o di immagine, più o meno gravi. Una volta subita l’intrusione, anche se tutti gli strumenti sembrano sostenere il contrario, l'intero sistema non è più affidabile. L’hacker ha rimosso ogni sua traccia dai log ed è assodato che egli è comodamente inserito nel sistema. Una delle principali preoccupazioni dell’intruso diventa l’agire nel modo più discreto possibile per evitare che l'amministratore lo possa notare. Per ottenere questo effetto l’hacker installerà particolari strumenti che verranno trattati in seguito. Ovviamente non agirà con tanta discrezione se il suo scopo è quello di distruggere tutti i dati. Certamente un amministratore non può restare collegato al suo sistema 24 ore su 24 per verificare ogni singola connessione. Tuttavia, tra i suoi compiti figura anche l’individuare un’intrusione il più rapidamente possibile. Il sistema compromesso può divenire una rampa di lancio per i programmi dell’hacker (bot IRC, DDoS, ...). Per esempio, ricorrendo ad uno sniffer, può accedere a tutti i pacchetti della rete a cui la macchina è collegata. Molti protocolli non cifrano i dati o le (per esempio telnet, r, pop3, e molti altri). Di conseguenza, più a lungo l’intruso rimane nel sistema, più può controllarne la rete di appartenenza. Identificata la presenza dell’intruso resta da stabilire cosa egli abbia alterato. Se non si prendesse in considerazione questo problema, la nostra infrastruttura di rete sarebbe in costante e perenne pericolo. Una volta stabilito cosa è successo bisogna prendere in esame le misure correttive da operare. Esistono due politiche in merito: la prima prevede che l'amministratore del sistema installi tutto exnovo mentre la seconda si limita a ripristinare i file corrotti. Se la prima tecnica richiede molto tempo, la ricerca dei file modificati richiede una grande attenzione. Indipendentemente dal sistema scelto, è bene fare un completo backup dell'intero sistema per scoprire come l’hacker abbia avuto accesso al sistema. Se la macchina venisse coinvolta in un attacco di più ampia scala, tale da portare conseguenze legali, non effettuare il backup potrebbe essere considerato come un metodo per nascondere delle prove. Al contrario, eseguire un costante backup potrebbe voler dire l’assoluzione dalle accuse. Ora discuteremo una serie di attività post attacco eseguite dall’hacker ed i relativi metodi per individuarne la presenza. Pagina 137 di 334

2.5.2

Attività 1: manomissione dei log file Per garantirsi un anonimato più o meno assoluto la prima attività che un hacker compie consiste nel manomettere i log files della macchina vittima, in modo da nascondere le tracce del suo aggio. I log che richiamano un'attenzione maggiore da parte degli intrusi riguardano gli accessi effettuati e gli eventi di sistema. Oltre a questi citati, altri log che vengono spesso alterati sono relativi al traffico di rete e ai processi schedulati. Ad esempio, per ambienti *nix, si fa menzione di lastlog, faillog, syslog, cronlog ecc.

2.5.2.1

I Log Analyzers

Esistono ottimi tools, chiamati Log Analyzer, che effettuano un controllo, anche real time, dei log di sistema. Tali tools sono programmi che monitorano le entry nei file di log di sistema e possono essere configurati per eseguire date operazioni in presenza di determinate righe di log. E' bene che agiscano in tempo reale, dal momento che, dopo un’intrusione una delle prime occupazioni di un hacker è, come già detto, quella di cancellare le tracce eventualmente lasciate. In questa categoria possono rientrare software noti come: Swatch - http://swatch.sourceforge.net/ - Può monitorare in tempo reale ogni tipo di file. E' in Perl e richiede alcuni moduli generalmente non installati di default e scaricabili da AN (http://www.an.org). Nei file di configurazione si settano le regole di pattern matching dei log e i comportanti da adottare. Swatch, quindi, è un filtro molto raffinato, che può essere configurato in maniera molto precisa per estrarre, dalla miriade di messaggi presenti nei file di log, solo quelli che veramente possono indicare la presenza di un problema nella sicurezza di un sistema o di un'intera LAN nella quale i log di tutte le macchine possono venire spediti ad un computer sicuro sul quale viene effettuata la verifica. Logsurfer - http://www.cert.dfn.de/eng/logsurf/ - Ha caratteristiche simili a Swatch ma presenta alcuni miglioramenti, tra cui la possibilità di correlare gli output di diversi log e, al contempo, propone un file di configurazione più complesso. LogWatch - http://www.logwatch.org/ - Installato di default su alcune distro Linux come RedHat, monitora diversi tipi di log secondo impostazioni configurabili e genera i relativi alert e report. E' uno degli strumenti di log monitoring più interessanti fra quelli disponibili nel panorama opensource: •

è molto semplice, versatile e flessibile in quanto permette di impostare il servizio che si vuole monitorare, il livello di monitoraggio, filtri customizzabili per il matching di pattern, periodi di tempo specifici ecc...;

•

si installa facilmente e su alcune distribuzioni è operativo ed efficace senza alcuna necessità di configurazione post-installazione.

La sua modalità di funzionamento non è in real-time, ma si presta ad essere schedulato in crontab: una volta avviata l’esecuzione processa i log e invia una mail di report all’amministratore. Se un intruso riuscisse a modificare i log e cancellare le sue tracce, LogWatch non riporterebbe tali azioni, ma riesce ad identificare eventi anomali del sistema. I file e le directory principali di Logwatch sono generalmente: Pagina 138 di 334

/etc/log.d/conf/logwatch.conf: file di configurazione di logwatch; /etc/log.d/conf/services/: directory che contiene i file di configurazione per i diversi servizi i cui log possono essere processati da logwatch; /etc/log.d/conf/logfiles/: directory che contiene i file di configurazione per i file contenenti i log di diversi servizi; /etc/log.d/scripts/shared/: directory che contiene i filtri comuni per i servizi o logfiles; /etc/log.d/scripts/logfiles/: directory che contiene i filtri specifici per logfiles particolari; /etc/log.d/scripts/services/: directory che contiene i filtri attuali per i vari servizi. 2.5.2.2

Come rendere sicura l’attività di logging

A prescindere dal meccanismo di controllo dei log utilizzato, alcuni accorgimenti rendono l'operazione più efficace: •

memorizzare i file di log, se possibile, su una macchina della rete locale con indirizzo privato e non connessa verso l’esterno, in modo tale da impedire eventuali manipolazioni dei log;

•

NON eseguire i programmi di log check come utente amministratore: eventuali stringhe maligne nei log potrebbero generare risultati incontrollabili;

•

allo stesso modo, non visualizzare i log da un terminale potenzialmente sensibile ad un "terminal emulator attack" (per dettagli: http://www.digitaldefense.net/labs/papers/Termulation.txt)

2.5.3

Attività 2: garantirsi accessi futuri Come già detto, dopo aver ottenuto l’accesso ad una macchina, un hacker cerca di garantirsi la possibilità di potervi accedere in futuro. L’intruso consegue l’obiettivo installando dei rootkits, programmi che gli consentono di nascondere la sua presenza e alterano il sistema in modo da poter operare sulla macchina nel modo più trasparente possibile agli occhi dell’amministratore. L’hacker ottiene questo risultato anche attivando particolari servizi o aprendo porte ad insaputa dell’amministratore, modificando particolari file di configurazione (es: inetd.conf ).

2.5.3.1

Installazione di Rootkits

I rootkits sono tool o collezioni di tool con lo scopo di fornire all’intruso gli strumenti per mantenere il pieno controllo dell’host compromesso senza essere individuato. Generalmente un rootkit comprende: •

un network sniffer, per registrare e utilizzate sulla o dalla macchina violata, in modo da estendere il raggio d'azione dell'intruso e la qualità e quantità di informazioni in suo possesso;

•

un keystroke logger, che registra quanto digitato dall'utente direttamente in console;

•

degli script che cancellano automaticamente le tracce dell'intrusione dai log di sistema;

•

versioni modificate (trojaned) di comandi di sistema comunemente utilizzati che possono rivelare l'esistenza del rootkit: ls, netstat, ifconfig, ps, killall, find, top; Pagina 139 di 334

•

una backdoor che accetta connessioni remote sia appoggiandosi ad una porta locale (nascosta dal netstat modificato) che modificando le versioni sul sistema di server telnet, ssh o analoghi.

Alcune utility di sistema che potrebbero essere state modificate per nascondere la presenza dell’intruso sono: •

chsh, wd e : permetto di diventare root;

•

du, find, ls: nascondono alcuni file e directory dell’intruso;

•

ifconfig: non mostra il flag PROMISC attivato dallo sniffer;

•

netstat: non mostra le porte aggiuntive aperte dal rootkit;

•

ps, top: nasconde i programmi e i processi del rootkit;

•

td, syslogd: i servizi di logging non loggano l’attività dell’intruso;

•

killall: non interrompe i processi dell’intruso;

•

crontab: non mostra i processi schedulati dal rootkit.

2.5.3.2

Controllo file system

Al fine di rilevare la presenza dell’intruso è molto importante controllare il file system della macchina ed in particolare: •

file setuid e setgid in directory utente;

• file in /dev in quanto alcuni rootkit hanno file di configurazione in /dev/pty* e perché spesso i bot irc si trovano in /dev/…; •

.rhosts – hosts.equiv - .shots – ecc… prestando particolare attenzione ai + e ai #;

•

. - . - .prfile - .cshrc - .forward facendo attenzione a eventuali comandi “strani”;

• file in /etc/wd controllando se esistono nuovi , se di sistema non sono disabilitati come invece dovrebbero essere, se sono presenti con uid/gid errati e/o 0 ed infine se vi sono vecchi con nuove ; • inetd.conf per verificare che non siano attivati servizi non richiesti, anche se apparentemente innocui; • file di startup ( rc.local – sh. – ecc..) per verificare che non sia stato cambiato il PATH (magari aggiungendo “.”); • i file modificati di recente, ad esempio modificati da non meno di un giorno, ma non da più di due. Un ulteriore strumento per verificare la presenza di rootkit consiste nell’utilizzare strumenti di cui l’hacker non ne immagina la presenza che permettono di rilevare eventuali anomalie nel traffico di rete. Per raggiungere questo scopo è possibile utilizzare argus,

Pagina 140 di 334

netstat - lsof per vedere che connessioni sono attive,

ntop per avvistare se il traffico in rete è elevato, uno sniffer come tdump o ethereal, nmap per analizzare su che porte siamo in ascolto, ed infine

Pagina 141 di 334

rpc per vedere se sono stati aggiunti servizi.

Una volta installato, un buon rootkit è, per natura, difficile da individuare proprio perché tende a nascondere le tracce della propria esistenza. Esistono tuttavia diversi metodi per individuarne la presenza che possono essere più o meno efficaci a seconda della natura del rootkit: •

verificare se il numero dei processi e i relativi PID che si visualizzano con ps è diverso da quello che si vede in /proc. Questa procedura, relativamente veloce, non funziona con rootkit basati su un modulo del kernel;

•

verificare con un port scanning da una macchina esterna, se sul sistema indagato sono aperte porte che non dovrebbero essere aperte e non vengono visualizzate con un netstat locale. Questo sistema non funziona con rootkit che modificano demoni esistenti come telnetd o sshd e tramite loro (e quindi tramite le rispettive porte) permettono accessi remoti non autorizzati; Pagina 142 di 334

•

indagare sempre quando un server si riavvia o si blocca senza apparente motivo o un servizio cade o comunque si riscontrano anomalie nel suo funzionamento: possono essere tutti indici di DOS attack o tentativi di intrusione o tentativi di installazione di un rootkit;

•

eseguire comandi come ls, ps, find da una fonte sicura (CDROM, NFS in read mode ecc.) e verificare se il loro output dà risultati diversi dai rispettivi comandi di sistema. Questo metodo non funziona con rootkit kernel based.

•

verificare in /dev se esistono nomi di device sospetti, in particolare device pty senza numeri successivi (es: /dev/ptyr);

•

verificare negli script di startup del sistema se vengono lanciati comandi non noti: ogni rootkit deve garantirsi l'esecuzione in memoria al riavvio;

•

monitorare la banda utilizzata da ogni singolo server (MRTG è lo strumento ideale) e indagare quando si notano picchi di traffico anomali: non di rado una macchina compromessa viene utilizzata come repository di warez.

•

verificare su www.incidents.org se il proprio IP risulta nel database degli attackers: se lo è qualcuno sta usando la nostra macchina per lanciare attacchi altrove.

Il modo migliore per rilevare la presenza di rootkit, consiste nell’utilizzo di file integrity checkers. 2.5.3.3

File Integrity checkers

Tali tool, come già detto, aiutano ad individuare manipolazioni effettuate all’interno del sistema e generalmente registrano cambiamenti nella data di creazione o modifica di un file, alterazioni dei permessi, degli attributi o dello contenuto di file di configurazione, binari di comandi più o meno comuni, testi di log ecc.. In questa categoria possono rientrare software noti come: Tripwire - http://www.tripwire.org - E' uno dei primi, più evoluti e utilizzati sistemi di Integrity Check. Oltre alla versione OpenSource ne esistono complementi proprietari che facilitano l'integrazione e la centralizzazione dei dati da diversi sistemi remoti, rendendo più agevole il monitoraggio di molti host. Il suo lavoro è quello di verificare lo stato di determinati file rispetto ad uno stato di partenza (baseline). Una modifica non prevista di questo stato può essere indice della compromissione del sistema e della manipolazione non autorizzata di comandi, log o file di configurazione. Come punto di partenza Tripwire crea un database con all'interno una "fotografia" dei file del sistema in uno stato che iniziale che viene considerato sicuro. D'ora in poi Tripwire sarà in grado di controllare se ci sono state modifiche (nel contenuto, nella data di modifica, nei permessi, negli attributi...) o cancellazioni dei file presi in considerazione informe o l'amministratore di sistema attraverso un rapporto. Se le modifiche sono legittime, perché dovute a normale attività del sistema, l'amministratore può aggiornare la baseline del database di Tripwire inglobando il nuovo status, altrimenti se le modifiche non vengono ritenute valide l'amministratore può immediatamente verificare quali componenti sono stati alterati. Tripwire permette inoltre di crittare i suoi file di configurazione rendendoli modificabili solo attraverso l'inserimento di creata in fase di installazione. Sono richieste due :

Pagina 143 di 334

• •

la site , di carattere generale, utilizzata per il file di configurazione e policies; può essere utilizzata per altre macchine esportando il file site.key; la local per il file database e i report. In figura un diagramma di flusso che illustra il funzionamento di Tripwire

Figura 22: flusso di funzionamento di tripwire

Aide - http://www.cs.tut.fi/~rammer/aide.html - Si presenta come l'alternativa completamente free di Tripwire, ha una logica simile e prevede controlli della stessa natura tramite una varietà di

Pagina 144 di 334

algoritmi di checksum. Si tratta di uno strumento prezioso per scoprire gli utilizzi impropri del sistema. Il funzionamento di AIDE è controllato da un file di configurazione, che generalmente è bene non lasciare nel file system per motivi di sicurezza, inserendolo solo nel momento del bisogno. Nello stesso modo, anche il file contenente le informazioni accumulate riguardo allo stato del file system va protetto, preferibilmente togliendolo dal file system stesso, in modo da garantire che non possa essere letto e alterato. La configurazione di AIDE è simile a quella di Tripwire, con l'aggiunta di direttive nuove. In generale, a parte i commenti che si indicano preceduti dal simbolo # e le righe che non contengono direttive, si distinguono tre gruppi: •

direttive di configurazione, con le quali si stabiliscono delle modalità di funzionamento generali;

•

direttive di selezione, con le quali si stabiliscono quali file e directory tenere sotto controllo;

•

macroistruzioni che servono per scandire il file di configurazione in modo differente in base a condizioni determinate, come fa un preprocessore di un linguaggio di programmazione.

Integrit - http://integrit.sourceforge.net/ - Altra promettente e performante alternativa a Tripwire che si presta ad essere integrata in un sistema di monitoring che utilizza diversi strumenti. Chkrootkit - http://www.chkrootkit.org - Sono una serie di script dedicati alla individuazione di rootkit noti. Oltre a controllare lo stato di alcuni binari esegue controlli di altra natura (verifica sul proc filesystem ecc). Una caratteristica comune di questi e altri Integrity Checkers è quella di creare una snapshot preliminare dello stato dei file di un host "pulito", adattare la configurazione per il proprio specifico sistema, eliminare controlli che producono eccessivi false-positive (troppi warning tendono ad essere ignorati) e schedulare periodicamente un check dello stato attuale del sistema rispetto allo snapshot iniziale. In tutti i casi ci sono alcune procedure di base che è giusto seguire per migliorare la sicurezza e l'affidabilità di simili strumenti: •

copiare i database di snapshot su un sistema remoto o comunque un mezzo non scrivibile dall'host a cui si riferiscono;

•

considerare che un checksum non è infallibile ed esistono metodi per mantenere lo stesso checksum in un file;

•

controllare effettivamente i log generati e rifinire gradualmente la configurazione per evitare segnalazioni errate, falsi positivi, per file che vengono modificati a causa di normali attività sul sistema.

Oltre all’utilizzo di questi tool ad hoc, esistono delle possibili contromisure all’installazione di rootkit da parte dell’intruso quali: •

una gestione rigorosa della configurazione e delle patch;

•

proteggere i sistemi dalle vulnerabilità più utilizzate;

Pagina 145 di 334

•

utilizzo di moduli linkati dinamicamente solo se necessario (host critici dovrebbero avere il kernel linkato staticamente) ed infine

•

protezione perimetrale rigorosa per prevenire intrusioni.

2.5.4

Attività 3: installazione trojan e backdoors Una volta entrati in un sistema, gli hacker vogliono garantirsi la possibilità ad accedervi successivamente nel modo più veloce e più trasparente possibile agli occhi dell'amministratore della rete. Per tale scopo vengono utilizzate delle backdoors o dei trojan. I trojan sono malicious program nascosti in applicazioni regolari che possono agire ben diversamente a danno dello stesso utente. Per esempio, all’interno di un programma qualsiasi si potrebbe nascondere un tool dell’attaccante che mira a nascondere all’amministratore alcune connessioni attive, oppure che cattura informazioni del sistema per poi inviarle all’attaccante stesso. Tali tool potrebbero essere configurati in modo tale che, dopo un certo periodo di attività, si disinstallano automaticamente. In questo modo, l’intruso ha la possibilità di ottenere informazioni importanti e nascondere la sua presenza, diminuendo la possibilità di essere scoperto. La parola backdoor significa letteralmente "porta sul retro" o "porta di servizio". La descrizione indica bene lo scopo di questi programmi: fungono da porta secondaria di accesso al proprio sistema, porta che può essere sfruttata da qualsiasi utente remoto che ne conosca il funzionamento. Una backdoor non ha una forma ben definita: può essere sia un programma comune che la ingloba (ma non un virus), oppure può essere agganciata ad un virus che la installa e la propaga. Gli effetti di tali “programmi” sono principalmente due: • l'hacker remoto può introdursi nel sistema ospite della backdoor e compiere svariate azioni: prelevamento di files, cancellazioni, modifiche al sistema, impedire l'utilizzo della tastiera, oscurare lo schermo, eseguire più azioni di quante non ne possa fare l'utente locale! • le backdoor più evolute permettono di accedere alle di sistema, di comunicare ogni sequenza di tasti premuti dalla vittima sia mentre è connesso ad Internet che quando non lo è. In quest'ultimo caso le informazioni raccolte saranno spedite all'hacker remoto, non appena la vittima si connette ad Internet. I sistemi che rilevano la presenza di trojan o backdoors sono denominati IDS (Intrusion Detection System).

2.5.4.1

IDS: Intrusion Detection System

I sistemi di intrusion detection (IDS) sono ati, in poco tempo, dall’essere strumenti di uso esclusivo nei laboratori di ricerca e università all’essere considerati uno dei pilastri della cybersecurity moderna. L’uso degli IDS è stato considerato fino ad ora molto importante perché forniscono informazioni sul tipo di attacco avvenuto, numero di attacchi subiti e tentati, frequenza degli attacchi e provenienza degli stessi. Aiutano quindi a capire quali sono le necessarie contromisure preventive per il futuro. L’uso di un IDS permette anche di scoraggiare l’hacker medio che comprenderà che l’azienda è ben protetta. Pagina 146 di 334

Esistono diverse tipologie di IDS: NIDS (Network-based IDS), HIDS (Host-based IDS) e AIDS (Application-based IDS). I primi sono installati su un apparato dedicato (computer o appliance chiamato sensore IDS) e monitorano l'intera sottorete da attacchi di rete contro delle macchine connesse. Per farlo usano un database di signature di attacco ed una serie di algoritmi per rilevare delle anomalie sul traffico di rete. Il compito di gestire gli alert e l'analisi dei pacchetti possono essere effettuati su macchine separate, che raccolgono le informazioni da diversi sensori. Gli IDS hanno distinti vantaggi e svantaggi sia dal punto di vista della tecnologia che da quello della gestione. I NIDS usano praticamente uno sniffer che raccoglie tutto il traffico di rete che a nel cavo, fa are i pacchetti raccolti in un motore di analisi e agisce di conseguenza in base alle politiche scelte dall’amministratore (registrando i pacchetti, avvisando gli esperti di security o iniziando alcune contromisure come terminare la connessione e modificare dinamicamente le regole del firewall). Un motore di analisi guarda in ogni singolo pacchetto i flag di protocollo, gli indirizzi sorgente e destinazione e la parte di dati del protocollo applicativo. Le analisi possono essere applicate all'intera connessione T piuttosto che ad un singolo pacchetto o includere una correlazione della connessione con altre avvenute in precedenza in altri o nello stesso punto della rete. La signature di attacco, normalmente rilasciata dal fornitore o sviluppata in casa, consiste in stringhe o in parametri del pacchetto di rete. I vantaggi dei NIDS includono: •

la possibilità di proteggere l’intera rete con una singola macchina IDS in modo trasparente alle altre;

•

la possibilità di ottenere in maniera semplice elevati livelli di sicurezza, addirittura nascondendo all’esterno la presenza dell'IDS;

•

la semplicità di aggiornare le signature.

Sembra che i network IDS basati su signature siano il modello di intrusion detection più diffuso ma il semplice rilevamento di attacchi basato su signature può essere estremamente ingannevole ed in certe circostanze risultare inefficace e controproducente. I NIDS, come detto, consistono in una serie di sensori collocati all’interno della rete da monitorare. Un’architettura del genere provoca i seguenti difetti: •

se la rete è ad alta velocità è difficile, per i sensori, non perdere nemmeno un pacchetto;

•

se la rete è composta da commutatori (switch) il NIDS non può catturare i pacchetti;

•

possono solo dire se un attacco è iniziato o è in corso, non se è riuscito.

Gli HIDS controllano il traffico da e verso un particolare host ed alcuni eventi di sistema. Sono installati sui server critici dove si rende necessario un controllo dettagliato su tutto ciò che accade. Alcuni sistemi utilizzano un'analisi euristica delle signature, controllano le attività dell'utente avvisando gli amministratori di eventuali usi impropri delle risorse. I maggiori vantaggi di tale strumento riguardano il fatto che possono rilevare anomalie che possono sfuggire ai NIDS ed inoltre non sono penalizzati da una rete di commutatori. I problemi che nascono dal loro uso derivano, invece, da una maggiore difficoltà nella loro gestione, rispetto ai NIDS, ed al fatto che il sensore risiede sull’host, e se questo viene attaccato il sensore può Pagina 147 di 334

essere disattivato o manipolato. Inoltre non possono rilevare le scansioni di rete perché hanno una visione limitata al singolo host. Gli AIDS, più sofisticati, rilevano il comportamento sospetto di un utente che tenta di abusare delle sue autorizzazioni ed analizzano gli eventi generati da una singola applicazione software (log degli applicativi). Tale “dispositivo” permette di risalire al singolo comando del singolo utente. Lo svantaggio principale è che i log dell’applicativo sono meno protetti di quelli di sistema. Di seguito definiamo un breve elenco degli IDS più utilizzati: Snort - http://www.snort.org - E' il progetto NIDS più noto nella comunità OpenSource. Seppur di non banale gestione e con un sistema di reporting piuttosto grezzo, viene utilizzato come base da molti altri prodotti che ne estendono le funzionalità migliore o la gestione e i meccanismi di reporting. Le policy di packet matching sono costantemente aggiornate sulla base di nuove vulnerabilità. Snort, quindi, è uno dei numerosi strumenti di rilevazione del traffico di rete per individuare e segnalare intrusioni. E’ stato progettato per funzionare in 3 modi differenti: •

Sniffer - intercetta i pacchetti che viaggiano nella rete e li visualizza in console;

•

Packet Logger - può anche effettuare il log dei pacchetti su linea di comando indirizzati ad una specifica locazione, in un syslog, ed invia alert a video. Uno dei migliori vantaggi è che esso effettua il formato leggibile decodificato in una directory basata su IP sorgenti. Esegue anche il log di pacchetti in formato binario su un singolo file;

•

Network Intrusion Detection - può essere usato come NIDS su reti dove sono richieste alte prestazioni. Precisamente può essere posizionato tra il firewall, che controlla una sottorete, e la linea esterna non sicura, analizzando in questo modo sia il traffico diretto al firewall, che il traffico nella sottorete controllata. Ha un piccolo sistema di firme ed è disegnato per essere un tool veloce di alerting per gli amministratori quando sono individuate attività sospette. In tale modalità snort non salva tutti i pacchetti, ma li analizza in base ad una serie di regole che si trovano nel file snort.conf.

Snort è un ottimo strumento che permette all’amministratore di sviluppare, in modo molto semplice e molto veloce, nuove regole. La sua installazione è breve e semplice ed ha una struttura modulare che permette di estenderne il funzionamento tramite numerosi plugin. E’ inoltre possibile utilizzarlo in reti eterogenee, dato che può inviare allarmi a workstation Windows attraverso Samba. Purtroppo non tratta bene la deframmentazione IP e non è implementata una gestione per livelli degli alert. Inoltre soffre di tutti i difetti comuni agli IDS basati sul pattern matching. Tamandua - http://tamandua.axur.org/ - E' un progetto relativamente poco conosciuto ma interessante: è possibile convertire le regole scritte per Snort sul database di Tamandua e sono previste tutte le features tipiche di un NIDS. Prelude - http://www.prelude-ids.org/ - E' un interessante ibrido fra un NIDS e un HIDS, che presenta sia sensori per il traffico di rete che sensori per il singolo host. Vanta prestazioni superiori a SNORT e una buona modularità.

Pagina 148 di 334

3.

Evidence Gathering

3.1

Raccolta delle informazioni utili relative ad un’intrusione

Tutte le informazioni riguardanti i sistemi compromessi e alle cause di un’intrusione devono essere raccolte e conservate in modo sicuro. Queste informazioni includono: • File di log relativi al sistema e alla rete21; • Messaggi di traffico della rete; • File utente; • Risultati prodotti da tool di intrusion detection; • Analisi dei risultati; • Log e note della console dell’amministratore; • Registrazioni di backup che mostrano la situazione sia prima che dopo l’attacco. Tutte queste informazioni devono essere collezionate, contrassegnate, catalogate e conservate con riguardo in ogni momento dell’analisi dell’intrusione. 3.1.1

Perché è importante

Se non si collezionano e proteggono tutte queste informazioni, non si sarà in grado di raccogliere le informazioni necessarie per eventuali follow up in aula giudiziaria, imparare dall’esperienza e quindi di migliorare le condizioni di sicurezza del sistema, le operazioni svolte e le potenzialità dello staff. Sarebbe inoltre difficile interagire in modo efficace con altri CSIRTs. Nel caso di intrusione generata dall’interno, non si sarebbe in grado di prendere i giusti provvedimenti per educare, ravvedere o licenziare il responsabile22. Se poi si ha l’intenzione di perseguire l’intruso a mezzo di denuncia presso la competente Autorità Giudiziaria, nasce la necessità di avere degli evidence completi, sicuri e mantenuti in modo chiaro e corretto attraverso una corretta procedura di chain-of-custody che tenga traccia di chi è stato coinvolto nel mantenimento delle prove e in quali luoghi esse siano state conservate. In caso contrario, le informazioni collezionate potrebbero non essere considerate valide in sede legale. I consigli degli ufficiali delle forze dell’ordine e dei legali sono utili per comprendere come meglio collezionare e proteggere informazioni critiche. 3.1.2

Collezionare tutte le informazioni concernenti l'intrusione

Fondamentalmente bisogna prefissarsi i seguenti obiettivi di massima: 21

Comprensivi di eventuali informazioni di correlazione. Si rammenta che eventuali procedimenti disciplinari devono essere giustificati e devono avere a monte delle politiche di sicurezza. Si consiglia di contattare un consulente legale.

22

Pagina 149 di 334

1. Raccogliere le informazioni ricavate dai log dei sistemi e delle reti degli ambienti compromessi, dai sistemi di intrusion detection, dai firewall, dai router e dagli altri strumenti. 2. Raccogliere i backup completi e parziali, documentare le schermate dei sistemi con screen-shot, videoregistrazioni e fotografie. 3. Documentare in forma cartacea le risposte alle domande: chi, che cosa, dove, quando, come e perché. Le informazioni di cui al punto 3 includeranno: • Nome del sistema; • Data e ora di ogni entry; • Quale operazione è stata effettuata; • Cosa è stato detto; • Cosa è stato notificato; • Chi ha avuto accesso; • Quali dati sono stati raccolti; • Quali informazioni sono state distribuite, a chi, da chi, quando e per quale motivo; • Cosa è stato comunicato all’ufficio legale, a chi, da chi e com’è stato verificato. Dette note potranno essere acquisite agli atti nell’eventualità di un procedimento da parte dell’Autorità Giudiziaria per la determinazione delle responsabilità. Assicurarsi di preparare un diverso fascicolo per ogni intrusione. 3.1.3

Analizzare tutte le informazioni a disposizione per caratterizzare un’intrusione

Una volta che si è stati allertati dal proprio sistema di intrusion detection o da un altro sito fidato in cui è stata individuata un’intrusione, occorre determinare l’estensione del danno e rispondere all’intrusione stessa. Le informazioni collezionate e interpretate attraverso la fase di analisi sono fondamentali per prendere decisioni e agire mediante il processo di risposta. L’obiettivo dell’analisi è di comprendere: • • •

Quale tipo di attacco è stato utilizzato per ottenere l’accesso; Quali parti del sistema e quali dati sono stati acceduti dall’intruso; Quali azioni sono state compiute dall’intruso a seguito dell’accesso.

Durante l’analisi, si può essere tentati di collezionare attivamente informazioni circa i metodi utilizzati dall’intruso per attaccare il sistema. Questi tentativi possono allertare l’intruso il quale, resosi conto di una risposta in atto o, peggio ancora, preso dal panico, potrebbe iniziare a cancellare ogni sua possibile traccia danneggiando così ulteriormente il sistema; oppure, potrebbe non accedere più al sistema stesso impedendoci così di collezionare informazioni aggiuntive. Nel caso poi in cui il sistema attaccante

Pagina 150 di 334

appartenga ad un’altra azienda, tali tentativi possono addirittura essere intesi come un’attività intrusiva23. Per queste ragioni, l’importanza di collezionare più informazioni possibili deve essere bilanciata contro i possibili rischi appena descritti. Di seguito saranno utilizzati i vari step utili per portare a termine quest’attività. • Catturare e registrare le informazioni del sistema che potrebbero essere state perse o non durante l’esecuzione delle procedure di backup Questo include: Tutte le connessioni di rete correnti; Tutti i processi correnti; Tutti gli utenti attivi loggati; Tutti i file aperti (i file possono essere cancellati se un processo termina quando la rete è disconnessa); Tutti gli altri dati volatili che potrebbero andare persi come la memoria o la cache. • Fare un backup del sistema compromesso E’ opportuno fare almeno 2 backup completi del sistema o dei sistemi che sono stati identificati come compromessi, così come dei dati degli utenti di quei sistemi. Per compiere questa operazione è opportuno utilizzare hardware-write-protectable e/o write-once media. Nel caso specifico, inoltre, è possibile utilizzare uno o più Hard Disk Preservare i backup in un posto sicuro. Potrebbero essere reinstallati su altri sistemi di test per analisi aggiuntive e i dati in essi contenuti potrebbero essere utilizzati per il recovery del sistema. Per proteggere i backup come fonte di prova è opportuno tenerne almeno una copia in una locazione sicura e mantenere una chain of custody. Questa copia non dovrà essere utilizzata per eseguire i controlli.24 Questo tipo di approccio permette di preservare più accuratamente le fonti di prova originali, anche se potrebbe allertare l’intruso; richiede inoltre delle significative risorse hardware. Nel pianificare le procedure occorre tenere presente che: Un utilizzo intenso ma sporadico del disco, come avviene quando si effettua un backup, potrebbe allertare l’intruso; Un intruso potrebbe avere installato un Trojan che cancella i file di log. Un esempio ricorrente è che il programma di backup del sistema può essere modificato in modo tale che se durante l’esecuzione non riesce a pingare un router, il disco su cui sta lavorando viene distrutto. Dunque, se il sistema in oggetto viene disconnesso dalla rete e si tenta di effettuarne il backup, tutti i file di log potrebbero essere irrimediabilmente persi. •

Isolare il sistema compromesso Questo punto può essere soddisfatto attraverso: Il trasferimento dei file di backup su un sistema di test isolato rispetto al resto del sistema compromesso e il ripristino del sistema compromesso sul sistema di test. Un ottimo tool di basso livello per il trasferimento remoto dei file, disponibile sia per Linux che per Windows, è NetCat (www.netcat.it), che consente di scrivere e leggere sulle reti utilizzando i protocolli T e UDP. Per i trasferimenti di file da e verso il

23

si tenga comunque conto che, in caso di attacchi di un certo “spessore tecnico” l’attività di obfuscation propriamente detta, rientra nelle operazioni di routine effettuate dall’intruder. 24 Si ribadisce che non è assolutamente indicato lavorare sull’originale. Si lavora sulle copie dei dischi presenti sulla macchina compromessa.

Pagina 151 di 334

server, l'IP e la porta specificati devono essere in ascolto prima di inviare il comando, altrimenti questo fallisce. I file possono essere trasferiti dal server usando il comando “T file send” e NetCat con una sintassi simile a questa: netcat -l -p 666 > file Allo stesso modo, i file possono essere trasferiti al server usando il comando “T file receive” e NetCat con una sintassi simile a questa: netcat -l -p 666 < file La disconnessione del sistema compromesso e l’analisi diretta su questo sistema, tenendo presente che questo tipo di attività compromette le sorgenti originali di informazione. • Cercare i segnali dell’intrusione su altri sistemi Gli intrusi, una volta ottenuto l’accesso iniziale attivano spesso più punti di collegamento alla rete. Qualora un attacco o intrusione sia rilevata, sarà necessario controllare tutti i sistemi “simili” al sistema violato. "Simili" può essere interpretato diversamente a seconda del contesto operativo: Sistemi che sono nello stesso range di indirizzi IP o che si trovano sul medesimo segmento di rete. Gli intrusi effettuano scansioni su ampi range di indirizzi IP al fine di scoprire le vulnerabilità di sistema; Sistemi che si trovano nello stesso “trusted domain”. Questi sistemi garantiscono l’accesso agli utenti da altri sistemi all’interno dello stesso dominio senza alcuna ulteriore autenticazione; Sistemi che hanno almeno un servizio di rete comune. Gli attacker effettuano spesso scansioni alla ricerca di servizi well-known, come DNS, FTP, HTTP e SMTP; Sistemi che hanno il medesimo sistema operativo; Sistemi che condividono lo stesso file system fornendo spazio disco ai sistemi compromessi o usando spazio disco dai sistemi compromessi. 3.1.4

Esaminare i log generati da firewall, network monitor e router

Gli attacchi lasciano sovente tracce che possono ricondurre l’analista al sistema che è stato acceduto dall’intruso. Queste tracce includono file di log e audit, file lasciati nel sistema dall’intruso o informazioni relative all’uso di server e servizi presenti su altri sistemi e usati per spostarsi attraverso la rete. Queste informazioni possono essere usate per cercare altri eventi o connessioni originate da un sistema che prima non era stato considerato. In questo modo, risulta possibile identificare gli altri sistemi ai quali l’intruso ha guadagnato l’accesso. I log di firewall, network monitor e router rimangono spesso intatti (quando è stato deciso, a priori, di generarli) e possono contenere informazioni preziose anche se l’attacker acquisisce soltanto l’accesso in locale, guadagna i privilegi di amministratore e cancella i log presenti sul sistema al fine di rimuovere le informazioni sul tipo di attacco utilizzato e sull’intrusione stessa. Questi programmi e dispositivi, se opportunamente configurati, possono registrare le connessioni e il traffico di messaggi generato dall’attacker. I log così prodotti possono rilevare l’attività dell’intruso. Con le informazioni raccolte attraverso le modalità sopra descritte, è possibile localizzare record collegati nei log che rivelano un maggior numero di dettagli riguardo un’intrusione o un dato mancante. È buona norma perciò cercare connessioni “simili”, comprese quelle provenienti dalla stessa sorgente o dirette verso la stessa destinazione. Pagina 152 di 334

Costruire un quadro completo della situazione post-attacco può rivelarsi un compito assai tedioso. I formati dei log di molti sistemi non sono compatibili e non esiste nessun tool generico che ordini cronologicamente i log prodotti da più sistemi. Tuttavia, esistono tool di monitoraggio che collezionano informazioni da più sistemi e ne integrano i log prodotti. Per di più, la “timing source” e la “time zone” potrebbe differire da sistema a sistema. I protocolli come NTP (Network Time Protocol) possono essere utilizzati per sincronizzare data e ora su tutti i sistemi.25 3.1.5

Identificare gli attacchi portati per guadagnare l’accesso al sistema compromesso

È necessario cercare nei log locali dei sistemi compromessi informazioni che rivelino il tipo attacco portato dall’intruso oltre che nei log prodotti da firewall, router e network monitor. Solitamente, gli intrusi tentano diversi tipi di attacco o vanno alla ricerca di una particolare vulnerabilità prima di acquisire l’accesso. A seconda di com’è configurato il vostro sistema, i log di rete e di sistema potrebbero contenere: •

Messaggi di “denied access” se l’attacker tenta di indovinare la (sono utili anche eventuali messaggi di errore;

•

Messaggi riferiti a vecchie vulnerabilità (es. il comando “wiz” nel sendmail di Unix);

•

Messaggi di accesso negato a servizi specifici monitorati da tool quali T Wrapper.

È anche possibile trovare data, ora e sorgente nei file di log; queste informazioni possono essere di grande utilità. Dopo aver guadagnato l’accesso, l’intruso potrebbe voler cancellare tutti i log o singole entry. Per questo motivo, è possibile che non vengano trovate informazioni di interesse. In alcuni casi la cancellazione di log entry è rilevabile. In questo caso ci verrà notificato un evento sospetto e sarà possibile effettuare un’analisi più approfondita. 3.1.6

Identificare le operazioni effettuate dall’intruso durante l’accesso al sistema

È importante capire come un attacker sia riuscito a guadagnare l’accesso al sistema. Questa conoscenza però non sarà sufficiente per risalire alle operazioni effettuate dall’intruso una volta entrato nel sistema. Senza informazioni aggiuntive, non sarà possibile quantificare la quantità di dati compromessi e quindi il danno subito. Su molti sistemi sono facilmente individuabili i tentativi di modifica di file, ma purtroppo per gli accessi in lettura non vale altrettanto; questo a causa del numero elevato di file letti durante una sessione, che rende impraticabile qualunque attività di logging. Senza ulteriori informazioni, occorre considerare che, una volta che gli intrusi hanno guadagnato l’accesso, potranno ottenere qualunque dato e accedere a servizi o programmi del sistema compromesso. Al momento della quantificazione del danno bisogna quindi ipotizzare il caso peggiore. Per identificare un intruso, è possibile: •

Analizzare diversi file di log;

•

Confrontare i checksum dei file conosciuti e fidati con quelli della macchina compromessa;

25

Si rammenta, inoltre, di documentare, a priori, la time zone sulla quale il sistema di logging viene regolato. Questa operazione è assolutamente fondamentale soprattutto quando si lavora in ambienti transnazionali.

Pagina 153 di 334

•

Utilizzare tool di intrusion detection e analysis.

Avere un checksum fidato con il quale poter fare dei confronti è particolarmente importante per scoprire se un intruso ha apportato modifiche al kernel del sistema operativo. Esempi di tracce che gli intrusi possono aver lasciato sono: •

Modifiche ai log file per nascondere la loro presenza;

•

Azioni compiute per modificare una utility di sistema per fare in modo che non elenchi i processi avviati dall’attacker;

•

Trojan, backdoor o nuove versioni dei comandi di sistema.

3.1.7

Proteggere la chain of custody per ogni fonte di prova

Questo punto è soddisfatto disponendo di una documentazione verificabile che indichi la sequenza di soggetti che hanno avuto a che fare con una o più prove e la sequenza di luoghi in cui è stata custodita. Tra questo informazioni è bene includere anche la data e l’ora del aggio. Per una chain of custody corretta è necessario: • Tener traccia di ogni prova; • Documentare in modo completo il aggio di consegne da una persona a un’altra; • Documentare in modo completo il aggio da una locazione a un’altra. Nel caso in cui la propria organizzazione abbia delle policy nell’ambito del mantenimento della CoC, è bene accertarsi che le proprie azioni avvengano nel rispetto di tali regole. La documentazione di IRItaly contiene, tra l’altro, anche i documenti di gestione della CoC. 3.1.8

Contattare le forze dell’ordine

Nel caso in cui si decida di perseguire l’intruso è bene contattare immediatamente le forze dell’ordine. Solitamente, a seguito di un’intrusione, si decide di spegnere e disconnettere il sistema compromesso. Se si decide di mantenere il proprio sistema funzionante e on-line per collezionare più informazioni riguardanti l’intruso e l’intrusione, è bene tener presente che il proprio sistema potrebbe essere o essere stato utilizzato come punto di partenza (stepping stone) per attaccare un altro sito. In questo caso, è essenziale contattare immediatamente le forze dell’ordine e prendere i provvedimenti suggeriti al fine di ridurre questa eventualità. Per quanto riguarda i dettagli operativi si rimanda agli appositi paragrafi del documento IRItaly. 3.1.9

Considerazioni sulle politiche aziendali

Le procedure di risposta relative alla sicurezza di una rete aziendale dovrebbero documentare i ruoli, le responsabilità, le autorità e le condizioni per l’esame di dati, sistemi e reti sospettate di essere state compromesse e per l’analisi dell’intrusione più in generale. Pagina 154 di 334

Le politiche aziendali dovrebbero indicare quali informazioni sono condivise con terze parti, sotto quali circostanze e chi ha l’autorità di iniziare la divulgazione delle informazioni al di là di quello che è specificato nelle politiche. Le procedure di risposta relative alla sicurezza di una rete aziendale dovrebbero anche assicurare il mantenimento di una CoC corretta e sicura. Un certo livello di rigore è necessario non solo nel caso in cui si decida di avviare un’investigazione legale con le forze dell’ordine; questo perché altre organizzazioni attaccate potrebbero decidere di prendere provvedimenti e richiedere le prove collezionate dalla propria azienda, se non addirittura avviare procedimenti legali contro la nostra azienda, ad esempio nel caso in cui la propria rete sia stata utilizzata come punto di partenza di un altro attacco. Ad ogni modo si rammenta che le politiche di sicurezza, anche quelle che riguardano il personale operativo IT, devono essere stabilite a priori, di concerto con il legal, e firmate per presa visione ed accettazione. Si tenga inoltre presente che le leggi sono differenti da Paese a Paese. È quindi opportuno determinare i requisiti legali (specialmente le leggi riguardanti la protezione e collezione di prove, CoC, la quantità sufficiente di prove per avviare le pratiche) richiesti dal Paese in cui si sta operando. In seguito si dovranno implementare le procedure necessarie per soddisfare tali requisiti. 3.1.10 Tool utili per la ricerca dei segnali di un’intrusione Segue un elenco di tool classificati in base alle funzioni, che permette di decidere se e quando possono essere di utilità nell’applicazione delle policy fissate e delle procedure di risposta a un’intrusione. È difficile definire una guida ai tool da utilizzare, in quanto la loro utilità varia a seconda delle specifiche condizioni aziendali e al momento non esiste uno scenario standardizzato nella gestione della sicurezza. È bene infine tenere presente che, per quanto riguarda alcuni software, è consigliabile una configurazione manuale per meglio venire incontro alle esigenze specifiche. Tool che riportano lo stato del sistema Esempi di tool che monitorizzano e ispezionano l’utilizzo delle risorse di sistema (es. modifiche al file system) e attività sospette (es. apertura di file insolita o sospetta, di amministratori, shutdown e restart inattesi, attività inusuale del modem, insolito o eccessivo numero di email) sono: •

watcher - ftp://ftp.cerias.purdue.edu/pub/tools/unix/sysutils/watcher/

•

klaxon - ftp://ftp.cerias.purdue.edu/pub/tools/unix/logutils/klaxon/

•

lsof (LiSt Open Files) - http://www.cert.org/securityimprovement/implementations/i042.05.html

•

nfswatch - ftp://ftp.cerias.purdue.edu/pub/tools/unix/netutils/nfswatch/

•

showid - ftp://ftp.cerias.purdue.edu/pub/tools/unix/sysutils/showid/ Pagina 155 di 334

•

log - ftp://ftp.cerias.purdue.edu/pub/tools/unix/logutils/log/

Esempi di intrusion detection system, che includono il monitoraggio attivo dei file di log, e che controllano possibili intrusioni o violazioni di accesso, sono: •

snort - http://www.snort.org/

•

asax (Advanced Security audit trail Analysis on uniX) ftp://ftp.cerias.purdue.edu/pub/tools/unix/sysutils/asax/

•

swatch - http://www.cert.org/security-improvement/implementations/i042.01.html

•

logsurfer - http://www.cert.org/security-improvement/implementations/i042.02.html

•

tklogger - ftp://ftp.eng.auburn.edu/pub/doug/tklogger

Tool che riportano le attività della rete Esempi di tool che monitorizzano e ispezionano il traffico di rete e le connessioni (es. che tipo di connessioni, da dove e quando), i tentativi di connessione falliti e le connessioni stabilite con successo, connessioni da/verso locazioni inusuali, prove non autorizzate sulla rete, sistematici port scan, traffico in opposizione alle regole del firewall e attività insolite di trasferimento dei file includono: •

t wrapper - http://www.cert.org/security-improvement/implementations/i041.07.html

•

tdump - http://www.cert.org/security-improvement/implementations/i042.13.html

•

argus - http://www.cert.org/security-improvement/implementations/i042.09.html

•

arpmon - ftp://ftp.cerias.purdue.edu/pub/tools/unix/netutils/arpmon/

•

arpwatch - ftp://ftp.cerias.purdue.edu/pub/tools/unix/netutils/arpwatch/

•

snort - http://www.snort.org/

•

courtney - ftp://ftp.cert.dfn.de/pub/tools/audit/courtney/

•

gabriel - ftp://ftp.cert.dfn.de/pub/tools/audit/gabriel/

•

logdaemon - http://www.cert.org/security-improvement/implementations/i041.11.html

•

rfingerd - ftp://ftp.cerias.purdue.edu/pub/tools/unix/daemons/rfingerd/

•

clog - ftp://ftp.cerias.purdue.edu/pub/tools/unix/logutils/clog/

•

pidentd - ftp://ftp.cert.dfn.de/pub/tools/audit/pidentd/

•

enhanced portmap/rpcbind - ftp://ftp.porcupine.org/pub/security/

Esempi di tool che verificano se l’interfaccia della propria scheda di rete è in modalità promiscua sono: •

ifstatus - ftp://ftp.cerias.purdue.edu/pub/tools/unix/sysutils/ifstatus/ Pagina 156 di 334

•

m (Check Promiscuous Mode) - ftp://ftp.cerias.purdue.edu/pub/tools/unix/sysutils/m/

Esempi di tool che controllano nuovi e non attesi servizi e verificano quelli disponibili sulla propria rete sono: •

nmap - http://www.insecure.org/nmap

•

fremont - ftp://ftp.cerias.purdue.edu/pub/tools/unix/netutils/fremont/

•

strobe - ftp://ftp.cerias.purdue.edu/pub/tools/unix/scanners/strobe/

•

satan (System Tool for Analyzing Networks) ftp://ftp.porcupine.org/pub/security/

•

saint (Security 's Integrated Network Tool) - http://www.wwdsi.com/saint

•

sara (Security Auditor's Research Assistant) - http://www.www-arc.com/sara/

Tool che riportano le attività degli utenti Esempi di tool che controllano la configurazione degli , come le informazioni sull’autenticazione e sull’autorizzazione, sono: •

cops (Computer Oracle and System) ftp://ftp.cerias.purdue.edu/pub/tools/unix/scanners/cops/

•

tiger - ftp://ftp.cerias.purdue.edu/pub/tools/unix/scanners/tiger/

•

checkXs http://www.rge.com/pub/security/coast/tools/unix/sysutils/checkXs/checkXs.gz

•

chkacct - ftp://ftp.cerias.purdue.edu/pub/tools/unix/sysutils/chkacct/

Esempi di tool che monitorizzano e ispezionano l’attività degli utenti, come l’attività di , tentativi ripetuti e falliti di , da postazioni insolite, in momenti insoliti, cambiamenti nell’identità degli utenti, tentativi di accesso ad informazioni ristrette, sono: •

noshell - ftp://ftp.cerias.purdue.edu/pub/tools/unix/

•

ttywatcher - ftp://ftp.cerias.purdue.edu/pub/tools/unix/sysutils/ttywatcher/

•

logdaemon - http://www.cert.org/security-improvement/implementations/i041.10.html

Tool che verificano l’integrità dei dati, dei file e dei software Esempi di tool che controllano il file system e la configurazione di altri programmi alla ricerca di possibili segnali della presenza di exploit sono: •

cops - ftp://ftp.cerias.purdue.edu/pub/tools/unix/scanners/cops/

•

tiger - ftp://ftp.cerias.purdue.edu/pub/tools/unix/scanners/tiger/ Pagina 157 di 334

•

secure-sun-check - ftp://ftp.cerias.purdue.edu/pub/tools/unix/sysutils/secure_sun/

Esempi di tool che individuano cambiamenti inattesi di file e cartelle e relative protezioni sono: •

tripwire - http://www.cert.org/security-improvement/implementations/i002.02.html

•

L5 - ftp://ftp.cerias.purdue.edu/pub/tools/unix/sysutils/l5/

•

hobgoblin - ftp://ftp.cerias.purdue.edu/pub/tools/unix/sysutils/hobgoblin/

•

RIACS Auditing Package (Research Institute for Advanced Computer Science) http://ciac.llnl.gov/ciac/ToolsUnixSysMon.html#Riacs

Tool che esaminano il sistema in dettaglio periodicamente o quando si verificano eventi insoliti Esempi di tool che mantengono e controllano i file di log per permettere l’immediata scoperta di attività sospette sono: •

top - http://www.cert.org/security-improvement/implementations/i042.06.html

•

sps (Special Process Status) - http://www.cert.org/securityimprovement/implementations/i005.03.html

•

spar (Show Process ing Records) - http://www.cert.org/securityimprovement/implementations/i042.04.html

•

logcheck - ftp://ftp.cerias.purdue.edu/pub/tools/unix/logutils/logcheck/

Esempi di tool che proteggono la consistenza dei log da possibili modifiche sono: •

chklastlog - ftp://ftp.cerias.purdue.edu/pub/tools/unix/logutils/chklastlog/

•

chkwtmp - ftp://ftp.cerias.purdue.edu/pub/tools/unix/logutils/chkwtmp/

•

log - ftp://ftp.cerias.purdue.edu/pub/tools/unix/logutils/log/

•

trimlog - ftp://ftp.cerias.purdue.edu/pub/tools/unix/logutils/trimlog/

Esempi di tool che controllano la presenza di vulnerabilità note sono: •

nessus - http://www.nessus.org/

•

satan (System Tool for Analyzing Networks) ftp://ftp.porcupine.org/pub/security/

•

saint (Security 's Integrated Network Tool) - http://www.wwdsi.com/saint

•

sara (Security Auditor's Research Assistant) - http://www.www-arc.com/sara/

•

cops - ftp://ftp.cerias.purdue.edu/pub/tools/unix/scanners/cops/

•

tiger - ftp://ftp.cerias.purdue.edu/pub/tools/unix/scanners/tiger/ Pagina 158 di 334

Un esempio di tool che permette di condurre un’analisi forense è: •

TCT (The Coroner's Toolkit) - http://www.fish.com/forensics/

Uno dei tools opensource più utilizzati, comunque basato su TCT è sleuthkit di Brian Carrier di Purdue University. Ha un’interfaccia grafica denominata Autopsy ed una serie di strumenti aggiuntivi.

Pagina 159 di 334

3.2

Raccolta delle fonti di prova

In questa parte del documento verranno illustrate le metodologie da seguire durante la raccolta delle fonti di prova. E’ stato adottato un approccio procedurale, organizzativo, che dà per consolidate le premesse di tipo tecnico e tutto quanto esposto nel capitolo 1.1. 3.2.1

Sviluppo di metodologie

Per effettuare un’analisi di digital forensics nel migliore dei modi, il team deve possedere un documento di specifica delle metodologie da seguire, cioè un insieme di regole e linee guida che indicano le procedure fondamentali da seguire in ogni analisi. In casi particolari e documentati il team può però discostarsi dalla metodologia predefinita, inoltre può accadere che i tool utilizzati differiscano da caso a caso. L’importante è che si proceda alla “dichiarazione” della metodica e degli strumenti utilizzati all’inizio della documentazione e che il tutto risponda comunque alle Best Practices. Pianificare è essenziale e dovrebbe sempre essere la prima attività di qualunque lavoro. Nel caso specifico, può essere utile conoscere alcune informazioni di base del caso su cui si andrà a lavorare. Di seguito una Check List sotto forma tabellare Domanda da porsi Su che tipo di sistema si sta intervenendo?

Risposta Mappare il sistema colpito (dovrebbe essere già stato fatto in sede di pianificazione, effettuare un check con il personale IT) Qual è l’ambiente? Definire l’ambiente in cui si sta lavorando in maniera sintetica E’ richiesta autorizzazione? Indicare il tipo di autorizzazione richiesta per effettuare l’analisi Come si otterrà l’accesso? Indicare, tra l’altro, se si effettueranno analisi/ricognizioni in locale o in remoto (remote forensic) Come si metterà al sicuro l’ambiente? Indicare le procedure di sicurezza relative alle cautele poste in essere nei confronti del target Si ha la disponibilità di specialisti di incident Rispondere in maniera affermativa o negativa response/ forensic selezionati per il task? aggiungendo le informazioni del caso Di quanti specialisti si ha bisogno? Rispondere fornendo le informazioni richieste Rispondere fornendo le informazioni richieste E’ stato preparato un toolkit? Trasporto sicuro? Indicare le modalità dell’eventuale trasporto delle digital evidences. Indicare le procedure di documentazione della Come verrà documentato l’ambiente? scena relativa al target (Il cosiddetto Green Circle) Pagina 160 di 334

Sempre ricordandosi che le proprie specifiche necessità ad un certo punto potranno variare, segue una proposta di metodologia. Gli step elencati di seguito non sono da prendere alla lettera e possono non essere perfetti per ogni caso a cui si lavora. Il presupposto è che prima dell’intervento (sia esso a cura del team aziendale o delle Forze dell’Ordine) bisogna avere già compilato i documenti adeguati e bisogna avere i permessi dall’autorità competente per fare delle ricerche sulle macchine sospette (PC, Server, Nastri, ecc.). 3.2.1.1

Preparazione

Prima dell’analisi, bisogna essere sicuri di essere preparati. Ci sono alcune guide di riferimento ampiamente accettate per un’analisi forense: -

-

“Sterilizzare” logicamente ogni media che verrà poi utilizzato durante l’analisi. Se non ci si può permettere nuovi media per ogni caso, bisogna essere sicuri che i media riutilizzati siano esenti da virus e che sia stato effettuato il wiping dei dati. Documentare i processi di wiping e di scansione. Per le modalità di dettaglio di dette procedure fare riferimento agli appositi paragrafi di IRItaly. Effettuare un’immagine identica (bit stream) dei media originali che verrà poi utilizzata per l’analisi. Controllare che tutti i tool / software utilizzati durante l’esame siano muniti di licenza. In caso di tool opensource verificare che si tratti di strumenti scaricati dai siti ufficiali e sottoposti ad un qualsivoglia processo di validazione. Controllare che tutte le attrezzature del laboratorio siano pronte per l’uso. Bisogna essere sicuri di aver scelto bene il forensic examiner. In particolare seguire la seguente checkist di massima

: L’esaminatore è in grado di testimoniare in tribunale se necessario? L’esaminatore è in grado di spiegare la metodologia usata in termini semplici e comprensibili? Oppure i giurati dovranno immaginarsi che cosa sono i bytes, i bit, i file nascosti e lo slack space? Un forensic examiner deve essere imparziale. Il lavoro che effettua consiste nell’analizzare i media e riportare il verdetto senza la presunzione di colpevolezza o di innocenza. L’integrità dei media originali deve essere mantenuta e documentata durante l’intera ricerca. 3.2.1.2

Trasportare il computer in un posto sicuro

Il sistema dovrebbe essere adeguatamente etichettato e preparato per un trasporto sicuro. Ovvero bisogna imballare saldamente la fonte di prova e fare attenzione alle scariche elettrostatiche. Si trasporti la prova se possibile nel laboratorio che è stato allestito26. In alcuni casi questo non sarà possibile e sarà necessario utilizzare un toolkit portatile per effettuare l’analisi on site. In ogni caso, si documentino, attraverso fotografie o videotape, le azioni compiute 26

Nel caso specifico, valutare anche l’intervento di un outsourcer.

Pagina 161 di 334

(movimentazione della prova dalla scena al veicolo di trasporto e dal veicolo di trasporto al laboratorio dove ne verrà effettuata l’analisi) e ci si tenga pronti ad argomentare la propria metodologia. In un’analisi forense è importante rendere sicuro l’ambiente. Questo protegge dalla manomissione delle fonti di prova o da situazioni potenzialmente pericolose. Ciò può sembrare scontato, ma troppo spesso i computer sottoposti a procedura di incident response vengono depositati in luoghi non sicuri. È obbligatorio che il computer venga trattato come prova e quindi venga immagazzinato fuori dalla portata di utenti curiosi. Inoltre, un elaboratore sequestrato lasciato incustodito può essere facilmente compromesso con la conseguente possibilità di perdere fonti di prova decisive. Un altro elemento da non sottovalutare è la CoC. Una dimenticanza in questo documento potrebbe rendere il documento improprio in sede di giudizio in quanto non sarebbe possibile assicurare che non ci siano state perdite di fonti di prova a seguito di qualsiasi operazione. 3.2.1.3

Documentare la configurazione hardware del sistema Si presuppone che il sistema di elaborazione venga trasportato in un'ubicazione sicura dove una corretta chain of custody può essere mantenuta e dove l’elaborazione delle fonti di prova può cominciare. Prima di eseguire qualsiasi analisi, è essenziale descrivere il luogo, chiamato il “luogo d’ingresso”. Cosa si vede quando si entra nell’ufficio dove la workstation è connessa oppure quando si apre lo chassis la custodia? Per recuperare il laptop? Registrazioni video possono essere delle risorse molto efficaci in questa fase. Utilizzando una videocamera, una macchina fotografica è possibile ricreare la scena. Oltre alle immagini fotografiche, si dovrebbe descrivere la scena mediante appunti. Questi appunti dovrebbero includere tutte le attrezzature, le periferiche e media indicando i numeri di serie e di modello e altre informazioni pertinenti che descrivono accuratamente la scena. Prima di aprire il computer, è importante che vengano fatte fotografie del computer stesso da ogni angolazione al fine di documentare i componenti hardware di cui il sistema è composto e come sono tra loro connessi. E’ anche importante etichettare ogni filo in modo da facilitarne la riconnessione quando viene ripristinata (alla sua condizione originale) la configurazione in una locazione sicura. Fotografare ancora dopo che le etichette sono state applicate.

3.2.1.4

Shutdown del computer La scelta tra Togliere la corrente elettrica o spegnere una rete di computer usando comandi pertinenti dipende spesso dal sistema operativo del computer in questione. Indipendentemente da quale metodo venga utilizzato, dovrebbe essere documentato. Si ricordi che il sistema dovrebbe essere spento prima possibile. Ciò è necessario per interrompere i potenziali programmi distruttivi in esecuzione in background.27

27

Fanno ovviamente eccezione i casi in cui sussiste l’esigenza di effettuare una Live System Analysis

Pagina 162 di 334

Fotografie dello schermo possono essere effettuate a scelta dell'investigatore. Comunque, la valutazione dovrebbe essere fatta in funzione dei possibili processi distruttivi che possono operare in background. Generalmente il computer deve essere spento il più presto possibile.28 Si ricordi di documentare sempre tutti gli step nella “chain of custody” e nella “tabella dei tempi”. Fino a quando il sistema è in nostra custodia, non dovrebbe mai essere lasciato “scoperto”. 3.2.1.5

Documentare tutto Molto importante nelle indagini forensi è la Chain of Custody , cioè la documentazione di tutte le persone che hanno custodito le fonti di prova in ogni step. Se le risorse lo consentono, si utilizzino due persone per ogni step in ciascun caso. Ciò può essere utile per avere una documentazione piú accurata delle azioni svolte e, ai fini legali, per avere un testimone. Importanti nella descrizione sono la data e l’ora in cui sono stati eseguiti gli step, il nome di chi li ha eseguiti e sotto la direzione di chi. A tal scopo può essere utile anche la Tabella dei Tempi. Avendo questa documentazione completa, è possibile respingere qualsiasi accusa di cattiva gestione delle fonti di prova , specialmente se sono stati seguiti i i definiti nella metodologia. Inoltre la documentazione è un buon punto di riferimento per l’esaminatore nel caso in cui il caso abbia una durata lunga o un carico elevato, o nell’eventualità in cui vi sia un aggio di consegne tra team od operatori singoli.

3.2.1.6

Preparazione A questo punto bisogna preparare la digital evidence acquisita per l’esame in laboratorio: -

3.2.1.7

disimballare la prova, documentando (data,ora, esaminatori, ecc.) il tutto nel rispetto della la metodologia seguita; esaminare visivamente la prova, annotando e documentando ogni configurazione insolita; effettuare un’immagine esatta della prova (se non è stato fatto prima) .

Sistema operativo e versione Il computer sequestrato può avere installato uno o più sistemi operativi. Il sistema operativo coinvolto dovrebbe essere documentato. Sui computer basati su DOS e su Windows questo può essere determinato esaminando il settore di boot di ogni partizione. Può essere determinato anche utilizzando un programma come le Norton Utilities. I risultati di tali scoperte dovrebbero essere annotati ed il software e la versione utilizzata dovrebbero essere documentate. Le versioni del software usate dovrebbero essere conservate29.

28

Per le modalità di spegnimento si faccia riferimento agli appositi paragrafi di IRItaly. A tal fine è altresì utile effettuare un check relativo alle licenze dei programmi e dei sistemi operativi contenuti all’interno della macchina in esame. Questo per evitare eventuali problemi relativi alla normativa in materia di tutela della proprietà intellettuale del software. 29

Pagina 163 di 334

3.2.1.8

Valutazione dei virus

È importante che l’esaminatore non comprometta l’integrità dei dischi sotto esame attraverso l’involontaria introduzione di virus. Di conseguenza, ogni software utilizzato in sede di esame dovrebbe essere esaminato da un’utility di virus scanning, come ad esempio Mc Afee, Norton, Dott. Solomon, ecc. Una metodologia ideale prevede che si utilizzino due differenti programmi di scansione, i cui risultati siano riportati nella documentazione del caso. Dovrebbero essere analizzati tutti gli hard disk e i floppy disk sequestrati e gli eventuali virus trovati dovrebbero essere documentati e, è scelta dell’analizzatore, rimossi. Come anche in questo caso la versione del software utilizzata dovrebbe essere conservata con la documentazione. È anche importante tenere presente che programmi infetti possono essere immagazzinati all’interno di file compressi, come ad esempio file zip. NB: L’esame deve essere effettuato sulla copia di lavoro, non sull'’originale, a meno che non si decida di operare in sola lettura (in questo caso si consiglia di assicurarsi a priori che l’opzione read only sia stata attivata) 3.2.1.9

Effettuare un Bitstream Backup degli hard disks e dei floppy disks Il computer non dovrebbe essere manomesso e le fonti di prova non dovrebbero essere analizzate fino a quando i backup bit a bit di tutti gli hard disk e di tutti i media non siano stati effettuati. Tutte le analisi delle fonti di prova dovrebbero essere effettuate sulla copia di backup piuttosto che sul computer colpito; le fonti di prova originali dovrebbero essere lasciate intatte fino alla fine dell’iter burocratico, in quanto l’integrità delle fonti di prova è di vitale importanza. Spesso è molto semplice alterare o distruggere i dati e può capitare che tali alterazioni siano irreversibili, quindi i backup risultano essere essenziali. Per questi motivi bisogna effettuare una copia esatta dell’hard drive, meglio ancora due immagini. Esistono molti strumenti che permettono di raggiungere questo scopo, come EnCase, o il comando DD di Unix, o Byte Back o ancora Safeback. Ci sono alcune importanti note da ricordare: -

-

chiudere l’antivirus; registrare la data e l’ora del CMOS (Complementary Metal Oxide Semiconductor). Questo è molto importante specialmente quando entrano in gioco i fusi orari. Da notare che è fondamentale rimuovere il media (hard drive,ecc.) prima di alimentare il PC per controllare il CMOS; non avviare il sistema sulla macchina sospetta. Farne un’immagine utilizzando una macchina controllata; documentare come l’immagine è stata creata: con quale strumento, la data e l’ora di creazione e l’esaminatore che l’ha effettuata; infine, assicurarsi che lo strumento che fa l’immagine non acceda ai file di sistema del media obiettivo dell’indagine, in quanto si vuole che non venga cambiato alcun file; dopo aver effettuato l’immagine sigillare il media originale in un contenitore che protegge contro le cariche elettrostatiche, catalogarlo e firmare con le iniziali dell’esaminatore il contenitore. Così facendo, se si commette un errore analizzando la prima copia, se ne ha un’altra per lavorare lasciando l’originale intatta ed inalterata. Pagina 164 di 334

Assicurarsi che chiunque entri in contatto col contenitore scriva anch’esso le proprie iniziali. Il contenitore dovrebbe essere chiuso in una stanza sicura fino ad immagine completata. 3.2.1.10

Autenticare matematicamente i dati su tutti i dispositivi di memorizzazione

Una volta che i dati sono stati resi sicuri, bisogna preoccuparsi di poter dimostrare, a scopo probatorio, l’integrità e l’autenticità degli stessi al fine di evitare che l’intero lavoro sia invalidato per una sottigliezza legale. Una regola fondamentale, infatti, nella computer forensic è che il media originale deve rimanere intatto e inalterato. Bisogna essere in grado di dimostrare, quindi, che le fonti di prova non sono state alterate dopo che il computer è entrato in nostro possesso in modo tale da negare accuse che riguardano la modifica delle fonti di prova originali. È evidente che deve esserci sempre un sistema di crittografia per garantire l’integrità delle fonti di prova (MD5, SHA-1 usato dal governo degli stati uniti). Queste funzioni sono come “impronte digitali”: pochi dati che riescono ad identificare oggetti molto grandi. MD5 o l’SHA-1 sono funzioni hash irreversibili (il termine irreversibili deriva dalla natura matematica). Le funzioni hash possono quindi essere utilizzate a scopo d’autenticazione e per garantire l’integrità dei dati. Dal 1989, le forze dell’ordine ed agenzie militari hanno usato un processo matematico a 32 bit per realizzare il processo di autenticazione. Comunque, considerando la velocità di computer di oggi e l'enorme capacità di memoria dei dischi rigidi, questo livello di precisione non è più sufficientemente adeguato. Il CRC a 32 bit può essere compromesso. Esistono programmi che usano un livello di accuratezza tra i 64 e 255 bit. Questi programmi vengono utilizzati per autenticare i dati sia a livello fisico che a livello logico. Alcuni di questi sono: md5deep, CRCMD5 e DiskSig. 3.2.1.11

Documentare la data e l’ora del sistema

La data e l’ora associate ai file possono risultare estremamente importanti dal punto di vista delle fonti di prova . Se, per esempio, l'orologio di sistema è un'ora indietro rispetto all’ora del luogo in cui si sta effettuando l’analisi a causa del fuso orario anche i file riporteranno data ed ora errate. La precisione dell’ora e della data dei file è legata direttamente all'accuratezza dell’ora e della data immagazzinata nel chip CMOS del computer. Di conseguenza, è importante documentare con esattezza sul computer sequestrato questi valori. Senza tali informazioni, sarà impossibile convalidare la precisione dell’ora e della data associate ai file del computer. Di conseguenza, è opportuno che l’ora corrente e la data siano confrontate con le stesse informazioni immagazzinate nel computer. L’ora corrente può essere ottenuta dalla società telefonica o dal sito Internet http://greenwichmeantime.com/home.htm. La data e l’ora dei file sono particolarmente importanti nel documentare i file retrodatati del computer. Quando le impostazioni sul computer sono imprecise, la data e l’ora associate ai file interessanti possono essere ricostruite per interpolazione dall’esaminatore. Dal punto di vista dell’analisi forense, comunque, è bene tenere

Pagina 165 di 334

presente che maggiore importanza è data non tanto alla data e ora assolute, ma alle relazioni temporali tra i dati analizzati.30 3.2.1.12

Effettuare una lista delle parole chiave cercate

Poiché i dischi rigidi moderni sono molto voluminosi, è estremamente complesso per un analizzatore prendere visione e valutare ogni file. A questo fine sono necessari tool automatizzati nella ricerca di parole chiave all’interno dei file di testo presenti su tutti i dispositivi di memorizzazione a disposizione. E’ importante raggruppare informazioni compilando una lista di parole chiavi pertinenti, tenere l'elenco il più corto possibile ed evitare di usare parole comuni o parole che costituiscono parte di altre parole.

3.2.1.13

Valutare i file di swap di Windows

I file di swap di Windows sono potenzialmente una fonte preziosa di prova. La valutazione dei file di swap può essere automatizzata attraverso l’utilizzo di tool forensic come SleuthKit. Nel ato questa tediosa operazione veniva svolta con editors esadecimali e il processo di valutazione di un solo file di swap di Windows durava giorni. Utilizzando tools automatici questo processo oggi impiega solo alcuni minuti. Con l’arrivo di Windows 95/98, i file di swap possono essere creati dinamicamente quando il computer viene , mentre quando il computer è spento i file di swap vengono cancellati. Esistono programmi che valutano il contenuto dei file di swap, catturando i file cancellati e creano archivi che verranno valutati da appositi filtri. 31 3.2.1.14

Valutare lo slack space

Lo slack space è un’area di deposito dei dati che la maggior parte degli utenti non conosce. E’una fonte di perdita di sicurezza e consiste in una copia grezza della memoria eseguita durante la chiusura della sessione di lavoro. I dati scaricati dalla memoria vengono immagazzinati alla fine dei file allocati, fuori dalla portata e dalla vista degli utenti. In un hard disk ben configurato 900 Mb di spazio potrebbero essere occupati dallo slack space. Per valutare lo slack space è richiesto l’utilizzo di specializzati tool di forensic che forniscono una ricchezza di informazioni e comandi investigativi. In questo modo l’investigatore può rintracciare delle parole chiave utili per recuperare importanti comandi e parole chiave che altrimenti non sarebbero noti. Queste parole chiave potrebbero essere aggiunte alla lista del computer dell’investigatore per usi futuri.

30 31

Trattasi del principio della correlazione. Il fatto che si utilizzino degli strumenti automatizzati di ricerca non esime l’operatore da conoscere il loro funzionamento.

Pagina 166 di 334

3.2.1.15

Valutare gli spazi non allocati (file cancellati)

La funzione di “delete” in DOS e Windows non cancella completamente i nomi e il contenuto dei file. Molti utenti non sono a conoscenza del fatto che lo spazio in memoria associato a tali file diventa così libero per essere sovrascritto con un nuovo file. Lo spazio non allocato è fonte di una significativa perdita di sicurezza, in quanto è un potenziale contenitore di informazioni relative a file cancellati. Spesso poi è possibile utilizzare la funzione di “undelete” per recuperare il file precedentemente cancellato. In questo modo possono essere recuperate importanti parole chiave e comandi che altrimenti resterebbero sconosciute all’investigatore. E’ anche possibile recuperare dati associati a file temporanei creati da applicazioni di vario tipo. Su un hard disk ben configurato molto spazio può contenere dati associati a file eliminati, recuperabili attraverso software di forensic specifici e automatizzati. 3.2.1.16

Cercare le parole chiave nei files, slack space e spazi non allocati

L'elenco di tutte le parole chiave attinenti identificate nei i precedenti dovrebbero essere cercate in tutti gli hard disk drive ed in tutti i floppy disk concernenti il caso. Esistono, sul mercato, molte utilities di forensic di ricerca di testo. E’ importante verificare l’output dell’utility di ricerca ed ugualmente importante è documentare le relative scoperte. Quando viene identificata una prova pertinente, questa dovrebbe essere annotata ed i dati identificati dovrebbero essere completamente esaminati per parole chiave. Quando viene trovata una nuova parola chiave questa deve essere aggiunta alla lista e dovrebbe essere condotta una nuova ricerca utilizzando l’utility di ricerca di testo. 3.2.1.17

Documentare i nomi, le date e l’ora dei files

Da un punto di vista della prova, i nomi dei file, la data di creazione, la data e l’ora dell’ultima modifica possono essere importanti. Per questo motivo è importante catalogare tutti i file allocati e “cancellati”. Il programma Filelist genera il suo output organizzandolo in un database che può essere ordinato in base al nome, dimensione, contenuto, data di creazione, data e ora di ultima modifica del file. Tali informazioni ordinate possono generare un grafo che indica l’utilizzo del computer su scala temporale. Quando il filelist database viene collegato con diversi computer coinvolti nello stesso caso, l’ordinamento finale può fornire informazioni utili, ad esempio i comandi utilizzati dall’intruder. 3.2.1.18

Identificare le anomalie di file, programmi e unità di memorizzazione

I file crittografati, compressi e di grafica sono memorizzati in formato binario. Per questa ragione i testi memorizzati nei file con questi formati non possono essere rintracciati da un programma di ricerca. Perciò è necessario analizzare questi file con metodi manuali e, nel caso di file crittografati è richiesto un maggior impegno. E’ anche opportuno controllare i file contenuti nel cestino, che sono quelli cancellati dall’utente. Questo può essere rilevante da un punto di vista probatorio. Si consiglia altresì di verificare la presenza di eventuali tools di steganografia. Pagina 167 di 334

3.2.1.19

Partizioni dell’hard disk

Quando si lavora sugli hard disk un potenziale pericolo consiste nella perdita dei dati o nel fatto che vengano nascosti. Di conseguenza, è importante documentare il modello e la dimensione di tutti gli hard disk drive contenuti nei computer sequestrati. Le informazioni di fabbricazione all’esterno dell'hard disk dovrebbero essere riportate nella documentazione. Controllare il partizionamento degli hard disk è altrettanto importante, specialmente per verificare la presenza di partizioni nascoste e/o partizioni formattate con un sistema operativo non compatibile con DOS. Quando questa eventualità si verifica è possibile trovare un hard disk nascosto e grandi quantità dei dati all’interno dei quali potrebbero esserci potenziali fonti di prova . Il partizionamento può essere controllato con un gran numero di software, come ad esempio il comando DOS “fdisk” o Partition Magic. Quando si trovano partizioni nascoste, devono essere controllate alla ricerca di fonti di prova e la loro esistenza deve essere documentata. Devono essere inseriti e descritti nella documentazione anche il numero e le dimensioni delle partizioni e tutti i file in esse rintracciate. Si rammenti, comunque, che sono molti i Vendor di Hard Disk che mettono a disposizione del pubblico dei servizi di individuazione delle caratteristiche dei propri prodotti. 3.2.1.20

Valutare le funzionalità dei programmi

In base all’applicazione software utilizzata, potrebbe essere necessario eseguire i programmi per conoscere la loro finalità. Nel caso in cui vengano scoperti processi dannosi legati a fonti di prova evidenti, questi possono essere utilizzati come fonti di prova inconfutabili. Tali processi distruttivi possono essere ricondotti a tasti funzione o all’esecuzione di comandi di uso comune legati al sistema operativo o alle applicazioni.32 3.2.1.21

Documentare la “sentenza”

Come indicato negli step precedenti, è importante: - documentare come sono state trovate gli elementi e le fonti di prova ; - documentare tutto il software utilizzato nelle indagini, compreso il numero di versione del programma utilizzato; - controllare che il software di forensic utilizzato abbia regolare licenza legale, in quanto le copie pirata non sono considerate valide in sede legale; - quando ritenuto necessario può essere d’aiuto descrivere con delle snapshot le modalità di utilizzo dei programmi. - In alcuni casi, inoltre, può essere necessario riscontrare l’output di uno strumento con un altro tool dello stesso genere.

32

In qualsiasi momento dell'indagine possono essere effettuati dei riscontri utilizzando programmi FILELIST e/o programmi autenticati matematicamente. Si tenga comunque conto che si tratta di un programma di tipo commerciale. Ulteriori informazioni possono essere reperite alla Url http://www.forensics-intl.com/filelist.html

Pagina 168 di 334

3.2.1.22

Tenere copie dei software usati

Come la tecnologia fa i in avanti, anche molti fabbricanti di software migliorano ed aggiornano i loro software. In un solo anno un programma molto probabilmente verrà aggiornato molte volte. Per questo motivo è importante che l’esaminatore trattenga la versione e la copia esatta del software utilizzata durante il processo di analisi. Può essere necessario per l’analizzatore duplicare i risultati del proprio lavoro e questo compito risulterebbe difficile o impossibile nel caso in cui non sia stata trattenuta la versione esatta del software originariamente usato. Se l’elaborazione dei risultati non può essere duplicata, potrebbero essere sollevati dubbi sulla precisione del metodo di elaborazione utilizzato e risulterebbe quindi difficile respingere le probabili affermazioni dell'avvocato difensore circa la modifica della prova da parte dalla polizia. Per questo è molto importante archiviare sullo stesso dispositivo di memorizzazione i file sorgenti, i file di testo prodotti duranti le ricerche, i file di output e i software forense fino dopo il processo e fino a che tutte le possibilità di appello sono state esaurite. I media di deposito raccomandati sono Jazz Disk, Zip disk o altri device di memorizzazione esterni che permettono l’accesso ai file come ad esempio un hard disk esterno. Come già specificato, nella documentazione devono essere chiaramente elencati il software utilizzato (nome e numero della versione), i nomi dei file sorgenti e i nomi dei file di output. 3.2.1.23

Licenze software

I tool software usati durante le analisi sono relativamente poco costosi e alcune società di software sostengono le forze dell’ordine con software forense libero e scontato. Bisogna essere sicuri di essere autorizzati nell’utilizzare il software e documentare questo fatto nella relazione, in quanto avvocati difensivi potrebbero contattare gli editori di software coinvolti e verificheranno se l’utente è autorizzato ad utilizzare il software.

Pagina 169 di 334

3.3

Conservazione delle fonti di prova

3.3.1

Introduzione

In questo documento è stata più volte sottolineata l'importanza, a seguito di un'intrusione, della fase di protezione dei dati e dei relativi i fisici. Preservare fisicamente e mantenere nello stato originale le fonti di fonte di prova (digital evidences) deve essere un obiettivo da non sottovalutare, in quanto tale operazione assume un ruolo fondamentale in un eventuale processo giudiziario, soprattutto in sede penale. Dal punto di vista legale, infatti, ogni alterazione, anche se minima, può rendere inefficace ogni fonte di prova presentata, col rischio di rendere vani i propri sforzi e non poter più far valere i propri diritti. Il trattamento e la custodia dei log memorizzati a seguito di un’intrusione dovranno essere soggetti a criteri diversi da quelli applicati ai normali log d’esercizio: verosimilmente il tempo di conservazione sarà più lungo ed il luogo in cui verranno conservate le informazioni ed i rispettivi i fisici dovrà avere elevate caratteristiche di integrità e sicurezza. Avere un adeguato ed aggiornato sistema di policies aziendali è un requisito indispensabile al fine di ridurre al minimo dimenticanze, errori, incomprensioni ed inefficienze da parte del personale, sia di quello non qualificato sia dei responsabili del servizio IT. Una policy di fondamentale importanza è quella relativa alla cosiddetta Chain of Custody (Catena di Custodia), documento nel quale verranno tutte le informazioni inerenti all'incidente, comprese quindi tutte le operazioni relative all'archiviazione e movimentazione delle fonti di fonte di prova. Ricordiamo infine che le procedure di risposta all'intrusione sono diverse a seconda che si parli di sospette violazioni amministrative, gestibili direttamente (in astratto) all'interno dell'azienda, oppure di veri e propri crimini informatici, per i quali ci si deve rivolgere alle Forze dell'Ordine. 3.3.2

Conservazione dei i fisici

E' importante che tutti i dispositivi vengano maneggiati con cura. Principio Base Tutte le azioni compiute a seguito di un incidente informatico non devono aggiungere, modificare, o distruggere dati memorizzati su un computer o su altri dispositivi. I computers sono strumenti elettronici fragili, molto sensibili a fattori esterni quali temperatura, umidità, urti, elettricità statica e campi magnetici. Speciali precauzioni devono perciò essere prese durante l'imballo, il trasporto e la conservazione delle fonti di prova elettroniche. 3.3.2.1

Imballaggio

Procedura di imballaggio: Pagina 170 di 334

•

Assicurarsi che tutti i dispositivi siano correttamente documentati, etichettati ed inventariati prima del loro confezionamento.

•

Riporre i i magnetici in confezioni antistatiche (carta o sacchetti di plastica antistatica) evitando di utilizzare materiali che possano generare elettricità statica, come le borse o i sacchetti di plastica normali.

•

Evitare di piegare, schiacciare o graffiare i quali dischetti, CDRom, e cassette.

•

Assicurarsi che tutti i contenitori siano correttamente etichettati. Se sono presenti vari componenti di uno stesso computer sull'etichetta dovrà esserci il relativo riferimento (es. PC1: mouse/HD1/monitor, PC2: mouse/HD1/HD2/... etc.)33

Il materiale di imballaggio ideale per una U è il contenitore originale fornito dal produttore, anche se raramente se ne ha la disponibilità. Se la confezione originale non risulta disponibile la U può essere imballata e trasportata così come si trova nel suo alloggiamento, facendo attenzione a non capovolgerla o ad appoggiarvi sopra altre cose durante il trasporto. Per quanto riguarda i dischetti segnaliamo che essi sono un o magnetico molto fragile. Se vengono imballati malamente e hanno la possibilità di urtare tra di loro durante il tragitto, si corre il rischio di danneggiarli e perdere dei dati. Se vi è la necessità di spedire i componenti si utilizzi un contenitore robusto di cartone (la cosa migliore resta comunque quella di utilizzare i contenitori originali). Usate imbottiture di gomma “spugnosa” o i classici fogli di plastica con le bolle d'aria.

33

Le istruzioni di massima inserite in questa parte del documento possono anche costituire una checklist

Pagina 171 di 334

Da non utilizzare invece le cosiddette “patatine” in quanto possono depositarsi all'interno del computer e/o dei componenti ed inoltre creano cariche statiche che possono causare perdite di dati o danneggiare i circuiti delle schede.

Sigillate poi i contenitori con del robusto nastro adesivo per pacchi. Imballate e spedite i componenti rivolti verso l'alto etichettando l'esterno del cartone con la scritta “LATO RIVOLTO VERSO L'ALTO” o scritte equivalenti (SU, ALTO etc.). Dischi, cassette, hard-disk devono essere imballati in modo da non permettere movimenti durante il trasporto. Etichettate poi l'esterno del contenitore con scritte quali: FRAGILE, APPARECCHIATURE ELETTRONICHE DELICATE, TENERE LONTANO DA MAGNETI O DA CAMPI ELETTROMAGNETICI.

3.3.2.2

Trasporto Pagina 172 di 334

Procedura per il trasporto: •

Mantenere i i lontani da fonti magnetiche: microfoni, trasmettitori radio, casse acustiche, sedili riscaldati sono esempi di elementi che possono danneggiare i dispositivi elettronici;

•

Evitare di lasciare i dispositivi nel veicolo per lunghi periodi di tempo: condizioni di eccessivo caldo, freddo, o umidità possono creare dei danni;

•

Assicurarsi che il computer e gli altri componenti siano messi al riparo da forti vibrazioni o sollecitazioni meccaniche: fissare accuratamente gli imballi in modo che non cadano durante frenate o altre manovre improvvise. Il posto migliore risultano essere i sedili poiché l’imbottitura attenua le vibrazioni del veicolo;

•

Mantenere la Chain of Custody su tutte le fonti di fonte di prova trasportate. Annotare anche le operazioni all’interno della “tabella dei tempi”

3.3.2.3

Conservazione

Dopo aver creato l'immagine bit a bit dei vari i, averne calcolato l’hash, e prodotto la relativa documentazione, tutti i dispositivi devono essere sigillati e riposti in un luogo fisicamente sicuro. Per “fisicamente” sicuro si intende un posto che non sia accessibile da personale non autorizzato e che non possa venire influenzato o compromesso da fattori fisici/ambientali esterni (campi elettromagnetici, inondazioni, incendi etc.). La vita limitata dei i magnetici e ottici è un problema di notevole rilevanza, sebbene esso non sia il fattore più importante nella conservazione del materiale digitale. Alcune ricerche sulla longevità dei i magnetici indicano un intervallo compreso tra i 10 e i 30 anni come “vita utile”, a patto che essi siano maneggiati ed archiviati in modo proprio. Migliorare la stabilità, capacità e longevità dei i di memorizzazione è necessario: vi è infatti il bisogno di ridurre la possibilità, insita nei i digitali, di subire perdite o alterazioni dei dati come conseguenza di degradazione fisica, instabilità delle particelle magnetiche etc. I dispositivi ottici sono soggetti a danni derivanti da polvere, elevata umidità, rapidi ed estremi sbalzi di temperatura: risulta palese l'importanza di avere un luogo sicuro in cui riporre i i citati. Un esempio di luogo sicuro può essere una cassaforte o un armadio blindato, ai quali abbiano accesso solamente il personale addetto alla gestione dell'incidente o coloro citati nelle policies specifiche. L'accesso ai i di memorizzazione sarà quindi limitato attraverso l'uso di: •

spazi di archiviazione sicuri (es. casseforti), il cui accesso sarà consentito solamente a coloro provvisti della chiave o della combinazione. Pagina 173 di 334

•

locali sicuri, con procedure di sicurezza che limitino l'accesso fisico (physical access control). E' consigliabile (soprattutto per grandi aziende, dotate di elevati budgets) che i locali adibiti alla conservazione delle fonti di fonte di prova siano sorvegliati tramite videocamere e/o che l'accesso sia consentito tramite l'utilizzo di apposite access control cards, che permetterebbero di mantenere una traccia di chi, e a che ora, abbia avuto accesso al locale protetto.

•

metodi di log e di registrazione della creazione, memorizzazione e trasporto dei dati.

La conservazione fisica dei i rappresenta quindi un punto molto importante nella fase di risposta all'incidente, in quanto le fonti di fonte di prova danneggiate non potranno essere ammesse in un eventuale processo legale. 3.3.3

Trattamento e custodia dei log

Attualmente non esiste una norma impositiva per le politiche di Log Rotation. A titolo esemplificativo, durante la normale operatività (log non generati da un'intrusione), i tempi di conservazione sono nell'ordine di: • • •

Piccole imprese: Media Imprese: Grandi Imprese:

6 mesi 12 mesi 24 mesi

A seguito di un'intrusione però (i log devono essere SUBITO masterizzati e firmati digitalmente) i tempi di conservazione si allungheranno; non è infatti possibile stabilire a priori quando, e per quanto, saranno necessari all'azienda o all'Autorità Giudiziaria. Molti casi giudiziari infatti si protraggono per anni prima di essere risolti: un posto sicuro in cui depositare le fonti di fonte di prova originali risulta perciò di rilevante importanza al fine di prevenire ogni tipo di contaminazione o alterazione dei dati. 3.3.4

Policies aziendali relative alla conservazione delle fonti di prova

Quando si subisce un accesso non autorizzato, può rendersi necessaria un'azione legale contro l'intruso. Tuttavia, se le fonti di prova dell'intrusione non sono trattate in modo opportuno, potrebbero diventare inammissibili in un eventuale processo giudiziario. E' quindi di fondamentale importanza porre tutta la cura necessaria nelle fasi di acquisizione, conservazione e protezione delle fonti di prova . Uno dei motivi per cui le fonti di prova possono risultare inadatte è dovuto al fatto che, all'interno dell'azienda, le politiche di gestione degli incidenti informatici sono inadeguate (o addirittura del tutto assenti!). Troppo spesso infatti manca un valido piano di incident response, il personale è scarsamente addestrato, o la Chain of Custody risulta incompleta e/o poco chiara.

Pagina 174 di 334

Uno degli obiettivi delle policies aziendali relative alla sicurezza informatica è quindi quello di poter sempre disporre della procedura di risposta specifica per ogni tipo di violazione riscontrata. Nel caso in cui il team di risposta all'incidente si trovi di fronte ad un computer aziendale utilizzato per creare e diffondere virus informatici e/o per attaccare altri computer, la violazione diventa perseguibile a livello civile/penale. Deve perciò esistere una policy che, oltre a segnalare con quale Autorità Giudiziaria si debba prendere contatto, specifichi quali sono le prime azioni da compiere per trattare e preservare in maniera opportuna le potenziali fonti di prova . Nello specifico si dovrà partire dal presupposto che tutta l'area di lavoro, l'ufficio, gli armadi etc. sono una potenziale “scena del crimine”, non solo il computer specifico. L'area di lavoro dovrà essere resa fisicamente sicura e protetta, al fine di mantenere l'integrità della scena e dei i di memorizzazione. Una volta che la sicurezza di base è stata stabilita, la scena non dovrà essere lasciata senza controllo fino a quando tutto il processo sarà completato: potrà accedervi solamente il personale direttamente coinvolto nella risposta all'incidente. Una policy di fondamentale importanza è quella relativa alla compilazione ed all'aggiornamento della Chain of Custody.. 3.3.5 Chain of Custody (CoC) Una volta che i dati sono stati raccolti, essi devono essere protetti da eventuali contaminazioni e/o alterazioni. Ricordiamo che gli originali non devono essere utilizzati nell'analisi forense ma si lavorerà solamente sulle copie verificate. L'accesso alle fonti di prova deve essere estremamente ristretto e documentato in modo chiaro: un buon modo per assicurare e documentare che i dati siano rimasti integri è quello di utilizzare la Chain of Custody. Un esempio di Chain of Custody si può trovare nella documentazione scaricabile dal sito di IRItaly (www.iritaly.org ). 3.3.6 3.3.6.1

Aspetti legali Rapporti con il Law Enforcement

Collaborare con l'Autorità Giudiziaria è un fattore di notevole importanza se si vuole che le indagini abbiano buon esito.

Pagina 175 di 334

I tecnici aziendali conoscono bene le politiche di sicurezza interne all'azienda, ma hanno una scarsa preparazione su quelle che sono le procedure, i tempi, i comportamenti da tenersi per garantire un'efficacia probatoria alle informazioni di cui dispongono. Troppo spesso infatti la denuncia, ed il relativo intervento da parte della Polizia Giudiziaria non viene fatta in modo repentino: il rischio è quello che non sia più possibile identificare il responsabile dell'attacco o che le fonti di fonte di prova non possano più essere ritenute inequivocabili in sede processuale. 3.3.6.2

Legislazione

Le fonti di prova devono soddisfare due requisiti fondamentali: ammissibilità e peso. Per “ammissibilità” si intende che una fonte di prova deve essere conforme a certe “regole” legali. Per “peso” intendiamo che le fonti di prova devono essere in numero ed importanza sufficiente a convincere il Giudice dell'effettivo svolgimento dei fatti e/o del contenuto inalterato delle fonti di prova . Anche se il “peso” non è un concetto scientifico, possono comunque essere identificati degli attributi di rilevante importanza quali: • Autenticità Bisogna dimostrare che tutte le azioni associate alla movimentazione dei dispositivi hanno mantenuto le fonti di prova nel loro stato originale. • Accuratezza Viene valutata in base alle tecniche, alle procedure, ai tools utilizzati. Completezza • Non è sufficiente raccogliere fonti di prova che mostrino l'incidente da un'unica prospettiva o solo quelle direttamente riconducibili alle azioni compiute dall'attacker. Per completezza bisognerà considerare e valutare anche quelle che potrebbero dare adito a delle contraddizioni o creare dei sospetti alternativi. • Attendibilità Le procedure di raccolta ed analisi delle fonti di prova non devono creare dubbi sull'autenticità e veridicità delle fonti di prova. Credibilità • Le fonti di prova presentate devono essere chiare, facili da capire e credibili. Ad esempio presentare un dump binario della memoria così come è stato acquisito può non essere compreso da personale non tecnico. Se lo stesso dump viene però presentato accompagnato da una versione formattata, che può essere letta e capita da chiunque, potranno essere mostrate le relazioni col dump originale, che risulterà più chiaro e quindi più credibile. Nell'ambito specifico della computer forensics possiamo espandere il range di attributi: Pagina 176 di 334

• • •

si rende necessaria una Chain of Custody chiara e precisa, con descrizioni dettagliate sullo stato in cui sono state trovate le fonti di prova, con fotografie fatte direttamente sul posto, con tutto il materiale etichettato e documentato. il metodo utilizzato deve essere “trasparente” in quanto un esperto esterno dovrebbe poter fare gli stessi test può essere utile spiegare e chiarire alcuni concetti poco familiari a personale non tecnico.

All'accuratezza “del contenuto” deve essere affiancata anche l'accuratezza “del processo” utilizzato per reperire le fonti di prova. Consigliamo quindi di utilizzare tool possibilmente “non proprietari”, oppure che siano talmente diffusi e sicuri da costituire uno standard de-facto.

Pagina 177 di 334

4. Sanitize: eliminazione degli strumenti utilizzati per l’intrusione La completa rimozione delle cause di un’intrusione è un traguardo raggiungibile a lungo termine, che può essere realizzato implementando un continuo processo di miglioramento della sicurezza. In risposta ad una specifica intrusione, bisogna assicurare che i sistemi compromessi siano protetti contro attacchi ed accessi simili in futuro. Gli intrusi spesso installano back-door o altri mezzi per ottenere accessi futuri ai sistemi compromessi. In questo capitolo verranno descritti i i per eliminare questi accessi nel miglior modo possibile. Le operazioni di sanitize saranno efficaci se, durante la fase di information gathering (capitolo 2 di questo documento), si saranno individuati tutti i cambiamenti effettuati durante l’intrusione. Gli amministratori potrebbero anche decidere di reinstallare tutti i sistemi compromessi e di ripristinare tutti i dati degli utenti, la scelta dell’amministratore dipende anche dal “grado di fiducia” riposto nei dati raccolti durante la fase di information gathering. La fase di sanitize deve essere eseguita in maniera molto accurata, assicurandosi che i sistemi non siano più vulnerabili, e non presentino più tracce dell’intrusione prima di essere rimessi in produzione. Bisognerà perciò prestare molta attenzione sia all’eliminazione delle tracce lasciate dall’intruso, sia all’eliminazione delle vulnerabilità presenti nei sistemi. Infine, in questa sede occorre ricordare che spesso le vittime di attacchi osservano dei tentativi di accesso ai loro sistemi molto tempo dopo l’avvenuta intrusione, ciò dipende soprattutto dal fatto che gli attacker dispongono di una fitta rete di comunicazione, utilizzata anche per lo scambio di informazioni sui sistemi vulnerabili esistenti.

Pagina 178 di 334

4.1 Modifica delle sui sistemi ove sia stata riscontrata un’intrusione La modifica delle è un’operazione di fondamentale importanza, soprattutto nel caso in cui si abbiano prove dell’accesso dell’intruso a file o dell’utilizzo da parte del soggetto di sniffer in grado di catturare spedite in chiaro attraverso la rete. E’ importante sapere che l’esecuzione di questo step potrebbe creare una grande mole di lavoro per gli utenti e potrebbe anche confonderli. Si ricordi che se le non possono essere cambiate, bisognerà bloccare gli compromessi e crearne di nuovi. 4.1.1

: vulnerabilità e policy In questo paragrafo verranno brevemente trattati i problemi di vulnerabilità delle e le policy aziendali che dovrebbero essere stilate per una loro corretta gestione; quest’argomento esula da quella che è la trattazione base proposta dal paragrafo, ma è di utile comprensione per poter evitare ulteriori danni alla struttura informatica aziendale. Va premesso che una corretta gestione delle prevede che esse vengano modificate a scadenze prefissate e non solo in caso di incidente informatico. Spesso perciò gli amministratori dei sistemi dovranno porsi il “problema” di modificare le di tutti i sistemi e anche far modificare le di accesso a tutti gli utenti dei sistemi. Questo tipo di politica, però, non basta per proteggere dall’accesso non consentito ai sistemi; bisogna infatti ricordare che le possono essere vittime di molteplici attacchi, tra i quali ricordiamo: •

Guessing: le possono essere facilmente indovinate da chi tenta di ottenere un accesso illegittimo. Un metodo per prevenire questa tipologia di attacchi è quello di scegliere una robusta;

•

Snooping: le possono essere osservate durante la digitazione da parte dell’utente;

•

Sniffing: possono essere acquisite nella comunicazione lungo la rete. E’ possibile evitare questo tipo di attacco non facendo viaggiare in chiaro le in rete;

•

Spoofing: le possono essere acquisite da terze parti che impersonano l’interfaccia di .

Va ricordato che una delle maggiori cause di vulnerabilità delle è rappresentata dalla scelta e dalla gestione delle stesse da parte degli utenti. I comportamenti errati degli utenti possono essere così schematizzati: •

le non vengono quasi mai modificate;

•

le vengono condivise con colleghi;

•

vengono scelte deboli, quali ad esempio data di nascita, nomi propri, etc;

•

la stessa viene utilizzate per accedere a più computer o servizi;

•

le vengono annotate su fogli di carta, agende per non dimenticarle. Pagina 179 di 334

Le Policy sono necessarie per proteggere la confidenzialità delle informazioni e l’integrità del sistema, evitando l’accesso ai sistemi aziendali di utenti non autorizzati. Non tutte le aziende, in ogni caso, realizzano i rischi collegati all’assenza o alla presenza di una policy insufficiente. Questi includono anche problemi di denial-of-service e di formazione degli utenti. E’ necessario ricordare, nella stesura di una policy, che essa deve considerare gli aspetti peculiari del contesto in cui viene inserita e perciò deve variare la sua complessità in dipendenza delle necessità degli asset aziendali. Le policy devono essere in accordo con questioni legali e devono essere elastiche e reattive ai cambiamenti aziendali. E’ importante, nella redazione di una policy, considerare il fattore umano, quale fattore di successo o insuccesso della stessa policy: la scelta di regole troppo complesse o di modifiche troppo frequenti delle possono essere percepite dall’utente come motivo di frustrazione e far fallire la policy prescelta. Bisogna, perciò, valutare il trade-off costi/benefici, onde evitare che i costi, rappresentati da un eccessivo carico nei confronti degli utenti, non superino il valore degli asset aziendali da proteggere. Una policy aziendale relativa alle dovrebbe essere redatta considerando tutti gli aspetti sopra citati, ossia le vulnerabilità alle quali sono soggette le , il comportamento degli utenti, gli asset aziendali e il trade-off costi/benefici. Una policy delle dovrebbe considerare le seguenti linee guida: •

Lunghezza: una dovrebbe essere di almeno 8 caratteri e comprendere caratteri speciali;

•

Complessità: dovrebbe essere richiesto, nella fase di creazione della , l’utilizzo di un mix di caratteri. Le dovrebbero contenere sia caratteri minuscoli che maiuscoli e almeno un carattere non alfabetico (numerici, speciali), non dovrebbero essere facilmente intuibili e non dovrebbero corrispondere a parole di dizionari (o leggere variazioni di queste);

•

Età: le dovrebbero essere periodicamente modificate dagli utenti (almeno ogni 30-120 giorni);

•

Facilità: la deve essere facile da ricordare, per evitare che venga scritta, ma difficile da indovinare;

•

vuote: non bisognerebbe mai lasciare la possibilità di non impostare una ;

•

Impersonalità: non utilizzare mai come qualsiasi cosa che possa essere collegato all’utente che la imposta, come ad esempio una simile alla , la propria professione, data di nascita, etc

•

Riutilizzo: spesso gli utenti, se obbligati a modificare la , tendono a riutilizzare le già usate in precedenza, bisognerebbe poter proibire questo comportamento agli utenti; Pagina 180 di 334

•

Autorità: definire chi ha l’autorità di modificare la ;

•

Segretezza: una dovrebbe essere nota solo all’utente che necessita dell’accesso ad una determinata risorsa;

•

Conservazione: le devono essere conservate in luoghi sicuri, possibilmente in busta chiusa e firmata; se si ha la possibilità le buste dovrebbero essere conservate in cassaforte. Una policy relativa alle dovrebbe considerare la possibilità degli amministratori di settare a priori dei controlli sulle caratteristiche delle , dovrebbero essere perciò previste:

•

restrizioni sulla lunghezza e sul numero minimo di caratteri da utilizzare;

•

obbligatorietà di inserire nella almeno un carattere numerico o un carattere speciale;

•

controlli rispetto ai dizionari e il divieto di utilizzo di parole del linguaggio naturale e sequenze numeriche simili a date, onde prevenire dictionary attacks e guessing delle ;

•

scadenza della , onde obbligare gli utenti ad una modifica periodica;

•

controllo sulla storia recente delle utilizzate, onde evitare la ripetizione delle stesse da parte degli utenti

Infine, bisogna ricordare che la policy deve essere documentata in modo preciso e facilmente comprensibile da tutti gli utenti dei sistemi aziendali; essa deve essere comunicata in maniera trasparente. E’ necessario anche prevedere dei cicli di formazione aziendale per far sì che gli utenti comprendano il valore della policy e si impegnino a rispettarla. 4.1.1.1

Modifica e creazione di una semplice policy

In questo paragrafo verranno analizzate la creazione di un utente, la modifica della ed il settaggio di una policy di base in sistemi Microsoft e Linux. La presente non vuole essere intesa come guida all’utilizzo dei sistemi, ma come esemplificazione di quanto detto in precedenza in relazione alle policy. 4.1.1.1.1

Microsoft

Nel caso di specie si prenderà ad esempio la gestione degli utenti dei Sistemi Operativi della famiglia Windows 2000, con riferimento ai soli utenti e gruppi locali e non a quelli globali o di dominio. Un utente o un gruppo locale è un a cui possono essere assegnati autorizzazioni e diritti dal computer in uso. Lo strumento per gestire gli utenti è “Utenti e Gruppi Locali” accessibile dalla “Gestione Computer”. I i per creare un utente possono essere così schematizzati: 1. Aprire Gestione computer 2. Nella struttura della console in Utenti e gruppi locali fare clic su Utenti. Pagina 181 di 334

3. Scegliere Nuovo utente dal menu Azione. 4. Digitare le informazioni appropriate nella finestra di dialogo, ossia: •

name: che verrà utilizzata dall’utente durante l’autenticazione al sistema;

•

Nome completo;

•

Descrizione;

•

: si segnala che è possibile impostare una contenente un massimo di 127 caratteri.

5. Selezionare o deselezionare le seguenti caselle di controllo: •

Cambiamento obbligatorio all'accesso successivo: obbliga l’utente a modificare la al primo . Permette all’amministratore di impostare “standard”, facilitando la comunicazione delle credenziali di accesso a molteplici utenti;

•

Cambiamento non consentito: non permette all’utente di modificare la propria ;

•

Nessuna scadenza ;

•

L' è disattivato.

Pagina 182 di 334

Figura 23: Proprietà utente

Per modificare le di un utente, un amministratore, deve effettuare i seguenti i: 1. Aprire Gestione computer 2. Nella struttura della console in Utenti e gruppi locali fare clic su Utenti. 3. Selezionare l' utente da modificare. 4.

Scegliere Impostazione dal menu Azione.

Per impostare una policy nei sistemi Windows è possibile utilizzare i “modelli di protezione” o “security template”. In seguito verrà definito un modello di protezione tale che rispetti i seguenti parametri: •

lunghezza minima : 10 caratteri;

•

criterio relativo al riutilizzo: non consentire l’utilizzo delle ultime 10 ;

•

scadenza : 40 giorni;

•

complessità : richiesta.

Per utilizzare i Security Template, bisogna accedere alla MMC (Microsoft Management Console); se lo snap-in relativo ai Security Template non è presente nella console, bisogna aggiungerlo. Pagina 183 di 334

Nella figura 23 viene presentata l’alberatura di questo servizio. I Security Templates forniscono un metodo centralizzato di definizione della protezione, un unico punto di accesso, perciò, da cui è possibile visualizzare, modificare e applicare l'intero sistema di protezione ad un computer locale. Essi prevedono la gestione di differenti categorie di policy, in questo paragrafo verrà presa in considerazione la definizione di Policy. In figura 23 si può notare l’alberatura del Security Template esplosa nella parte relativa alle Policy, dove si trova la Policy di nostro interesse.

Figura 24: Security Template

La figura 24, mostra il dettaglio della Policy e la modifica di uno dei parametri presenti.

Pagina 184 di 334

Figura 25: Modifica di un parametro

Come si può notare dalla figura 24 e dalla figura 25, i parametri presenti per l’impostazione di una policy sono: •

storia delle utilizzate precedentemente;

•

età massima delle ;

•

età minima delle ;

•

lunghezza minima delle ;

•

complessità delle ;

•

utilizzo di reversibile encryption delle .

Pagina 185 di 334

Figura 26: Policy

Come si evince dalla figura 25, la Policy settata concorda con quella definita all’inizio del paragrafo. 4.1.1.1.2 Linux In questo paragrafo prenderemo in considerazione l’utilizzo di “ shadow” e analizzeremo brevemente le differenze con /etc/wd. Il meccanismo delle shadow si basa su un principio molto semplice: nascondere le cifrate ai processi che non hanno i privilegi dell'utente root. Infatti, nei sistemi in cui le shadow non sono attivate, è il file /etc/wd, leggibile a tutti i tipi di utenti, che contiene tali le cifrate. Il formato del file /etc/wd non “oscurato” è il seguente: utente:pwd:UID:GID:nome_completo:directory:shell

dove: •

utente: dell’utente;

•

pwd: codificata;

•

UID: identificativo numerico dell'utente;

•

GID: identificativo numerico predefinito del gruppo;

•

nome_completo: Il nome completo dell'utente - in realtà questo campo viene chiamato campo GECOS (General Electric Comprehensive Operating System) e può contenere altre informazioni invece del solo nome completo;

•

directory: home directory dell'utente (percorso completo);

•

shell: shell di dell'utente (percorso completo).

Se si utilizza la shadow suite, il formato del file /etc/wd non cambia, ma non contiene più la dell’utente, che viene salvata nel file /etc/shadow. Il formato del file /etc/shadow è il seguente: Pagina 186 di 334

utente:pwd_cifrata:mod:val_min:val_max:preavv:tempo_riserva:scad:ris

dove: •

utente: dell'utente;

•

pwd_cifrata: cifrata;

•

mod: data di ultima modifica della (espressa in numero di giorni trascorsi dal 01/01/1970);

•

val_min: numero di giorni di validità minima della ; entro questo periodo, l'utente non può cambiarla;

•

val_max: numero di giorni di validità massima della ; prima che trascorra questo tempo, l'utente deve cambiarla;

•

preavv: numero di giorni, prima della scadenza, durante i quali l'utente viene avvisato

della necessità di modificare la ; •

tempo_riserva:

durata massima di validità dell’ dopo la scadenza della

; •

data di scadenza dell’ (espressa in numero di giorni trascorsi dal 01/01/1970);

•

ris: campo riservato per usi futuri.

scad:

Si procederà ora con un esempio esplicativo, come effettuato per la parte Microsoft, di creazione dell’utente e di gestione di una policy. Per creare un utente si utilizza il comando add. Tramite questo comando, si possono anche modificare le impostazioni predefinite dell’utente. Vengono effettuate differenti operazioni: •

visualizzazione delle impostazioni predefinite dell’utente: add –D

Figura 27: add -D •

modifica delle impostazioni predefinite, settando il gruppo predefinito (-g100) a 100, la scadenza dell’ al 7 gennaio 2004 (-e07/01/04) e il fatto di non voler bloccare Pagina 187 di 334

l’ in caso di scadenza della (-f0): add –D –g100 –e07/01/04 –

f0

Figura 28: modifica delle impostazioni predefinite di add •

Creazione dell’utente “iritaly”: add –c “IRItaly” iritaly

Figura 29: creazione utente

In figura 30, si può vedere il record creato nel file /etc/wd e si nota la “x” al posto della .

Figure 30: /etc/wd

Nel file /etc/shadow, (figura 31), si può notare che il record relativo all’utente creato non ha ancora la impostata (al posto della si trova “!!”), si procede perciò ad inserire una per quest’utente.

Figure 31: /etc/shadow

Pagina 188 di 334

Per settare una ad un utente viene utilizzato il comando wd, seguito dal nome utente per il quale desideriamo inserire la (figura 32).

Figure 32: impostazione

Il file /etc/shadow viene modificato e la impostata (figura 33).

Figure 33: /etc/shadow, dopo l'inserimento della

Si crea ora una policy utilizzando il comando wd. I criteri che si vogliono impostare sono i seguenti: •

massimo numero di giorni di validità di una : il suo valore viene stabilito utilizzando il parametro “-x”, in questo esempio sarà posto uguale a 40;

•

minimo numero di giorni tra cambiamenti della : si setta utilizzando il parametro “-n”. Il suo valore verrà posto uguale a 10;

•

numero di giorni di avviso prima della scadenza di una : si imposta utilizzando il parametro “-w”, in questo esempio sarà posto uguale a 7;

•

numero di giorni dopo la scadenza della , prima che l' venga bloccato: si stabilisce il suo valore grazie al parametro “-i”. Esso sarà posto uguale a 15.

Il comando da digitare è presente in figura 34.

Pagina 189 di 334

Figure 34: modifica parametri utente

Lo schema dei tempi può essere così espresso:

Data di modifica

Inizio giorni di preavviso

Fine giorni di validità

“mod”

10

Data di Scadenza

33

Fine tempo riserva

40

55

Disattivazione

“scad” Tempo (giorni)

Giorni di riserva Giorni di validità della

Giorni di preavviso

Validità minima

Le modifiche possono essere osservate nel file /etc/shadow (figura 35). La figura mostra che i campi del record iritaly sono stati aggiornati, abbiamo infatti il campo “10” relativo al numero minimo di giorni tra modifiche della , il campo “40” relativo alla validità della , i campi “7”, e “15”, relativi alla scadenza della .

Figure 35: /etc/shadow dopo la modifica dei parametri

L’amministrazione degli utenti ed il settaggio un policy possono essere effettuati più agevolmente utilizzando un unico file di configurazione: /etc/.defs.

Pagina 190 di 334

Questo file permette di stabilire alcune caratteristiche predefinite degli utenti che utilizzano le shadow. Il file /etc/.defs contiene impostazioni che riguardano dall'aspetto del prompt fino alla scadenza predefinita, si tratta di un file che offre la possibilità di impostare numerosi parametri. In questa trattazione verranno considerati solo quei parametri relativi alle , ossia: •

_MAX_DAYS: permette di stabilire la durata massima, predefinita, di validità di una

; •

_MIN_DAYS: serve a stabilire la durata minima di una ;

•

_MIN_LEN: permette di impostare il numero minimo di caratteri;

•

_WARN_AGE: il periodo di preavviso prima della scadenza di una .

Volendo impostare un Policy simile a quella utilizzata nel paragrafo dedicato ai sistemi Operativi Microsoft, si inseriranno i seguenti valori: •

_MAX_DAYS = 40;

•

_MIN_DAYS = 0;

•

_MIN_LEN = 10;

•

_WARN_AGE

precedente).

=

7

(parametro

non

impostato

nel

paragrafo

La figura 36 mostra la parte del file /etc/.defs, modificata.

Figure 36: /etc/.defs

4.1.2

Modifica e organizzazione In seguito ad un’intrusione, è necessario pianificare minuziosamente il cambio delle dei propri sistemi. L’effettuazione di quest’operazione prevede, in primis la decisione di quali di quali sistemi dovranno essere modificate. La fase di information gathering Pagina 191 di 334

dell’intrusione (analizzata nel capitolo 2 di questo documento) sarà la prima guida che permetterà di affrontare questo o dell’operazione di sanitize. Durante la fase di information gathering si analizzano i sistemi compromessi e tutta la struttura informatica aziendale alla ricerca di eventuali altre tracce dell’intrusione. Questa fase permette sia di capire e stimare i danni provocati dall’intruso alla struttura aziendale, sia di pianificare le fasi successive relative all’eliminazione di tutte le tracce relative all’intrusione. Per poter riportare tutti i sistemi alla normale operatività, la modifica delle è uno dei primi step da compiere. In primo luogo andranno modificate le dei sistemi sui quali si sono riscontrate tracce di intrusione. Se i sistemi compromessi sono pochi e non “critici”, l’operazione sarà di breve durata e non creerà problemi organizzativi. Se la modifica investe sistemi con criticità maggiore e soprattutto con un rilevante numero di , si avranno ripercussioni organizzative. Gli amministratori potrebbero decidere, in seguito anche alla rilevazione della presenza di sniffer sulla rete, di modificare tutte le di tutti i sistemi server e client. Questa operazione deve essere pianificata e programmata minuziosamente in modo da non creare disservizi ulteriori e/o denial-of-service. La prima fase di questa operazione è valutare l’impatto organizzativo della modifica delle , stilando una lista dei servizi offerti dall’azienda e dagli presenti. Se si considerano servizi erogati esclusivamente a personale interno all’azienda, si può riscontrare che gli utenti, in media, dispongono di: •

accesso al proprio client;

•

posta elettronica;

•

accesso alla rete aziendale (se diversa dalla di del PC);

•

accesso alle applicazioni (ogni applicazione presente all’interno della struttura informatica aziendale potrebbe prevedere l’utilizzo di meccanismi di autenticazione);

•

accesso alla intranet aziendale.

Considerando aziende che erogano servizi anche all’esterno dell’azienda, quali ad esempio servizi web, l’impatto sulla gestione di quest’operazione sarà ancora più traumatico e richiederà uno sforzo organizzativo maggiore. In queste pagine ci occuperemo della gestione della modifica delle legate a servizi erogati esclusivamente al personale interno dell’azienda. Il primo o da compiere è relativo alla modifica di tutte le di amministrazione dei sistemi. Il processo non coinvolge gli utenti comuni, ma solo gli amministratori, la modifica perciò sarà breve. Bisogna ricordarsi che le di amministrazione di un sistema dovrebbero non essere diffuse e conosciute esclusivamente dagli utenti che ne possono fare un corretto e lecito utilizzo. I successivi i riguardano la modifica delle di tutti gli dei sistemi. In questo caso, visto il coinvolgimento diretto di tutti gli utenti, l’operazione deve essere svolta in tempi brevi, ma deve essere minuziosamente pianificata. Gli scenari base che si possono prospettare sono due: 1. gli utenti hanno la possibilità di modificare le loro ; Pagina 192 di 334

2. gli utenti non possono autonomamente modificarsi la . Nel primo caso, gli amministratori potrebbero reimpostare tutte le di tutti i sistemi ad un valore di default e conseguentemente obbligare gli utenti ad inserire una nuova al primo accesso. L’esecuzione dell’operazione così strutturata non sarà troppo dispendiosa in termini di tempo e di risorse, e permetterà agli utenti la possibilità di scegliere la propria in autonomia, non dimenticando i criteri di scelta di una descritti in precedenza. Per le comunicazioni riguardanti questa operazione potranno essere scelti anche canali “insicuri” e potenzialmente vulnerabili, dato che non verranno divulgati dati sensibili. Nel secondo caso, che riguarda l’impossibilità per gli utenti di possedere un’interfaccia per modificare in autonomia la propria , l’operazione di modifica sarà onerosa e coinvolgerà pesantemente gli utenti per la sua realizzazione. In questo caso gli amministratori dovranno resettare e reimpostare una nuova differente per ogni utente; gli utenti potranno collaborare nello svolgimento di quest’operazione recandosi dall’amministratore e digitando personalmente la nuova : questa modalità risulta essere troppo onerosa per l’organizzazione e presenta ulteriori pericoli per il sistema, legati all’accesso, anche se temporaneo, dell’utente ad un sistema in modalità super . Se invece si decidesse di non coinvolgere gli utenti, gli amministratori dovranno modificare tutte le e successivamente comunicarle. In questo caso si creerebbe un problema relativo al canale di comunicazione da utilizzare per lo “smistamento” delle ; gli amministratori dovranno ricordarsi di non utilizzare la posta elettronica, se non cifrata, e, per questa consegna, dovranno affidarsi a metodi più tradizionali, quali ad esempio la consegna ad personam.

Pagina 193 di 334

4.2 Reinstallazione completa dei sistemi compromessi 4.2.1

Quando è utile reinstallare completamente il sistema Ogni professionista della sicurezza o amministratore di sistema, ad un certo punto della sua carriera, si scontra con la decisione: è meglio cercare di riparare il danno subito o reinstallare completamente il sistema e ripartire da zero? La scelta fra queste due alternative deve essere specificata e motivata nella politica di risposta all’incidente dell’organizzazione. Le due opzioni tra cui effettuare una scelta sono: • Procedere al ripristino del sistema da backup completi e affidabili e patch di sistema; • Effettuare il wipe dei dischi, reinstallare del sistema operativo, applicare i service pack e le patch disponibili, reinstallare le applicazioni e recuperare i dati solo ed esclusivamente da backup fidati. Prima di entrare nello specifico, consideriamo come si è potuti giungere a dover prendere una decisione di tale rilevanza. Ovviamente si deve essere verificato un incidente informatico, cioè un intruso deve in qualche modo aver fatto breccia e compromesso in modo serio il nostro sistema. A questo punto, si potrebbe pensare di applicare semplicemente delle patch al sistema, ripristinare la macchina allo stato originario e rimetterla in funzione. Ma per ogni particolare exploit, anche se si possiede una procedura specifica di ripristino molto dettagliata, è difficile essere certi che non siano state fatte modifiche al di fuori del suo raggio d’azione. Worm, virus e rootkit possono diffondersi su qualunque sistema; spesso rimuovono e cancellano file rilevanti, si nascondono in altre parti del sistema e a volte restano inattivi e possono essere modificati in ogni momento per eseguire altre azioni dannose. Per questa ragione le procedure di ripristino rilasciate dopo un grave incidente diventano presto obsolete. La realtà, come ogni esperto di Incident Response può confermare, è che la scoperta di tutti i cambiamenti effettuati sul sistema compromesso è estremamente difficile. Una volta entrato nel sistema, infatti, un attacker può attivare delle backdoor, modificare alcune operazioni standard del sistema e nascondere dei file. Anche se è installato un tool di controllo dell’integrità dei file (come Tripwire) è virtualmente impossibile garantire che il sistema sia completamente pulito. Riparare un sistema compromesso è sicuramente uno degli aspetti più problematici del lavoro di un professionista che opera nell’ambito della sicurezza informatica. Mentre il ripristino del sistema potrebbe sembrare la soluzione più semplice, fare il wipe del sistema e installare una versione pulita del software è spesso la procedura migliore.

4.2.2

Operazioni preliminari Prima di iniziare la formattazione o il wipe dei i di memorizzazione coinvolti nell’attacco, è importante controllare di avere a disposizione tutti i dischi di installazione originali e gli eventuali aggiornamenti, i codici di registrazione e i numeri telefonici dell’assistenza. Si consiglia inoltre di assicurarsi di disporre dei driver aggiornati e certificati per tutte le periferiche del sistema e di tutte le patch disponibili. Pagina 194 di 334

La cosa migliore è avere tutte queste informazioni a portata di mano prima di iniziare il processo di recupero del sistema: in questo modo non ci saranno interruzioni durante il lavoro di setup. In aggiunta a queste informazioni, si tenga traccia in modo dettagliato di ogni azione effettuata. Le informazioni ottenute in questo modo risulteranno utili per documentare il processo corrente e nel caso in cui si debba reinstallare il sistema in futuro. 4.2.2.1

Verifica dei file di backup

Nel paragrafo 1.1 sono state fornite alcune definizioni di “backup” rapportate al contesto di utilizzo. L’essere attrezzati con backup effettuati regolarmente è molto importante per la gestione dei problemi di sicurezza. Nel caso in cui il sistema venga compromesso, è in questo modo sempre possibile ripristinare i propri dati dai file di backup. Prima di recuperare alcuni file è opportuno effettuare la verifica degli stessi attraverso backup effettuati in momenti differenti, anche molto tempo addietro, in modo da potersi accertare dell’integrità dei file stessi. Infatti l’intruso potrebbe aver compromesso tale file molto tempo prima e i backup più recenti potrebbero quindi contenere una copia già compromessa del file. Ovviamente esistono una serie di problemi di sicurezza relativi ai backup; è quindi opportuno assicurarsi di custodirli in un luogo sicuro, verificare e controllare tutte le persone che vi hanno accesso e sapere con certezza che i backup sono stati creati prima della compromissione. Un metodo di backup semplice è fare una copia di tutto una volta e poi copiare solo quei file che sono stati modificati dal precedente backup. Il primo viene chiamato backup completo, i successivi sono detti backup incrementali. Un backup completo è spesso più laborioso di uno incrementale, dato che bisogna scrivere più dati sul nastro, e un solo nastro (o cdrom) potrebbe non bastare; d’altra parte recuperare dati da backup incrementali può essere molto più faticoso che da un backup completo. Il recupero può essere ottimizzato copiando tutto quello che è stato modificato dall'ultimo backup completo; questo modo di operare è un po' più laborioso, ma non ci dovrebbe mai essere bisogno di recuperare più che un backup completo e uno incrementale. È importante fare bene i backup, assicurarsi che funzionino e che contengano tutti i dati sensibili durante la loro creazione, per evitare di scoprire nel momento del bisogno che c’è qualche problema o dimenticanza. Può anche capitare che tutti i backup siano perfettamente funzionanti, ma che l'ultimo lettore che poteva leggere quel tipo di file non sia più disponibile. È importante sottolineare l’importanza di fare il backup di tutti i dati presenti sulla macchina. L'eccezione principale è costituita dal software che si può facilmente reinstallare, che però può avere file di configurazione importanti e quindi da salvare. Un'altra eccezione importante è il filesystem /proc; dato che contiene solo dati che i kernel genera automaticamente, non è mai una buona idea farne il backup. Specialmente il file /proc/kcore è del tutto inutile, dato che è solo un'immagine della memoria fisica, ed è anche piuttosto grande. Importanti invece sono i file degli utenti (/home) e i file di configurazione del sistema (/etc), ma probabilmente anche altre cose sparpagliate per il filesystem. Pagina 195 di 334

La decisione più importante sui backup è la scelta del mezzo, di cui ricordiamo alcuni importanti parametri di scelta: • il costo: preferibilmente è meglio avere molto più materiale di quello che serve per i dati. Un mezzo economico è di solito indispensabile. • l'affidabilità: un mezzo di backup deve essere in grado di mantenere i dati invariati per anni; il modo in cui lo si usa influisce sulla sua affidabilità: un hard disk è di solito molto affidabile, ma come mezzo di backup non lo è, se si trova nello stesso computer del disco di cui si sta facendo backup; i floppy sono molto economici, non molto veloci, si trovano facilmente, ma sono poco affidabili e non possono essere usati per grandi quantità di dati; i nastri vanno da quelli economici a quelli piuttosto costosi, sono abbastanza affidabili, veloci, disponibili sul mercato e, a seconda della loro capacità, permettono di immagazzinare parecchi dati; i dischi magneto-ottici hanno dei vantaggi sia rispetto ai floppy (hanno alte capacità) che ai nastri (sono ad accesso casuale, rendendo così molto veloce il recupero di un singolo file); il CD-ROM/RW, che ha una capacità media e un prezzo piuttosto basso, può essere riscritto parecchie centinaia di volte e garantisce un’ottima affidabilità; è quindi conveniente per backup molto frequenti e per quantità di dati non troppo elevate. Il DVD-ROM/RAM/RW utilizza la stessa tecnologia dei CD-ROM ma ha capacità decisamente più elevate, fino a 9 Gb. Può quindi memorizzare ingenti quantità di dati e garantire allo stesso tempo la massima affidabilità. Può essere riscritto molte volte e permette di trasferire dati con una buona velocità. • la velocità: spesso non è molto importante, se si possono fare backup senza interazione; d'altra parte, se il backup non può essere fatto quando il computer non sarebbe comunque usato, allora anche la velocità è importante. • la disponibilità sul mercato: la necessità che il mezzo sia disponibile anche in futuro e su computer diversi da quello attuale, altrimenti potrebbe non essere possibile recuperare i dati dopo un disastro. • l'utilizzabilità: un mezzo di backup non deve essere difficile o noioso da usare. Recuperare file con tar L'opzione --extract (-x) di tar estrae dei file dall'archivio:

# tar --extract --same-permissions --verbose --file /dev/fd0H1440 usr/src/ usr/src/linux usr/src/linux-1.2.10-includes/ usr/src/linux-1.2.10-includes/include/ usr/src/linux-1.2.10-includes/include/linux/ usr/src/linux-1.2.10-includes/include/linux/hdreg.h usr/src/linux-1.2.10-includes/include/linux/kernel.h ... #

Si possono anche estrarre file o directory specifiche (compresi tutti i file e le sottodirectory in esse contenuti) dandoli sulla linea di comando: # tar xpvf /dev/fd0H1440 usr/src/linux-1.2.10-includes/include/linux/hdreg.h usr/src/linux-1.2.10-includes/include/linux/hdreg.h

Pagina 196 di 334

#

Si usi l'opzione --list (-t), se se si vogliono solo vedere quali file ci sono in un volume di backup: # tar --list --file /dev/fd0H1440 usr/src/ usr/src/linux usr/src/linux-1.2.10-includes/ usr/src/linux-1.2.10-includes/include/ usr/src/linux-1.2.10-includes/include/linux/ usr/src/linux-1.2.10-includes/include/linux/hdreg.h usr/src/linux-1.2.10-includes/include/linux/kernel.h ... #

Si noti che tar legge sempre i volumi di backup sequenzialmente, quindi per volumi grandi è piuttosto lento. Non è possibile, comunque, usare delle tecniche di accesso casuale quando si usa un'unità a nastro o qualche altro mezzo ad accesso sequenziale. tar non gestisce bene i file che sono stati cancellati. Se si deve recuperare un sistema da un backup completo e uno incrementale, e si sono cancellati dei file tra i due backup, questi esisteranno di nuovo dopo il recupero, il che può essere un problema serio, se questi file hanno dati importanti che non dovrebbero essere più disponibili. Powerquest DriveImage Per completezza si vuole citare anche il software commerciale Powerquest DriveImage con il quale è possibile salvare il file d'immagine che verrà creato (ossia la copia speculare di una partizione o dell'intero disco fisso) su un altro disco fisso, su un'altra partizione o, meglio, su CDROM o su di un'unità esterna (ad esempio un o tipo Iomega Zip). Come la maggior parte dei software di disk imaging, DriveImage deve essere eseguito in modalità DOS a causa delle caratteristiche intrinseche del sistema operativo. Windows, infatti, apre contemporaneamente decine di file e applicazioni. Con così tanti file aperti (pensate poi che ogni applicazione carica in memoria numerose librerie necessarie per il suo funzionamento) sarebbe impossibile creare un'immagine della partizione o del disco. In modalità DOS nessun programma può disturbare il lavoro di DriveImage. 4.2.2.2

Formattazione del disco fisso

Prima di iniziare ad installare nuovamente tutti i software applicativi e di sistema, è necessario effettuare lo wipe o la formattazione dei dispositivi di memorizzazione coinvolti nell’attacco. Gli obiettivi delle azioni che andremo a descrivere consistono nel riportare il sistema al normale stato di funzionamento nel più breve arco di tempo possibile, cercando di ridurre le possibilità di un futuro attacco portato a buon fine. In aggiunta si tenga presente che è bene, nel caso in cui si volessero effettuare delle indagini di tipo forense, effettuare una copia dell’intero sistema su un altro dispositivo di memorizzazione attraverso l’utilizzo di un programma apposito (disk image copier).

Pagina 197 di 334

In questo modo, sarà subito possibile recuperare le macchine senza andare a compromettere alcune importanti evidence e rimandare l’analisi del sistema compromesso ad un momento successivo. Una raw image del sistema è necessaria per ogni tipo di analisi ufficiale, per questo motivo si raccomanda di non tralasciare questo importante step. Infatti, se la macchina vittima dell’attacco venisse modificata o analizzata in un qualunque modo, i dati verrebbero considerati invalidi dalle autorità per il grande numero di file, di sistema e non, che potrebbero essere stati così compromessi. Software di creazione dell’immagine di un disco (es. Encase o DD) forniscono al personale addetto alla gestione dell’incidente e agli esperti di forensic l’ambiente incontaminato di cui hanno bisogno (come descritto nel paragrafo 1.3.3). Per completezza citiamo anche il programma Norton Ghost che permette di fare un'immagine di un disco o partizione locale, e poter ripristinare così il contenuto del disco in pochi minuti e senza problemi. Per utilizzare il programma si deve disporre, oltre all'unità di cui si vuol fare il ghost, di un'altra unità accessibile da DOS. Non è possibile utilizzarlo per dei backup parziali delle unità. Ghost fa un'immagine completa dell'unità; se trova errori, anche questi andranno a finire nell'immagine. Il momento più critico nella ricostruzione di un sistema consiste nello wipe e nella formattazione dei drive di sistema. Questa attività consiste nella distruzione di tutti i dati memorizzati sul disco e rende possibile l’installazione da zero di tutti i software di sistema ripuliti da ogni eventuale virus o worm. Come detto, queste due operazioni cancellano irrimediabilmente tutte le informazioni presenti sul disco. Per questa ragione, ci si potrebbe domandare se non sarebbe possibile, molto più semplicemente, riparare o aggiornare il sistema colpito; questa possibilità è offerta da molti sistemi operativi. Se un sistema viene riparato, processo che richiede normalmente un disco di emergenza o di ripristino, il sistema operativo ripulisce la versione precedente andando a reinstallare o a sostituire i file di sistema più critici o le applicazioni rimosse. Il problema relativo a questo genere di scelta consiste nel fatto che tali operazioni di riparazione ripristinano i file di sistema modificati o cancellati, ma non vanno a controllare tutti i file che sono stati eventualmente aggiunti dall’intruso. In questo modo tutte le eventuali backdoor, applicazioni aggiuntive o ogni altro genere di malicious code viene lasciato installato sul sistema, senza che avvenga alcuna modifica e/o segnalazione. Per questa ragione è fortemente consigliabile la reinstallazione completa del software, preceduta da una procedura di formattazione dell’intero sistema compromesso. Andiamo ora ad analizzare più in dettaglio le attività di wiping, formattazione e partizionamento del disco. Procedura di formattazione La formattazione è il processo con cui si segnano ex-novo sul mezzo magnetico le tracce e i settori. Prima che venga formattato, il disco ha una superficie in cui i segnali magnetici si sovrappongono in maniera caotica, mentre dopo la formattazione si porta un certo ordine nel Pagina 198 di 334

caos, essenzialmente tracciando delle linee dove vanno le tracce e dove esse vengono suddivise in settori. Per quanto riguarda la terminologia, nell'MS-DOS, la parola formattazione viene usata anche per il processo di creazione di un filesystem; i due processi sono spesso combinati. La formattazione reale viene chiamata formattazione a basso livello, mentre la creazione del filesystem si chiama formattazione ad alto livello. Nei circoli UNIX, i due processi vengono chiamati formattazione e creazione di un filesystem. Prima di procedere alla formattazione del o di memorizzazione è bene ricordare di eseguire le seguenti azioni preliminari: • Fare il backup di tutti i dati sensibili; • Creare un disco di ripristino; • Verificare di disporre di tutte le informazioni/software necessari; • Prendere nota di tutte le azioni effettuate. Si inserisca il disco di start-up e quando il pc si riavvia e compare sullo schermo un prompt dei comandi di MS-DOS si digiti il comando fdisk. La schermata che segue illustra la situazione corrente del disco, cioè in quante partizioni logiche è suddiviso.

Le scelte disponibili sono: 1. Creare una nuova partizione o unità logica DOS; 2. Impostare la partizione attiva; 3. Eliminare una partizione o unità logica DOS: 4. Visualizzare le informazioni sulle partizioni, senza effettuare alcuna modifica; 5. Cambiare l’unità disco rigido corrente, se si dispone di più hard disk collegati alla stessa macchina. Per cancellare una partizione si selezioni l'opzione 3. Si ricorda che con questa operazione tutti i dati contenuti nella partizione andranno irrimediabilmente persi. Pagina 199 di 334

Dal menu principale si crei quindi una nuova partizione primaria e le eventuali partizione estesa e unità logiche. A questo punto, si chiuda fdisk e si riavvii il pc pronto per la formattazione. Per fare questo, sempre dal prompt di DOS si digiti FORMAT C: . File System I filesystem comprendono i metodi e le strutture di dati usate da un sistema operativo per tenere traccia dei file su un hard disk o su una sua partizione, cioè il modo in cui i file sono organizzati sui dischi; di questi ne è stata fornita una descrizione nel paragrafo 1.1.2. La differenza tra un disco o una partizione ed il filesystem che esso contiene è molto importante. Alcuni programmi (compresi ovviamente quelli che creano i filesystem) operano direttamente sui settori del disco o della partizione; se c'è un filesystem presente, questo verrà distrutto o seriamente danneggiato. La maggior parte dei programmi operano su un filesystem e quindi non funzioneranno su una partizione che non ne contiene uno (o che ne contiene uno del tipo sbagliato). Prima che si possa usare un disco o una partizione come filesystem, questo deve essere inizializzato e bisogna scriverci le strutture di dati per l'archiviazione: questo processo si chiama creazione di un filesystem. Linux a diversi tipi di filesystem. I più importanti sono: • minix Il più vecchio e molto probabilmente il più affidabile, ma piuttosto limitato (mancano alcuni time stamp, i nomi di file sono al massimo di 30 caratteri) e di capacità ristrette (al massimo 64 MB per filesystem); • xia Una versione modificata del filesystem minix, che alza i limiti sulla lunghezza dei nomi di file e sulla dimensione dei filesystem; non introduce però nuove caratteristiche. Non è molto conosciuto, ma pare che funzioni molto bene; • ext2/ext3 Il più completo dei filesystem nativi di Linux e al momento anche il più usato. È disegnato per essere compatibile in avanti, in modo che per usare nuove versioni del codice non si abbia bisogno di ricreare i filesystem esistenti; • ext Una versione più vecchia dell'ext2 che non era compatibile in avanti. Non è usato quasi mai nelle nuove installazioni, perché la maggior parte delle persone si sono convertite all'ext2/ext3. Oltre a questi vengono ati molti filesystem di altri sistemi operativi, per rendere più semplice lo scambio di file: • msdos Compatibile con i filesystem FAT di MS-DOS (e OS/2 e Windows NT); • usmdos Estende il driver msdos sotto Linux, in modo da avere i nomi di file lunghi, i permessi, i link e i file di device, e da assegnare ciascun file a un utente. In questo modo è possibile usare un normale filesystem msdos come se fosse uno Linux, eliminando la necessità di avere una partizione separata per quest'ultimo; • iso9660 Il filesystem standard per i CD-ROM; viene ata automaticamente l'estensione Rock Ridge allo standard per i CD-ROM, che permette di avere i nomi dei file lunghi; • nfs Un filesystem di rete che permette la condivisione dei file tra vari computer per premettere un accesso più facile; • hpfs Il filesystem di OS/2; • sysv I filesystem SystemV/386, Coherent e Xenix. Pagina 200 di 334

La scelta del filesystem da usare dipende dalla situazione: se ci sono ragioni di compatibilità o altri motivi che rendono indispensabile l'uso di uno dei filesystem non nativi, deve essere usato quello; se si può scegliere liberamente, allora probabilmente la scelta più saggia è l'ext3, dato che ha tutte le caratteristiche e la sua performance è migliore. I filesystem vengono creati, cioè inizializzati, con il comando mkfs. In realtà esiste un programma separato per ciascun tipo di filesystem e mkfs è solo un'interfaccia che avvia quello adatto a seconda del tipo di filesystem desiderato. Il tipo viene selezionato con l'opzione -t tipofs. I programmi richiamati da mkfs hanno interfacce su linea di comando leggermente diverse. Per creare un filesystem ext2/ext3 su un floppy si dovrebbero dare i seguenti comandi: $ fdformat -n /dev/fd0H1440 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... done $ badblocks /dev/fd0H1440 1440 $>$ bad-blocks $ mkfs -t ext2 -l bad-blocks /dev/fd0H1440 mke2fs 0.5a, 5-Apr-94 for EXT2 FS 0.5, 94/03/10 360 inodes, 1440 blocks 72 blocks (5.00%) reserved for the super First data block=1 Block size=1024 (log=0) Fragment size=1024 (log=0) 1 block group 8192 blocks per group, 8192 fragments per group 360 inodes per group Writing inode tables: done Writing superblocks and filesystem ing information: done $

Per prima cosa il floppy viene formattato (l'opzione -n fa in modo che non vengano ricercati i blocchi danneggiati); poi viene attivata la ricerca con badblocks, con l'output rediretto in un file, bad-blocks. Infine, si crea il filesystem, con l'elenco dei blocchi danneggiati letto da ciò che è stato trovato dal comando badblocks. Si poteva usare nello stesso modo l'opzione -c di mkfs invece di badblocks e un file separato, come riportato nell'esempio qui sotto. $ mkfs -t ext2 -c /dev/fd0H1440 mke2fs 0.5a, 5-Apr-94 for EXT2 FS 0.5, 94/03/10 360 inodes, 1440 blocks 72 blocks (5.00%) reserved for the super First data block=1 Block size=1024 (log=0) Fragment size=1024 (log=0) 1 block group 8192 blocks per group, 8192 fragments per group 360 inodes per group Checking for bad blocks (read-only test): done Writing inode tables: done Writing superblocks and filesystem ing information: done $

L'opzione -c è più conveniente che usare separatamente badblocks, ma badblocks è indispensabile per i controlli successivi alla creazione del filesystem.

Pagina 201 di 334

Il processo per preparare i filesystem sugli hard disk o sulle partizioni è lo stesso che per i floppy, tranne che non è necessario formattarli. Non tutti i dischi o le partizioni vengono usati come filesystem: le partizioni di swap, ad esempio, non hanno filesystem. Molti floppy vengono usati come fossero dei nastri, scrivendo direttamente un tar o un altro file sul disco vuoto, senza un filesystem. Evitare il filesystem ha il vantaggio di rendere utilizzabile una parte maggiore del disco, dato che questo occupa sempre dello spazio per l'archiviazione; inoltre, rende il disco più facilmente compatibile con gli altri sistemi: ad esempio, il formato dei file tar è lo stesso su tutti i sistemi, mentre i filesystem sono diversi. Vi abituerete presto ai dischi senza filesystem se ne avrete bisogno. Anche i floppy di boot di Linux non hanno necessariamente un filesystem, anche se possono averlo. Una ragione di usare i dischi senza filesystem è che se ne possono fare copie identiche. Ad esempio, se il disco contiene un filesystem parzialmente danneggiato, è una buona norma farne una copia esatta prima di tentare di ripararlo, in modo da poter ricominciare da capo se cercando di aggiustarlo lo si danneggia ancora di più. Un modo di farlo è usare dd: $ dd if=/dev/fd0H1440 of=floppy-image 2880+0 records in 2880+0 records out $ dd if=floppy-image of=/dev/fd0H1440 2880+0 records in 2880+0 records out $

Il primo comando dd crea un'immagine esatta del floppy nel file floppy-image, il secondo copia l'immagine nel floppy (presumibilmente l'utente ha cambiato floppy prima del secondo comando, altrimenti la coppia di comandi non è molto utile). Procedura di wipe I programmi che offrono funzionalità di wiping permettono di rendere irrecuperabili i file precedentemente eliminati andandoli a sovrascrivere, una o più volte, con dati generati in modo del tutto casuale: in questo modo il recupero dei file risulterà praticamente impossibile. Avviando un’operazione di wiping si potrà, quindi, evitare che qualcuno che dispone dell’accesso al personal computer possa mettere mano a documenti riservati, precedentemente cancellati, ricorrendo all’uso di utilità per il recupero dei file. I programmi migliori generalmente includono la possibilità di optare fra diverse metodologie di wiping. Il metodo standard (Simple, 1x) sovrascrive i dati un’unica volta: è il più veloce ma anche il meno sicuro. Un altro metodo standard è il DoD Method (Department of Defense Method): è probabilmente il più usato perché unisce a prestazioni velocistiche accettabili un ottimo livello di sicurezza. DoD permette di sovrascrivere i dati, in genere, tre volte: una prima "ata" con una sequenza di zero-uno-zero-uno-zero-uno sopra ciascun byte; le successive con dati generati in modo casuale (random). Pagina 202 di 334

Esistono poi metodi ancor più evoluti, come ad esempio l’SFS): essi offrono livelli di sicurezza da servizio segreto ma sono terribilmente lenti anche su dischi fissi SCSI superveloci. Si raccomanda quindi di porre grande attenzione qualora decidiate di eseguire il wiping di un disco fisso o di un qualsiasi altro o di memorizzazione: i dati cancellati non saranno più in alcun modo recuperabili. Qualora, eseguendo un qualunque programma di wiping, il sistema operativo dovesse mostrarvi un messaggio che informa sull’imminente esaurimento dello spazio a disposizione su disco, non eseguite mai l’utilità di Pulitura disco proposta; cliccate invece sul pulsante Annulla.

La funzione per la pulitura del disco di Windows consente di eliminare file non più necessari liberando spazio su disco. Qualora si dovesse avviare la pulitura, questa interferirebbe con l’operazione di wiping rallentandola e, nei casi peggiori, causando problemi al file system. Sure Delete Sure Delete è un programma gratuito, compatibile con tutte le versioni di Windows, sviluppato con un unico obiettivo: offrire un software di semplice utilizzo che permettesse di eseguire il wiping del disco fisso e di qualsiasi altro o di memorizzazione. Il software è costituito da due moduli separati, SD Disk e SD File: l’uno permette di rendere non più recuperabili i file cancellati in precedenza (ciò è possibile sovrascrivendo più volte tutti i cluster del disco marcati come spazio libero), l’altro consente di cancellare file e cartelle in modo sicuro impedendone da subito eventuali tentativi successivi di ripristino. Durante l’utilizzo di SD Disk, dopo aver avviato il wiping sullo spazio libero, è possibile che Windows mostri un messaggio che segnala l’imminente esaurimento dello spazio a disposizione sul disco fisso (il testo completo del messaggio è il seguente: “Spazio su disco dell’unità X esaurito. Per eliminare i file vecchi o inutilizzati e liberare spazio sull’unità, scegliere il pulsante Pulitura disco”). È di importanza fondamentale che non acconsentiate all’esecuzione dell’utilità di Pulitura disco: cliccate sempre sul pulsante Annulla.

Pagina 203 di 334

Anche Sure Delete permette di optare fra tre differenti metodi di wiping: Quick wipe (effettua un wiping rapido), DoD e Super Secure (SFS Method o Gutmann). A seconda del metodo di wiping utilizzato delle dimensioni del disco, l’operazione di wiping può richiedere tempi differenti. 4.2.2.3

Calcolo dello spazio disco

Dopo aver formattato il disco, potrebbe risultare necessario creare, modificare o eliminare lo schema di partizioni precedentemente utilizzato. Non è facile partizionare un disco nel modo migliore possibile. Peggio ancora, non c'è nessun modo corretto per farlo, in quanto vengono coinvolti troppi fattori. La procedura più comune da seguire è avere un filesystem radice (relativamente) piccolo, che contenga /bin, /etc, /dev, /lib, /tmp e altre cose necessarie per fare partire il sistema: in questo modo il filesystem radice (nella sua partizione o sul suo disco) è tutto quello che serve per avviare il sistema. Questo in quanto se il filesystem radice è piccolo e non viene usato pesantemente, è meno probabile che venga corrotto quando si ha un crash del sistema e quindi sarà più facile risolvere qualsiasi problema che si potrebbe venire a creare. Poi si creano delle partizioni separate o si usano dischi separati per l'albero delle directory sotto /usr, le home directory degli utenti (di solito sotto /home) e lo spazio di swap. Separare le home directory (con i file degli utenti) in una partizione distinta rende più facili i backup, dato che spesso non è necessario farlo per i programmi (che risiedono sotto /usr). In un ambiente di rete è anche possibile condividere /usr tra svariate macchine (ad esempio usando NFS) e riducendo così lo spazio disco totale richiesto di diverse decine o centinaia di megabyte moltiplicato per il numero di macchine. Il problema di avere molte partizioni è che ciò divide lo spazio libero totale in piccoli pezzi; oggigiorno, essendo i dischi e i sistemi operativi molto più affidabili, molte persone preferiscono avere solo una partizione che contenga tutti i file. D'altra parte può essere meno doloroso fare il backup (e il restore) di una partizione piccola. Per un hard disk piccolo (assumendo che non sviluppiate il kernel), il modo migliore è probabilmente avere una sola partizione. Per dischi grandi è probabilmente meglio avere alcune partizioni grandi, giusto in caso vada bene qualcosa (notate che “piccola” o “grande” sono termini usati in senso relativo: le soglie sono dettate dal vostro bisogno di spazio disco). Pagina 204 di 334

Se avete più di un disco potete pensare di tenere il filesystem radice (compreso /usr) su uno e le home degli utenti su un altro. Nella documentazione della vostra distribuzione del sistema operativo troverete alcune indicazioni sullo spazio disco necessario per svariate configurazioni; i programmi installati separatamente possono fare lo stesso. In questo modo vi sarà possibile pianificare l'uso dello spazio disco, ma dovreste prepararvi per il futuro e riservare dello spazio extra per le cose di cui vi accorgerete di avere bisogno. 4.2.2.4

Partizionamento

La formattazione di un drive è un’operazione molto semplice: molti moderni sistemi operativi richiedono unicamente l’inserimento di un disco di boot che avvia il processo di installazione e presenta una lista di drive disponibili e di sistemi operativi precedentemente installati. L’operazione successiva consiste nel partizionare lo spazio presente sul o sui dischi selezionati. Tale operazione può essere effettuata, in alcuni casi, in maniera automatica. È però consigliabile, se si ha a disposizione la descrizione della configurazione precedente, mantenerla inalterata. In alternativa, se è necessario un livello di controllo o di assistenza maggiore durante questo processo, oppure se il software disponibile crea dei problemi con il sistema operativo, è possibile servirsi di un’utility in grado di ridimensionare partizioni già esistenti e formattare i drive potendo scegliere tra formati differenti. Un singolo hard disk può essere diviso in diverse partizioni, ciascuna delle quali funziona come se fosse un disco a se stante. Le informazioni sul partizionamento di un hard disk si trovano nel primo settore dello stesso (cioè, il primo settore della prima traccia della prima superficie del disco). Questo settore si chiama master boot record (MBR) del disco: è il settore che il BIOS legge e avvia quando la macchina viene accesa. Il master boot record contiene un piccolo programma che legge la tabella delle partizioni, controlla quale è attiva (cioè quale è contrassegnata come avviabile) e ne legge il primo, ossia il boot sector (settore di avvio) della partizione (anche l'MBR è un settore di avvio, ma ha uno status speciale e quindi un nome speciale). Il boot sector contiene un altro programmino che legge la prima parte del sistema operativo contenuto in quella partizione (sempre che sia bootabile) e lo avvia. La struttura delle partizioni di un hard disk può apparire come in figura: il disco viene diviso in tre partizioni primarie, la seconda delle quali è divisa in due partizioni logiche, e parte del disco non viene partizionato. Il disco intero e ciascuna partizione primaria hanno un settore di boot.

Pagina 205 di 334

Le tabelle delle partizioni (quella nell'MBR, e quelle per le partizioni estese) contengono un byte per partizione che ne identifica il tipo. In questo modo si cerca di identificare il sistema operativo che usa la partizione, o il modo in cui essa viene usata. Non c'è nessuna agenzia di standardizzazione che specifica cosa significhi ciascun valore di questo byte, ma alcuni valori comunemente accettati sono riportati nella tabella sottostante. La stessa lista è disponibile nel programma fdisk di Linux. 0

Vuota

40

Venix 80286

94

Amoeba BBT

1

DOS 12-bit FAT

51

Novell?

a5

BSD/386

2

XENIX root

52

Microport

b7

BSDI fs

3

XENIX usr

63

GNU HURD

b8

BSDI swap

4

DOS 16-bit <32M

64

Novell

c7

Syrinx

5

Estesa

75

PC/IX

db

/M

6

DOS 16-bit >=32M

80

MINIX vecchio

e1

DOS access

7

OS/2 HPFS

81

Linux/MINIX

e3

DOS sola lettura

8

AIX

82

Linux swap

f2

DOS secondaria

9

AIX avviabile

83

Linux nativa

ff

BBT

a

OS/2 Boot Manag

93

Amoeba

Esistono molti programmi per creare e rimuovere partizioni. La maggior parte dei sistemi operativi ne ha uno proprio, ed è una buona idea usare quello del sistema installato, in caso faccia qualcosa di particolare che gli altri non fanno. La maggior parte di questi programmi, compreso quello per Linux, si chiamano fdisk, o variazioni sul tema. I dettagli sull'uso dell'fdisk di Linux sono riportati nella sua pagina man. Il comando cfdisk è simile a fdisk, ma ha un'interfaccia utente più usabile. Ciascuna partizione o partizione estesa ha il proprio file di device. Per convenzione i nomi di questi file sono composti dal nome del disco e dal numero della partizione, tenendo conto che da 1 a 4 si tratta di partizioni primarie (indipendentemente da quante partizioni primarie ci siano in Pagina 206 di 334

realtà), e da 5 a 8 di partizioni logiche (indipendentemente da quale sia la partizione primaria che le contiene). Ad esempio, /dev/hda1 è la prima partizione primaria sul primo disco IDE, e /dev/sdb7 è la terza partizione estesa sul secondo disco SCSI. 4.2.3

Installazione del sistema operativo Dopo aver creato, attraverso gli step descritti in precedenza, un sistema ripulito da ogni genere di malicious code, il o successivo consiste nell’installare il sistema operativo. Questo genere di attività può variare in modo considerevole a seconda del software utilizzato ed è quindi consigliabile seguire le linee guida relative all’installazione fornite dal produttore. In aggiunta, può essere utile verificare la disponibilità di una versione più aggiornata dello stesso sistema operativo o l’utilità di cambiare software, a seconda delle esigenze aziendali.

4.2.3.1

Installazione dei driver aggiornati

Durante il processo di installazione del sistema operativo, verrà richiesto di fornire i driver, qualora questi non siano già inclusi nel cdrom di installazione del sistema stesso, per le periferiche plug-&-play rilevate all’interno del sistema. Si raccomanda di fornire sempre driver aggiornati (solitamente scaricabili dal sito del produttore) e, possibilmente, certificati dalla ditta produttrice del sistema operativo. Prima di procedere all’installazione, i driver scaricati dovranno sempre essere controllati con un antivirus aggiornato e, ove possibile, verificati digitalmente. È comunque sempre preferibile installare un driver meno recente ma di cui possiamo conoscere con certezza la provenienza e la cui affidabilità è stata certificata attraverso una fase di testing. 4.2.3.2

Installazione delle patch di sistema (linux update, windows update)

Dopo aver ultimato l’installazione del sistema operativo e dei relativi driver, è importante applicare tutte le patch sinora rilasciate dal produttore. Qualora si disponga dei cdrom con tutti gli aggiornamenti richiesti, si raccomanda si installarli prima di mettere la macchina ondine. Qualora non si disponesse delle patch necessarie e non si avesse la possibilità di scaricarle da una terza macchina, è possibile effettuare gli aggiornamenti direttamente via Internet, attraverso servizi quali Linux Update e Windows/Office Update. Quest’ultima operazione andrà comunque effettuata una volta installate le patch a in proprio possesso, in quanto nuovi aggiornamenti di sicurezza vengono rilasciati piuttosto frequentemente ed è quindi molto probabile che ne siano usciti di nuovi da quando si è fatto l’ultimo . 4.2.4

Installazione delle applicazioni Dopo aver installato il sistema operativo, si installino le applicazioni, come i server, le utility e tutti i programmi necessari per il corretto svolgimento delle attività aziendali. Pagina 207 di 334

Anche in questo caso, così come per l’installazione del sistema operativo descritta nel paragrafo precedente, il processo di installazione varia a seconda dell’applicazione. È possibile, solo nel caso in cui si ha la certezza che i programmi non siano stati coinvolti nell’attacco, reinstallare le configurazioni critiche e i file di sistema copiandoli dalla macchina compromessa. Si tenga però presente che tale tipo di operazione è molto rischiosa e deve essere eseguita solo nel caso in cui è veramente necessaria e si ha la certezza che i file che si sta andando a copiare non siano stati in alcun modo compromessi. 4.2.4.1

Installazione delle patch

A questo punto è opportuno aggiornare il sistema operativo e le applicazioni installate con le patch a disposizione e altre più aggiornate, eventualmente attraverso file scaricati da siti fidati su Internet. Questi file sono infatti disponibili, spesso con aggiornamenti relativi alla sicurezza, sul sito dell’azienda produttrice. È una buona idea, come già detto in precedenza, raggruppare tutte le patch a disposizione su un unico disco prima di iniziare il processo di reinstallazione del sistema. È inoltre importante non mettere online il sistema fino a quando non è completamente sicuro. Si può anche pensare di prendere nota di tutte le patch applicate per potervi fare riferimento in futuro. 4.2.5

Settaggio delle policy di sicurezza Prima di riconnettere il sistema alla rete, è necessaria una revisione delle politiche di sicurezza, in modo tale da non fornire all’attacker le stesse vulnerabilità sfruttate nella precedente intrusione. Si inizi tale attività rimuovendo tutte le porte inutilmente aperte e tutti i servizi di rete non necessari. Si utilizzi un portscanner (ad es. Nmap, descritto nel par. 4.6) per determinare quali server sono in ascolto e si chiudano tutti quelli non essenziali. In seguito, si controllino tutte le applicazioni attive e si rimuovano tutte quelle ritenute non necessarie. L’obiettivo è quello di creare un sistema molto povero in termini di numero di processi attivi e offerti all’utente, in quanto ciascuno di questi è da considerarsi una potenziale vulnerabilità.

4.2.6

Settaggio delle impostazioni di rete Arrivati a questo punto, si dovrebbe avere a disposizione una replica del sistema originale, ma ancora offline. La ricostruzione di una macchina senza tener in conto la connettività alla rete può essere fatta solo su alcuni sistemi operativi, ma su altri è difficile. Se le circostanze rendono necessario il collegamento del sistema alla rete, è bene procedere con cautela e con la massima attenzione. Ci si accerti che tutti i servizi in ascolto siano spenti prima di connettere la macchina. In aggiunta, la macchina potrebbe essere posta dietro un firewall che blocchi tutto il traffico in entrata. Infine, per evitare che un eventuale virus o worm interno alla rete raggiunga nuovamente la macchina, dovrebbe essere l’unica macchina posta su quel particolare segmento di rete. Pagina 208 di 334

Una macchina senza patch è infatti estremamente vulnerabile ad un grande numero di problemi; per questa ragione, ci si accerti che siano state adottate le corrette tecnologie di difesa prima di collegare una macchina alla rete per effettuare gli aggiornamenti online. È anche consigliabile modificare tutte le del sistema, in quanto l’attaccante potrebbe aver scoperto qualcuna di queste e avere quindi la possibilità di effettuare accessi futuri al sistema. 4.2.7

Test del sistema (penetration/vulnerability test) Uno scanner delle vulnerabilità è un buon programma da utilizzare durante questo processo. Questo genere di tool controlla il sistema attraverso una lista di vulnerabilità note e genera un report di potenziali “buchi” di sicurezza. Ci si accerti che ciascuna di queste vulnerabilità identificate dal processo siano riparate prima di mettere il sistema online.

4.2.7.1

Nessus Per effettuare un controllo sul grado di sicurezza e affidabilità della propria rete è possibile utilizzare i programmi Nessus e nmap (descritti nel par. 4.6). Nessus è un progetto che ha come scopo quello di fornire alla comunità uno strumento potente, facile e gratuito per analizzare e scoprire le vulnerabilità di una rete. Nmap è un'utility per l'esplorazione e l'auditing della propria rete. Disponibile per quasi tutti i sistemi UNIX (Linux, FreeBSD, NetBSD, OpenBSD, Solaris, ...), attualmente non ne esiste una versione per Windows.

4.2.8 Conclusioni Una volta terminate le operazioni sopra descritte, sarà possibile riportare il sistema online. Tutte le azioni intraprese dovrebbero prevenire, almeno in un primo momento, il ritorno dell’attacker all’interno del proprio sistema. Se la macchina venisse nuovamente compromessa in un breve lasso di tempo, le cause potrebbero essere riscontrate nella mancata individuazione della reale vulnerabilità che ha portato alla compromissione del sistema, oppure nella presenza di un’ulteriore vulnerabilità non individuata in precedenza. Per questa ragione è sempre opportuno monitorare costantemente il sistema attraverso la revisione dei file di log e l’utilizzo di meccanismi di sicurezza quali i tool di check dei file e gli Intrusion Detection System.

Pagina 209 di 334

4.3 Rimozione di tutti i programmi utilizzati per realizzare l’intrusione e di tutte le modifiche determinate dall’intrusione e Reinstallazione dei programmi eseguibili e dei file binari dai i di distribuzione originali. 4.3.1

Punti chiave per la rilevazione dell’intrusione su sistemi UNIX

Ricerca di segnali che attestino la compromissione del sistema 1.

2.

Esaminare i files di log al fine di trovare collegamenti dati da situazioni o attività inusuali. Per esempio, prendere visione del ‘last’ log contenente informazioni relative agli accessi effettuati dagli utenti, tutti i log creati da syslog e tutti gli altri security log. Se il firewall o il router usato scrive una posizione differente dal sistema compromesso, ricordarsi di controllare anche questi log. Notare che questo approccio non è infallibile fino a che non si scrivono log su media che permettano solamente di eseguire operazioni di append; in situazione diverse da quella appena citata, molti abili intrusi sono in grado di modificare i log tentando di nascondere le tracce del loro aggio. Controllare i files con setuid e setgid attivi presenti in tutto il sistema, in modo particolare i files con setuid proprietari di root. Spesso gli intrusi lasciano nascoste nel sistema copie di file con setuid come /bin/bash o /bin/time in modo da garantirsi un futuro accesso al sistema con permessi di root. Il programma find di UNIX può essere usato per trovare all’interno dell’albero di sistema file setuid di root e setgid kmem file. Per esempio, possono essere usati comandi di ricerca come i seguenti per fare una ricerca estesa all’interno sistema: find / - root -perm -4000 –print find / -group kmem -perm -2000 –print

E’ da notare che gli esempi fatti percorrono l’intero albero delle directory del sistema, compresi filesystem NFS/AFS montati. Alcune versioni di find ano l’opzione “-xdev” che permette di evitare la ricerca in queste tipologie di gerarchie. Per esempio: find / - root -perm -4000 -print –xdev

Un’altro modo per cercare file di tipo setuid è tramite il comando ncheck eseguto su ogni partizione del sistema. Per esempio, il comando seguente ricerca setuid files e device speciali sulla partizione /dev/rsd0g: ncheck –s /dev/rsd0g

3.

Controllare i binari di sistema per accertarsi che siano stati alterati. Gli intrusi possono alterare i programmi di base dei sistemi UNIX come , su, telnet, netstat, ifconfig, ls, find, du, df, libc, sync, alcuni binari citati in /etc/inetd.conf, altri programmi di sistema critici e librerie di oggetti condivisi. E’ necessario comparare le versioni presenti sul proprio sistema con copie note e riconosciute dei file in questione, come ad esempio quelle provenienti dal o di installazione del sistema. Bisogna prestare attenzione quando si fa affidamento a copie di backup e tenere presente che copie di backup potrebbero essere infettate da Trojan Horse. I Trojan Horse potrebbero in alcuni casi produrre lo stesso checksum e timestamp dei file come nelle versioni Pagina 210 di 334

4. 5.

6.

7.

8.

9.

legittime. A causa di questo, il programma standard di UNIX sum e il timestamp associato con i programmi non sono sufficienti per determinare se il programma è stato sostituito con una copia alterata. L’utilizzo di programmi come cmp, MD5, Tripwire e altri strumenti di controllo crittografico sono sufficienti ad identificare i Trojan Horse, sempre a patto che anche questi ultimi strumenti siano sicuri e non alterati dall’intruso. In aggiunta è possibile tenere in considerazione l’uso di tool (per esempio PGP) per “firmare” l’output generato da MD5 o Tripwire per un futuro utilizzo. Controllare se sono stati utilizzati programmi di monitoring della rete, chiamati in gergo “sniffer” o “packet sniffer”. Gli intrusi potrebbero avere utilizzato questo genere di strumenti per catturare informazioni riservate degli utenti e le loro relative . Esaminare tutti i file lanciati da ‘cron’ e ‘at’. Alcuni intrusi lasciano back door in file lanciati da ‘cron’ o sottoposti ad ‘at’. Queste tecniche permettono all’intruso di guadagnare nuovamente l’accesso al sistema. Verificare anche che tutti i file/programmi referenziati (direttamente o indirettamente) da ‘cron’ ed ‘at’, ed essi stessi, non siano scrivibili da tutti gli utenti. Controllare che non ci siano servizi non autorizzati. Ispezionare /etc/inetd.conf per cercare aggiunte o cambiamenti non autorizzati. In modo particolare, ricercare righe che eseguono programmi di shell (per esempio, /bin/sh o /bin/csh) e controllare la validità di tutti i programmi che sono specificati in /etc/inetd.conf verificando che non siano stati sostituiti da Trojan Horse. Controllare anche i servizi ‘legittimi’ che sono stati decommentati in /etc/inetd.conf. L’intruso potrebbe avere abilitato un servizio che pensavamo fosse stato disabilitato precedentemente oppure potrebbe avere sostituito inetd con un Trojan Horse. Esaminare il file /etc/wd del sistema e controllare che non siano state effettuate modifiche al file. Controllare in modo particolare che non siano stati aggiunti nuovi utente, senza , o cambiamenti di UID (specialmente a UID 0, quella di root) di esistenti. Controllare che non siano state introdotte modifiche non autorizzate nella configurazione di sistema e di rete. Guardare in modo particolare se sono stati aggiunti dei ‘+’ (segno più) e nomi di host non locali inappropriati in /etc/hosts.equiv, /etc/hosts.lpd, e in tutti i file .rhosts (in modo particolare root, uu, ftp, e altri di sistema). Questi file non dovrebbero essere scrivibili da tutti. In aggiunta controllare anche che questi file esistano da prima dell’intrusione avvenuta e che non siano stati quindi creati dell’intruso. Cercare in tutto il sistema file inusuali o nascosti (i file che iniziano con un punto e che non sono normalmente visualizzati da ‘ls’) che possono essere usati per nascondere strumenti e informazioni (programmi di cracking, file di relativi ad altri sistemi, etc.). Una tecnica comune sui sistemi UNIX è quella di creare una directory nascosta all’interno di un utente con un nome insolito, qualcosa come ‘…’ o ‘.. ’ (punto punto spazio) o ‘..^G’ (punto punto control-G). Il programma find può essere usato nuovamente per cercare questo tipo di file nascosti, per esempio con: find / -name ".. " -print -xdev find / -name ".*" -print -xdev | cat –v

Anche file con nomi come ‘.xx’ e ‘.mail’ sono stati usati (ovvero file che potrebbero apparire del tutto normali). 10. Esaminare tutte le macchine della rete locale quando si stanno cercando tracce di intrusione. Gran parte delle volte, se un host è stato compromesso, lo sono anche altre macchine presenti sulla stessa rete. Questo è vero in modo particolare per le reti in cui è attivo il demone NIS o dove gli Pagina 211 di 334

host si scambiano relazioni di fiducia tra essi tramite l’uso dei file .rhosts e/o /etc/hosts.equiv. Per sapere se qualche demone NIS è in esecuzione: ps –ef | grep yp

Potrebbero essere in escuzione ‘ypbind’ o ‘ypserv’. Anche altri demoni come ‘rpc.wd’ o ‘rpc.ypwdd’ potrebbero essere in esecuzione. 4.3.2 1.

2. 3.

4. 5.

6.

Punti chiave per la rilevazione dell’intrusione su sistemi Windows NT Esaminare i file di log alla ricerca di connessioni o attività insolite. E’ possibile utilizzare Event Viewer per controllare la presenza di inusuali strani logon, falle dei servizi o insoliti reboot del sistema. Nel caso vi siano installati firewall, web server o router che loggano al di fuori del sistema compromesso, controllare con attenzione questi log, ricordandosi che spesso gli intrusi modificano i file di log al fine di occultare la loro attività. Controllare o gruppi di utenti insoliti. E’ possibile utilizzare Manager o i comandi ‘net ’, ‘net group’ e ‘net localgroup’ dalla linea di comando. Assicurarsi che l’ guest sia disabilitato se il sistema non lo richiede. Controllare tutti i gruppi per la presenza di eventuali hip di utenti non valide. Alcuni dei gruppi di default in NT forniscono speciali privilegi ai membri di quel gruppo. I membri del gruppo s possono compiere qualsiasi attività sul sistema, i Backup Operators possono leggere qualsiasi file del sistema. I Power s possono creare condivisioni. Controllare se esistono inappropriati permessi utente, tramite Manager sotto le voci Policy, Rights. Ci sono 27 differenti permessi che possono essere assegnati a utenti o gruppi. Solitamente la configurazione di default per questi permessi è sicura. Controllare se sono state fatte partire applicazioni non autorizzate. Ci sono parecchi diversi metodi con cui un intruso potrebbe far partire un programma back doork, pertanto assicurarsi di: • controllare le cartelle di Startup. Notare che ve ne sono due: una per l’utente locale e una per tutti gli utenti. Quando un utente si logga, tutte le applicazioni in “All s” vengono fatte partire, pertanto controllare eventuali applicazioni sospette; • controllare il registro Locazioni 1; • controllare se esistono servizi insoliti. Alcuni programmi backdoor si autoinstallano come servizi, i quali vengono caricati al boot della macchina. I servizi possono essere abilitati tramite il privilegio utente “Logon as Service”. Controllare i servizi eseguiti automaticamente all’avvio ed assicurarsi che siano necessari. Verificare inoltre che i file eseguibili non siano programmi Trojan horse o backdoor. Controllare eventuali alterazioni dei binari confrontando le versioni sul sistema con copie fidate e non alterate. Porre comunque attenzione nell’utilizzo di copie di backup, poiché anche queste potrebbero contenere Trojan horse. I programmi Trojan horse possono produrre la stessa dimensione e lo stesso timestamp dell’originale del file, pertanto controllare le proprietà del file e i timestamp associati con i programmi non è sufficiente a determinare se i programmi siano stati modificati. E’ possibile utilizzare tool quali Tripwire, MD5 e altri che effettuano checksum crittografico, al fine di individuare eventuali modifiche apportate a programmi o file, purché i tool di checksum siano mantenuti in luogo sicuro, evitando così modifiche da parte dell’intruso. Pagina 212 di 334

7.

8. 9. 10.

11. 12. 13.

14.

Utilizzare un tool, ad esempio PGP, per firmare l’output generato da MD5 o Tripwire, per referenze future. L’utilizzo di software antivirus aiuta nella ricerca di virus, backdoor e trojan horse, tuttavia poiché vengono continuamente creati malicious programs mantenere aggiornato costantemente il proprio antivirus. Controllare il sistema e le configurazioni di rete per eventuali modifiche non autorizzate nelle impostazioni del WINS, DNS, IP forwarding, ecc. Tale controllo è effettuabile usando dalle proprietà di rete o tramite “ipconfig/all” da linea di comando. Assicurarsi che solo le proprietà di rete desiderate sul sistema siano presenti nella configurazione. Controllare la presenza di porte inusuali in ascolto per connessioni ad altri host usando il comando “netstat –an”. Un lista dei “well-known port number” è disponibile al seguente indirizzo http://www.iana.org/assignments/port-numbers. Porte aggiuntive utilizzate dai prodotti Microsoft sono disponibili nei seguenti articoli: Windows NT, Terminal Server, and Microsoft Exchange Services Use T/IP Ports http://.microsoft.com//kb/articles/q150/5/43.asp SMS: Network Ports Used by Remote Helpdesk Functions http://.microsoft.com//kb/articles/q167/1/28.asp XGEN: T Ports and Microsoft Exchange: In-depth Discussion http://.microsoft.com//kb/articles/q176/4/66.asp How to Configure a Firewall for Windows NT and Trusts http://.microsoft.com//kb/articles/q179/4/42.asp Controllare se esistono condivisioni indesiderate tramite il comando “net share” da linea di comando o utilizzando lo strumento Server Manager per elencare tutte le condivisioni nel sistema. E’ possibile visualizzare condivisioni nascoste aggiungendo il simbolo ‘$’ alla fine del nome di una condivisione. Pertanto disabilitare tutte quelle condivisioni che NT ha di default ma che non si rendono necessarie (per esempio: PRINT$ ma senza stampante condivisa). Gli intrusi possono lasciare backdoor in file presenti nello scheduler per attività future, permettendo ad un intruso di ritornare nel sistema. Pertanto verificare che tutti i file e programmi referenziati dallo scheduler e gli stessi job file siano protetti da scrittura. Per controllare i lavori attualmente in sospeso usare il comando “at” o il tool WINAT dal resource kit di NT. Verificare la presenza di strani processi attraverso Task Manager o i comandi pulist.exe e tlist.exe dal resource kit NT. Tuttavia vi è un diverso numero di applicazioni shareware/freeware che mostrano i file attualmente in uso. Col comando pulist è possibile sapere chi ha avviato ogni processo, mentre col comando “tlist –t” è possibile sapere quali processi sono stati generati da altri processi. Scandire il sistema alla ricerca di eventuali file insoliti o nascosti, file che possono contenere programmi per il crack delle , file di di altri sistemi, ecc. E’ possibile scoprire tali file attraverso l’utilizzo di Explorer, selezionando dal campo Strumenti, la voce Opzioni Cartella, Visualizza tutti i file. Per visualizzare file nascosti è possibile utilizzare il comando “dir/ah”. Controllare eventuali alterazioni dei permessi su file o chiavi di registro. Un modo per garantire sicurezza su un sistema NT è quello di impostare correttamente i permessi su file o chiavi di registro, in modo che utenti non autorizzati non possano far partire programmi non autorizzati (per es. backdoor o keylogger) o modificare i file del sistema. Al fine di controllare i file delle varie directory del sistema utilizzare il programma xcacls.exe che è parte del Resource kit di NT. Il Security Configuration Manager di NT può essere usato per analizzare Pagina 213 di 334

15.

16.

4.3.3

il sistema, controllando una configurazione precedentemente definita. Questo aiuta a determinare se sono stato apportate eventuali modifiche. Controllare se vi sono alterazioni delle policy utente e del sistema. Le politiche sono utilizzate sui sistemi NT per definire una grande varietà di configurazioni e per controllare ciò che gli utenti possono e non possono fare. E’ consigliato preservare una copia della corrente configurazione delle politiche, utile nel caso vengano modificate e sia necessario determinare quali aspetti sono stati alterati. Assicurarsi che il sistema non sia stato ridefinito in un dominio differente. Un intruso potrebbe accedere a una workstation come Amministratore di dominio cambiando il dominio corrente in uno sul quale ha pieno controllo. Ripristino post intrusione

Ricordarsi sempre che se una macchina è compromessa, qualsiasi cosa sul sistema potrebbe essere stata modificata, incluso il kernel, binari, file di dati, processi running, e la memoria. In generale, l’unico modo fidato per ottenere la macchina ripulita da backdoor e modifiche dell’intruso è quello di reinstallare il sistema operativo dai i di distribuzione originali e installare tutte le patch di sicurezza prima di connettere la macchina alla rete. Riconoscere le vulnerabilità sfruttate dall’intruso e installarne le relative patch può non essere sufficiente. E’ pertanto consigliato fare un restore del sistema usando binari fidati, reinstallando il sistema operativo usando i i di distribuzione originali. Successivamente configurare il sistema con i soli servizi che si vogliono offrire, non uno di più. Controllare che non vi siano punti deboli nei file di configurazione di questi servizi e che questi servizi siano disponibili solo ad altri sistemi fidati. In generale, la policy più conservativa è quella di cominciare disabilitando tutto e abilitando solo servizi necessari. Configurati i servizi si può are alla fase di installazione delle patch di sicurezza. Tale fase è fortemente consigliata, ed è di fondamentale importanza assicurarsi che siano stati installati i set di patch per ognuno dei propri sistemi. Un’altra operazione fondamentale consiste nell’effettuare regolarmente aggiornamenti delle patch installate, assicurandosi della loro provenienza e integrità. E’ possibile tenersi aggiornati consultando periodicamente bollettini di sicurezza, quali i Past AusCert advisories e gli External Security Bulletins, disponibili all’indirizzo http://www.auscert.org.au/Information/Advisories/esb_advisories.html Nel ripristinare i dati da un backup, assicurarsi che quest’ultimo provenga da una macchina non compromessa, poiché esiste il rischio di reintrodurre le stesse vulnerabilità sfruttate dall’intruso per accedere al sistema. Inoltre, nel caso si stiano ripristinando solamente file di dati e le cartelle personali degli utenti, ricordarsi che ognuno di questi file potrebbe contenere un Trojan horse. Porre particolare attenzione ai file .rhosts nelle cartelle personali degli utenti. 4.3.4 i per il recupero di un sistema UNIX o NT compromesso 4.3.4.1 Individuazione file modificati durante l’intrusione Con il sistema disconnesso dalla rete è possibile are in rassegna i file di log e di configurazione alla ricerca di tracce di intrusione, modifiche e vulnerabilità. Pagina 214 di 334

Nel cercare le modifiche dei file di configurazione e del software di sistema, tenere presente che i tool utilizzati sul sistema compromesso per verificare l’integrità dei suddetti potrebbero essere a loro volta modificati; anche il kernel potrebbe essere modificato, pertanto è conveniente eseguire il boot da un kernel fidato. Su sistemi UNIX è possibile creare un boot disk e proteggerlo in scrittura. E’ necessario effettuare un controllo dei binari di sistema con quelli presenti sui i di distribuzione originali. Alcuni binari sostituiti da Trojan horse nei sistemi UNIX: telnet, in.telnetd, , su, ftp, ls, ps, netstat, ifconfig, find, du, df, libc, sync, inetd, and syslogd. Inoltre è utile controllare ogni binario referenziato in /etc/intetd.conf, reti critiche e programmi di sistema, librerie condivise. Su sistemi NT i Trojan horse di solito introducono virus o programmi di amministrazione remota. Ci sono stati casi in cui il file di sistema che gestisce la connessione internet era stato sostituito con un Trojan horse. Poiché alcuni Trojan horse possono avere lo stesso timestamp dei binari originali e dare il corretto valore di sum, si raccomanda di usare cmp sui sistemi UNIX per un diretto confronto dei binari e dei i di distribuzione originali. Altrimenti è possibile controllare il checksum MD5, sia sotto UNIX che NT, dei binari sospetti col checksum di binari fidati. Nell’ispezionare i file di configurazione su sistemi UNIX, occorre: • controllare il file /etc/wd alla ricerca “valori” estranei; • controllare se /etc/inetd.conf è stato modificato; • se è consentito “r-commands” (r, rsh, rexec), assicurarsi che non ci sia niente contenuto in /etc/host.equiv o in alcun .rhost file; • controllare eventuali nuovi file SUID o SGID; il seguente comando stamperà tutti i file SUID e SGID all’interno del filesystem # find / \( -perm -004000 -o -perm -002000 \) -type f –print

Nell’ispezionare sistemi NT, occorre: • controllare se ci sono utenti o gruppi d’utenti insoliti; • controllare eventuali modifiche ai valori dei registri, che caricano programmi al logon oppure servizi (http://www.cert.org/tech_tips/win-listings.html#A); • controllare eventuali condivisioni nascoste non autorizzate col comando “net share” o col tool Server Manager; • controllare processi non identificati col tool pulist.exe da NT Task Manager o NT resurce kit. 4.3.4.2

Individuazione dati modificati

I dati presenti all’interno di un sistema compromesso sono spesso modificati dagli intrusi, pertanto è consigliato verificare l’integrità di: • pagine web • archivi ftp • file nell’home dell’utente • ogni altro tipo di file presente nel sistema Pagina 215 di 334

4.3.4.3

Individuazione dati e tool usati dall’intruso

Gli intrusi avranno quasi certamente installato tool personalizzati al fine di monitorare o accedere al sistema compromesso. Le più comuni categorie di file lasciati dagli intrusi sono: 1. Sniffer di rete Utility che monitora e registra le attività di rete in un file. Gli intrusi di solito li usano per catturare name e , inviati in chiaro lungo la rete. 2. Trojan Horse Programmi che sembrano svolgere una determinata funzione mentre in realtà svolgono funzioni differenti. Sono utilizzati dagli intrusi per nascondere la loro attività, catturare name e , e inoltre creare backdoor per garantirsi accessi futuri al sistema compromesso. 3. Backdoor Progettati per nascondersi all’interno dell’host, target dell’intrusione, consentono a chi li installa di accedere al sistema senza il bisogno di autenticarsi o di sfruttare vulnerabilità. 4. Vulnerabilità La maggior parte delle intrusioni sono il risultato di macchine con versioni software vulnerabili. Gli intrusi spesso usano tool che sfruttano vulnerabilità conosciute, guadagnandosi accessi non autorizzati. Questi tool sono spesso lasciati nel sistema all’interno di directory nascoste. 5. Altri tool di intrusione Oltre ai tool sopra citati, possono essercene altri lasciati dall’intruso all’interno del sistema. Alcuni potrebbero essere tool per: • sondare i sistemi alla ricerca di vulnerabilità (probing); • effettuare probing esteso su altri siti; • effettuare attacchi DoS; • usare le risorse di computazione e di rete. Output dei tool d’intrusione 6. E’ possibile trovare file di log per un certo numero di tool di intrusione. Questi file di log possono contenere informazioni riguardo altri siti coinvolti, vulnerabilità delle proprie macchine compromesse e di altri siti. E’ consigliato effettuare ricerche accurate di tali tool e file di output, assicurandosi di utilizzare copie fidate dei tool utilizzati per la ricerca dei tool di intrusione. Durante la ricerca dei tool di intrusione su un sistema compromesso: • su sistemi UNIX, cercare inattesi file ASCII nella directory /dev, oppure binari Trojan nei file di configurazione, spesso locati in /dev; • cercare molto attentamente eventuali file o directory nascoste, presenti se un intruso ha creato un nuovo e una directory di home; • su sistemi UNIX, cercare file o directory con nomi strani come “…”(tre punti) o “.. “ (due punti e alcuni spazi); gli intrusi spesso creano e nascondono file all’interno di tali directory. Pagina 216 di 334

•

Su sistemi NT, cercare file e directory che potrebbero assomigliare a file di sistema (EXPLORE.EXE, UMGR32.EXE, etc).

4.3.4.4 Chkrootkit Chkrootkit è uno strumento per determinare localmente sul sistema tracce di rootkit. Il pacchetto scaricabile dall’homepage dello strumento contiene: • chkrootkit: E’ lo script che esegue il controllo sui binari di sistema per identificare alterazioni a questi file dovute all’uso di rootkit sul sistema in esame. Vengono eseguiti i seguenti test: o aliens asp bindshell lkm rexedcs sniffer wted w55808 scalper slapper z2 amd basename biff chfn chsh cron date du dirname echo egrep env find fingerd gpm grep hdparm su ifconfig inetd inetdconf init identd killall ldsopreload ls lsof mail mingetty netstat named wd pidof pop2 pop3 ps pstree rpcinfo rd rshd s sendmail sshd syslogd tar td tdump top telnetd timed traceroute vdir w write • ifpromisc.c: Controlla se l’interfaccia di rete di trova in modo promiscuo. • chklastlog.c: Controlla se sono state fatte cancellazioni in lastlog. • chkwtmp.c: Controlla se sono state fatte cancellazioni in wtmp. • check_wtmpx.c: Controlla per cancellazioni in wtmpx. (solo Solaris) • chkproc.c: Controlla se ci sono tracce di LKM troiani. • chkdirs.c: Controlla se ci sono tracce di LKM troiani. • strings.c: Sostituzione di stringhe in modo veloce e ‘sporco’ chkwtmp e chklastlog ‘provano’ a determinare la cancellazione di entries nei file wtmp e lastlog, ma non è garantito che ogni tipo di modifica sia rilevata. Aliens tenta di trovare log di sniffer e file di configurazione di sniffer. Cerca in alcune locazioni di default del sistema. Anche in questo caso non è garantito che la ricerca abbia successo in ogni caso. chkproc controlla se le entries in /proc sono nascoste dal comando di sistema ‘ps’ e dalla chiamata di sistema ‘readdir’. Questo potrebbe essere l’indicatore della presenza di LKM troiani. Questo comando può essere eseguito con l’opzione –v per ottenere un output del programma più prolisso. Installazione L’operazione di installazione del tool è abbastanza semplice. Prima di tutto decomprimere il tarball in una directory come nel seguente esempio in /usr/local: # tar xfvz chkrootkit.tar.gz -C /usr/local/

Una volta posizionati all’interno della directory in cui è stato decompresso il tarball è possibile compilare tutti i programmi digitando: # make sense gcc -DHAVE_LASTLOG_H -o chklastlog chklastlog.c

Pagina 217 di 334

gcc -DHAVE_LASTLOG_H -o chkwtmp chkwtmp.c gcc -DHAVE_LASTLOG_H -o ifpromisc ifpromisc.c gcc -o chkproc chkproc.c gcc -o chkdirs chkdirs.c gcc -o check_wtmpx check_wtmpx.c gcc -static -o strings strings.c

In questo modo vengono generati tutti i programmi descritti precedentemente. Utilizzo chkrootkit deve essere eseguito con i privilegi di root. Il modo più semplice per eseguirlo è digitando il comando: # ./chkrootkit

In questo modo vengono eseguiti tutti i test. E’ possibile specificare esclusivamente i test che desideriamo eseguire come mostrato qui sotto: Usage: ./chkrootkit [options] [test ...] Options: -h show this help and exit -V show version information and exit -l show available tests and exit -d debug -q quiet mode -x expert mode -r dir use dir as the root directory -p dir1:dir2:dirN path for the external commands used by chkrootkit

Dove ‘testname’ può essere sostituito con uno o più dei test presenti nella lista seguente: aliens asp bindshell lkm rexedcs sniffer w55808 wted scalper slapper z2 amd basename biff chfn chsh cron date du dirname echo egrep env find fingerd gpm grep hdparm su ifconfig inetd inetdconf identd init killall ldsopreload ls lsof mail mingetty netstat named wd pidof pop2 pop3 ps pstree rpcinfo rd rshd s sendmail sshd syslogd tar td tdump top telnetd timed traceroute vdir w write Per esempio il comando seguente controlla che non ci siano Trojan Horse nei binari ‘ps’ e ‘ls’ e inoltre controlla se la l’interfaccia di rete si trova in modo promiscuo. # ./chkrootkit ps ls sniffer

Con l’opzione ‘-x’ è possibile esaminare stringhe sospette presenti all’interno dei binari e che potrebbero identificare la presenza di Trojan Horse. In questo caso tutta l’analisi è lasciata all’utente. Per effettuare questo tipo di analisi è possibile lanciare: # ./chkrootkit -x | more

Per cercare nomi di percorso all’interno dei comandi di sistema: Pagina 218 di 334

# ./chkrootkit -x | egrep '^/'

Chkrootkit per eseguire i suoi test utilizza i seguenti comandi: awk, cut, egrep, find, head, id, ls, netstat, ps, strings, sed, uname. Per mezzo dell’opzione ‘-p’ è possibile fornire a chkrootkit un percorso alternativo da cui caricare dei binari non compromessi per eseguire i suoi test. Per esempio, per usare dei binari presenti su un cdrom è possibile lanciare, dopo aver montato il dispositivo cdrom: # ./chkrootkit -p /cdrom/bin

A volte risulta utile montare il disco di una macchina compromessa su una macchina di fiducia ed eseguire i test da quest’ultima. Basta montare il disco e specificare la nuova rootdir con l’opzione ‘-r’. Per esempio, supponendo di aver montato il disco sotto /mnt, digitare: # ./chkrootkit -r /mnt

Messaggi di output I seguenti messaggi sono stampati a schermo da chkrootkit (ad eccezione delle opzioni ‘-x’ e ‘-q’) durante il suo funzionamento: "INFECTED": Il test ha identificato un comando probabilmente modificato da un rootkit conosciuto; "not infected": Il test non ha individuato tracce di rootkit conosciuti. "not tested": Il test non è stato eseguito; questo può avvenire in alcune situzioni: a) il test è dipendente dal SO; b) il test dipende da un programma esterno che non è disponibile; c) sono state inserite alcune opzioni specifiche a linea di comando (es: ‘-r’). "not found": il comando da testare non è disponibile; "Vulnerable but disabled": il comando è infetto ma non in uso. (non in esecuzione o commentato in inetd.conf) E’ stato identificato un comando troianizzato. Cosa fare? Il problema più grande è determinato dal fatto che la macchina è stata compromessa e l’intruso possiede i privilegi di root. Probabilmente può essere risolto il problema sostituendo i comandi troianizzati. Il modo migliore per fare questa operazione è quello di reinstallare i comandi da un media di installazione sicuro. 4.3.4.5 Tripwire Tripwire è un software Open Source Security, Intrusion Detection, Damage Assessment and Recovery, Forensics. Pagina 219 di 334

E’ un programma basato su policy che controlla l’integrità di file e directory, rilevando eventuali modifiche tramite il confronto con un database crittato, contenente le informazioni precedentemente salvate. Ogni differenza è segnalata e loggata in un report, con l’inclusione di entries aggiunte o cancellate. Eseguito su file di sistema permette di segnare i cambiamenti di file critici di sistema e prendere immediatamente le contromisure. Tripwire lavora in cinque diverse modalità, vediamole in dettaglio: 1. Database Initialization Mode È il primo step effettuato al momento dell’installazione. Viene creato il database, una “fotografia” degli oggetti presenti nel sistema, nella locazione specificata dalla varibile DBFILE presente nel file di configurazione. In questa modalità, tripwire legge il file di policy e genera il relativo database crittato. Da riga di comando è possibile usare le opzioni per specificare quale politica, configurazione, e file chiave usare nella creazione del databse. Se nessuna opzione è specificata, vengono usati i valori di default del corrente file di configurazione. 2. Integrity Checking Mode Dopo la costruzione del database, viene scandito il sistema alla ricerca di violazioni, come specificato nel file di policy. Usando le regole di tale file, Tripwire confronta lo stato attuale del file system con quello salvato nel database. Viene quindi creato un report, salvato nella locazione specificata dal REPORTFILE presente nel file di configurazione. Tale report descrive ogni violazione dettagliatamente (a seconda che l’oggetto sia stato aggiunto, cancellato o modificato) elencando le proprietà dell’oggetto prima e dopo. Se vi sono differenze, l’amministratore può sostituire il file corrotto con l’originale presente nel database (es. un intruso ha sostituito /bin/), oppure aggiornare il database con l’attuale versione del file (es. un altro amministratore ha installato una nuova versione di /usr/local/bin/emacs). L’opzione –I o – interactive permette di aprire un editor e aggiornare velocemente il database. 3. Database Update Mode Permette di aggiornare il contenuto del database sulla base delle informazioni presenti nel report di un controllo di integrità. Le voci da modificare sono specificate in una “ballot box” del report all’interno di un editor e specificate con una x di fianco a ogni violazione di policy. Dopo l’uscita dall’editor l’utente fornisce la corretta phrase locale e tripwire aggiorna il database. Opzioni per questa operazione: flag -Z o –secure-mode e –a o –accept-all. 4. Policy Update Mode Usato da Tripwire per modificare o aggiornare il file di policy e di conseguenza sincronizzare il database. Il modo in cui vengono interpretate le violazioni dipende dal livello di sicurezza specificato con l’opzione –Z o –secure-mode. Alto livello(default): elenco delle violazioni senza modifiche al database. Basso livello: elenco violazioni con aggiornamento automatico del database. 5. Test Mode Modalità per verificare l’operazione di notifica tramite e-mail, il cui settaggio è specificato nel file di configurazione. Se MAILMETHOD è settato a SMTP, i valori SMTPHOST e SMTPPORT saranno usati per inviare la mail. Se MAILMETHOD è settato a SENDMAIL verrà usato il valore MAILPROGRAM. Se tale notifica funziona correttamente, l’indirizzo specificato in linea di comando riceverà il seguente messaggio: Pagina 220 di 334

To: [email protected] From: < [email protected]> Subject: Test email message from Tripwire If you receive this message, email notification from Tripwire is working correctly

Utilizzo dello strumento Alcuni semplici i per installare Tripwire sul sistema, possono essere sintetizzati nel seguente modo: Step 1: Configurazione post installazione Tripwire possiede due file file importanti, uno di configurazione (/etc/tripwire/twcfg.txt) e un file di policy (/etc/tripwire/twpol.txt) i quali vanno modificati al fine di attare le funzionalità del tool alla configurazione del proprio sistema. Le modifiche a questi file di configurazione vanno effettuate prima di eseguire lo script /etc/tripwire/twinstall.sh. Se vengono fatte modifiche a questi file dopo l’esecuzione di tala script di installazione è necessario lanciarlo nuovamente al fine di salvare le nuove modifiche apportate alla configurazione. Step 2: Lanciare lo script ‘twinstall.sh’ Questo script permette all’utente di are per tutti gli step necessari per installare lo strumento. Il primo o è eseguire lo script: # /etc/tripwire/twinstall.sh

La prima cosa che fa è chiedere la “site keyfile phrase”: Enter the site keyfile phrase: the site keyfile phrase: Generating key (this may take several minutes)...

In un secondo momento viene richiesta una “local keyfile phrase”: Enter the local keyfile phrase: the local keyfile phrase: Generating key (this may take several minutes)...

Una volta generati i file di chiave, lo script firmerà la nostra configurazione e i file di policy. Verrà chiesta nuovamente la nostra “site phrase” a ogni aggio di questo procedimento: g configuration file... Please enter your site phrase: Wrote configuration file: /etc/tripwire/tw.cfg A clear-text version of the Tripwire configuration file /etc/tripwire/twcfg.txt has been preserved for your inspection. It is recommended that you delete this file manually after you have examined it. ---------------------------------------------g policy file...

Pagina 221 di 334

Please enter your site phrase: Wrote policy file: /etc/tripwire/tw.pol A clear-text version of the Tripwire policy file /etc/tripwire/twpol.txt has been preserved for your inspection. This implements a minimal policy, intended only to test essential Tripwire functionality. You should edit the policy file to describe your system, and then use tw to generate a new signed copy of the Tripwire policy.

Lo script di installazione provvede anche alla generazione di chiavi crittate che usa poi per firmare e quindi proteggere i file di configurazione e di policy. Una volta crittate e firmate il file di configurazione /etc/tripwire/tw.cfg e di policy /etc/tripwire/tw.pol generate dallo script /etc/tripwire/twinstall.sh è consigliata la rimozione dei file di configurazione in chiaro /etc/tripwire/twcfg.txt e /etc/tripwire/twpol.txt che contengono la versione leggibile da tutti della configurazione di Tripwire. Una volta spostati o rimossi è possibile vedere quelli crittati e firmati tramite l’utility ‘tw’ con le opzioni ‘--print-cfgfile’ e ‘--print-polfile’. Sempre con la stessa utility è possibile designare un file di testo esistente (quindi in chiaro) come nuovo file di policy o configurazione: attraverso l’uso della ‘site key’ impostata nella fasi precedenti il nuovo file viene crittato e salvato. Le opzioni utilizzabili sono ‘--create-cfgfile’ e ‘--create-polfile’. Step 3: Inizializzare il Database Il aggio successivo è l’inizializzazione del database. Tripwire a questo punto erà in rassegna tutti i file definiti precedentemente nelle policy utilizzate e salverà tutte le informazioni relative al loro stato. In seguito, quando verrà richiesto di generare un report, i binari saranno confrontati con i valori salvati per controllarne l’integrità. Per inizializzare il database eseguire il comando: # tripwire –init Please enter your local phrase: Parsing policy file: /etc/tripwire/tw.pol Generating the database...

Potremmo vedere messaggi del tipo “No such file or directory”. Non allarmarsi. Se non viene scelto di abilitare un servizio o se viene rimosso un pacchetto verranno stampati a schermo questi avvisi inoffensivi. Quando tutto è completo, viene stampato a video un messaggio di questo tipo: Wrote database file: /var/lib/tripwire/localhost.localdomain.twd The database was successfully generated. Tripwire is now successfully configured and installed.

Step 4: Lanciare l’Integrity Check Quando viene lanciato l’Integrity Check, Tripwire confronta gli oggetti presenti nel filesystem al momento dell’esecuzione del test con le loro proprietà memorizzate precedentemente nel database durante la fase di inizializzazione. Eventuali violazioni vengono stampate a video e salvate in un file di report che può essere visionato successivamente con l’utility ‘twprint’. Per lanciare l’Integrity Check, basta usare il comando: # tripwire –-check

Il test ha una durata dipendente dal numero di file da analizzare e dalle prestazioni del sistema. Pagina 222 di 334

Una volta eseguiti correttamente gli step descritti precedentemente, Tripwire ha una vera e propria ‘fotografia’ dello stato del sistema che verrà usata successivamente per trovare le eventuali modifiche avvenute ai file critici di sistema. Può essere utile creare una script da posizionare per esempio dentro a /etc/cron.daily che esegua in modo automatico il controllo di integrità dei file di sistema critici giorno dopo giorno. Uno script di base che si puù trovare già incluso in alcune versioni di Tripwire è: #!/bin/sh HOST_NAME=`uname -n` if [ ! -e /var/lib/tripwire/${HOST_NAME}.twd ] ; then echo "**** Error: Tripwire database for ${HOST_NAME} not found. ****" echo "**** Run "/etc/tripwire/twinstall.sh" and/or "tripwire --init". ****" else test -f /etc/tripwire/tw.cfg && /usr/sbin/tripwire --check fi

4.3.4.6

LSOF

Lsof è stato soprannominato il coltellino svizzero dell’intrusion detection per il vasto range nel quale il tool può essere impiegato alla ricerca di tracce di intrusione. Ma come parecchi tool è tanto utile quanto l’esperienza di chi l’utilizza, soprattutto riguardo lsof, a causa della sua versatilità. Opzioni comuni Utilizzando lsof senza opzioni si genera una lista enorme di file aperti (a seconda del sistema) che è troppo vasta per essere utile. Tuttavia questa lista potrebbe aiutare a capire qual è il “normale” comportamento del sistema. All’inizio, le due opzioni maggiormente utilizzate sono: -p e –i. Opzione –p: elenca i file aperti per un determinato process id. Per esempio, per vedere i processi associati a init, digitare: lsof –p 1. Opzione –P: il tool non converte i numeri di porta coi relativi nomi dei programmi associati con essi. Opzione –i: il tool esamina le porte aperte in listening per eventuali tentativi di collegamento. Ciò aiuta a rilevare segni di intrusione e mettere in evidenza servizi aperti non necessari. Esempio: # lsof –i | grep LISTEN

Lsof dispone di due modalità avanzate di utilizzo. Utilizzo con altri comandi L’output di lsof può essere utilizzato come input per altri comandi. Probabilmente il più evidente di questi è utilizzare lsof con grep. I dati possono essere manipolati con criteri specifici utilizzando grep, adattando così le ricerche in modo più specifico. Automatizzazione tramite script Una volta diventati più familiari con lsof e i processi più importanti del sistema, è possibile creare script allo scopo di automatizzare la noiosa fase di revisione dell’output di lsof. Una volta Pagina 223 di 334

stabilita una baseline per i vari processi (ricordando che alcuni processi potrebbero non essere buoni candidati a tale baseline), bisogna controllare eventuali scostamenti da tale baseline. Per esempio, è possibile generare uno script che crea una lista dei processi di rete aperti tramite lsof –i e la confronta periodicamente con quella corrente. Se questo confronto evidenzia differenze nel numero dei processi aperti o altri criteri predefiniti, lo script può avvisare l’amministratore che qualcosa è cambiato. Seguendo questa logica, è possibile automatizzare la ricerca di irregolarità in un ampio range di processi di sistema. Ricordarsi che l’automazione dipende dalle proprie decisioni in base al comportamento tipico del sistema. Pertanto se le decisioni iniziali sono sbagliate o incomplete si avrà un falso senso di sicurezza o un gran numero di falsi positivi su cui indagare. Esempi di utilizzo Per listare tutti i file aperti: # lsof

Per listare tutti gli UNIX e X.25(HP-UX) domain file: # lsof

-i –U

Per listare tutti i file di rete Ipv4 aperti e in uso dal processo il cui PID è 1234, usare: # lsof

-i 4 –a –p 1234

Nel caso il sistema i Ipv6, per elencare tutti i file di rete Ipv6 in uso: # lsof –i 6

Per listare tutti i file di ogni tipo di protocollo sulle porte 513, 514, o 515 dell’host locale, usare: # lsof –i :513-515

Per elencare tutti i file di tutti i protocolli e tutte le porte utilizzate usare: # lsof –i

Per elencare tutti i file per il nome di “abe” o l’ID utente 1234 o il processo 567, usare: # lsof –p 567 –u 1234,abe

Per elencare tutti i file aperti sul device /dev/hd4: # lsof /dev/hd4

Per trovare il processo che ha aperto il file /u/abe/foo, usare: # lsof /u/abe/foo

Pagina 224 di 334

4.4 Determinare se sussitono vulnerabilità nella rete e correggerle 4.4.1

4.4.2

Introduzione La comunità degli esperti di sicurezza delle reti informatiche scopre nuove vulnerabilità tutti i giorni. A volte le minacce proliferano in una sola notte, altre volte invece ano mesi prima che le vulnerabilità siano sfruttate ai danni di aziende in tutto il mondo. Fino a poco tempo fa la maggior parte degli attacchi organizzati era diretta contro i siti governativi e quelli delle grandi multinazionali. Di pari o con lo sviluppo di strumenti di attacco sempre più evoluti ed automatizzati facilmente reperibili, gli hacker non-professionisti sono in grado di prendere di mira reti non altrettanto ben protette, come quelle delle piccole e medie imprese e finanche delle reti domestiche connesse in banda larga ad Internet. Definizioni

Cos'è l'Audit di Sicurezza delle reti E' un processo che identifica i device (computing equipment) della rete e le vulnerabilità di cui sono affetti. Queste informazioni possono essere usate per misurare la sicurezza, gestire i rischi ed eliminare le vulnerabilità prima che utenti non autorizzati possano sfruttare i potenziali buchi di sicurezza.

Concetto di “Analisi delle vulnerabilità” E' il processo preventivo d' identificazione delle vulnerabilità delle reti e dei relativi device prima che virus, hackers, trojan horses, worms possano sfruttare i buchi di sicurezza.

Vulnerability scan Il documento tratterà gli aspetti relativi alla determinazione della vulnerabilità facendo riferimento al tool NESSUS. Il progetto Nessus si propone di offrire alla comunità internet uno strumento gratuito potente e sempre aggiornato in grado di effettuare vulnerability scan da remoto. Un security scanner è uno strumento che permette di verificare, all’ interno di una determinata rete, la presenza di falle di sicurezza che potrebbero permettere un accesso non autorizzato al sistema. 4.4.3

Port scan Per permettere a due o più applicazioni, in esecuzioni su sistemi diversi, di comunicare tra loro è necessario determinare quali saranno le porte di comunicazione che verranno usate, per questo i pacchetti generati al livello di trasporto del protocollo T, dovranno contenere nel proprio header le informazioni riguardanti le porte sorgente e destinazione che verranno utilizzate per lo scambio dei messaggi. Schema dell’ header del protocollo T:

Pagina 225 di 334

Essendo di 16 bit il campo relativo alle porte sorgente e destinazione dell’ header T gli identificativi vanno da 0 a 1024 per le cosiddette “ porte privilegiate” e da 1025 a 65536 per quelle “ non privilegiate”. Solitamente si usa associare una determinata porta e una specifica applicazione, un esempio: ftp-data ftp ssh smtp domain www www pop3 irc x11

20/t 21/t 22/t 25/t 53/udp 80/t 80/udp 110/t 194/t 6000/t

mail nameserver http pop-3 x11-0

# SSH Remote Protocol # # # # #

WorldWideWeb HTTP HyperText Transfer Protocol POP version 3 Internet Relay Chat X windows system

Un elenco delle associazioni porte <–> servizio conosciute può essere reperito all’indirizzo: http://www.iana.org/assignments/port-numbers Un semplice scan si basa sulla ricerche delle cosiddette “ porte aperte”, ovvero verificare se sono attivati e disponibili determinati servizi sul sistema, e se è possibile dialogare con essi. È comunque possibile associare a ogni servizio una porta casuale, senza rispettare lo standard. Associare una porta “non privilegiata” a un web server potrebbe nasconderne in parte la presenza e quindi essere meno vulnerabile agli attacchi. Una volta rilevata la presenza di un “demone” attivo, ovvero di un servizio pronto a dialogare con altri, è possibile cominciare a reperire le prime informazioni utili a un attacco, come ad esempio la versione del WebServer o di SSHD presente nel sistema, una volta ottenuta sarà possibile generare una serie di attacchi mirati a sfruttare le vulnerabilità note di quella versione. Per questo motivo è di fondamentale importanza mantenere sempre aggiornati i servizi di sistema che devono essere visibili all’esterno della rete. Pagina 226 di 334

4.4.4 Nmap Una prima tecnica di scansione delle porte si basa sull’ utilizzo di nmap. Una volta creata la rete e configurato il firewall è possibile testarne l’efficacia lanciando il comando: # nmap [metodo_di_scansione] [opzioni] {nodo|rete} Nmap effettua un port scan di tutte le porte possibili basandosi sulle opzioni impostate e fornisce l’elenco delle porte : • Aperte (porte a cui corrisponde un servizio che accetta la connessione) • Chiuse (porte che rispondono con un segnale di reset della connessione) • Filtrate (porte filtrate da qualcosa, per le quali non si può determinare se esista effettivamente un servizio disponibile) Possibili opzioni di nmap: -sS

Esegue una scansione di tipo T SYN, che è quella predefinita se l'utente è root.

-sT

Esegue una scansione «normale», attraverso la funzione connect() del sistema operativo, che è quella predefinita se richiesta da un utente comune senza privilegi.

-sF

Scansione di tipo T FIN.

-sX

Scansione nota come Xmas tree.

-sN

Scansione nota come Null scan.

-sP

Scansione attraverso l'invio di richieste di eco ICMP (ping); serve soltanto per determinare la presenza dei nodi ipotizzati.

-sU

Scansione alla ricerca di servizi UDP.

-sO

Scansione IP, per determinare quali protocolli IP sono disponibili.

-sA

Scansione T ACK, per determinare la presenza di un firewall e delle sue caratteristiche generali.

-sW

Scansione Window, intesa come una variante del metodo ottenuto con l'opzione -sA.

-sR

Scansione RPC, da abbinare a un altro metodo di scansione, per determinare se le porte di servizi disponibili corrispondono a servizi RPC.

4.4.5

Nessus Il progetto Nessus si propone di offrire alla comunità internet uno strumento gratuito potente e sempre aggiornato in grado di effettuare vulnerability scan da remoto. Caratteristiche del tool: Scan Intelligente Pagina 227 di 334

Differentemente dagli altri security scanner, Nessus “non da nulla per scontato”. Questo significa che non viene fatta nessuna ipotesi sull’ associazione servizio <-> numero di porta. Se per qualche motivo un Web Server è in esecuzione sulla porta 1234, Nessus lo identifica e effettua lo scan relativamente a quel servizio. Inoltre lo scan non sarà basato sulla versione del servizio, ma su tutte vulnerabilità note. Modulare Basandosi su un’ architettura client/server, Nessus fornisce un’ estrema flessibilità d’ uso. Il demone viene eseguito e per mezzo del client, sia testuale che grafico, può essere amministrato da remoto, permettendo a client diversi l’utilizzo del server da postazioni differenti. Il tool è in grado di effettuare scan simultanei di un elevato numero di host, il numero varia a seconda della potenza di calcolo del sistema che ospita il Server Nessus. Un’ altra caratteristica riguarda la capacità di rilevare la presenza di servizi moltiplicati sulla stessa macchina, come ad esempio l’esistenza di due Web Server che rispondono a porte differenti. In questi casi lo scan viene eseguito per entrambi i servizi.

Architettura Plug-in Ogni test di sicurezza è scritto come plug-in indipendente e esterno al funzionamento di Nessus, per questo motivo scrivere i propri script di scanning non comporta lo studio del funzionamento dell’ interno programma. Il comando “nessus-update-plugin” permette di mantenere Nessus sempre aggiornato relativamente agli ultimi plugin disponibili e alle nuove vulnerabilità scoperte.

NASL

Pagina 228 di 334

Nesuss include, Nessus Attack Scripting Language, ovvero il linguaggio per la generazione dei plug-in, e quindi la possibilità di riscrivere specifici scan relativamente al contesto di rete da analizzare. Sempre Aggiornato Nel database reperibile all’ indirizzo http://www.nessus.org/scripts.php è possibile scaricare gli ultimi aggiornamenti relativi ai bachi di sicurezza appena scoperti. Il database viene aggiornato con frequenza giornaliera. Ottimizzato Nessus permette un’ accurata selezione dei plug-in che verranno usati durante lo scan, questo aspetto è molto utile nei casi in cui sia necessario testare solo determinate caratteristiche della rete. Inoltre la funzionalità “safe check” permette uno scan non intrusivo ma basato sulla rilevazione delle versioni dei servizi in esecuzione senza tentarne l’exploit. o SSL Nessus permette lo scan dei servizi che si appoggiano al protocollo sicuro SSL, come https, imaps, smtps e altri, semplicemente fornendo al server Nessus i certificati che verranno inseriti nel suo ambiente PKI. Report delle scansioni Nessun fornisce, oltre alle informazioni relative alle falle di sicurezza rilevate, anche le possibili soluzioni e un indice (Alto, Medio, Basso) che identifica la pericolosità dell’ exploit scoperto. Il report generato può essere convertito in formato XML, HTML, Test, Latex. Attualmente Nessus a più di 1200 test di vulnerabilità, che si dividono in 23 categorie principali: Backdoors CGI abuses CISCO Denial of Service Finger abuses Firewalls FTP Gain a shell remotely Gain root remotely General Misc. Netware NIS Port scanners Remote file access RPC Settings SMTP problems SNMP Untested Useless services Windows Windows : management

Pagina 229 di 334

Requisiti di sistema Nessus Server Nessus Server può essere compilato e eseguito sui sistemi: • NetBSD • GNU/Linux • FreeBSD • Solaris Nessus Client Nei sistemi unix Nessus Client usa le librerie GTK La versione Win32 funziona con tutti i sistemi operativi Microsoft Windows. 4.4.5.1 Installazione in sistemi Unix Esistono tre diverse procedure di installazione di Nessus. Prima Procedura (Standard e sicura) Scaricare dal sito ufficiale di Nessus e compilare nel seguente ordine i sorgenti: • • • •

nessus-libraries libnasl nessus-core nessus-plugins

Seconda Procedura (Facile ma rischiosa) Se è necessario installare Nessus su un computer direttamente connesso a internet e provvisto del tool lynx digitare (Non con privilegi di root): #

lynx -source http://install.nessus.org | sh

Con questa modalità di installazione si impone l’ esecuzione di un comando remoto sul proprio sistema, nell’ eventualità che un intruso si intrometta nella comunicazione impersonificando il vostro DNS, il comando eseguito non sarebbe sicuro e potrebbe contenere codice dannoso. Terza Procedura (Facile e veloce) Scaricare dal sito ufficiale il file autoinstallante ed eseguirlo: # nessus-installer.sh L’installazione delle diverse componenti di Nessus avverrà in modo automatico.

Pagina 230 di 334

4.4.5.2 Utilizzo di Nessus Nessus è costituito da due componenti fondamentali, il Server (nessusd) e il client (nessus). La versione server è in grado di funzionare su tutti i sistemi basati su Unix, e in questa sezione verrà utilizzato Linux per la sua esecuzione. Il client, oltre che per sistemi Unix, esiste anche per ambiente Windows. Dopo aver installato i due componenti è necessario configurare il Server che dovrà soddisfare tutte le richieste provenienti dai client. Nessus fornisce un efficiente organizzazione degli utenti che possono usufruire della versione Server installata su un sistema remoto. Ogni utente avrà accesso al server con determinati privilegi, sia legati alle tipologie di scan effettuabili, sia legate alla limitazione degli host analizzabili. Questa strutturazione dello strumento permette l’ utilizzo da parte di molti utenti, in luoghi diversi, dello stesso server. 4.4.5.3 Creazione e rimozione degli utenti Il primo o relativo alla configurazione del server, identificato anche come “nessusd”, è l’ aggiunta degli utenti. Il comando utilizzato per questa operazione è: # nesuss-add nessus-add è un semplice programma che permette di inserire nel file configurazione di nessusd gli attributi degli utenti creati, in particolare verrà richiesto di inserire: • • • •

Autentication Type Rules

Benché l’ uso di e sia banale è utile descrivere gli altri due aspetti. Autentication Type permette di scegliere se l’autenticazione tra server e client avverrà in chiaro o con procedura crittata. Rules usato per specificare i privilegi dell’ utente. Ogni utente a un suo specifico set di regole che restringono il range di host scannabili. La sintassi è: • accept | deny ip / mask • default accept | deny Esempio: Le seguenti regole permettono all’ utente creato di eseguire scan verso gli host identificati dagli ip 192.168.1.0/24 , 192.168.3.0/24 , 172.22.0.0/16, e relativa netmask (in notazione binaria) e bloccare di default tutto il resto. accept 192.168.1.0/24 accept 192.168.3.0/24 Pagina 231 di 334

accept 172.22.0.0/16 default deny Per rimuovere un utente viene usato il comando: # nessus-rm 4.4.5.4 Configurazione avanzata del server Di default, dopo l’ installazione, viene creato il file di configurazione di Nessus Sever e scritto in : /usr/local/etc/nessus/nessusd.conf Il file contiene diversi parametri, inizialmente impostati a valori standard, che se necessario, possono essere modificati secondo le esigenze. Il file è commentato e quindi autoesplicativo ma citiamo i più importanti: Percorso della directory contenente i plug-in fino a quel momento riconosciuti da Nessus: plugins_folder = /usr/local/lib/nessus/plugins Numero massimo di host simultaneamente scannabili (30 di default): max_hosts = 30 Percorso della directory contenente il log file di Nessus: logfile = /usr/local/var/nessus/logs/nessusd.messages Nel caso in cui il Sistema che ospita Nessus Sever sia protetto da firewall, sarà necessario aprire sia in ingresso che in uscita la porta 1241. Un esempio di configurazione di iptables può essere: ###INPUT### $IPTABLES -A INPUT -i $EXTIF -p t --dport 1241 -m state --state ESTABLISHED -j ACCEPT

###OUTPUT### $IPTABLES -A OUTPUT -o $EXTIF -p t --sport 1241 -m state --state ESTABLISHED -j ACCEPT

4.4.5.5 Avvio di nessus server Una volta configurato, il server può essere lanciato usando il comando: # nessusd [-c config-file] [-a address ] [-p port-number] [-D] –D,

esegue nessusd in background

-c ,

specifica un file di configurazione

-a

,

impone a nessusd di accettare solo connessioni provenienti da un determinato indirizzo ip Pagina 232 di 334

-p <port-number>,

imposta la porta di ascolto del server nessus , 1241 (default)

4.4.5.6 Impostazione e uso del client Il client di Nessus esiste sia per sistemi Unix che Windows. La versione per Unix viene installata automaticamente insieme al server, mentre per Windows attualmente sono disponibili: • NeWT 1.0 (porting della versione Unix, commerciale) • NessusWX (client nativo win32) Per avviare il client è necessario eseguire il comando nessus.

• • • •

Nessusd host, identifica l’ indirizzo del server su cui è in esecuzione Nessus Server (nessusd) Port, numero della porta di comunicazione in ascolto sul server e dell’ utente creato Pulsante , per iniziare l’autenticazione

Pagina 233 di 334

Nel caso in cui si voglia assicurare una maggiore sicurezza nella comunicazione tra server e client ed evitare un attacco del tipo “man in the middle”, è possibile impostare il client per l’ uso di una chiave SSL certificata da un Certificate Authority. Una volta autenticati al sistema, il pulsante di log-in diventa log-out, ed è possibile iniziare l’impostazione dello scan. La sezione Plugin visualizza la lista dei possibili scan da effettuare e viene caricata dal server remoto, qui è possibile scegliere ogni singola tipologia di scan ordinata in base alle diverse famiglie elencate precedentemente.

Si noti che effettuando un scan del tipo Denial of Service è molto probabile che la connettività del sistema target venga a mancare. L’ utente può anche utilizzare la funzione plugin per inviare al server nessusd nuovi script di scan, per questa operazione però deve essere munito degli appropriati privilegi. Nella sezione preferences è possibile affinare le tecniche di scan immettendo e dei servizi attivi sul target. Tali informazioni vengono usati per offrire ulteriori informazioni e dati nel report finale. Scan option è utilizzato per impostare le modalità di scan, un elenco: Pagina 234 di 334

• •

Port range, il server effettuerà uno scan delle porte rispettando il range impostato Port Scanner, impone a nessusd di usare uno specifico scanner, il più noto e nmap ma ne esistono altri, tali port scanner devono essere installati nel sistema. • Host to test, numero di host scannabili allo stesso momento • Detached Scan, ovvero la possibilità di avviare lo scan in background disconnettendo server e client. • Consider port Closed, deve essere usata quando si presume che il sistema target sia protetto da un firewall. • Sezione Target, qui viene impostato l’ indirizzo ip o host name del sistema che dovrà essere sottoposto allo scan. La notazione varia a seconda che si deva analizzare un solo host o una range di indirizzi: Esempio: 10.163.156.1 10.163.156.1-254 10.163.156.1-10.163.159.254 10.163.156.1/24 hope.fr.nessus.org

Un singolo host Un range di host Un range di host (come sopra diversa notazione) (Range di host notazione binaria ) (Uso dell’ host name)

In questa sezione è inoltre possibile utilizzare una funzionalità avanzata di Nessus ovvero il salvataggio della sessione. Quando uno scan deve essere effettuato su un elevato range di indirizzi e per altri motivi deve interrotto, la sessione di analisi può essere ripristinata in un secondo tempo risparmiando così molto tempo. Nella sezione si può affinare la sezione target escludendo da un range di ip un particolare host, sintassi: reject default accept / reject Una volta certi che gli ip target siano corretti, onde evitare particolari problemi riguardanti le policy di sicurezza aziendali, è possibile avviare lo scan che, a seconda della quantità di plugin selezionati potrà richiedere diverso tempo.

Pagina 235 di 334

Report Finale Terminato lo scan verrà generato un report esportabile nei formati : NBE, NSR, HTML, ASCII, LaTeX e strutturato nel seguente modo: Sezione subnet La sezione subnet suddivide il range di host analizzati in base alle diverse sottoreti presenti Sezione Host Per ogni sottorete sono elencati tutti gli host scannati Port Selezionando un host di una sottorete appare l’ elenco delle vulnerabilità riscontrate ordinate in base al numero di porta. Gravità Ad ogni vulnerabilità trovata è associato un determinato livello di rischio Descrizione La descrizione della vulnerabilità e le possibili contromisure da adottare per la sua eliminazione

Pagina 236 di 334

4.4.5.7 Nessus funzionalità avanzate La descrizione fatta in precedenza illustra come può essere usato il tool facendo uso di una configurazione di base al fine di fornire l’ analisi e i risultati di determinati sistemi target. Esistono tuttavia funzionalità avanzate, sperimentali, che migliorano l’attività di Nessus sia per quello che riguarda l’ efficienza degli scan sia dal punto di vista della sua gestione. Salvataggio della knowledge base (kb) Traduciamo il termine come “conoscenza acquisita”, ovvero quella serie di dati e informazioni generati da Nessus nel corso di un’analisi. L’idea è quella di salvare tutti i dati relativi ad un determinato sistema e riutilizzarli quando verrà rieseguito lo scan. Supponiamo di aver effettuato lo scan di un sistema rivolto nello specifico all’ FTP server in esecuzione su di esso specificando inoltre, nella sezione preferences, e al fine di ottenere un’ analisi più specifica e precisa. Nel caso in cui si debba rieseguire lo scan a distanza di qualche giorno o mese, se la Pagina 237 di 334

configurazione dell’ FTP server non è cambiata, sarebbe inutile cercare di nuovo le vulnerabilità di questo servizio. Per questo motivo il salvataggio di queste informazioni permette a Nessus di: • • •

risparmiare tempo limitare l’uso della banda testare le vulnerabilità della rete solo per nuove vulnerabilità

kb è considerata un’ opzione sperimentale per questo motivo deve essere attivata a tempo di compilazione con il comando: # cd nessus-core # ./configure --enable-save-kb Per usare questa funzionalità è necessario attivarla nella sezione kb del client di Nessus, tutte le informazioni raccolte durante l’ analisi daranno salvate sul disco dell’ host remoto nella directory: /usr/local/var/nessus/name/kbs/ dove name è il dell’ utente in uso. Salvataggio della sessione Scannare una rete richiede tempo e utilizzo di banda, se durante un’analisi uno o più host cadono, per diverse ragioni, sarà necessario rieseguire il test di vulnerabilità dall’ inizio. L’ opzione session saving nella sezione target salva in: /usr/local/var/nessus/name/ tutti i dati scambiati tra client e server e permetto il ripristino dello scan dal punto in cui era stato interrotto. Come knowledge base, session saving è un’ opzione sperimentale e deve essere compilata con il comando: # cd nessus-core # ./configure --enable-save-sessions Abilitare l’ opzione nella sezione target, dopo il crash e la riconessione al server Nessus le informazioni slavate saranno visualizzate nel riquadro. Le sessioni salvate possono essere anche cancellate.

Pagina 238 di 334

4.5 Migliorare gli strumenti di protezione per limitare l’esposizione dei sistemi e della rete. Nella fase di lesson learning, a fronte dell’avvenuta intrusione, risulta senz’altro opportuno rimettere in discussione la validità delle policy di sicurezza e della soluzione organizzativa adottate (argomento approfondito in altro contesto) in base soprattutto ai risultati che l’intrusione ha portato. Contemporaneamente è opportuno andare ad effettuare verifiche e correzioni su quei sistemi di protezione che sono stati oggetto dell’ intrusione, facendo riferimento alle policy aziendali per quanto riguarda gli aspetti organizzativi e di impostazione, ai fornitori di hardware e software per gli aggiornamenti e le patch o hot-fix. In generale verranno qui indicate alcune tra le più probabili fonti di intrusione per i sistemi Windows e Unix, così come segnalato dal SANS Institute1, per poi dare alcune indicazioni riguardanti i firewall e la loro revisione.

4.5.1 WINDOWS 4.5.1.1

Internet Information Services (IIS) IIS, che interessa nelle sue varie versioni i sistemi operativi Windows, è ibile di vulnerabilità in tre grandi categorie: problemi di gestione di richieste inattese, problemi di “buffer overflow” e vulnerabilità legate alle applicazioni di esempio: a) Problemi di gestione di richieste inattese. Molte vulnerabilità di IIS sono dovute a problemi di gestione delle richieste http non corrette o volutamente composte in modo anomalo. Un ben noto esempio è la vulnerabilità Unicode sfruttata dal worm Code Blue. b) Problemi di buffer overflow. Molte estensioni ISAPI (incluse le estensioni ASP, HTR, IDQ, PRINTER e SSI) sono vulnerabili ai buffer overflow (es. estensione ISAPI .idq sfruttata dai worm Code Red e Code Red II). c) Problemi legati alle applicazioni di esempio. Le applicazioni di esempio sono di solito progettate per esemplificare le funzionalità di un ambiente server e non per resistere ad attacchi, e non sono nate per essere applicazioni da utilizzare se non in fase di test. Se a ciò si aggiunge il fatto che è noto a tutti il loro indirizzo di default e che il loro codice sorgente è disponibile per scopo di analisi, si capisce come esse siano gli obiettivi preferiti degli exploit. La protezione da queste vulnerabilità possono essere fornite sia da hot-fix che da pacchetti cumulativi, dato l’elevato numero di bug. Per migliorare dunque il livello di protezione di IIS è consigliabile seguire le seguenti indicazioni:

1

i.

Applicare le patch o Service Pack più recenti,

ii.

Rimanere aggiornati, ovvero essere tempestivi ad applicare le patch non appena vengono approntate a fronte di nuove vulnerabilità. Può essere utile utilizzare uno

“The Twenty Most Critical Internet Security Vulnerabilities”, Sans Institute 2003

Pagina 239 di 334

strumento (HFNetChk – Network Security Hotfix Checker) che aiuta gli amministratori di sistema ad analizzare se nei sistemi locali e remoti sono state installate le patch più recenti,

4.5.1.2

iii.

Eliminare le applicazioni di esempio non appena si è verificato che l’installazione sia corretta e che il server funzioni nel modo atteso,

iv.

Disabilitare le estensioni ISAPI non necessarie: infatti la maggior parte dei sistemi IIS non ha bisogno di molte estensioni ISAPI che sono mappate per default e quelle non utilizzate dovrebbero essere disabilitate. Uno strumento che può essere utilizzato allo scopo è IIS Lockdown Wizard di Microsoft,

v.

Filtrare le richieste http: si può configurare il filtro URLScan per respingere tali richieste prima che il server tenti di processarle. URLScan è integrato in IIS Lockdown Wizard ma può essere anche scaricato separatamente.

Microsoft Data Access Components (MDAC) – Remote Data Services Il componente Remote Data Services (RDS) nelle versioni meno recenti del Microsoft Data Access Components (MDAC) presenta un baco che permette agli utenti remoti di eseguire comandi locali con privilegi di amministratore. Nella maggior parte dei sistemi Windows NT 4.0, sfruttando il baco assieme ad una vulnerabilità nel Microsoft Jet database engine 3.5 (componente di MS Access), un exploit può anche stabilire un accesso anonimo dall’esterno ai database interni. Queste vulnerabilità sono ben documentate e i rimedi sono disponibili da tempo, ma i sistemi non aggiornati o mal configurati ne sono ancora esposti e sono ancora soggetti ad attacchi di questo tipo. Dopo aver verificato l’esistenza di “msadcs.dl” (solitamente è installata in “C:\Program Files\Common Files\System\msadcs.dl”, ma può anche cambiare a seconda dei sistemi), si può fare riferimento ad alcune guide e/o avvisi di sicurezza che indicano come proteggersi attraverso alcune modifiche alla configurazione: http://www.wiretrip.net/rfp/p/doc.asp?id=29&iface=2 http://.microsoft.com//kb/articles/q184/3/75.asp http://www.microsoft.com/technet/security/bulletin/ms98-004.asp http://www.microsoft.com/technet/security/bulletin/ms99-025.asp

4.5.1.3

Microsoft SQL Server Microsoft SQL Server (MSSQL) contiene numerose vulnerabilità gravi che permettono ad aggressori remoti di ottenere informazioni riservate, di alterare il contenuto dei database, di compromettere i server SQL e, in alcune configurazioni, anche gli host. Infatti la porta 1433 (porta di default di MSSQL) risulta regolarmente una delle porte più sondate secondo le denunce rilevate. Se il sistema Windows con installato MSSQL non è stato aggiornato con le patch più recenti, molto probabilmente è vulnerabile. Microsoft fornisce una guida per aiutare a verificare la versione di SQL e, conseguentemente, il livello di protezione raggiunto. Per minimizzare i rischi di vulnerabilità è necessario seguire le seguenti indicazioni: •

Applicare il più recente service pack per Microsoft SQL server;

•

Applicare le patch cumulative più recenti rilasciate dopo l’ultimo service pack; Pagina 240 di 334

•

Applicare ciascuna singola patch rilasciata dopo la più recente patch cumulativa;

•

Rendere più sicuro il server a livello di sistema e a livello rete: Verificare che l’ di amministrazione di default (noto come “sa”) abbia una sufficientemente robusta, Eseguire il servizio MSSQLServer e l’SQL Server Agent sotto un valido di dominio con privilegi minimi, non come amministratore del dominio o con l’ SYSTEM (su NT) o LocalSystem (su 2000 o xp), Abilitare l’Autenticazione Windows NT, abilitare la verifica dei effettuati e falliti e quindi fermare e riavviare il servizio MSSQLServer, configurare i client in modo che usino l’autenticazione NT, Effettuare un’azione di packet filtering a livello perimetrale (porte T 1433 e 1434) in modo da bloccare le connessioni che provengono dall’esterno ai servizi non autorizzati all’interno della rete; se queste porte devono rimanere aperte, abilitare e personalizzare il filtering in ingresso ed in uscita in modo da prevenire l’uso non corretto di queste porte.

4.5.1.4

NETBIOS – Condivisioni di rete non protette in Windows Mcrosoft Windows fornisce alle macchine host la possibilità di metter in comune file o cartelle con altri host tramite condivisioni di rete. I meccanismi che permettono questa funzione sono il protocollo Server Message Block (SMB) o il Common Internet File System (CIFS). Questi protocolli permettono agli host di operare su file remoti come se risiedessero in locale. Per quanto questa funzione di Windows sia utile e valida, la configurazione impropria delle condivisioni di reti può mettere in pericolo i file di sistema o può favorire processi che portino utenti o programmi ostili ad ottenere il pieno controllo dell’host. Molti possessori di computer aprono inconsciamente i loro sistemi agli hacker quando vogliono favorire i colleghi o i collaboratori esterni condividendo i loro dischi in lettura e in scrittura per gli utenti della rete. Facendo attenzione quando si configurano le condivisioni di rete i rischi possono essere adeguatamente mitigati. La determinazione della vulnerabilità può essere effettuata tramite la maggior parte degli scanner di rete disponibili in commercio al fine di individuare le condivisioni aperte; questi test possono essere effettuati sia in locale che da host remoto. Per limitare il rischio determinato dalle vulnerabilità sfruttabili attraverso le condivisioni di rete di Windows si possono intraprendere diverse azioni: •

Disabilitare le condivisioni quando non sono necessarie,

•

Non permettere condivisioni operate tramite Internet: lo scambio di file con gli host connessi ad Internet deve essere permesso solo tramite FTP o http,

•

Non permettere condivisioni senza autenticazione,

•

Limitare la condivisione solo alle directory strettamente necessarie,

•

Restringere il più possibile i permessi di accesso alle cartelle condivise, Pagina 241 di 334

4.5.1.5

•

Permettere la condivisione solo ad indirizzi IP specifici poiché i nomi DNS possono essere aggirati,

•

Bloccare le porte utilizzate dalle condivisioni di Windows al perimetro della vostra rete. Bloccare le porte NetBIOS comunemente utilizzate dalle condivisioni di Windows al perimetro della rete usando il vostro router esterno o il vostro firewall per la protezione perimetrale. Le porte che devono essere bloccate sono le T dalla 137 alla 139, le UDP dalla 137 alla 139, la 445 T e la 445 UDP.

Accesso anonimo – Null session Una connessione tramite questo tipo di accesso è un meccanismo che consente ad un utente anonimo di ottenere informazioni attraverso la rete (come ad esempio nomi utente e condivisioni) o di connettersi senza autenticazione. Viene utilizzato da applicazioni come explorer.exe per enumerare le condivisioni sui server remoti. In Windows NT, 2000 e XP molti servizi locali sono eseguiti con l’ SYSTEM, noto su Windows 2000 e XP come LocalSystem. Questo possiede privilegi virtualmente illimitati e non richiede alcuna ; poiché non può connettersi ad altri sistemi con ID e , utilizza per accedere una Sessione Nulla. Sfortunatamente anche gli aggressori possono connettersi utilizzando una Sessione Nulla. Al fine di determinare se si è sensibili a questo tipo di vulnerabilità, si provi a connettersi al proprio sistema con una Sessione Nulla utilizzando il seguente comando: net use \\a.b.c.d\ipc$ “” /use:”” dove a.b.c.d rappresenta l’indirizzo IP del sistema remoto. Se si riceve una risposta di “connessione non riuscita” il sistema non è vulnerabile. Se non si riceve alcuna risposta significa che il comando è stato eseguito con successo e che il sistema è vulnerabile. È possibile anche utilizzare lo strumento “Hunt for NT”: si tratta di un componente dell’”NT Forensic Toolkit” reperibile presso http://www.foundstone.com/index.htm?subnav=resources/navigation.htm&subcontent=/reso urces/proddesc/forensic-toolkit.htm. Correre ai ripari non sempre è possibile. Infatti i controller di dominio richiedono sessioni nulle per comunicare; perciò se si sta lavorando in un dominio di rete non si può impedirne del tutto la disponibilità ma si può limitare la quantità di informazioni che può cadere in mano agli aggressori modificando la seguente chiave di registro: HKLM/System/CurrentControlSet/Control/LSA/RestrictAnonymous=1 L’impostazione di RestrictAnonymous su 1 (Windows NT) permette ugualmente la disponibilità di alcune informazioni per gli utenti anonimi ma la riduce al minimo. In Widows 2000 e XP è possibile impostare il valore a 2 bloccando così l’accesso agli utenti anonimi a tutte le informazioni con permessi di accesso non esplicitamente assegnati all’utente anonimo o al gruppo Tutti, il quale include anche gli utenti della sessione nulla. Se non è necessaria la condivisione di file e stampa, svincolare il NetBIOS dal T/IP. È necessario invece fare attenzione che la configurazione di RestrictAnonymous sui controller di dominio e su altri server specifici può compromettere molte operazioni normali di rete: si raccomanda quindi di configurare questo valore solo per le macchine visibili da Pagina 242 di 334

Internet. Tutte le altre macchine dovrebbero essere protette da un firewall configurato per bloccare NetBIOS e CIFS. 4.5.1.6

Autenticazione LAN Manager – Hashing LM debole

Per quanto la maggior parte degli ambienti Windows attuali non necessitino del o LAN Manager (LM), Microsoft memorizza per default in locale gli hash delle legati al LM (noti anche come hash LANMAN) nei sistemi Windows NT, 2000 e XP. Siccome LAN Manager usa uno schema di codifica molto più debole di quelli, più aggiornati, attualmente utilizzati da Microsoft (NTLM and NTLMv2), le del LAN Manager possono essere violate in brevissimo tempo. Anche le che in un altro ambiente sarebbero considerate "forti" possono essere violate con sistemi "brute-force" in meno di una settimana. La debolezza degli hash del Lan Manager deriva dal fatto che: • le sono troncate a 14 caratteri; • le utilizzano lo spazio come carattere di riempimento per raggiungere i 14

caratteri; • i caratteri usati nelle vengono convertiti tutti in caratteri maiuscoli; • le vengono divise in due blocchi di sette caratteri.

Questo processo di hashing comporta che, per ottenere un accesso autenticato al vostro sistema, un eventuale aggressore ha bisogno solo di determinare due semplici da sette caratteri, che per di più contengono solo caratteri maiuscoli. Siccome la difficoltà nel violare gli hash aumenta con progressione geometrica in proporzione alla lunghezza dell’hash, ciascuna stringa di sette caratteri è almeno di un ordine di grandezza più semplice da attaccare con sistemi "bruteforce" rispetto a una stringa di quattordici caratteri. Dal momento che le stringhe sono tutte esattamente di sette caratteri (spazi inclusi) e tutte in caratteri maiuscoli, anche un attacco da dizionario risulta molto semplificato. IL metodo di hashing del Lan Manager rende quindi inefficace qualsiasi buona policy sull’uso delle . In aggiunta al rischio dettato dal fatto di avere gli hash collegati a LM memorizzati nel SAM, il processo di autenticazione del LAN Manager è spesso abilitato per default sui client e accettato dai server. La conseguenza è che macchine Windows, in grado di utilizzare hash più robusti, inviano hash LM deboli attraverso la rete, rendendo l’autenticazione di Windows vulnerabile all’intercettazione attraverso packet sniffing e facilitando il compito degli aggressori di recuperare e violare le degli utenti. Se si utilizza un'installazione predefinita di NT, 2000 o XP, si è vulnerabili, perché l’impostazione predefinita prevede il salvataggio in locale degli hash del LAN Manager. Se vengono utilizzati sistemi operativi che richiedono l’autenticazione LM per comunicare con in server, allora si è vulnerabili perché tali macchine inviano gli hash del Lan Manager attraverso la rete, e questi corrono il rischio di essere intercettati. Gli accorgimenti per migliorare la protezione in ambiente LM sono: •

Disabilitare l’autenticazione LM attraverso la rete. Il modo migliore per sostituire l’autenticazione LAN Manager in Windows è quello di utilizzare NT Lan Manager versione 2 (NTLMv2). I metodi di verifica/risposta di NTLMv2 eliminano la maggior parte dei difetti del Lan Manager utilizzando crittografia più avanzata e meccanismi di autenticazione e per la sicurezza delle sessioni decisamente migliori, Pagina 243 di 334

•

4.5.1.7

Evitare la memorizzazione degli Hash LM. Un altro problema che si presenta anche qualora si eviti che gli hash LM vengano inviati attraverso la rete è che gli hash vengono comunque creati e memorizzati nella SAM o Active Directory. Microsoft rende disponibile un meccanismo per evitare la creazione degli hash LM, ma solo in Windows 2000 e XP. Autenticazione generica di Windows – senza o con deboli

In quasi tutte le interazioni tra gli utenti e i sistemi informativi vengono utilizzate , frasi identificative o codici di sicurezza. La maggior parte delle forme di autenticazione, come la maggior parte delle protezioni per file e dati, si basa su fornite dall’utente. Dal momento che gli accessi correttamente autenticati spesso non vengono registrati, o anche se vengono registrati non lo sono in modo da fornire alcun segnale di allarme, una compromessa rappresenta un’opportunità di esplorare un sistema dall’interno potenzialmente senza essere identificati. Un aggressore avrebbe accesso completo a qualsiasi risorsa disponibile per quell’utente e sarebbe molto vicino ad essere in grado di accedere ad altri , a macchine vicine e forse anche ad ottenere privilegi di amministrazione. Nonostante questi pericoli, gli con deboli o addirittura senza rimangono estremamente diffusi e le società con una buona policy sull’utilizzo delle ancora troppo rare. Le più comuni vulnerabilità delle sono dovute (a) ad senza o con deboli, (b) al fatto che, a prescindere dalla robustezza delle , spesso gli utenti non le proteggono, (c) al fatto che il sistema operativo o il software applicativo creano di amministrazione con deboli o privi di (d) al fatto che gli algoritmi di hashing delle sono noti e spesso gli hash vengono memorizzati in modo da essere accessibili a chiunque. La difesa migliore e la più corretta contro queste vulnerabilità è una solida policy che includa le istruzioni per creare delle buone e che riassuma i comportamenti corretti per conservarne la riservatezza, unita a una verifica proattiva dell’integrità delle . Per quanto vi siano alcuni sintomi osservabili di una generale debolezza delle , come la presenza di attivi appartenenti a utenti che non operano più all’interno dell’organizzazione o a servizi non più attivi, l’unico modo per accertarsi che ogni singola sia sufficientemente robusta è quello di verificare tutte le con gli stessi strumenti per la determinazione delle utilizzati dagli aggressori. La difesa migliore e la più corretta contro la debolezza delle è una solida policy che includa le istruzioni su come generare buone e descriva i comportamenti corretti per mantenerne la sicurezza, assieme ad una verifica proattiva dell’integrità delle . o Assicursi che le siano sufficientemente robuste. I meccanismi di definizione delle riportate nella policy di sicurezza devono essere sufficientemente articolati; o Proteggere le robuste. Anche se le sono robuste, gli possono essere ugualmente compromessi se gli utenti non proteggono adeguatamente la propria . Una buona policy include sempre istruzioni che specificano come gli utenti devono comportarsi nella gestione della propria ; o Controllare rigorosamente l’utilizzo degli . Devono essere verificati continuamente tutti i requisiti che giustifichino l’esistenza degli (corrispondenza con utenti reali, verifica dei diritti di accesso degli );

Pagina 244 di 334

o Implementate una solida policy per le in azienda. In aggiunta ai controlli a livello di sistema operativo o a livello di rete, è opportuno utilizzare strumenti completi che aiutano a gestire una buona policy per le . 4.5.1.8

Internet Explorer

Microsoft Internet Explorer (IE) è il web browser installato di serie sulle piattaforme Microsoft Windows. Tutte le versioni esistenti di Internet Explorer presentano vulnerabilità critiche. È possibile progettare pagine Web che sfruttino queste vulnerabilità sull’Internet Explorer dell’utente che visualizza tali pagine. Le vulnerabilità possono essere classificate in diverse categorie che comprendono lo spoofing di pagine Web, le vulnerabilità dei controlli ActiveX, le vulnerabilità da Active scripting, l’interpretazione non corretta di MIME-type e di content-type e i buffer overflow. Le conseguenze possono riguardare la rivelazione del contenuto di cookye, file o dati in locale, l’esecuzione di programmi in locale, il e l’esecuzione di codice arbitrario, fino al controllo completo del sistema vulnerabile. Se si utilizza Internet Explorer e non è stata installata la più recente patch cumulativa, molto probabilmente esiste vulnerabilità. Se sulla rete è abilitato l’Aggiornamento di Windows, è possibile verificare sia se IE è effettivamente installato, sia quali patch di Internet Explorer siano presente sul vostro sistema visitando l’indirizzo http://windowsupdate.microsoft.com/. Sono disponibili le patch per queste vulnerabilità per le versioni 5.01, 5.5, 6.0 di Internet Explorer. Anche le versioni precedenti di Internet Explorer sono vulnerabili, ma non sono disponibili per queste versioni le patch di alcune vulnerabilità. Se sul sistema è attiva una versione precedente di IE, si dovrebbe prendere in considerazione un aggiornamento. Per mantenere protetto il sistema, è necessario seguire costantemente le uscite di nuovi aggiornamenti di IE utilizzando Windows update (http://windowsupdate.microsoft.com/), HFNetChk (http://www.microsoft.com/technet/security/tools/hfnetchk.asp), o il MBSA (http://www.microsoft.com/technet/security/tools/Tools/MBSAhome.asp). È possibile anche ottenere informazioni generali sugli aggiornamenti di IE dalla Internet Explorer Home (http://www.microsoft.com/windows/ie/default.asp). 4.5.1.9

Accesso remoto al Registro

Microsoft Windows 9x, Windows CE, Windows NT, Windows 2000 e Windows XP impiegano un database gerarchico centralizzato, meglio conosciuto come Registro, per gestire il software, la configurazione dei dispositivi e le impostazioni degli utenti. Permessi o impostazioni di sicurezza non corretti possono permettere un accesso remoto al Registro. È possibile sfruttare questo fatto per compromettere il sistema o porre le basi per adattare l’associazione dei file e i permessi in modo da consentire l’esecuzione di codice dannoso. L’NT Resource Kit (NTRK) disponibile presso Microsoft contiene un file eseguibile denominato "regdump.exe" che verifica ivamente i permessi per l’accesso remoto al Registro da un host Windows NT verso altri host Windows NT/Windows 2000 o Windows XP attraverso Internet o la rete interna. Oltre a ciò, è possibile scaricare una raccolta di shell script a linea di comando che verificano i permessi di accesso al vostro Registro, oltre a una serie di altre caratteristiche che riguardano la sicurezza. È disponibile all’indirizzo http://www.afentis.com/top20. Pagina 245 di 334

Per far fronte a questa minaccia, l’accesso al Registro di sistema deve essere limitato e devono essere rivisti i permessi impostati per le chiavi del Registro più critiche. Prima di ottimizzare il Registro, gli utenti di Microsoft Windows NT 4.0 devono anche assicurarsi che sul loro sistema sia già installato il Service Pack 3 (SP3). ATTENZIONE: Le modifiche al Registro di sistema possono comportare seri effetti sulle performance e sull’operatività del computer e, in casi estremi, possono causare danni irreparabili e richiedere la reinstallazione del sistema operativo. Gli accorgimenti necessari a migliorare il sistema di protezione sono: o Limitare l’accesso al Registro dalla rete; o Limitate gli accessi remoti autorizzati. Applicare limitazioni troppo ristrette sul registro può avere effetti secondari su servizi dipendenti quali il Directory Replicator e il servizio di spooling per le stampanti di rete. 4.5.1.10

Windows Scripting Host o Nella primavera del 2000, uno script di Visual Basic (VBScript), il worm "Love Bug" (conosciuto anche come virus "ILOVEYOU"), ha causato danni per milioni di dollari. Questo worm, come gli altri che sono arrivati dopo, sfruttano il Windows Scripting Host (WSH), che permette a qualsiasi file di testo con estensione ".vbs" di essere eseguito come uno script di Visual Basic. Se WSH è abilitato, un tipico worm si propaga includendo un VBScript come contenuto di un altro file che si esegue quando tale file viene visto, in qualche caso anche solo in anteprima. o Anche se gli amministratori devono sempre controllare che applicativi come browser, client di posta o le suite che li contengono siano sempre aggiornati alle versioni più recenti e siano loro applicate le ultime patch, aggiornare queste applicazioni per eliminare la possibilità che siano colpite da un particolare worm è una soluzione non definitiva (non migliore di una semplice reazione) ai rischi derivati dallo scripting. o Se si utilizza Windows 95 o NT con IE 5 o successivi, oppure si utilizza Windows 98, ME, 2000 o XP e non si è disabilitato WSH, allora esiste vulnerabilità. o In questo caso occorre: o Disabilitare o rimuovete del tutto Windows Scripting Host; o Aggiornare sempre il software Anti-Virus e le relative definizioni. Alcuni Anti-Virus presentano anche un’opzione che blocca gli script.

4.5.2 UNIX 4.5.2.1

Remote Procedure Call

Le Remote Procedure Call (RPC), installate automaticamente in quasi tutte le versioni di sistemi Unix e Linux, consentono ai programmi di un computer di eseguire programmi presenti su un altro computer ando loro i dati e recuperando i risultati. Le RPC vengono quindi largamente utilizzate in diversi servizi di rete come l’amministrazione da remoto, la condivisione dei file NFS e NIS. Nelle RPC vi sono però diverse imperfezioni che possono essere sfruttate. In molti casi i servizi RPC vengono eseguiti con privilegi di root, facendo di conseguenza correre gravi rischi ai sistemi che presentano vulnerabilità nei servizi RPC che possono portare un aggressore ad Pagina 246 di 334

ottenere un accesso root non autorizzato da remoto. Ci sono prove convincenti che la maggior parte degli attacchi del tipo "distributed denial of service" verificatisi durante il 1999 ed i primi mesi del 2000 siano stati eseguiti da sistemi vittime delle vulnerabilità RPC. Anche il massiccio attacco riuscito ai danni dei sistemi delle forze armate americane durante l'incidente Solar Sunrise ha sfruttato vulnerabilità dell' RPC riscontrate su centinaia di sistemi del Dipartimento della Difesa. Per verificare l’eventuale vulnerabilità vengono utilizzati un vulnerability scanner o il comando 'rpcinfo' per verificare se si stanno utilizzando uno dei servizi RPC più comunemente sfruttati: I servizi RPC vengono generalmente sfruttati per attacchi del tipo "buffer overflow", che hanno successo perché i programmi RPC non eseguono un controllo appropriato degli errori o una adeguata convalida degli input. Le vulnerabilità del tipo "buffer overflow" consentono agli aggressori di inviare dati che il programma non si aspetta (spesso in forma di codice dannoso) nello spazio di memoria del programma. A causa dello scarso controllo errori e dell’insufficiente convalida degli input, i dati sovrascrivono le parti di memoria che sono pronte ad essere eseguite dal processore. In un attacco overflow riuscito, questo codice dannoso viene quindi eseguito dal sistemo operativo. Dal momento che molti servizi RPC vengono eseguiti con privilegi di root, sfruttando uno di questi servizi è possibile ottenere da remoto un accesso root al sistema non autorizzato. Per evitare tali conseguenze, è necessario: o Disattivare o rimuovete tutti i servizi RPC che non sono strettamente necessari all’operatività della vostra rete; o Installare le patch più recenti per tutti i servizi che non si possono rimuovere; o Verificare regolarmente se il produttore distribuisce nuove patch e installarle immediatamente; o Bloccare la porta RPC (porta 111) a livello di router o firewall perimetrale; o Bloccare le porte RPC di "loopback" 32770-32789 (T e UDP); o Nei sistemi operativi che lo permettono, abilitare uno stack non-eseguibile. Anche se uno stack non-eseguibile non protegge da tutti i buffer overflow, può ostacolare lo sfruttamento di alcuni buffer overflow standard pubblicamente disponibili in Internet. o Per i file system esportati in NFS, si possono prevedere i seguenti accorgimenti: o Usare una export list basata su host/IP; o Se possibile, impostare il file system esportato come no-suid o per sola lettura; o Utlizzare 'nfsbug' per rintracciare le vulnerabilità. È possibile trovare un documento di sintesi che riporta indicazioni specifiche sulle tre principali vulnerabilità RPC - Tooltalk, Calendar Manager e Statd - all’indirizzo: http://www.cert.org/incident_notes/IN-99-04.html Si possono reperire documenti che riguardano le specifiche vulnerabilità RPC di Statd, Tooltalk, Calendar Manager, Cachefsd, Sd, Mountd, SnmpXdmid all’indirizzo: http://www.cert.org/advisories/

Pagina 247 di 334

4.5.2.2

Web Server Apache

Gli amministratori di server Web troppo spesso concludono che poichè l’Internet Information Server (IIS) di Microsoft è particolarmente soggetto ad essere violato, il web server open-source Apache (http://www.apache.org/) è completamente sicuro. Quasi tutti i sistemi Linux e molti altri sistemi Unix si presentano con Apache pre-installato e abilitato. Per quanto possa essere condivisibile il confronto con IIS, e nonostante Apache goda di una meritata reputazione di sicurezza, ad una attenta analisi anche questo web server non è invulnerabile. I metodi per violare Apache o i suoi moduli nel recente ato sono state pochi, ma molto ben documentati e velocemente utilizzati in attacchi concreti. Tra i più recenti vi sono: •

Apache/mod_ssl Worm (CERT Advisory CA-2002-27)

•

Apache Chunk Handling Exploit (CERT Advisory CA-2002-17)

In definitiva, nessun web server può essere considerato sicuro finché non viene analizzato nel contesto della sua interazione con le diverse applicazioni web, in particolare con i programmi CGI e con i database. Anche una configurazione particolarmente sicura di Apache può permettere l’accesso non autorizzato ai dati se gli script non sono attentamente verificati o i controlli d’accesso ai database non sono correttamente configurati. Gli script CGI vengono eseguiti con gli stessi permessi del web server, e così uno script CGI fatto ad arte o semplicemente scritto non correttamente può essere altrettanto pericoloso di una vulnerabilità nel software di Apache. Sfortunatamente queste debolezze nel back end del web server rimangono problemi di stretta attualità. È anche necessario rafforzare la sicurezza del sistema operativo per impedire che i contenuti web vengano sottratti o modificati. Per quanto ciò valga per tutti i servizi attivi, il fatto che i servizi web tendano ad avere una esposizione verso l’esterno si presta alla falsa idea che essi ed i dati che proteggono siano in qualche modo indipendenti dal resto del sistema. La verifica della possibile vulnerabilità si ottiene controllando quale sia la versione più recente e il più recente livello di patch sul sito di Apache: http://httpd.apache.org/. Se la versione indagata non è la più recente, il server è probabilmente vulnerabile. Su questo sito è possibile trovare anche una lista aggiornata delle vulnerabilità più recenti e la documentazione su come determinare se siete affetti da tali vulnerabilità. Le seguenti istruzioni possono aiutare a proteggere un web server Apache: 1. Recuperare da Apache le patch più recenti all’indirizzo http://www.apache.org/dist/httpd/patches/ (http://www.openssh.org/) e aggiornare alla versione più recente; 2. Modificare l’HTTP Response token di default di Apache. Ciò farà in modo che il vostro server Apache restituisca false informazioni nel suo header di risposta, aiutando a nascondere il software del web server. Anche se questa tecnica non impedisce a un determinato aggressore di scoprire quale sia il vostro software, può fare molto per proteggere il vostro web server Apache da worm che innescano il loro codice di attacco basandosi sulle informazioni ricevute in risposta dagli header; 3. Compilare solo i moduli di Apache necessari per il corretto funzionamento del vostro server. Come per un sistema operativo sul quale girano servizi inutili, lo stesso Apache dovrebbe essere ridotto al minimo per diminuire l’esposizione a futuri problemi di sicurezza; Pagina 248 di 334

4. Considerare la possibilità di eseguire Apache in un ambiente chroot(). Per evitare che vengano eseguite con successo le richieste HTTP dannose, un web server dovrebbe essere configurato per inizializzarsi con la funzione chroot() di Unix. Quando un web server parte in chroot, è posto in un ambiente che si potrebbe definire una "Botte di ferro". Da questa configurazione il web server non può accedere ad alcuna parte della struttura delle directory del sistema operativo al di fuori dell’area chroot() definita; 5. Non eseguire Apache come root. Create un nuovo utente con privilegi minimi sulla vostra rete e nel database offerto dai vostri servizi web ed eseguite Apache con tale utente. NON usare l’ nobody, perché questo è utilizzato per mappare l’ di root su NFS; 6. Eliminare i contenuti html di default, inclusi i due script CGI test-cgi e printenv. Le vulnerabilità presenti nei contenuti di default sono molto ben conosciute e frequentemente sfruttate negli attacchi; 7. Ottimizzare e migliorare la gestione degli script CGI; 8. Il suggerimento forse più importante di tutti è quello di controllare che il sistema operativo e i servizi che stanno sotto il vostro web server siano rafforzati, o tutti i provvedimenti suggeriti fin qui risulteranno inutili. Seguite ciò che è descritto negli altri punti di questo documento, nelle SANS Consensus Security Guides, e nei Center for Internet Security's Benchmarks (http://www.cisecurity.org/). Per ulteriori informazioni di sicurezza su Apache, consultate http://www.sans.org/Gold/apache.php e http://www.infosecuritymag.com/articles/april01/features1_web_server_sec.shtml. 4.5.2.3

Secure Shell (SSH)

Secure shell (ssh) è un popolare servizio per rendere sicuri i , l’esecuzione di comandi e il trasferimento di file attraverso una rete. La maggior parte dei sistemi utilizza il pacchetto opensource OpenSSH (http://ww.openssh.org) o la versione commerciale di SSH Communication Security (http://www.ssh.com/). Per quanto ssh sia largamente più sicuro dei programmi di telnet, ftp, e R-command per sostituire i quali è stato progettato, sono state riscontrate diverse falle in entrambi i pacchetti citati. Si tratta per la maggior parte di bachi di minore importanza, ma alcuni costituiscono dei problemi di sicurezza che devono essere riparati immediatamente. Il più pericoloso di questi buchi di sicurezza attivamente sfruttati permette agli aggressori di ottenere da remoto un accesso root alla macchina. È stato dimostrato che lo stesso protocollo SSH1 è potenzialmente vulnerabile e in certe configurazioni può permettere la decifratura di una sessione in transito. Per questo si invitano gli amministratori ad utilizzare, quando possibile, il più solido protocollo SSH2. Oltre a ciò, gli utenti di OpenSSH devono stare attenti al fatto che le librerie OpenSSL sulle quali di solito OpenSSH è installato presentano a loro volta delle vulnerabilità (http://www.cert.org/advisories/CA-2002-23.html). Si deve stare anche attenti al fatto che, anche se per un breve periodo di tempo, nell’estate 2002 è stata distribuita una versione di OpenSSH che conteneva un trojan (http://www.openssh.org/txt/trojan.adv). Al fine di verificare la vulnerabilità del sistema, è possibile utilizzare un vulnerability scanner per controllare se si sta utilizzando una versione vulnerabile oppure si verifichi la versione del software riportata eseguendo il comando 'ssh -V'. Pagina 249 di 334

I i consigliati per prevenire i rischi di intrusione sono: o are alla versione più recente di OpenSSH o SSH. Oppure, se SSH o OpenSSH sono preistallati nel sistema operativo, si recuperino le patch più recenti presso il produttore del sistema operativo. Se si usa OpenSSL, si controlli che usi le librerie nella versione più recente; o Se possibile, si eviti di utilizzare il protocollo SSH1, che presenta alcune note debolezze già corrette nel protocollo SSH2; o Entrambe le implementazioni di SSH comprendono una varietà di opzioni di configurazione per limitare le macchine che possono connettersi e per indicare quali utenti possano autenticarsi per definire attraverso quali meccanismi debbano avvenire queste operazioni. Gli amministratori dovrebbero scegliere quali di queste opzioni può risultare più appropriata per il loro ambiente. 4.5.2.4

Simple Network Management Protocol (SNMP)

Il Simple Network Management Protocol (SNMP) è largamente utilizzato per controllare e configurare da remoto quasi tutti i tipi di dispositivi T/IP moderni. Anche se SNMP è ato nelle sue varie distribuzioni da quasi tutte le piattaforme di rete, è usato più di frequente come metodo per configurare e gestire dispositivi quali stampanti, router e switch e per inviare input a servizi di monitoraggio della rete. La comunicazione Simple Network Management consiste in diversi tipi di messaggi scambiati tra le stazioni di gestione SNMP e i dispositivi di rete che eseguono quello che comunemente è definito come agent software. Sia la metodologia con la quale questi messaggi sono trattati, sia il meccanismo di autenticazione che sottende a tale trattamento, presentano significative vulnerabilità. Le vulnerabilità che stanno dietro il metodo attraverso il quale la versione 1 di SNMP tratta e cattura i messaggi è descritta in dettaglio nel CERT Advisory CA-2002-03 (http://www.cert.org/advisories/CA-2002-03.html). Esistono una serie di vulnerabilità nel modo in cui i messaggi di richiesta e cattura sono gestiti e decodificati dalle stazioni di gestione e dagli agenti. Queste vulnerabilità non sono limitate a una specifica implementazione di SNMP, ma affliggono una varietà di distribuzioni di SNMP di diversi produttori. Sfruttando queste vulnerabilità gli aggressori possono arrivare a risultati che variano dal denial of service alla modifica della configurazione e del sistema di gestione delle macchine abilitate all’SNMP. Il meccanismo interno di autenticazione dei protocolli SNMP meno recenti presenta anche un’altra importante vulnerabilità. Le versioni 1 e 2 di SNMP utilizzano un meccanismo di autenticazione "community string" non crittata. La mancanza di crittografia è già abbastanza grave, ma in più la community string usata per default nella grande maggioranza dei dispositivi SNMP è "public," e solo pochi produttori più accorti di apparati di rete la modificano in “privata" per il trattamento delle informazioni più sensibili. Gli aggressori possono sfruttare la vulnerabilità di SNMP per riconfigurare o per spegnere i dispositivi da remoto. Lo sniffing del traffico SNMP può rivelare molti dettagli relativi alla struttura della vostra rete e ai dispositivi ad essa collegati Gli intrusi utilizzano queste informazioni per scegliere gli obiettivi e per pianificare gli attacchi. A dispetto del fatto che queste vulnerabilità sono presenti solo nelle prime versioni dei protocolli SNMP, molti produttori abilitano per default la versione 1 di SNMP. Molti non offrono prodotti in grado di utilizzare SNMP versione 3, che non presenta nessuna di queste vulnerabilità congenite. In Pagina 250 di 334

ogni caso esistono dei sostituti gratuiti che provvedono a fornire il o SNMPv3 con licenza GPL o BSD. SNMP non è un’esclusiva di Unix e viene usato diffusamente anche in Windows per apparati di rete, stampanti e altri dispositivi. La maggior parte degli attacchi che si appoggiano a SNMP finora riscontrati si è presentata però su sistemi UNIX con configurazioni non corrette. È possibile verificare se SNMP è attivo sui dispositivi connessi alla rete adoperando uno scanner o effettuando un controllo manuale. SNMPing – È possibile richiedere lo strumento di scanning gratuito SNMPing al SANS Institute (http://www.sans.org/alerts/snmp/?printer=Y). SNScan - Foundstone ha creato un altro strumento per lo scanning SNMP di semplice uso chiamato SNScan, che può essere scaricato da http://www.foundstone.com/knowledge/free_tools.html. Se non è possibile utilizzare uno degli strumenti sopra citati, avete la possibilità di verificare manualmente se SNMP è attivo sui vostro sistemi. Consultate la documentazione del vostro sistema operativo per le indicazioni su come identificare l’implementazione specifica di SNMP, il daemon di base può di solito essere identificato trovando "snmp" nella process list o cercando tra i servizi che girano sulle porte 161 o 162. Se SNMP è attivo e riscontrate una delle seguenti variabili, potreste soffrire di una vulnerabilità legata a una stringa di default o comunque troppo facile da indovinare: 1. Community name SNMP vuoti o di default. 2. Community name SNMP facili da indovinare. 3. Community string SNMP nascoste. Si legga http://www.sans.org/newlook/resources/IDFAQ/SNMP.htm per informazioni su come identificare la presenza di queste condizioni. Le azioni da effettuarsi sono quindi: Vulnerabilità di cattura e gestione della richiesta:

•

i.

Se non si ha necessità assoluta di utilizzare l’SNMP, lo si disabiliti;

ii.

Quando possibile, si utilizzi SNMP versione 3;

iii.

Se dovete usare SNMPv1 o v2, controllate di aver installato la patch più recente rilasciata dal vostro produttore. Un buon punto di partenza per ottenere le informazioni specifiche per ciascun produttore è consultare l’Appendice A del CERT Advisory CA2002-03;

iv.

Filtrate SNMP (porte 161 T/UDP e 162 T/UDP) ai punti di ingresso delle vostre reti, a meno che non sia assolutamente necessario effettuare il polling o gestire i dispositivi dall'esterno della rete locale;

v.

Sui sistemi con gli agenti SNMP effettuate un controllo degli accessi basato sugli host. Anche se questa possibilità dipende dalle funzionalità del sistema che ospita gli agenti SNMP, è possibile effettuare comunque un controllo per verificare da quali sistemi i vostri agenti accettano richieste. Sulla maggior parte dei sistemi Unix è possibile effettuare questo controllo configurando T-Wrappers o Xinetd. Potete anche usare un Pagina 251 di 334

firewall che effettui il packet filtering sugli agenti per bloccare le richieste SNMP indesiderate. •

Vulnerabilità correlate alle stringhe di default o troppo semplici da indovinare: 1. Se non si ha la necessità assoluta di utilizzare l’SNMP, lo si disabiliti. 2. Quando possibile, utilizzate SNMP versione 3. 3. Se dovete usare SNMPv1 o v2, utilizzate per i community name la stessa policy che usate per le . Assicuratevi che siano difficili da indovinare o da violare e che siamo periodicamente modificati. 4. Controllate e convalidate i community name utilizzando snmpwalk. Potete trovare maggiori informazioni su http://www.zend.com/manual/function.snmpwalk.php. Una buona guida per questo strumento è reperibile all’indirizzo http://www.sans.org/newlook/resources/IDFAQ/SNMP.htm. 5. Filtrate SNMP (porte 161 T/UDP e 162 T/UDP) ai punti di ingresso delle vostre reti, a meno che non sia assolutamente necessario effettuare il polling o gestire i dispositivi dall'esterno della rete locale. 6. Dove possibile, impostate le MIB in sola lettura. Potete trovare maggiori informazioni sull’argomento all’indirizzo http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/snmp.htm#ocid210315.

4.5.2.5

File Transfer Protocol

Il daemon FTP viene utilizzato per distribuire file ad utenti anonimi o autenticati con name e . I servizi FTP anonimi non richiedono una univoca (vale per tutti) e tutti gli utenti usano lo stesso nome di ("anonymous" o "ftp"), così da permettere a chiunque l’accesso al servizio. Il servizio FTP autenticato richiede invece un name e una , ma entrambi vengono trasmessi in chiaro attraverso la rete, consentendo a un terzo di intercettarli durante lo scambio di credenziali. Per sottrarre le informazioni di FTP, un aggressore ha bisogno di piazzare un network sniffer da qualche parte lungo il percorso di connessione come, ad esempio, sul server FTP della LAN o sul client LAN. Oltre a questa insita insicurezza nella trasmissione, sono state rilevate diverse vulnerabilità gravi in molte versioni dei software FTP server, sia in quelle fornite da produttori di sistemi operativi (Sun, HP-UX, ecc), sia in quelle sviluppate dalla comunità open source (WU-FTPD, ProFTPD, ecc). Molti degli attacchi che sfruttano queste vulnerabilità permettono all’aggressore di ottenere un accesso root alla macchina che ospita il server FTP, mentre altri permettono semplicemente l’esecuzione di comandi a livello di utente. La vulnerabilità di WU-FTPD, ad esempio, permette agli aggressori di ottenere un accesso root e di caricare sul sistema strumenti come i “rootkits”, ed utilizzare quindi il sistema per i loro intenti. La maggior parte dei sistemi di attacco a queste vulnerabilità richiede che sia abilitato l’accesso anonimo, ma qualcuno funziona anche quando l’accesso anonimo viene negato a condizione che il server FTP ascolti la porta della rete. È da notare che anche se il server FTP usa una chiamata chroot() al sistema per confinare l’utente anonimo in una specifica directory, può essere ugualmente attaccato se presenta dei bachi importanti nell’implementazione. Pagina 252 di 334

Diverse versioni di daemon FTP UNIX presentano un grande numero di vulnerabilità e devono essere regolarmente aggiornate e corrette. È necessario controllare quale sia la versione più recente e l’ultimo livello di patch dello specifico FTP server software consultando il sito del produttore del sistema operativo o del software FTP interessati. Se la versione non è la più recente, vi sono delle possibilità che sia vulnerabile e che i metodi per sfruttare le sue vulnerabilità siano pubblicamente disponibili nella comunità underground. Si può anche utilizzare lo scanner gratuito Nessus (http://www.nessus.org/) per evidenziare le vulnerabilità FTP. Per proteggere il servizio FTP si dovrebbero adottare i seguenti accorgimenti: i.

Si i alla versione più recente dell’FTP. I più conosciuti server FTP gratuiti sono WUFTPD (http://www.wuftpd.org/) e ProFTPD (http://www.proftpd.org/). Se la versione di FTP interessata era compresa nel sistema operativo, è necessario rivolgetersi al produttore del sistema operativo per le informazioni sull’aggiornamento;

ii.

Si disabiliti l’accesso anonimo ai servizi FTP se non è necessario. Si seguano le istruzioni contenute nel manuale del software della specifica versione. Per WU-FTPD e ProFTPD, si crei o si modifichi il file /etc/ftps e si aggiungano gli name "anonymous" e "ftp" (su righe diverse). Questo file definisce quali utenti non sono abilitati a connettersi al server FTP. Per aggiungere un ulteriore livello di sicurezza, si tolga anche l’utente "ftp" dal file delle ;

iii.

Nel caso in cui fosse necessario la funzionalità dell’FTP anonimo, si controlli almeno che sia disabilitata la possibilità di un caricamento anonimo, in modo che gli utenti abbiano bisogno di un name valido e di una per inserire file sul vostro server. Il caricamento anonimo è disabilitato per default sulla maggior parte dei daemon FTP. Per verificare che sia davvero disabilitato, si effettui una connessione al server FTP e si provi ad eseguire un comando "put qualche.file". Se l’istruzione non ha successo, il messaggio di errore indicherà che il caricamento non è abilitato;

iv.

Si limiti l’accesso al server FTP a determinati indirizzi IP o domini utilizzando T wrappers. T wrappers è già preinstallato sulle più recenti distribuzioni di Unix e Linux. Se non ci fosse, è possibile installarlo dai sorgenti che potete trovare all’indirizzo ftp://ftp.porcupine.org/pub/security/t_wrappers_7.6.tar.gz. Alcune distribuzioni di Linux (come ad esempio RedHat) utilizzano una versione migliorata di inetd chiamata xinetd, che contiene il codice T wrapper e controlla di default i file sopra descritti;

v.

Si implementino delle restrizioni ai permessi dei file sull’FTP server in modo che gli utenti possano accedere solo ai file di cui hanno bisogno. La maggior parte dei server FTP offrono la possibilità di imporre un controllo granulare degli accessi per gli utenti FTP che si somma ai permessi UNIX dei file;

vi.

Si aggiungano tutti gli di amministrazione (come root, daemon, sys, ecc.) al file /etc/ftps in modo che tali non possano essere accessibili in FTP;

vii.

Si consideri la possibilità di sostituire FTP con soluzioni software più sicure come SFTP o S (componenti del pacchetto Secure Shell) e si utilizzi un web server per distribuire file a un pubblico vasto;

Pagina 253 di 334

viii. 4.5.2.6

Si disattivino i server FTP inutilizzati e si disinstalli il software dal sistema. Si chiuda con il firewall la porta 21 sui dispositivi perimetrali se essa non viene utilizzata. Servizi R – Relazioni di Trust

Remote shell (rsh), remote copy (r), remote (r), e remote execution (rexec) – conosciuti tutti assieme come "R-commands" – sono molto usati nel mondo Unix. Le organizzazioni con molti server Unix spesso configurano i corrispondenti "R-services" (in.rshd, in.rd, in.rexecd) in modo che gli utenti possano spostarsi da una macchina all’altra senza inserire ogni volta uno ID e una . Anche nelle reti dove le risorse di un dato utente sono contenute da un singolo sistema, gli amministratori sono spesso responsabili di dozzine o anche centinaia di sistemi, e quindi configurano i servizi R in modo da facilitare i propri movimenti da una macchina all’altra. Un singolo utente può effettuare comandi rsh, r, r o rexec dalla macchina A alla macchina B senza dover ri-autenticarsi inserendo il nome o l’indirizzo della macchina A nel suo file ~/.rhosts file sulla macchina B. Tutti gli utenti possono eseguire comandi rsh, r, r o rexec dalla macchina A alla macchina B senza dover ri-autenticarsi se il nome o l’indirizzo della macchina A è presente nel file /etc/hosts.equiv della macchina B. I servizi R soffrono di due grandi fondamentali debolezze nelle connessioni di rete: mancanza di crittografia e autenticazione dell’host piuttosto scarsa. La trasmissione dell’informazione tra i client R-command e i servizi R in testo piano fa in modo che i dati o ciò che viene digitato sulla tastiera possano essere intercettati. Il fatto che i servizi R accettino semplicemente il nome o l’indirizzo presentato da un client che si connette consente che queste informazioni siano catturate. Se non sono state stabilite relazioni di trust, gli utenti sono obbligati a inviare in rete le in chiaro. Con le relazioni di trust, un aggressore può assumere l’identità di un utente valido su un host valido e utilizzarla per ottenere l’accesso a tutte le altre macchine che hanno impostato la relazione con la macchina violata. I servizi R girano su un meta-server chiamato "inetd" o, su alcuni sistemi, "xinetd." Inetd permette le connessioni rsh o r se vi è una voce per "in.rshd" (il nome specifico può variare lievemente a seconda della vostra distribuzione) in /etc/inetd.conf o in /etc/inet/inetd.conf. Allo stesso modo, rexec richiede una voce per "in.rexecd," e r una voce per "in.rd." Xinetd funziona in modo simile, aspettando che nella directory /etc/xinetd.d appaia un file nominato dopo che ciascun servizio è partito. Le relazioni di Trust sono stabilite su una macchina se vi sono delle voci nel file /etc/hosts.equiv o nel file ~/.rhosts di ciascun utente valido. Per migliorare il sistema di protezione, si seguano i seguenti accorgimenti: i.

Si disabilitino i servizi R su qualsiasi sistema nel quale non siano assolutamente necessari. Le funzionalità dei servizi R possono essere svolte in modo molto più sicuro da Secure shell (ssh, disponibile presso OpenSSH o presso SSH Communications Security) e i sui complementi di s e sftp. Se i servizi R sono assolutamente necessari, si disabilitino le relazioni di trust e si utilizzi T Wrappers per registrare tutti i tentativi di connessione, si limiti l’accesso a specifici host ed si effettui la verifica degli host. La funzionalità di T Wrappers è già contenuta in xinetd;

ii.

Per disabilitare le relazioni di trust, si elimini il file /etc/hosts.equiv e il file ~/.rhosts di ciascun utente. Se fosse necessario proprio utilizzare le relazioni di trust, non si usi mai il carattere "+" (carattere jolly), perché può essere utilizzato da qualsiasi utente o da qualsiasi Pagina 254 di 334

macchina (o, peggio, da qualsiasi utente da qualsiasi macchina) per connettersi con credenziali corrette, e ci si assicuri di usare T Wrappers. Non si utilizzi mai ~/.rhosts per permettere l’autenticazione senza . 4.5.2.7

Line Printer Daemon (LPD)

Il Berkeley line printer daemon (LPD) è storicamente il servizio che permette agli utenti di connettersi a una stampante locale da una macchina locale o da una macchina remota attraverso la porta T 515. Anche se sono disponibili server alternativi, LPD rimane il più utilizzato server di stampa tra le diverse distribuzioni di Unix e Linux. Molte implementazioni di LPD, però, contengono delle falle di programmazione che hanno portato a buffer overflow, permettendo agli aggressori di eseguire codice arbitrario con privilegi di root. Così tanti sistemi operativi Unix contengono daemon LPD vulnerabili che il CERT ha emesso un avviso generale (http://www.cert.org/advisories/CA-2001-30.html) alla fine del 2001 per fornire informazioni specifiche sui problemi e sui rimedi per dozzine di diversi sistemi Unix. Siccome tutti i sistemi Unix e Linux sono distribuiti con un qualche server di stampa installato, e dal momento che anche quelli che utilizzano un qualche sostituto di LPD (come LPRng) chiamano il loro servizio "lpd" o "in.lpd," è necessario controllare presso il distributore di software per verificare se quella utilizzata è la versione più recente o comunque se la versione è corretta con la patch più recente, e se non è così si consideri vulnerabile il sistema. Si consulti il CERT Advisory 2001-30 per le informazioni su come risolvere il problema di uno specifico sistema operativo. Gli utenti Solaris possono consultare anche CERT Advisory 2001-15 e Sun Security Bulletin #00206. Se la macchina in oggetto non ha bisogno di fungere da server di stampa per richieste da remoto, esiste la possibilità di ridurre al minimo il rischio di future vulnerabilità in LPD disabilitando il servizio "in.lpd" in inetd o in xinetd. Per inetd, si commenti la voce "in.lpd" in /etc/inetd.conf o in /etc/inet/inetd.conf e si riavvii inetd. Per xinetd, si aggiunga la riga "disable = yes" al file "in.lpd" e quindi si riavvii xinetd. Se proprio sussiste il bisogno si soddisfare richieste di stampa da remoto, si restringano gli host abilitati a connettersi a in.lpd con T Wrappers. Ci si può garantire una certa protezione dai buffer overflow abilitando uno stack non eseguibile sui sistemi operativi che ano questa funzione. Anche se uno stack non eseguibile non protegge da tutti i buffer overflow, può ostacolare lo sfruttamento di alcuni buffer overflow standard pubblicamente disponibili su Internet. 4.5.2.8

Sendmail

Sendmail è il programma che invia, riceve e inoltra la maggior parte della posta elettronica elaborata su computer UNIX e Linux. La grande diffusione dell’uso di Sendmail in Internet lo rende uno degli obiettivi di attacco principali, concretizzatisi in numerosi exploit nel corso degli anni. La maggior parte di questi exploit hanno successo solo con le versioni meno recenti del software. Sendmail, infatti, non ha presentato vulnerabilità gravi negli ultimi due anni. Nonostante questi problemi ormai vecchi siano stati ben documentati e siano stati risolti nelle versioni più recenti, sono ancora oggi in circolazione un tale numero di versioni non aggiornate o mal configurate che Sendmail rimane uno dei servizi più spesso presi di mira.

Pagina 255 di 334

I rischi che si presentano nell’utilizzo di Sendmail possono essere raggruppati in due categorie principali: l’acquisizione di privilegi causata da buffer overflow e la non corretta configurazione che fa diventare la vostra macchina un tramite per la posta elettronica inviata da un’altra macchina. Il primo è un problema che riguarda qualsiasi sistema che utilizzi ancora le vecchie versioni del codice. Il secondo è il risultato dell’uso dei file di configurazione non corretti o di quelli di default e rappresenta uno degli ostacoli maggiori nella lotta alla diffusione dello spam. Sendmail ha presentato in ato un grande numero di vulnerabilità. È meglio non fidarsi sempre della stringa di versione restituita dal daemon, perché questi non fa altro che leggerla da un file di testo presente sul sistema che può non essere correttamente aggiornato. Verificate quale sia la versione più recente di Sendmail (se dovete istallarlo da zero) o quale sia il livello di patch raggiunto (se Sendmail è già inserito nel vostro sistema operativo); se non state utilizzando l’ultima versione o l’ultimo livello di patch, probabilmente siete vulnerabili. Per proteggere Sendmail dovrebbero essere adottate le seguenti precauzioni: i.

Si i alla versione più recente e/o installate la più recente patch. Il codice sorgente è reperibile all’indirizzo http://www.sendmail.org/. Se la vostra versione di Sendmail è inserita nel sistema operativo, le patch dovrebbero essere disponibili presso il sito web del produttore del vostro sistema operativo (all’indirizzo http://www.sendmail.org/ potrete trovare anche diverse informazioni specifiche che riguardano i diversi produttori, che comprendono le indicazioni sulla configurazione e sui tempi di compilazione);

ii.

Sendmail è di solito abilitato per default sulla maggior parte dei sistemi Unix e Linux, anche in quelle che non sono utilizzate come mail server o mail relay. Non si esegua Sendmail in modalità daemon (disabilitate l’opzione "-bd") su tali macchine. Si potranno comunque spedire messaggi dal sistema in oggetto richiamando periodicamente "sendmail -q" per far partire la posta in uscita;

iii.

Se è necessario utilizzare Sendmail in modalità daemon, ci si assicuri che la configurazione sia progettata per inviare correttamente la posta e solo per i sistemi autorizzati a farlo. Si consulti http://www.sendmail.org/tips/relaying.html e http://www.sendmail.org/m4/antispam.html per i consigli su come effettuare una corretta configurazione dei server. A partire dalla versione 8.9.0 di Sendmail, la funzione di open relay è disabilitata per default. Molti produttori di sistemi operativi, però, la ri-abilitano nelle loro configurazioni di default. Se si sta utilizzando la versione di Sendmail che vi è arrivata con il sistema operativo, si controlli con molta attenzione che il server non sia utilizzabile come relay;

iv.

Quando viene aggiornato il codice binario di Sendmail, si controlli di aggiornare o di verificare anche il file di configurazione, poiché le vecchie configurazioni possono ancora permettere il relaying anche con il codice aggiornato.

4.5.2.9

BIND/DNS

Il pacchetto software Berkeley Internet Name Domain (BIND) è l'implementazione di gran lunga più utilizzata del Domain Name Service (DNS), il sistema che permette di localizzare un server su Internet (o in una rete locale) utilizzando un nome (ad esempio www.sans.org) senza dover conoscere il suo specifico indirizzo IP. La diffusione di BIND lo ha reso bersaglio di frequenti attacchi. Anche se gli sviluppatori di BIND sono storicamente molto rapidi nel correggerne le vulnerabilità, un numero eccessivo di server non aggiornati o mal configurati rimane ancora esposto agli attacchi. Pagina 256 di 334

A questa categoria contribuiscono un certo numero di fattori. I più importanti di questi sono costituiti da amministratori che non sono informati degli aggiornamenti di sicurezza, da sistemi che utilizzano il daemon BIND (chiamato "named") senza averne bisogno e da file di configurazione non appropriati. Ciascuno di questi sistemi può subire un denial of service, un buffer overflow o un DNS cache poisoning. Tra le più recenti debolezze scoperte in BIND, vi è quella discussa nel CERT Advisory CA-2002-15 che può portare a un denial of service. In questo caso un aggressore invia particolari pacchetti DNS per forzare il controllo interno che è in sé vulnerabile e fare in modo che il daemon BIND si disattivi. Un’altra vulnerabilità scoperta permette un attacco buffer overflow, trattato nel CERT Advisory CA-2002-19, nel quale gli aggressori utilizzano le versioni vulnerabili delle librerie del DNS resolver. Inviando risposte DNS confezionate ad arte, l’aggressore può sfruttare questa vulnerabilità ed eseguire codice arbitrario o anche causare un’interruzione del servizio. Oltre ai rischi che un BIND vulnerabile pone al server che lo ospita, è da aggiungere una singola macchina compromessa può costituire una piattaforma per attività dannose che hanno come obiettivo altre macchine su Internet, o può essere utilizzata come deposito di materiale illecito senza che l’amministratore lo sappia. Se viene utilizzata una versione di BIND arrivata con il sistema operativo, si verifichi di essere aggiornati con le patch più recenti rilasciate dal produttore. Se viene utilizzato BIND installato dal sorgente dell’Internet Software Consortium (ISC), controllate che quella che state usando sia la versione più recente di BIND. Qualsiasi versione non aggiornata o non corretta del software è ibile di vulnerabilità. Nella maggior parte dei sistemi, il comando "named -v" mostrerà la versione di BIND installata, numerata come X.Y.Z, dove X è la versione principale, Y è la versione secondaria e Z è il livello di patch. Vi sono attualmente tre versioni principali di BIND: 4, 8 e 9. Se si utilizza BIND installato dal codice sorgente, si dovrebbe sostituire la versione 4 con le versioni più recenti 8 o, meglio ancora, 9. È possibile recuperare il codice aggiornato dal sito ISC. Un approccio ancora più corretto sarebbe quello di utilizzare un vulnerability scanner aggiornato per verificare periodicamente il vostro sistema DNS per controllare che non presenti nuove vulnerabilità. Per proteggersi dalle vulnerabilità di BIND in generale: i.

Si disabiliti il daemon BIND (chiamato "named") su tutti i sistemi che non sono specificatamente demandati e autorizzati ad essere server DNS. Per prevenire il fatto che questa modifica possa essere invertita, è buona norma rimuovere anche il software di BIND;

ii.

Si applichino tutte le patch del produttore o si aggiornino i DNS Server alla versione più recente. Per maggiori informazioni su come rafforzare l’istallazione di BIND, si consultino gli articoli su come rendere sicuri i servizi di naming riportati nella Unix Security Checklist del CERT;

iii.

Per rendere più difficili gli attacchi o le scansioni automatiche al vostro sistema, si nasconda il banner "Version String" di BIND sostituendo la reale versione di BIND con un numero falso nel file "named.conf";

iv.

Vengano permessi i trasferimenti di zona solo verso DNS server secondari nel vostro dominio. Si disabilitino i trasferimenti di zona verso domini padri o figli, utilizzando al suo posto delegation e forwarding. Pagina 257 di 334

v.

Per evitare che "named" compromessi mettano a rischio l’intero sistema, si faccia in modo che BIND venga eseguito come utente senza privilegi in una directory chroot(). Per BIND 9, si consulti http://www.losurs.org/docs/howto/Chroot-BIND.html ;

vi.

Si disabilitino la recursion e il glue fetching, per difendersi dalla contaminazione della cache del DNS;

Per proteggervi dalle vulnerabilità di BIND scoperte recentemente: i.

Per la vulnerabilità Denial of Service su ISC BIND 9: http//www.cert.org/advisories/CA-2002-15.html ;

ii.

Per i Buffer Overflow nelle librerie del Resolver DNS: http//www.cert.org/advisories/CA-2002-19.html.

Per delle eccellenti guide su come rafforzare BIND sui sistemi Solaris e per maggiori indicazioni sulla documentazione per BIND, consultate Hardening the BIND v8 DNS Server e Running the BIND9 DNS Server Securely. 4.5.2.10

Autenticazione generica di Unix – senza o con deboli

In quasi tutte le interazioni tra gli utenti e i sistemi informativi vengono utilizzate , frasi identificative o codici di sicurezza. La maggior parte delle forme di autenticazione, come la maggior parte delle protezioni per file e dati, si basa su fornite dall’utente. Dal momento che gli accessi correttamente autenticati spesso non vengono registrati, o anche se vengono registrati non lo sono in modo da fornire alcun segnale di allarme, una compromessa rappresenta un’opportunità di esplorare un sistema dall’interno senza essere identificati. Un aggressore avrebbe accesso completo a qualsiasi risorsa disponibile per quell’utente e sarebbe molto vicino ad essere in grado di accedere ad altri , a macchine vicine e forse anche ad ottenere privilegi di amministrazione. Nonostante questi pericoli, gli con deboli o addirittura senza rimangono estremamente diffusi e le società con una buona policy sull’utilizzo delle ancora troppo rare. Le più comuni vulnerabilità delle sono dovute (a) ad senza o con deboli, (b) al fatto che, a prescindere dalla robustezza delle , spesso gli utenti non le proteggono, (c) al fatto che il sistema operativo o il software applicativo creano di amministrazione con deboli o privi di , (d) al fatto che gli algoritmi di hashing delle sono noti e spesso gli hash vengono memorizzati in modo da essere accessibili a chiunque. La difesa migliore e la più corretta contro queste vulnerabilità è una solida policy che includa le istruzioni per creare delle buone e che riassuma i comportamenti corretti per conservarne la riservatezza, unita a una verifica proattiva dell’integrità delle . Sul sistema locale le vengono salvate in either /etc/wd o in /etc/shadow. /etc/wd: questo file ha bisogno di essere leggibile da tutti gli utenti della rete per poter permettere il processo di autenticazione. Se tale file include anche gli hash delle , allora ogni utente con accesso al sistema può leggere gli hash e provare a violarli con un cracker. Per custodire gli hash si può utilizzare in alternativa /etc/shadow, che deve essere leggibile solo da root. Se i vostri locali non sono protetti da /etc/shadow, allora il rischio per le vostre diventa molto alto. Pagina 258 di 334

Se utilizzate NIS, gli hash delle sono leggibili da tutti gli utenti e si viene a costituire come nel caso precedente un rischio molto elevato. Ciò può essere il caso di alcune implementazioni di LDAP come servizio di autenticazione di rete. Ma anche se gli hash delle sono protetti, le possono essere indovinate in altri modi. Per quanto vi siano alcuni sintomi osservabili di una generale debolezza delle , come la presenza di attivi appartenenti a utenti che non operano più all’interno dell’organizzazione o a servizi non più attivi, l’unico modo per accertarsi che ogni singola sia sufficientemente robusta è quello di verificare tutte le con gli stessi strumenti per la determinazione delle utilizzati dagli aggressori. ATTENZIONE: Non si utilizzi mai un scanner, neanche sui sistemi per i quali avete un accesso da amministratore, senza autorizzazione esplicita e preferibilmente scritta da parte del datore di lavoro. È già accaduto che amministratori di sistema con le migliori intenzioni siano stati licenziati per aver utilizzato strumenti per la determinazione delle senza autorizzazione. I migliori strumenti per la determinazione delle sono: •

Crack

•

John the Ripper

•

Symantec NetRecon

La difesa migliore e la più corretta contro la debolezza delle è una solida policy che includa le istruzioni su come generare buone e descriva i comportamenti corretti per mantenerne la sicurezza, assieme ad una verifica proattiva dell’integrità delle .

4.5.3

i.

Ci si assicuri che le siano sufficientemente robuste;

ii.

Una volta fornite agli utenti le corrette indicazioni su come generare buone , possono essere messe in opera le procedure per controllare che queste indicazioni vengano seguite. Il modo migliore per farlo è quello di convalidare le ogni volta che l’utente le cambia. La maggior parte dei tipi di Unix può usare Nwd come front-end per verificare le inserite alla luce della vostra policy. I sistemi abilitati PAM possono anche includere cracklib (le librerie del tool “Crack”);

iii.

Un altro modo per proteggersi da deboli o assenti è quello di utilizzare forme alternative di autenticazione come token generatori di o sistemi di autenticazione biometria;

iv.

Proteggere le robuste;

v.

Controllare rigorosamente gli ;

vi.

Implementare una solida policy per le in azienda.

Porte vulnerabili

In questa sezione, sono elencate le porte che sono generalmente esaminate e attaccate. Bloccando il traffico che a attraverso le porte di firewall o di altri dispositivi di protezione del perimetro della rete, è possibile ottenere un livello di difesa aggiuntivo che aiuta a tutelare da eventuali errori di configurazione. Si tenga comunque presente che, anche se viene utilizzato un firewall per bloccare il

Pagina 259 di 334

traffico di rete diretto a una porta, essa non è protetta da possibili azioni causate da soggetti che si trovano già all’interno del perimetro, né dall’azione di hacker penetrati utilizzando altri metodi. Il blocco di queste porte rappresenta il requisito minimo per la sicurezza perimetrale, non una lista esaustiva delle specifiche per il firewall. Una regola di gran lunga migliore sarebbe quella di bloccare tutte le porte inutilizzate. Comunque, anche se si ritiene che queste porte siano bloccate, si deve sempre controllarle attivamente per scoprire eventuali tentativi d'intrusione. Un ultimo avvertimento è doveroso: il blocco di alcune delle porte elencate può disabilitare servizi necessari. Prima di implementare queste raccomandazioni, si considerino i potenziali effetti. Si tenga presente che il blocco di queste porte non rappresenta un sostituto alle soluzioni di sicurezza globali. Se le porte non sono state rese sicure in maniera adeguata su ogni sistema host dell’organizzazione, un aggressore che ha ottenuto l'accesso alla rete con altri mezzi (un modem telefonico, un trojan allegato ad un’e-mail o un complice interno all'organizzazione, per esempio) può sfruttare dette porte anche se sono bloccate. a) Servizi di – telnet (23/t), SSH (22/t), FTP (21/t), NetBIOS (139/t), r e altri (da 512/t a 514/t); b) RPC e NFS – Portmap/rpcbind (111/t e 111/udp), NFS (2049/t e 2049/udp), lockd (4045/t e 4045/udp); c) NetBIOS in Windows NT – 135 (t e udp), 137 (udp), 138 (udp), 139 (t). Windows 2000 le prime porte più la 445(t e udp); d) X Windows – da 6000/t a 6255/t; e) Naming Services – DNS (53/udp) per tutte le macchine che non sono server DNS, trasferimenti di zona DNS (53/t) eccezion fatta per le external secondaries, LDAP (389/t e 389/udp); f) Mail – SMTP (25/t) per tutte le macchine che non siano relay di posta esterni, POP (109/t e 110/t), IMAP (143/t); g) Web – HTTP (80/t) e SSL (443/t) eccezion fatta per i server Web esterni, e potreste anche bloccare le comuni porte HTTP più significative (8000/t, 8080/t, 8888/t, ecc.); h) "Small Services" – porte al di sotto di 20/t e 20/udp, time (37/t e 37/udp); i) Varie – TFTP (69/udp), finger (79/t), NNTP (119/t), NTP (123/udp), LPD (515/t), syslog (514/udp), SNMP (161/t e 161/udp, 162/t e 162/udp), BGP (179/t), SOCKS (1080/t); j) ICMP – bloccate le echo request in entrata (ping e traceroute di Windows), blocco delle echo reply in uscita, time exceeded e messaggi destination unreachable eccezion fatta per i messaggi "packet too big" (type 3, code 4). (Questo suggerimento suppone che vogliate rinunciare all'uso classico dell’echo request ICMP al fine di bloccarne alcuni noti utilizzi illeciti). In aggiunta a queste porte, si blocchino gli indirizzi "spoofed" – pacchetti in arrivo dall'esterno della vostra azienda che hanno come sorgente indirizzi interni, indirizzi privati (RFC1918 e rete 127) e riservati IANA. Si blocchino anche i pacchetti instradati alla sorgente o i pacchetti con il campo delle opzioni IP impostato.

Pagina 260 di 334

4.5.4

Il Firewall La sicurezza perimetrale garantita dai firewall è uno dei punti che sicuramente deve essere verificata a fronte di un tentativo di intrusione. Questo meccanismo, il firewall, è conosciuto dai più come “il” sistema di protezione della rete e il più delle volte viene lasciato al suo destino, una volta installato e personalizzato, pensando di aver protetto definitivamente la propria rete. Ma come tutti i sistemi complessi e dinamici, questo strumento ha la necessità di essere aggiornato sia a livello di patch che a livello di configurazione, per adeguarsi alle mutazioni architetturali nelle quali è inserito. Evidentemente ogni architettura di rete è diversa dalle altre, con delle considerazioni di revisione che si differenziano tra di loro. Però è possibile affrontare l’analisi dello stato della propria rete affrontando alcuni semplici quesiti che sono utilizzati generalmente nelle fasi di audit dei firewall: Verificare l’esistenza nell’organizzazione una policy relativa all’utilizzo di internet; Assicurarsi che le regole siano implementate correttamente così da assicurarne la protezione; Verificare quale scelta di policy è stata fatta: è permesso l’accesso a qualsiasi servizio che non sia espressamente negato, o viceversa? Assicurarsi che il firewall possa are una policy che impedisca l’accesso a tutti i servizi eccetto a quelli espressamente permessi, anche se questa non è la policy effettivamente utilizzata; Assicurarsi che il firewall sia flessibile e possa ospitare nuovi servizi e necessità nel caso in cui le policy di sicurezza dell’organizzazione debbano cambiare; Verificare che il firewall contenga misure di autenticazione avanzate oppure possa contenere le opzioni per poterle installare; Assicurarsi che le tecniche di employ filtering permettano o impediscano l’accesso ai servizi a specifici host secondo necessità; Assicurarsi che il linguaggio di IP filtering sia flessibile, e che possa filtrare il maggior numero di attributi possibile compresi gli indirizzi IP di partenza e di destinazione, il tipo di protocollo, la porta T/UDP di partenza e di destinazione e l’interfaccia inbound e outbound; Verificare che il firewall utilizzi proxy service per servizi come HTTP, FTP e Telnet, così che misure di autenticazione avanzate possano essere implementate e centralizzate sul firewall; Determinare se gli application gateway includano la possibilità di impedire l’esecuzione dei comandi put e get per specificare gli host e se essi sono in uso; Assicurarsi che il firewall abbia la possibilità di centralizzare gli accessi SMTP (Simple Mail Transfer Protocol) per ridurre le connessioni SMTP dirette tra sistema remoto e locale; Determinare chi amministra il firewall; Pagina 261 di 334

Verificare se esiste un Incident Response Team e se l’amministratore del firewall fa parte di questo; Assicurarsi che il firewall permetta libero accesso al sito così che i server che contengono le informazioni pubbliche possano essere protetti dal firewall, essendo tuttavia segregati dai sistemi che non forniscono informazioni pubbliche; Verificare che il firewall contenga meccanismi per il logging del traffico e di attività sospette e che contenga meccanismi per la log analysis affinché i log siano leggibili e comprensibili; Assicurarsi che il firewall sia prontamente aggiornato con patch e hot-fix, che l’application software sul firewall server sia aggiornato alla versione più recente; Verificare il processo autorizzativo per effettuare le modifiche al firewall e come le modifiche sono controllate; Determinare se esiste una policy di back-up e che questa sia rispettata.

Pagina 262 di 334

4.6 Migliorare i sistemi di Intrusion Detection per avere segnalazioni migliori. 4.6.1

Introduzione Nel paragrafo 2.5.4.1 si è introdotto il concetto di IDS – Intrusion Detection System, specificandone le tipologie principali ed esponendo brevemente quali sono i pregi e limiti di ciascuna soluzione. In questo paragrafo tratteremo quali sono i rischi e le debolezze più comuni legate ai sistemi di Intrusion Detection e proporremo eventuali soluzioni o accorgimenti attualmente adottati o dibattuti nella comunità IT. Cercheremo, dove possibile, di non parlare di sistemi o tools specifici ma di fare un'analisi generale sulle debolezze legate ai vari tipi di approccio: non esiste infatti una soluzione migliore in assoluto ma, in base alle specifiche esigenze (prestazioni, contromisure, tipologia di attacchi da prevenire etc.) in un determinato momento, sarà spesso necessario un trade-off tra le diverse alternative a disposizione Ricordiamo che l' IDS è un componente che non sostituisce il firewall o i vari meccanismi di logging, ma che è consigliabile che venga affiancato ad essi nel processo di sicurezza dei sistemi. Attraverso i dispositivi di Intrusion Detection si ha la possibilità di determinare se un intruso ha guadagnato, o sta per guadagnare, un accesso non autorizzato. Lo scopo è quello di allertare gli amministratori che vi è stato un accesso, prima che l'intruso possa causare ulteriori danni o rubare delle informazioni. E' lo stesso principio degli allarmi degli edifici: il ladro è già all'interno, o quantomeno sta cercando di forzare un'entrata: si tratta quindi di intervenire prima che egli possa rubare o distruggere qualcosa.

4.6.2

IDS: Richiami

4.6.2.1

Funzionalità base degli IDS

L' “intrusion detection” è il processo di scoperta, analisi e reporting di attività non autorizzate o che possono procurare un danno al sistema informativo aziendale. Questo processo serve a rivelare violazioni avvenute nell'ambito della confidenzialità, integrità e disponibilità delle risorse e delle informazioni. Gli IDS collezionano informazioni da una molteplicità di sistemi e fonti sulla propria rete, analizzandole poi alla ricerca di problemi inerenti la sicurezza. In alcuni casi, i sistemi di rilevazione delle intrusioni, permettono all'utente di specificare in real-time dei comportamenti da adottare in risposta ai tentativi di intrusione che si stanno subendo. I sistemi di Intrusion Detection adempiono ad una varietà di funzioni: •

Monitoraggio ed analisi dell'attività di utenti e sistemi Pagina 263 di 334

• • • • •

Verifica delle configurazioni di sistema e delle vulnerabilità Accertamento dell'integrità di sistemi e files critici Riconoscimento di patterns che riflettono tipi di attacchi conosciuti Analisi statistiche alla ricerca di schemi di attività anomale Gestione dei controlli dei sistemi operativi, con l'identificazione di quelle attività degli utenti che riflettono violazioni nelle policies di sicurezza

Alcuni sistemi forniscono funzionalità aggiuntive che includono: • •

Installazione automatica di patch software Installazione e gestione di sistemi virtuali usati come esca per raccogliere informazioni sugli attaccanti.

La combinazione di queste caratteristiche permettono ai manager IT di trattare in modo più semplice il controllo, la verifica, e la valutazione dei loro sistemi e reti. Gli IDS sono un elemento sempre più importante nel mercato della sicurezza informatica. Sebbene i sistemi di intrusion detection siano stati, fino a poco tempo fa, molto costosi e difficili da mantenere, essi hanno cominciato ad essere accessibili anche per le ditte più modeste. Il fenomeno degli IDS ha portato però alcune persone, a pensare che essi siano la panacea per tutti i loro problemi di sicurezza. Sebbene essi siano un'utilissima arma nell'ambito della sicurezza informatica, hanno pur sempre delle capacità e possibilità limitate. Aspettarsi troppo da un IDS può rivelarsi quindi controproducente: è sempre necessario che la sicurezza percepita coincida con l'effettiva sicurezza del sistema. 4.6.2.2

IDS e Firewalls

I firewall pongono una barriera nel punto di connessione tra Internet e la rete protetta. Sebbene i firewalls siano un componente necessario per la sicurezza, essi solitamente non sono infallibili. Essi infatti, il più delle volte sono difficili da installare e configurare correttamente, perfino da personale esperto. Anche i più piccoli errori di configurazione possono creare un'ampia breccia nella sicurezza del sistema. Una difficoltà aggiuntiva con i firewall è il fatto che necessitano di continui aggiornamenti e monitoraggi per essere sicuri che le configurazioni riflettano gli effettivi livelli di sicurezza richiesti. Gli IDS entrano quindi in gioco quando un attacco è riuscito a superare la protezione esterna fornita dal firewall. Un ulteriore modo per caratterizzare le differenze tra firewall e IDS e quello di classificare le violazioni per origine: non tutte le violazioni infatti provengono dall'esterno della rete. Nel caso in cui l'attacco provenga da una fonte interna il firewall sarebbe di poca utilità: esso infatti vede solamente il traffico ai confini tra la rete interna ed Internet. Se il traffico generato a seguito della violazione della sicurezza non attraversa mai il firewall esso non riuscirà ad evidenziare che c'è stato un problema.

Pagina 264 di 334

Un ulteriore debolezza del firewall è data dal fatto che non tutto il traffico verso l'esterno, generato dalla rete interna, a attraverso di esso. Gli utenti interni, per una serie di ragioni che vanno dall'impazienza all'ingenuità, talvolta impostano delle connessioni non autorizzate attraverso l'utilizzo di modem che collegano le loro postazioni con providers esterni. Infine i firewalls sono a loro volta soggetti ad attacchi, ed esistono praticamente da sempre strategie volte ad eludere il loro controllo. Un esempio è quello di utilizzare il tunneling per byare le protezioni del firewall (tunneling è la pratica di incapsulare un messaggio in un certo protocollo, che verrebbe bloccato dal firewall, all'interno di un altro messaggio che il firewall lascia are). 4.6.3

Modelli di classificazione degli IDS Si possono identificare varie tipologie di sistemi di intrusion detection: •

Classificazione in base alla fonte delle informazioni Application-based e Application-integrated Module Host-Based Target-based (o Integrity checkers) Network-based Sistemi integrati

•

Classificazione in base al momento dell'analisi delle informazioni Sistemi Batch o Interval-based Sistemi Real-Time

•

Classificazione in base alla tipologia di analisi Anomaly Detection Approccio statistico Approccio rule-based / Predictive pattern generation Misuse Detection Expert systems Keystroke monitoring State Transition Analyses Pattern Matching Stateful Pattern Matching Protocol Decode-Based Analysis Model-based intrusion detection

•

Il o successivo nell'evoluzione degli IDS: IPS e Honeynets IPS: Intrusion Prevention Systems Honeypots / Honeynets Pagina 265 di 334

4.6.3.1

Classificazione in base alla fonte delle informazioni

Application-based e Application-integrated Module I sensori application-based raccolgono informazioni a livello applicativo. Esempi di livello applicativo sono i log generati da software di gestione dei database, web server, o firewalls. Con la proliferazione del commercio elettronico e dei servizi basati sul Web, la sicurezza si è focalizzata sulle interazioni tra gli utenti ed i programmi applicativi. I vantaggi del controllo a livello applicativo sono: • possibilità di controllare le attività dei sistemi ad un livello molto dettagliato (es. sapere se un determinato utente ha utilizzato un particolare servizio di una particolare applicazione) • indipendenza dalla velocità della rete • possibilità di ricostruire e decodificare le sessioni e le transazioni avvenute • opportunità di eseguire azioni di controllo preventive Svantaggi: • le vulnerabilità insite nel livello applicativo (es. in particolari protocolli) possono diminuire l'effettiva efficienza ed utilità dei controlli application-based • dipendente da applicazioni specifiche • invasivo: possono avere notevole impatto sulla stabilità e sulle performance • difficoltà nell'eseguire test adeguati Host-Based Gli Host-IDS (HIDS) utilizzano un sensore (chiamato anche agent) che risiede su ogni host che deve essere monitorato. L'agente esamina i log di sistema, del kernel, i files critici del sistema ed altre risorse alla ricerca di modifiche non autorizzate o di segni di attività sospette. Ogni volta che qualcosa fuori dalla norma viene riscontrato, degli allarmi vengono generati ed inviati agli amministratori dei sistemi. Ad esempio, un HIDS può monitorare il registro di sistema per segnalare in tempo degli accessi non autorizzati; può monitorare i log del kernel per scoprire quando un determinato processo ha avuto inizio oppure monitorare i per prendere nota di quando è stato fatto un tentativo di accesso con una non corretta. Monitoraggio dell'attività di . Malgrado i notevoli sforzi degli amministratori di rete, ed il recente sviluppo di software di intrusion detection, ogni tanto un intruso riesce a loggarsi in un sistema sfruttando qualche tipo di attacco sconosciuto. Probabilmente l'attacker ha ottenuto in qualche modo una (facendo del packet sniffing oppure in altri modi) ed ora ha la possibilità di loggarsi nel sistema da remoto. Osservare attività insolite nel sistema è il compito di alcuni HIDS. Questo tipo di tool monitora i tentativi di e , avvertendo l'amministratore di sistema se riscontra dell'attività inusuale o sospetta. Pagina 266 di 334

Monitoraggio dell'attività di Root Lo scopo di tutti gli intrusi è quello di ottenere l'accesso come super- (root), o amministratore del sistema compromesso. Sistemi affidabili e correttamente mantenuti utilizzati come web server o database hanno solitamente una bassa attività da parte dell'amministratore, eccetto che per particolari orari del giorno o della notte per la manutenzione ordinaria del sistema. Solitamente gli attackers colpiscono ad ogni ora ed eseguono azioni che sono insolite per un normale amministratore: come un'ulteriore linea di difesa quindi, si può pensare di monitorare le azioni compiute da root o dagli amministratori di sistema alla ricerca di comportamenti sospetti. Molti sistemi Unix consentono il logging o altri tipi di monitoraggio di tutte le attività compiute dall'utente root, eseguendo una scansione di questi log alla ricerca di attività insolite per avvertire tempestivamente il responsabile IT. Gli amministratori di sistemi operativi open-source hanno un'ulteriore opzione: modificare il kernel per loggare attività specifiche (come fare ciò esula dallo scopo di questo documento). Vantaggi degli HIDS: • i sistemi possono monitorare l'accesso alle informazioni nei termini di “chi ha avuto accesso a cosa” • i sistemi possono mappare verso specifici -id tutte le attività che hanno dato luogo a problemi • i sistemi possono tenere traccia di tutti i cambiamenti associati alle violazioni subite • i sistemi possono operare in ambianti criptati • i sistemi possono operare in reti switched Svantaggi: • • • • •

l'attività di rete non è visibile ai sensori host-based i meccanismi di verifica possono provocare un overhead delle risorse possono essere necessarie notevoli risorse in termini di spazio per salvare tutti i log le vulnerabilità insite nei sistemi operativi possono limitare l'integrità degli agenti gli agenti devono essere molto specifici per la piattaforma su cui operano: ciò comporta un costo di sviluppo non indifferente • lo sviluppo di politiche di audit efficaci è complicato e può essere molto dispendioso in termini di tempo durante la fase di configurazione e di test • possono essere a loro volta vittime di tecniche di Kernel Hacks, By della stack protection, Library Hacks, HTTP Logging Una breve lista e descrizione di log checkers e HIDS si può trovare nei paragrafi 2.5.2.1 e 3.1.10 Target-based (o Integrity checkers) Una volta che un intruder ha compromesso un sistema, sicuramente i file presenti subiranno delle modifiche. L'intruso potrebbe ad esempio voler installare un packet sniffer, modificare alcuni programmi o files di sistema al fine di disabilitare i meccanismi di intrusion detection. Anche l'installazione di nuovo software generalmente causa delle modifiche in alcune parti del sistema (files o librerie). Pagina 267 di 334

Gli intergrity checkers aiutano ad individuare simili manipolazioni e generalmente registrano cambiamenti nella data di creazione o modifica di un file, alterazioni dei permessi, degli attributi o del contenuto di file di configurazione, binari, log etc. Per esempio può essere utilizzato il seguente approccio: •

creare un MD5 o un altro tipo di checksum su tutti i file di sistema e salvarli in un database: quando il file verrà modificato anche il relativo checksum risulterà essere diverso da quello presente nel database.

•

salvare l'orario e la data di creazione o modifica di ogni file di sistema: controllare questi timestamp per verificare ogni cambiamento

•

tenere traccia di ogni programma SUID (esegui-come-root) del sistema: se qualcuno di questi cambia, viene aggiunto o eliminato, significa che c'è un problema.

I metodi usati da tools quali Tripwire o AIDE differiscono in alcune cose, ma sono comunque basati sui meccanismi sopracitati. Questi programmi hanno inoltre la cura di evitare che il database contenente i checksum dei files sia a sua volta compromesso: il suddetto infatti viene criptato e solo il proprietario della relativa potrà accedere al programma principale per effettuare delle modifiche o degli aggiornamenti. Vantaggi degli integrity checkers: •

non dipendendo da una registrazione cronologica degli avvenimenti, la verifica dell'integrità può rivelare intrusioni che altre metodologie non riescono a scoprire

•

questo approccio permette di rilevare in modo affidabile la presenza di attacchi che modificano il sistema (es. Trojan horses)

•

sono poco intrusivi

•

agevolano la capacità di determinare quali files devono essere ripristinati a seguito di un'intrusione facendo risparmiare una notevole quantità di tempo.

Svantaggi: •

siccome dipendono dal numero dei file e dagli attributi degli oggetti da verificare, questo approccio può comportare un certo livello di carico, soprattutto per sistemi che non sono provvisti di determinate capacità computazionali o con risorse limitate

•

questo approccio non è adatto per processi di rilevamento dell'intrusione in real-time

•

possono essere effettuate delle modifiche al kernel che rendano vane alcuni tipi di analisi (es. quelle effettuate sugli attributi dei files etc.)

Una breve lista e descrizione di integrity checkers tools si può trovare nei paragrafi 2.5.3.3 e 3.1.10. Pagina 268 di 334

Network-based I sensori network-based raccolgono informazioni dalla rete stessa. Queste informazioni sono catturate attraverso l'uso di packet sniffers, utilizzando interfacce di rete in modalità promiscua; altre volte invece, gli agenti sono direttamente incorporati in dispositivi hardware dedicati. Questi sensori sono dislocati in vari punti sulla rete e solitamente, dopo aver effettuato un analisi in locale, segnalano la presenza di un attacco ad una console centralizzata. Ascoltando su un segmento di rete, un network IDS può monitorare il traffico dei diversi host che sono collegati a quel segmento, fornendo ad essi una protezione maggiore dagli attacchi esterni. Vantaggi dei network-based IDS: •

pochi sensori ben collocati possono monitorare grandi reti

•

lo sviluppo di un IDS network-based ha un impatto relativo sulla rete esistente. I sensori infatti sono generalmente dispositivi ivi che ascoltano sul filo senza interferire con le normali operazioni della rete. In questo modo risulta quindi semplice modificare una rete per includere gli agenti dell'IDS.

•

i NIDS possono risultare molto sicuri contro gli attacchi di rete (ad es.contro i SYN flood ed i packet storm attacks) e possono essere perfino resi invisibili agli occhi degli attaccanti

•

possono loggare ivamente, avvisare gli amministratori con messaggi SMTP/SNMP oppure inviando fax, SMS etc.

Svantaggi: •

gli IDS network-based possono avere difficoltà nel processare tutti i pacchetti presenti in reti grandi o congestionate e, quindi, possono fallire nel riconoscere un attacco lanciato durante un momento di elevato traffico. Molti produttori stanno cercando di risolvere questo problema implementando gli IDS direttamente in hardware, indubbiamente più veloce.

•

Molti dei vantaggi dei NIDS non possono essere applicati alle reti switch-based. Gli switch suddividono le reti in molti piccoli segmenti e forniscono una linea dedicata tra gli host collegati dallo stesso switch. Molti di questi dispositivi non forniscono un monitoraggio universale delle porte ma si limitano al monitoraggio di singoli host

•

non possono analizzare informazioni criptate. Questo problema aumenta nel momento in cui una azienda utilizza reti private virtuali (VPN)

•

molti NIDS non possono segnalare se un attacco ha avuto successo; possono solamente stabilire se un attacco è iniziato. Questo significa che se viene rilevato un attacco gli amministratori devono investigare su ogni host per determinare se è stato colpito o meno Pagina 269 di 334

•

molti NIDS hanno problemi a gestire attacchi che utilizzano pacchetti frammentati. Questi pacchetti malformati possono rendere instabile l'IDS generando addirittura dei crash.

•

Il numero e qualità delle signatures su cui si basano alcuni NIDS possono ridurre l'efficienza del sistema di intrusion detection

•

grandi dimensioni richieste per lo storage dei log

•

vittime di tecniche di insertion

•

vittime di tecniche di evasion

•

vittime di tecniche di denial of service

Una breve lista e descrizione di tools network based si può trovare nei paragrafi 1.3.2, 2.5.2.1, 2.5.4.1, 3.1.10 Sistemi integrati Alcuni prodotti di intrusion detection combinano soluzioni a livello di application, di host e sensori network-based. Vantaggi: •

il sistema può monitorare l'attività ad alcuni o a tutti i livelli

•

è possibile vedere le tracce di un attacco sulle rete e sull'host nello stesso tempo: ciò è di grande aiuto durante le fasi di valutazione e stima dei danni e di recovery del sistema

Svantaggi:

4.6.3.2

•

non esistono standard industriali che permettono la completa interoperabilità tra i vari componenti: risulta quindi pressoché impossibile integrare componenti di diversi vendors

•

i sistemi integrati sono più difficili da gestire e sviluppare

Classificazione in base al momento dell'analisi delle informazioni

Possiamo catalogare le varie tipologie di IDS in base all'intervallo di tempo che a dal momento in cui viene effettuata l'operazione di monitoraggio, fino a quando viene compiuta l'analisi sugli eventi.

Pagina 270 di 334

Sistemi Batch o Interval-based Nell'approccio interval-based il flusso di informazioni dai punti di monitoraggio ai sistemi dediti all'analisi dei dati non è continuo. Solitamente i meccanismi di audit dei sistemi operativi (o dei sistemi host-based in generale) registrano le informazioni in file di log che, in un tempo successivo e ad intervalli periodici, vengono analizzati dai sistemi di intrusion detection alla ricerca di segni di intrusione o di abusi. Vantaggi dei sistemi batch: •

gli schemi di analisi batch richiedono un minor carico in termini di risorse rispetto ai sistemi real-time

•

i sistemi batch sono preferiti in quelle aziende in cui le risorse ed il personale dedicato alla sicurezza sono limitati: risulta infatti meno impegnativo utilizzare sistemi che non obblighino ad intervenire in tempo reale alle sospette violazioni (ad es. intervenire subito a seguito di un allarme generato dal sistema, magari fuori orario lavorativo).

•

sono preferiti in ambienti nei quali i livelli di minaccia sono relativamente bassi ed i potenziali danni derivanti da singoli attacchi sono invece elevati (ad es. istituti finanziari). In questi ambienti infatti è solitamente di maggior interesse identificare le responsabilità dei problemi piuttosto che reagire immediatamente al sospetto incidente. In queste situazioni un'analisi batch-oriented verrà combinata con altri processi investigativi allo scopo di identificare il colpevole dell'incidente.

•

gli attacchi ai sistemi spesso implicano la ripetizione dell'attacco verso lo stesso target. Per esempio, un intruso potrebbe riuscire ad installare un Trojan-horse per garantirsi un facile accesso futuro. L'analisi batch solitamente riesce ad identificare i segni di questo tipo di attacchi.

•

molte procedure a livello giuridico relative alle fonti di prova si basano sull'acquisizione di log generati e processati da sistemi batch di intrusion detection.

Svantaggi: •

gli utenti raramente possono accorgersi dell'incidente prima che questo venga completato

•

non è possibile intervenire attivamente ed immediatamente per ridurre i possibili danni (ma solo verificare a posteriori quali danni vi sono stati)

•

è necessaria una notevole quantità di spazio per salvare i dati necessari all'analisi batch

Sistemi Real-Time I sistemi real-time prevedono una raccolta delle informazioni, un'analisi ed un reporting, effettuati in modo continuativo.

Pagina 271 di 334

Questo tipo di schema è utilizzato soprattutto nei network intrusion detection system, per i quali è necessario che la scoperta dell'attacco sia effettuata rapidamente, al punto di bloccare sul nascere ogni tentativo di intrusione. A seguito della scoperta di un tentativo di attacco possono venir generati una serie di allarmi. Alcuni di questi sono di o, come ad esempio l'invio di una mail, di un fax o SMS. Altri invece consentono di intervenire direttamente rispondendo in maniera automatica all'attacco ad esempio terminando la connessione con la fonte dell'attacco, riconfigurando le regole del firewall, cambiando i settaggi del sistema per limitare i danni. La maggior parte dei sistemi network-based commerciali è di tipo real-time. Vantaggi: •

in relazione anche alla velocità nell'analizzare i dati, gli attacchi possono essere scoperti abbastanza rapidamente da consentire agli amministratori di bloccarli o comunque di limitare i danni consentendo una più rapida fase di recovery.

•

Gli amministratori sono in grado di raccogliere informazioni utilizzabili in un momento futuro per identificare e perseguire legalmente gli intrusi

Svantaggi:

4.6.3.3

•

i sistemi di IDS real-time consumano molta memoria e risorse di calcolo degli altri tipi di IDS, basati su un'analisi posteriore

•

possono esserci conseguenze giuridiche derivanti da azioni automatiche di risposta all'attacco, configurate su alcuni IDS: esse infatti possono a loro volta arrecare danni ai sistemi attaccanti

•

la configurazione ed il testing di sistemi real-time è una fase critica: i rischi maggiori infatti sono quelli di trovarsi di fronte ad un elevato numero di falsi positivi o, ancora peggio, non rilevare alcuni attacchi.

Classificazione in base alla tipologia di analisi

Anomaly Detection Le tecniche di anomaly detection partono dal concetto che tutte le attività intrusive sono necessariamente anomale. Questo significa che è possibile creare un “profilo di attività” considerate normali: in seguito questo profilo verrà confrontato con gli eventi che avvengono in tempo reale. Ogni comportamento (sugli host o nelle attività di rete) che risulterà discostarsi da quello considerato normale verrà loggato e segnalato. Possono presentarsi quindi un paio di possibilità: •

attività che non sono intrusive possono venire etichettate come intrusive

•

attività intrusive che non vengono considerate anomale non verranno segnalate Pagina 272 di 334

Questi problemi sono comunemente definiti come falsi positivi e falsi negativi. Uno degli obiettivi più importanti nei sistemi di anomaly detection è quello di definire un livellosoglia adeguato, per il quale i due problemi sopracitati non vengano troppo ingigantiti. Tratteremo più in dettaglio dei falsi positivi e falsi negativi nel seguito del capitolo, quando parleremo dei problemi legati agli IDS. Generazione dei profili Uno dei fattori che maggiormente differenzia le varie tecnologie di anomaly detection risiede nel metodo di costruzione del profilo del sistema. La modellazione di un comportamento normale può essere basata su due tipi di approccio: statistico o basato su regole. Entrambi possono essere applicati a singole macchine, reti, protocolli o applicazioni. Approccio statistico Con questo metodo sono inizialmente generati dei profili di comportamento dei soggetti. Mentre il sistema lavora, l'anomaly detector genera costantemente una variazione del profilo attuale rispetto a quello originale. Potranno poi essere eseguite molte misurazioni sul profilo di comportamento, come misurazioni di attività del sistema, utilizzo del tempo di U, numero di connessioni di rete in un certo intervallo di tempo, etc. Vantaggi: •

non essendo necessaria una conoscenza a priori dell'attacco, questo tipo di sistemi può rilevare dei tentativi di attacco sconosciuti. Se una rete o un host è attaccato da un nuovo worm, virus, Denial Of Service, il sistema di intrusion detection statistical-based può segnalare la presenza di attività sospetta.

•

la manutenzione di questi sistemi è potenzialmente più semplice di quella necessaria per gli altri metodi di IDS. Non vi è infatti la necessità di effettuare continui aggiornamenti delle firme ogni qualvolta compaia un nuovo tipo di attacco.

Svantaggi: •

molte reti e sistemi sono estremamente diversi in termini di protocolli, servizi, tempi di utilizzo etc. Ad esempio, del traffico verso uno specifico host può essere innocuo mentre verso un altro host può sfruttare delle vulnerabilità specifiche: la stessa definizione di comportamento “normale” cambia quindi continuamente.

•

l'IDS ha il compito di decidere cosa deve essere considerato normale e cosa anomalo, ma non ha modo di sapere se un comportamento è “buono” o “cattivo”

•

la fase di apprendimento può essere lunga e difficoltosa prima di poter avere un sistema di rilevamento accurato ed efficace.

•

È necessario il o di persone molto qualificate

Pagina 273 di 334

•

spesso l'allarme generato non è di facile interpretazione. Potrebbe infatti consistere solamente nel log di un determinato pacchetto: sarà poi compito dell'operatore determinare la natura dell'allarme

•

la soglia di attivazione del sistema di intrusion detection non è semplice da valutare: fissare una soglia troppo alta rischia di non attivare il sistema quando sarebbe necessario; una soglia troppo bassa produrrà un sovrannumero di falsi positivi

Approccio rule-based / Predictive pattern generation Questo metodo di intrusion detection cerca di prevedere eventi futuri basandosi su eventi che sono già accaduti. Potremmo ad esempio avere una regola del tipo: E1 - E2 --> (E3 = 80%, E4 = 15%, E5 = 5%)

Il significato è che se si sono verificati gli eventi E1 ed E2, con E2 accaduto dopo E1, allora vi è l'80% di probabilità che li seguirà l'evento E3, il 15% di probabilità che sarà E4 ed il 5% che sarà E5. Il problema con questo tipo di approccio è che alcuni scenari di intrusione non siano descritti come pericolosi nelle regole. In questo caso al verificarsi di una sequenza di eventi non presente nel database, questa verrà etichettata come “non riconosciuta”. Il problema può essere parzialmente risolto assegnando ad ogni evento non riconosciuto il ruolo di sospetto attacco (incrementando però i falsi positivi) oppure al contrario assegnando il ruolo di evento innocuo (incrementando la possibilità di falsi negativi). Vantaggi: •

possono essere scoperte attività anomale difficilmente evidenziabili con metodi tradizionali

•

i sistemi costruiti su questo modello si adattano bene ai cambiamenti: i pattern di scarsa qualità vengono infatti costantemente eliminati lasciando il posto a pattern sempre migliori e più affidabili

•

le attività anomale possono essere scoperte e segnalate pochi secondi dopo la verifica degli eventi

Svantaggi: •

difficoltà nel fissare una soglia adeguata che permetta di ridurre falsi positivi e falsi negativi

•

è necessario fare un numero considerevole di prove ed errori, il che comporta un dispendio di tempo e la necessità di avere personale qualificato

•

un intruder potrebbe cercare di ingannare il sistema durante la fase di apprendimento

Pagina 274 di 334

Misuse Detection Le tecniche di misuse detection si occupano di scoprire azioni sospette da parte di utenti, che assomigliano ad attacchi conosciuti, che sfruttano le vulnerabilità note dei sistemi, o che in qualche modo violano direttamente le policies di sicurezza. Per fare ciò si avvalgono di signatures (chiamate anche firme), spesso create da esperti che hanno particolare familiarità con i sistemi target, con i vari sistemi operativi e con le varie tecniche di intrusione. Altre persone che collaborano alla stesura di signatures sempre più aggiornate ed efficaci sono i ricercatori nel settore della sicurezza informatica, le comunità degli utenti e degli sviluppatori dei vari sistemi di intrusion detection. Allo stato attuale non vi sono metodi univoci per creare le firme migliori, e la misuse detecton è ancora fortemente legata alla conoscenza diretta dei vari tipi di intrusione e delle vulnerabilità conosciute. Molti sistemi di misuse detection sono stati sviluppati negli anni. Essi si differenziano in diversi approcci: •

expert systems (sistemi esperti: if then else)

•

keystroke monitoring

•

state transition analyses

•

pattern matching

•

protocol decode-based analysis

•

model-based intrusion detection

Expert systems I primi sistemi di misuse detection utilizzavano gli expert systems per scoprire le intrusioni Sistemi come NIDES, MIDAS, e NADIR hanno sistemi esperti che fanno da complemento ai loro anomaly detectors. In questi IDS le possibili intrusioni sono codificate come regole (rules) di sistemi esperti. Una regola ha la forma del tipo: se condizione allora azione. Le regole possono riconoscere dei singoli eventi o una sequenza di eventi che rappresenta lo scenario dell'intrusione. Un esempio di expert rule utilizzata da NIDES è la seguente: 1. rule [SimuLogon(#1;*): 2. [+tr:transaction] 3. [+se:session|id == tr.id] 4. [?|se.terminal != tr.terminal] 5. ==> 6. [!|printf("SimuLogon: %s at terminals %s, %s\n", tr.id, tr.terminal, se.terminal)]

Questa regola, SimuLogon, è scritta nel linguaggio specifico per sistemi esperti PBEST. Essa rivela gli utenti loggati ad un terminale che risultano essere già loggati su qualche altro Pagina 275 di 334

terminale. Quando un utente effettua il , viene effettuata una transazione, e l'evento viene memorizzato. La regola verifica quindi se sono presenti altre sessioni con lo stesso ID: se si, vengono confrontati i terminali e, qualora risultassero essere differenti, verrà inviato un messaggio di avviso al terminale dell'amministatore. Un vantaggio che deriva dall'utilizzo di sistemi esperti è che il meccanismo per individuare le intrusioni è automatico (se la regola è soddisfatta allora viene compiuta un'azione). Per contro, la creazione di regole che identifichino sequenze di azioni, non è molto intuitiva: programmatori esperti possono incontrare notevoli difficoltà anche solo per apportare modifiche o aggiornamenti alle regole esistenti. Keystroke monitoring Il keystroke monitoring è una tecnica molto semplice che monitora le sequenze di tasti premuti sulla tastiera alla ricerca di pattern conosciuti. Sfortunatamente questo sistema ha svariati difetti. Alcune caratteristiche di shell come bash, ksh e tcsh, in cui l'utente può specificare diversi alias, possono infatti rendere vano il monitoraggio della tastiera se non viene effettuato nessun controllo espandendo l'alias o effettuando un'analisi semantica. Questo metodo inoltre non analizza l'esecuzione di un programma ma solo le sequenze di tasti digitati sulla tastiera: questo significa che un programma “malevolo” non sarà individuato e segnalato. I sistemi operativi non offrono un grande o per il keystroke capturing: un miglioramento potrebbe essere quello di monitorare direttamente le system calls generate dagli applicativi. State Transition Analyses Nella State Transition Analyses, il sistema monitorato è rappresentato da un diagramma statotransizioni. Quando i dati vengono analizzati, il sistema effettua delle transizioni da uno stato ad un altro. Una transizione ha luogo quando alcune condizioni booleane risultano verificate (ad esempio, un utente che apre un file). L'approccio utilizzato in USTAT è quello di effettuare delle transizioni da stati classificati come sicuri a stati classificati come non sicuri, se vengono riscontrati dei patterns di attacchi conosciuti. Uno stato è una fotografia del sistema in un determinato momento e rappresenta il contenuto della memoria volatile e di quella semi-permanente e permanente. Esso è rappresentato dai valori di un insieme di attributi del sistema. Lo stato iniziale corrisponde allo stato in cui il sistema si trova prima di subire un intrusione; lo stato finale è quello in cui l'intrusione è già avvenuta. Una o più transizioni possono verificarsi nel are dallo stato iniziale a quello finale. Dopo aver identificato lo stato iniziale il o successivo è quello di identificare le azioni chiave, chiamate signature actions che, se correttamente gestite, consentiranno di prevenire il proseguimento Pagina 276 di 334

dell'intrusione. Vantaggi: •

possono essere scoperti attacchi che utilizzano sessioni utente multiple

•

basandosi sullo stato corrente del sistema si possono utilizzare misure preventive per evitare specifici attacchi

Svantaggi: •

questo modello può rappresentare un'intrusione solo come una sequenza totalmente ordinata di azioni predefinite: non è possibile specificare altri modi di intrusione come ad esempio utilizzando azioni ordinate solo parzialmente

•

non è possibile identificare attacchi di denial of service, falliti, ascolto ivo

Alcuni rimedi alle debolezze dei sistemi state-transitions sono implementati nel modello Pattern Matching. Pattern Matching Il pattern matching è basato sull'osservazione di sequenze fissate di bytes in un singolo pacchetto. Come suggerisce il nome, questo è un approccio abbastanza rigido ma semplice da implementare. In molti casi la verifica sul pacchetto viene fatta solamente se esso è associato ad un determinato indirizzo sorgente o di destinazione, ad un determinato protocollo oppure se destinato o proveniente da una specifica porta. Questo aiuta a diminuire il numero di ispezioni eseguite su ogni pacchetto alleggerendo il carico dei sistemi IDS. Tuttavia, può risultare complicato per questo tipo di sistemi trattare con quei protocolli che non si avvalgono delle cosiddette well known ports e soprattutto con il traffico generato da Trojans. La struttura di una signature in un approccio pattern-matching è simile alla seguente (in uno pseudo-linguaggio): SE il pacchetto E' E E la porta di destinazione E' <2222> E il payload CONTIENE la stringa ALLORA genera un allarme.

Questo esempio di pattern-matching è molto semplice; si possono poi includere specifici punti in cui iniziare e finire di ispezionare il pacchetto specificando più nel dettaglio cosa si vuole monitorare, ad esempio i singoli flag del pacchetto T. Più specifici saranno questi parametri, minore ispezione sarà necessaria per ogni pacchetto che corre sul cavo.

Pagina 277 di 334

Sebbene sia abbastanza semplice definire delle regole per exploit specifici, il pattern-matching può spesso risultare troppo specifico, e non è raro che siano necessarie più signatures per gestire le possibili variazioni dell'exploit conosciuto. Vantaggi: •

questo è il metodo più semplice da implementare per rilevare le intrusioni

•

permette di stabilire una correlazione diretta tra il pattern e l'exploit: è altamente specifico

•

fornisce avvisi attendibili su specifici pattern

•

è applicabile con tutti i protocolli

Svantaggi: •

questo metodo è soggetto ad un elevato tasso di falsi positivi se il pattern non è unico, come chi ha scritto la regola credeva che fosse

•

modifiche all'attacco possono vanificare il controllo introducendo falsi negativi

•

possono essere necessarie più signature per uno specifico attacco

•

non funzione molto bene con la natura stream-based del traffico di rete, come ad esempio il traffico HTTP. In questo modo sono facilmente implementabili tecniche di evasion.

Stateful Pattern Matching Un metodo più sofisticato consiste nell'analisi stateful basata su pattern-matching. Siccome uno stream sulla rete comprende più di un singolo pacchetto, questo metodo di sviluppo delle signatures aggiunge al pattern matching classico la possibilità di effettuare confronti in un contesto nel quale anche lo stato totale dello stream assume importanza. I prodotti IDS stateful devono considerare l'ordine di arrivo dei pacchetti in uno stream T: ad esempio se in un exploit la stringa la verificare è foobar, e l'exploit è diviso in due differenti pacchetti con foo in uno e bar nell'altro, il pattern-matching classico non sarà in grado di rilevare la stringa completa. Tutto ciò comporta una richiesta di risorse maggiore in confronto al pattern-matching semplice: non è raro infatti che gli IDS moderni debbano allocare ingenti quantità di memoria e di potenza computazionale per tenere traccia di elevati numeri di sessioni aperte per lunghi periodi. Vantaggi: •

questo metodo richiede uno sforzo di implementazione solo di poco superiore a quello necessario per un pattern-matching semplice Pagina 278 di 334

•

permette di stabilire una correlazione diretta tra il pattern e l'exploit: è altamente specifico

•

fornisce avvisi attendibili su specifici pattern

•

è applicabile con tutti i protocolli

•

permette di contrastare le più comuni tecniche di evasion

Svantaggi: •

questo metodo è soggetto ad un elevato tasso di falsi positivi se il pattern non è unico, come chi ha scritto la regola credeva che fosse

•

modifiche all'attacco possono vanificare il controllo introducendo falsi negativi

•

possono essere necessarie più signature per uno specifico attacco

Protocol Decode-Based Analysis Gli IDS protocol-decode sono in un certo modo l'estensione intelligente all'approccio di stateful pattern matching. Con questa tecnica, il motore di ricerca delle intrusioni effettua un'analisi completa del protocollo, decodificando e processando il contenuto dei pacchetti allo stesso modo di come farebbe un'applicazione client o server. Quando degli elementi di un protocollo vengono identificati, l'IDS applica le regole definite nell'appropriata RFC, alla ricerca di violazioni del protocollo. Questo può aiutare a prevenire alcune anomalie. Ad esempio verrebbero segnalati dei dati binari in una richiesta HTTP, oppure un'anomala serie di dati troppo lunga di quanto non dovrebbe essere, potrebbe essere il sintomo di un buffer overflow. Un semplice esempio può essere quello della ricerca di stringhe di per Telnet che molti rootkits settano per default. Un sistema basato sul pattern matching effettuerebbe una scansione di tutto il traffico Telnet alla ricerca di tutti questi patterns: maggiore sarà il numero di queste stringhe da cercare, più lento risulterà il sistema. Per contro, una protocol analysis decodificherà il protocollo Telnet ed estrarrà il -name; effettuerà poi una ricerca più efficiente nel proprio albero di ricerca o nella propria hash table. Pattern matching e protocol analysis non sono comunque mutualmente esclusive. Vantaggi: •

questo metodo minimizza la possibilità di falsi positivi se il protocollo è ben definito e robusto (il numero di falsi positivi può invece aumentare se il protocollo è ambiguo)

•

permette di stabilire una correlazione diretta tra il pattern e l'exploit

Pagina 279 di 334

•

questo metodo permette generalizzazioni che consentono di identificare anche variazioni di attacchi conosciuti (non è necessario creare molte signatures per ogni piccola variazione)

•

fornisce avvisi attendibili sulle violazioni delle regole dei protocolli definiti

Svantaggi: •

questo metodo può generare un elevato numero di falsi positivi qualora le RFC siano ambigue e permettano agli sviluppatori di interpretare ed implementare il protocollo a propria discrezione. Questi tipi di “violazioni” di protocolli sono molto comuni.

•

Questo metodo richiede lunghi periodi di sviluppo al fine di implementare correttamente il protocol parser.

Model-based intrusion detection Questi tipi di intrusion detection partono dal presupposto che una determinata situazione possa essere dedotta da certe altre attività osservabili. Se queste ultime vengono monitorate, è possibile inferire la presenza di un tentativo di intrusione solamente osservandone il comportamento. Uno “scenario model” rappresenta dei comportamenti caratteristici di un'intrusione. Gli scenario models consentono agli amministratori di generare delle versioni astratte degli attacchi. Lo schema base di questo modello è costituito da tre importanti moduli: L'anticipator utilizza modelli e scenari attivi cercando di predire il prossimo o che ci si aspetta che accada in quella situazione. Il planner poi traduce queste ipotesi in diverso formato ed usa l'informazione per pianificare cosa cercare come prossimo o dell'intrusione. L'interpreter infine effettua una ricerca di questi dati nel proprio database. Il sistema procede in questo modo, accumulando prove su prove della sospetta intrusione fino a quando viene raggiunto un livello soglia e viene generato un allarme. Questo è un approccio molto “pulito”: siccome il planner e l'interpreter sanno ad ogni o cosa stanno cercando, la gran quantità di rumore presente dei dati viene quindi filtrata, consentendo miglioramenti eccellenti nelle performance. In aggiunta il sistema può predire la prossima mossa dell'attacker basandosi sul modello dell'attacco: queste previsioni possono essere usate per verificare un ipotesi di intrusione, per adottare misure preventive, o per determinare quali dati utilizzare nel prossimo o.

4.6.3.4

Il o successivo nell'evoluzione degli IDS: IPS e Honeynets

IPS: Intrusion Prevention Systems Con il termine “Intrusion Prevention System” intendiamo un dispositivo (hardware o software) che ha la capacità di scoprire attacchi, conosciuti e sconosciuti, prevenendo il tentativo di intrusione. Pagina 280 di 334

Con un network IPS il sensore viene posto in una posizione diversa da quella dei normali IDS. Generalmente questi ultimi sono posti on-line su una porta separata della rete, sulla quale viene copiato tutto il traffico. Un IPS viene invece posto “in-line”, posizione che solitamente viene riservata ai firewall o ai routers. Per questo motivo quindi ha il vantaggio di lavorare come un IDS classico monitorando tutto il traffico e, qualora individui un pacchetto sospetto, ha la possibilità di bloccarlo prevenendo l'attacco.

Alcuni dispositivi, in presenza di un attacco, si auto-riconfigurano utilizzando regole più restrittive, oppure cambiano dinamicamente le regole del firewall a cui sono collegati. Alcuni tipi di IPS, qualora individuino un pacchetto sospetto, lo riscrivono utilizzando dati innocui: questa procedura è nota col nome di packet scrubbing. Questo metodo è comodo qualora non si voglia far sapere all'attaccante che il suo tentativo non è andato a buon fine oppure si vuol nascondere che il sistema sta cercando di accumulare ulteriori prove in merito all'attacco. Questo meccanismo è molto utilizzato nelle honeynets, nelle quali solo il traffico in uscita viene bloccato o ripulito.

Esiste una differenza in termini di resa tra un IDS ed un IPS: il primo infatti, qualora non sia in grado di monitorare tutti i pacchetti in arrivo, in generale a ad una modalità di Pagina 281 di 334

campionamento controllando solo una parte dei pacchetti. Il livello di monitoraggio diminuisce ma, oltre a questo, non vi sono ulteriori problemi. Nel caso di un IPS invece, qualora il sensore non sia in grado di gestire tutto il traffico, i pacchetti verranno scartati con la conseguente necessità di una ritrasmissione degli stessi: siamo quindi di fronte ad un possibile collo di bottiglia per il traffico. Un ulteriore rischio è quello dei falsi positivi: se prima un falso positivo generava un allarme ma consentiva di continuare la comunicazione, con gli intrusion prevention system si rischia di interrompere connessioni che non rappresentavano alcun pericolo. Se oltre a ciò si considera che un IPS, per essere veramente efficace, deve implementare anche meccanismi che gestiscano la frammentazione IP e la ricostruzione degli stream T, allora si può capire come questa soluzione non sia comunque priva di debolezze soprattutto dal punto di vista prestazionale. Honeypots / Honeynets Una honeynet è uno strumento per imparare. E' una rete di sistemi designata per essere compromessa. L'idea è simile a quella degli honeypots, anche se con alcune differenze. “Definiremo un honeypot come “una risorsa il cui valore sta nell'essere attaccata e compromessa”. Significa che qualsiasi cosa decidiamo di usare come honeypot, la nostra aspettativa e il nostro risultato è di avere un sistema che venga scoperto, attaccato e potenzialmente bucato. Tenete a mente che l'honeypot non è una soluzione. Non fa dei 'fix' a niente. Invece, l'honeypot è uno strumento. Come usarlo dipende da voi e da cosa volete ottenere, Un honeypot può essere semplicemente un sistema che emula un altro sistema o un'applicazione, crea un ambiente jailed, o può essere un sistema standard. Indipendentemente da come costruite e usate l'honeypot, il suo valore sta nell'essere attaccato. Dividiamo gli honeypot in due categorie, come stabilito da Marty Roesch, creatore di Snort. Marty ha indicato che le due categorie di honeypot sono "produzione" e "ricerca", una distinzione che ho trovato molto utile. Lo scopo di un honeypot di produzione è di aiutare a ridurre i rischi in una azienda. L'honeypot aggiunge valore alla sicurezza dell'azienda. La seconda categoria, ricerca, è costituita da honeypot in grado di raccogliere informazioni sulla comunità blackhat. Questi honeypot non aggiungono direttamente valore ad una organizzazione. Piuttosto sono usati per trovare i pericoli, e capire come meglio proteggersi da essi.34” Una honeynet è qualcosa di differente. Vi sono due principali differenze con un honeypot tradizionale:

34

(Traduzione di: Honeypots - Definizione e valore degli Honeypots http://www.itvirtualcommunity.net/educational/honeypots.htm)

Pagina 282 di 334

•

essa non è un sistema singolo ma una rete di vari sistemi. Queste rete è posta dietro ad un firewall che controlla tutto il traffico in entrata ed in uscita. Queste informazioni catturate vengono poi analizzate.

•

La honeynet può utilizzare molteplici sistemi nello stesso tempo: Unix, Linux, Solaris, Windows NT, router Cisco etc. creando un ambiente di rete realistico, come un sistema di produzione vero e proprio. Avendo poi a disposizione sistemi con differenti servizi, come un DNS server Linux, un webserver di Windows NT, un server FTP Solaris etc. si può imparare molto sui tool e sulle tecniche adottate dagli intrusi.

•

Niente è simulato: sono utilizzati sistemi ed applicazioni reali, come quelle che si trovano solitamente in Internet

Risulta quindi evidente come una honeypot possa essere considerata anche un sistema di intrusion detection: ogni volta che arriva in ingresso una connessione diretta verso la honeynet sappiamo di essere di fronte ad una scansione, ad una prova o ad attacco. I normali sistemi di intrusion detection hanno il comune problema di dover determinare ogni volta quali attività sono da considerarsi normali e quali sospette. Problemi quali il sovraccarico di informazioni, i falsi positivi ed i falsi negativi rendono estremamente difficili le attività di analisi ed identificazione degli attacchi. Gli honeypots e le honeynets risolvono con semplicità questo problema: tutto il traffico in entrata o uscita è sospetto per definizione: questo concetto di traffico non legato all'ambiente produttivo semplifica molto le fasi di acquisizione ed analisi dei dati. Maggiori informazioni sulle honeynets si possono trovare sul sito ufficiale http://www.honeynet.org. Il referente italiano (facente parte anche del progetto IRItaly) della Research Alliance è invece raggiungibile all'url http://www.honeynet.it.

Pagina 283 di 334

4.6.4

Problemi e debolezze legati ai sistemi di Intrusion Detection

4.6.4.1

NIDS – Punti critici della rete

Negli attacchi provenienti dall'esterno generalmente, oltre ai dispositivi IDS, è presente anche un firewall che si frappone tra l'attaccante e la rete interna. L'amministratore solitamente dovrà decidere se applicare un sensore IDS a monte o a valle del firewall o in entrambe le posizioni. Se possibile, un sensore IDS network-based dovrebbe essere posto sia all'esterno che dietro al firewall. Il sensore all'esterno permette il monitoraggio di tutto il traffico diretto verso la rete: ciò si rivela utile nell'analisi del comportamento di un eventuale attaccante (postscans e vulnerability scans). Il sensore posto dietro al firewall si rivela altrettanto utile. Innanzitutto esso permette di monitorare il traffico in uscita (outbound) determinando se vi è già stata un'intrusione oppure se un utente interno sta cercando di preparare un attacco nei confronti di target esterni. Inoltre, questo sensore segnala se un attacco dall'esterno è riuscito a superare la protezione perimetrale: analizzando gli allarmi dell'IDS l'amministratore sarà in grado di configurare in maniera appropriata le nuove regole del firewall. Altri sensori possono venire posizionati in prossimità di punti strategici quali: dorsali LAN e WAN, webserver, database, log machines. Questo consente inoltre di ricevere un ulteriore avviso nel caso in cui un attaccante esterno sia riuscito a penetrare nella rete e, in aggiunta, permette di individuare tutti quegli attacchi provenienti da utenti interni (che altrimenti sarebbero di difficile individuazione). Un IDS network-based idealmente dovrebbe fornire una copertura al 100% contro le intrusioni di rete garantendo, allo stesso tempo, la completa disponibilità della stessa. Quelle che seguono sono problematiche legate a molti sistemi di network ID. Gli ambienti maggiormente suscettibili al rischio di mancate segnalazioni di intrusione sono: •

reti con un elevato traffico. In questi ambienti l'elevato traffico di rete sovraccarica il sensore IDS consentendo a traffico potenzialmente dannoso di non venire rilevato

•

reti switched. In questo ambiente il NIDS necessita di poter monitorare il traffico su tutti i segmenti switchati. In una “switched network” non esiste una collocazione ideale per connettere il NIDS e, il posizionamento di un IDS su ogni segmento, risulta essere un costo proibitivo per la maggior parte delle realtà aziendali

•

reti asimmetriche. Nelle reti asimmetriche con la presenza di routers il traffico può attraversare percorsi diversi prima di raggiungere il dispositivo di intrusion detection; quest'ultimo talvolta vedrà solo una parte del flusso di dati, rischiando di non individuare un attacco.

Performance Il rendimento è uno dei punti più controversi riguardo ai NIDS in quanto è difficile da quantificare in modo univoco. Pagina 284 di 334

Alcuni elementi da considerare sono: •

hardware e software utilizzati per far funzionare il sensore

•

utilizzo di tecniche di pattern matching o di protocol-analysis

•

quanto traffico criptato a sulla rete

•

dimensione dei pacchetti

•

policy adottate sul sensore

Esistono due versioni principali di NIDS sul mercato: una utilizza sensori per reti a 10/100MB, e l'altra usa sensori per reti con Gigabit di traffico. Una notevole difficoltà è quella di avere statistiche attendibili sui rendimenti, soprattutto per quei test effettuati in laboratorio. Il fattore più importante non è infatti quanti attacchi il sensore può scoprire (che di solito è la prova principale effettuata nei laboratori), bensì quanto efficacemente il sensore può gestire degli attacchi in una rete normale. Questo può risultare molto difficile in situazioni in cui il traffico è criptato, come ad es. accade col traffico SSL o SSH: in questi casi il monitoraggio implica solo uno spreco di U visto che comunque non può venire effettuata alcuna analisi sui pacchetti ricevuti. Un secondo elemento da considerare nelle prestazioni degli IDS è la dimensione dei pacchetti. Durante la fase di test molti produttori di NIDS utilizzano pacchetti di dimensioni predefinite, limitandosi quindi ad una casistica molto ristretta. Il motivo principale di questo atteggiamento risiede nella volontà di ridurre i costi ed abbreviare i tempi di rilascio del prodotto. Un ulteriore elemento è la velocità con cui il sensore applica la policy che gli è stata imposta. Tipicamente un NIDS ha centinaia di signatures da controllare: più signatures dovrà verificare in un determinato stream, più lungo sarà il tempo necessario. Questo è un fattore molto più critico per i sistemi che si basano sul pattern-matching piuttosto che quelli basati su protocol-analysis. Solitamente le variabili per determinare le effettive prestazioni di un NIDS sono troppe, anche se tipicamente su un sensore a 10/100MB ci si può aspettare un monitoraggio di 60-80MB/s, e su un sensore Gigabit approssimativamente 400-600MB/s. Indicativamente si ha un carico di utilizzo del 60-80% su un segmento a 100MB e del 40-60% su un segmento Gigabit. Reti switched Innanzitutto vediamo perché gli switch sono diversi dagli hub. Un hub comprende solo le informazioni di livello 2 della pila ISO-OSI, e copia ogni singolo pacchetto su tutte le sue porte. In questo caso mettere un sensore IDS su un segmento qualsiasi consente di monitorare tutto il traffico, anche quello degli altri segmenti.

Pagina 285 di 334

Uno switch invece lavora a un livello superiore, conoscendo quindi gli indirizzi dei dispositivi collegati ad esso. Quando ad es. un dispositivo vorrà comunicare con un altro, lo switch invierà il pacchetto solo verso la sua specifica porta direttamente collegata col segmento di destinazione. Il problema risulta essere quello di come monitorare con un IDS tutto il traffico ante per lo switch. Una soluzione è implementata da alcuni produttori di switch e routers, e consiste nell'utilizzo di Mirror Ports. Il principio è quello di settare una porta che si occuperà esclusivamente di copiare tutto il traffico proveniente dalle altre porte. Un problema derivante da questo approccio è dato dalla notevole quantità di traffico presente sulla porta mirror: potrà infatti risultare che la somma del traffico di tutte le porte non possa essere gestita. Una soluzione di questo problema è quella di usare una porta mirror che utilizzi una capacità di banda molto superiore a quella delle altre, ad esempio una Gigabit port anziché una porta a 100MB come le altre presenti sullo switch. In questo caso entra ancora in gioco la capacità del sensore di fornire prestazioni che garantiscano il monitoraggio di tutto il traffico. Reti asimmetriche Le Asymmetrical Routed Networks vengono implementate per aumentare la ridondanza dei frontend routers di una rete, consentendo loro di lavorare con più efficienza bilanciando il carico di lavoro.

Pagina 286 di 334

Nella figura possiamo notare come, con questo tipo di configurazione, i dati possano fluire dalla rete verso internet su quattro strade diverse. Un NIDS sarà efficace solamente se potrà monitorare tutto lo stream di dati. Ad esempio, con un semplice exploit CGI, digitando http://www.target.com/cgi-bin/test-cgi?* un attaccante potrebbe ottenere la lista di tutti i file e cartelle presenti nella directory degli scripts di un web server.

Se questa richiesta verrà suddivisa in 5 diversi pacchetti che eranno attraverso una routed network, i sensori NIDS non riusciranno ad identificare la presenza di un attacco.

Pagina 287 di 334

In questi tipi di reti i dati devono quindi essere riassemblati prima di are attraverso l'IDS. Per fare ciò è possibile collegare le mirror ports dei vari router ad un ulteriore dispositivo, che si occuperà di redirigere tutto il traffico verso un sensore NIDS (appare evidente come il problema delle prestazioni dell'IDS assuma un peso sempre più rilevante).

Pagina 288 di 334

4.6.4.2

NIDS - Tecniche di elusione

Esistono due problemi generali con i network intrusion detection system: primo, nei pacchetti vi è un'insufficienza di informazioni tale da non consentire una completa ricostruzione di ciò che è avvenuto durante complesse transazioni; secondo, gli IDS sono a loro volta vulnerabili ad attacchi di Denial of Service. Il primo di questi problemi riduce l'accuratezza del sistema, e il secondo compromette la sua disponibilità. Attacchi Verranno ora discusse tre tipologie di attacchi nei confronti dei sistemi di intrusion detection sniffer-based. Due di esse cercano di rendere inefficace la protocol-analysis, ostacolando il riconoscimento di signatures da parte degli IDS. La terza si basa sul fatto di esaurire tutte le risorse provocando dei malfunzionamenti del sistema. Tutti questi attacchi implicano la manipolazione, talvolta a basso livello, del traffico di rete. Diversamente dai normali “spoofing attacks”, queste tecniche sono avvantaggiate dal fatto che l'attaccante può gestire una sessione propria e non deve cercare di modificare quella di altri utenti. Insertion Un IDS può accettare un pacchetto che un end-system (un server etc.) invece rifiuterà. Un IDS che fa questo commetterà uno sbaglio nel credere che il sistema finale ha accettato e processato il pacchetto quando invece ciò non è avvenuto. Un attaccante può sfruttare questa condizione inviando appositi pacchetti che il sistema finale rifiuterà, ma che l'IDS riterrà validi. Facendo questo, l'attaccante “inserirà” dati nell'IDS (gli altri sistemi sulla rete invece non si cureranno di questi pacchetti non validi). La tecnica sopracitata è definita “insertion attack”, ed è una delle vulnerabilità maggiori dei sistemi di intrusion detection. Un attaccante può utilizzare questa tecnica per eludere la signature analysis, permettendo che alcuni attacchi superino il controllo dell'IDS. Per comprendere come gli attacchi di inserzione confondano la signature analysis, è importante capire come la tecnica sia usata nei reali sistemi di ID. Una analisi delle firme usa maggiormente algoritmi di pattern-matching per scoprire le presenza di determinate stringhe in un flusso di dati. Ad esempio, un IDS che tenta di scoprire un attacco PHF cercherà la stringa “phf” in una richiesta HTTP di tipo GET, come nella stringa GET /cgi-bin/phf? L'IDS troverà facilmente la stringa “phf” effettuando una semplice ricerca della sottostringa. Tuttavia, il problema diventa più difficile da risolvere quando un attaccante invia la stessa richiesta ad un webserver, ma costringendo l'IDS a vedere una stringa differente, come ad esempio Pagina 289 di 334

GET /cgi-bin/pleasedontdetectthisforme? L'attaccante ha qui utilizzato un insertion attack per aggiungere le stringhe “leasedontdetectt” , “is” , e “orme” allo stream originale. Notate come le lettere che mancano siano proprio quelle che andranno a formare la parola “phf”: l'IDS vedrà tutti i pacchetti e non segnalerà nulla di anomalo, il webserver invece scarterà i pacchetti resi non validi dall'attaccante e si ritroverà a dover processare la stringa voluta dall'attaccante. Un esempio simile dello stesso attacco è riportato nella figura seguente. In questo caso un attaccante invia all'IDS uno stream di pacchetti da 1 carattere: inserirà poi un pacchetto che sarà accettato solo dal sistema di intrusion detection (quello contenente la lettera “X”). Come risultato, l'IDS ed il sistema vittima dell'attacco ricostruiranno due stringhe differenti.

In generale, gli insertion attacks avvengono quando l'IDS è poco rigoroso nel processare i pacchetti rispetto al sistema finale. Un'ovvia reazione a questo problema potrebbe essere quella di rendere l'IDS il più rigoroso possibile. Per contro, utilizzando questa soluzione, si rischia di incorrere in un ulteriore problema definito “evasion attack”. Evasion Un end-system può accettare un pacchetto che un IDS invece rifiuta. Un IDS che erroneamente rifiuta un pacchetto legittimo fallisce nel suo compito. Questa condizione può essere sfruttata facendo sì che informazioni cruciali non vengano identificate dall'IDS a causa della sua configurazione troppo restrittiva, e che invece arrivino intatte al sistema finale. Questi pacchetti quindi “evadono” il controllo che il sistema IDS dovrebbe effettuare. Intere sessioni possono essere abilmente inserite in pacchetti che evaderanno il controllo del sistema di intrusion detection: IDS e sistema finale vedranno due stream differenti Pagina 290 di 334

ma, in questo caso, sarà il sistema finale a ricevere più informazioni. Questi dati persi dall'IDS saranno proprio quelli che si riveleranno cruciali per l'attacco. In un attacco di inserzione, l'attaccante invia una richiesta HTTP, ma maschera il reale contenuto con dati aggiuntivi che fanno sembrare la richiesta innocua. In un attacco di evasione, l'attaccante invia parti della stessa richiesta in pacchetti che l'IDS erroneamente scarterà, consentendo di rimuovere parti dello stream dal controllo del sistema. Ad esempio, la richiesta originale potrebbe diventare “GET /gin/f” che, per la maggior parte degli IDS non ha significato.

Nella realtà, gli attacchi di insertion e di evasion non sono cosi semplici da sfruttare. E' possibile, tuttavia, sfruttare questi attacchi ad un livello più basso che consente di eludere il controllo del pattern-matching. Un esempio è costituito dal riassemblaggio dello stream T. Molti protocolli di rete sono semplici e facili da analizzare. Essi consistono nel fatto di inviare una singola richiesta ed attendere poi la risposta. Altri protocolli sono più complessi, e richiedono di fare considerazioni su più pacchetti prima di fare ipotesi sulla transazione che essi rappresentano: per fare questo è indispensabile effettuare un monitoraggio stateful dell'intero stream dei pacchetti. Protocolli come T permettono di inviare dati suddividendoli in gruppi di pacchetti che arriveranno alla destinazione non con lo stesso ordine del loro invio Per una corretta ricostruzione di questo ordine quindi ogni pacchetto viene numerato con un numero che indica la sua posizione nello stream originale (il cosiddetto sequence number)

Pagina 291 di 334

Il processo adibito al corretto riordino dei pacchetti una volta giunti a destinazione viene definito “riassemblaggio”. Il riassemblaggio opera anche a livello IP; IP infatti definisce un meccanismo chiamato “frammentazione”, che permette ai sistemi di spezzettare singoli pacchetti in altri più piccoli. Ogni singolo frammento sarà fornito di un valore che specificherà la posizione di quel determinato frammento rispetto all'inizio del pacchetto originale: questo campo è definito “offset”. Le implementazioni del protocollo IP consentono di ricevere i pacchetti frammentati e riassemblarli nel giusto ordine utilizzando il loro valore di offset. Gli attacchi di inserzione confondono questo meccanismo aggiungendo pacchetti allo stream che verrà valutato in modo differente dal sistema finale. I pacchetti inseriti andranno a cambiare la sequenza dello stream, riuscendo anche a sovrascrivere i vecchi dati. Denial Of Service Gli attacchi di tipo Denial Of Service (DOS) contro sistemi d intrusion detection possono essere molto gravi in quanto, anche se il monitoraggio fornito dall'IDS viene disattivato, un attaccante avrà comunque la possibilità di continuare a comunicare con i sistemi finali vittime dell'attacco. Molti attacchi di questo tipo sfruttano specifici bug del software. Un IDS che va in crash quando riceve un certo pacchetto, o una serie di messaggi di controllo corrotti, può essere reso inefficace istantaneamente. Fortunatamente, questo tipo di bug sono spesso risolti tempestivamente dai produttori; per contro, scoprire tutti i possibili bug di un software è un' operazione pressoché impossibile. E' inoltre interessante notare come alcuni sistemi IDS, che includono capacità di reagire in maniera attiva ad un attacco (ad esempio filtrando alcuni pacchetti), possano a loro volta essere sfruttati per generare degli attacchi DOS verso altri sistemi (a causa di falsi positivi, ad esempio, possono venir chiusi alcuni servizi). Esempi di attacchi con tecniche di insertion ed evasion Pagina 292 di 334

Il modo più semplice che un datagram IP ha per essere scartato è quello di avere un campo header non valido. Gli header fields di un pacchetto IP sono descritti nella RFC731. Un problema che si può verificare quando si cerca di utilizzare un pacchetto con campi dello header non validi è quello per il quale il pacchetto viene scartato direttamente dai routers presenti sulla rete. Questo rende difficoltoso l'utilizzo di questi pacchetti per un attacco anche se un metodo per aggirare l'ostacolo è quello di sferrare l'attacco dallo stesso segmento di rete. Un campo dello header IP che è spesso trascurato dagli IDS è il checksum. Potrebbe risultare non necessario per un IDS effettuare una verifica del checksum di ogni pacchetto IP catturato; tuttavia questo verrebbe comunque scartato dalla maggior parte delle implementazioni IP. Un IDS che non rifiuti pacchetti con un checksum errato risulta essere vulnerabile a semplici attacchi di inserzione. Un problema difficile da risolvere è quello relativo al campo TTL. Il campo TTL (Time To Live) di un pacchetto IP segnala quanti hops (salti) un pacchetto può attraversare sul suo percorso prima di arrivare a destinazione. Ogni volta che un router inoltra un pacchetto decrementa di 1 il valore del TTL. Quando questo valore raggiunge lo zero il pacchetto viene scartato: questo meccanismo serve per prevenire l'instradamento in loops infiniti. Se un IDS non risiede sul medesimo segmento di rete del sistema che deve monitorare, vi è la possibilità che alcuni pacchetti riescano a raggiungere l'IDS, ma non abbiano un valore di TTL abbastanza grande da raggiungere anche il sistema di destinazione. Un problema simile avviene col flag “Don't Fragment” nei pacchetti IP. Questo flag segnala ai dispositivi di non spezzare in diversi frammenti il pacchetto, nel caso quest'ultimo dovesse essere troppo grande per essere inoltrato, ma dice semplicemente di buttarlo. Se la dimensione massima del pacchetto, consentita dalle specifiche della rete su cui risiede l'IDS, dovesse essere più grande di quella su cui risiede il sistema di destinazione, un attaccante potrebbe inviare dei pacchetti (con il flag DF settato) con una dimensione tale da superare la rete dell'IDS ma venire poi scartati da quella di destinazione. Entrambi questi problemi possono dare luogo ad ambiguità risolvibili solamente se l'IDS ha la possibilità di avere una conoscenza approfondita della topologia della rete che sta monitorando. Sebbene il problema del checksum IP sia abbastanza semplice da risolvere, implementando sull'IDS la possibilità di effettuarne una verifica, altre tipologie di analisi potrebbero rivelarsi più complicate. Questo accade soprattutto perché diversi sistemi interpretano ed agiscono in maniera differente rispetto agli stessi dati. Alcuni sistemi operativi, ad esempio, possono essere configurati per scartare automaticamente pacchetti nei quali il percorso da seguire sia stato preventivamente settato (source routing): sarebbe quindi ragionevole che anche l'IDS riconoscesse questo tipo di pacchetti evitando attacchi di inserzione. Spesso, quando un sistema scarta per qualche motivo dei pacchetti, invia al mittente un messaggio per segnalare l'accaduto (ad esempio messaggi di errore ICMP). Questa comunicazione potrebbe essere utilizzata dagli IDS per determinare quali opzioni del pacchetto erano corrette e quali no. Questa soluzione non è però sempre applicabile: alcuni sistemi operativi sopprimono molti messaggi di errore, rendendo meno efficace questo approccio. Inoltre, tenere traccia di tutte le risposte ICMP in base alle opzioni dei pacchetti di origine, costringerebbe i sistemi di IDS a mantenere lo stato di ogni datagram IP consumando notevoli risorse e consentendo all'attaccante di sferrare attacchi di tipo Denial Of Service. Pagina 293 di 334

Frammentazione IP I pacchetti IP possono essere spezzati in pacchetti più piccoli e ri-assemblati alla destinazione. Questo processo è definito “frammentazione”, ed è parte integrante del protocollo IP. La frammentazione IP permette ad un datagram di viaggiare su diversi tipi di media (che potrebbero avere differenti limiti nella dimensione dei pacchetti) senza limitare l'intero protocollo ad una dimensione minima arbitraria. Una spiegazione dettagliata si può trovare nella RFC791. Siccome gli end-system sono in grado di riassemblare i pacchetti IP, è importante che i dispositivi di monitoraggio della rete abbiano la capacità di eseguire la stessa operazione in modo corretto. Un IDS che sappia fare ciò può essere attaccato semplicemente assicurandosi che tutti i dati scambiati tra due macchine vengano frammentati in modo adeguato. I flussi di frammenti IP solitamente arrivano in ordine. L'ultimo frammento dello stream viene marcato con un apposito flag nello header IP. Tuttavia il protocollo consente che i frammenti arrivino a destinazione in un ordine arbitrario. Un IDS che non gestisca in modo appropriato i frammenti che arrivano in maniera non ordinata sarà vulnerabile: un attaccante potrebbe intenzionalmente mischiare i frammenti dello stream per eludere il controllo dell'IDS (tool come Fragroute servono a questo scopo). E' inoltre importante non cercare di ricostruire i pacchetti fino a quando tutti i frammenti siano arrivati (si rischia di perdere informazioni ottenibili solamente avendo una visione d'insieme), oppure ricostruire il pacchetto non appena arrivi il frammento marcato come ultimo (perché comunque il sistema finale aspetterà tutti i frammenti prima di ricostruire il pacchetto). Un ulteriore problema è quello derivante dal fatto di salvare momentaneamente tutti i frammenti in attesa di ricostruire l'intero flusso: il rischio è quello di venire “inondati” da una serie di frammenti che intenzionalmente non verrà mai completata e che porterà quindi all'esaurimento della memoria dell'IDS. Molti sistemi, per contrastare ciò, scartano progressivamente i frammenti troppo vecchi; questa operazione deve però essere fatta in modo consistente con il sistema monitorato: si rischierebbe infatti di accettare frammenti che il sistema ha già scartato (insertion) oppure scartare frammenti che il sistema finale non ha ancora rifiutato (evasion). Problemi legati al layer T Un gran numero di attacchi scoperti dai sistemi di ID avvengono in connessioni T. Questo impone che l'IDS sia in grado di ricostruire il flusso di dati che a attraverso uno stream T. Se ciò non viene fatto in modo consistente con il sistema finale che si vuole monitorare, allora si è vulnerabili all'attacco. Il giusto modo per elaborare uno stream di pacchetti T è uno dei maggiori problemi dei sistemi di intrusion detection network-based. Introduciamo alcuni concetti legati alle sessioni T. Ogni connessione T ha quattro identificatori (due per il client e due per il server) che la distinguono da ogni altra connessione sulla rete. Questi identificatori sono l'indirizzo IP del client e del server, e le relative porte T. Ci riferiremo a queste informazioni con il termine di “parametri della connessione”. Pagina 294 di 334

Le specifiche del protocollo T (RFC793) definiscono alcuni “stati” in cui una connessione si può trovare: noi ci riferiremo solamente a quelli osservabili da un IDS (quelli cioè che riguardano lo scambio di dati tra due host). Quando non esiste una connessione con determinati parametri ci si trova nello stato “CLOSED”; quando invece viene instaurata una connessione attiva siamo nello stato di “ESTABLISHED”. Il T implementa un protocollo affidabile che fa uso dei numeri di sequenza per determinare la posizione dei singoli pacchetti all'interno del flusso di dati generale. L'affidabilità consente ad ogni capo della connessione di determinare quali dati siano stati effettivamente ricevuti ed eventualmente ritrasmettere quelli andati persi. Per ricostruire il flusso di informazioni un IDS deve essere in grado di determinare quali siano i numeri di sequenza validi in un determinato momento della connessione: questo processo viene definito “sincronizzazione”. Quando un IDS non è sincronizzato non è in grado di ricostruire nessun dato sullo stato della connessione. L' insieme di informazioni sugli stati possono essere rappresentate da vari sistemi in molti modi. Chiameremo “T control block”, o “TCB”, questo blocco di informazioni che un sistema gestisce per seguire ogni singola connessione. Un network IDS deve mantenere un TCB per ogni connessione che monitora. I TCB sono utili per quelle connessioni che non sono in uno stato di CLOSED. Siccome è pressoché impossibile per un IDS mantenere un TCB per ogni possibile connessione, devono essere definiti dei meccanismi per i quali i TCB possano essere creati solo per le connessioni nuove, e distrutti per le connessioni non più valide. I punti in cui questo processo può essere sovvertito sono: •

durante la fase di creazione del TCB per una nuova connessione

•

durante la ricostruzione dello stream T

•

nel momento in cui viene deciso di eliminare un TCB

Il primo punto in cui il monitoraggio di una sessione T può essere eluso è durante la creazione del TCB. Le politiche di creazione del TCB determinano il punto in cui inizierà la registrazione dei dati di una specifica connessione, così come lo stato iniziale (sequence numbers, etc.) verrà utilizzato per sincronizzare la fase di monitoraggio con la sessione attuale. Esistono diversi modi che possono essere utilizzati per determinare quando aprire una TCB, e nessuno di essi è privo di problemi. Alcune tecniche sono però inferiori ad altre in maniera evidente. La creazione del TCB ruota attorno al three-way-handshake del T (o “3WH”), che è uno scambio di particolari pacchetti tra il client (colui che apre in modo “attivo” la connessione) ed il server (colui che apre in modo “ivo” la connessione). Il 3WH stabilisce i sequence numbers iniziali per quella specifica connessione, in aggiunta ad ulteriori parametri (per esempio i timestamps) che possono essere ritenuti importanti. Diversi IDS possono quindi decidere in quale momento creare il TCB: se dopo che il three-way-handshake è stato completato oppure se prima. Con la prima soluzione l'IDS non registra nessun dato sulla connessione fino a quando vede ed accetta tutti e 3 i pacchetti del three-way handshake. Due di questi pacchetti sono inviati dal client (e, nel caso di attacco ad un server essi sono da considerarsi controllati completamente Pagina 295 di 334

dall'attaccante), ed uno viene inviato dal server. In questo contesto possiamo dire che l'IDS non comincia a registrare fino a quando la connessione entra nello stato di ESTABLISHED. La necessità di un handshake completo rende pericolosamente semplice il fatto di perdere alcune connessioni, per colpa di tecniche di evasione oppure di problemi di performance che portano alla perdita di alcuni pacchetti fondamentali. Altri IDS possono richiedere solo un 3WH parziale prima di creare il TCB. Questo potenzialmente riduce la capacità di un attacker di ingannare il sistema con falsi TCB ed inoltre riduce la probabilità che una connessione non venga riconosciuta a causa della perdita di alcuni pacchetti durante elevati carichi di traffico. La questione è “di quale porzione del three-way handshake si ha bisogno prima di creare il TCB?”. Un IDS può creare il TCB non appena incontri il flag SYN settato dal client, oppure quando il server ritorna una risposta positiva col SYN+ACK. In questo secondo caso avere la conferma del server è un'indicazione attendibile del fatto che una connessione sia in corso, così come saranno più attendibili i sequence numbers presenti nella risposta del server. In entrambi i casi però bisogna ricordare che, fino a quando il three-way handshake non è completato, la connessione effettivamente non esiste: se un IDS utilizza handshake parziali per aprire un TCB, potrebbe quindi venire ingannato con connessioni inesistenti. Altri IDS poi iniziano a registrare non curandosi del three-way handshake ma solamente delle sequenze di ACK presenti nei pacchetti: questo consente di monitorare anche quelle connessioni iniziate prima che l'IDS fosse attivo ma introduce il rischio di monitorare sessioni fasulle. Una potenziale contromisura consiste nel permettere agli IDS di sincronizzarsi sui dati ma di porre comunque attenzione ai pacchetti di 3WH che vengono rilevati dopo aver iniziato la registrazione. Questi sistemi inizializzeranno lo stato di connessione dal primo pacchetto osservato, ma lo re-inizializzeranno qualora incontrino un 3WH reale (che verrà riconosciuto come attendibile al posto di quello precedente, considerato fasullo). Riassemblaggio dello stream T Uno dei compiti più difficili per un network IDS è quello di garantire un'accurata ricostruzione dei dati scambiati durante una connessione T. Il T fornisce abbastanza informazioni ad un sistema per verificare la validità di ciascuna parte dei dati, ma per fare questo sul sistema deve essere presente una completa implementazione del protocollo T/IP. I punti agli estremi di una connessione hanno un grande vantaggio rispetto ad un sistema di monitoraggio intermedio: se infatti dei dati vengono persi, l'altra parte della connessione li ritrasmetterà automaticamente dopo un certo periodo di tempo. Entrambi i partecipanti alla comunicazione hanno un ruolo attivo sul comportamento dell'altro, in modo da assicurare che i dati siano scambiati correttamente. Un sistema di monitoraggio non possiede queste caratteristiche: se perde un pacchetto, egli non può (praticamente) chiederne la ritrasmissione; inoltre non capirà facilmente se la mancanza di qualche parte dei dati sia dovuta all'arrivo non ordinato dei pacchetti oppure se uno di essi sia andato perso. Essendo un partecipante ivo della comunicazione, è molto facile perdere alcuni dati. Questo problema diventa ancor più importante nel momento in cui il riassemblaggio di uno stream T richiede un'accurato meccanismo di ricostruzione dei numeri di sequenza. Pagina 296 di 334

Senza qualche meccanismo di recovery, la connessione rischia di essere completamente desincronizzata. Le tecniche utilizzate da un IDS per recuperare un pacchetto perso (e ri-sincronizzare la connessione) possono essere a loro volta attaccate. Gli IDS hanno a disposizione dai pacchetti catturati un utile indicazione sullo stato dell'endsystem: il numero di sequenza dell'acknowledgment. Il numero di acknowledgement rappresenta il prossimo numero di sequenza di un pacchetto che un sistema finale di aspetta di ricevere. Presumibilmente ogni pacchetto valido sarà confermato da un messaggio di ACK. Si potrebbe quindi pensare che un IDS possa monitorare in maniera affidabile una connessione semplicemente aspettando un acknowledgement prima di agire su alcuni dati. Questo non è facile come possa sembrare: il numero di acknowledgement infatti è cumulativo, ogni segmento (in questo caso inteso come pacchetto T) non necessita di un acknowledgement dedicato ma, al contrario, un singolo ACK può essere inviato come conferma ad un intero gruppo di segmenti ricevuti. Un ulteriore problema nel riassemblaggio dello stream T da parte di un IDS consiste nel fatto che un attaccate può inviare diversi pacchetti con diversi dati ma col medesimo numero di sequenza. Le informazioni presenti nell'intestazione del pacchetto (eccetto il checksum) saranno le stesse, ma i dati saranno diversi: solamente il sistema finale saprà quale pacchetto sarà effettivamente processato. E' evidente che l'IDS si trova nella situazione di non sapere quale pacchetto sia stato considerato valido dal sistema: ciò può essere sfruttato da un insertion attack inviando pacchetto accettati dall'IDS ma respinti dall'end-system (che non genera quindi un ACK), ed inviando subito dopo dei pacchetti validi che verranno accettati. In questo caso, se l'IDS ha accettato i pacchetti precedenti (scartati dal sistema finale), avrà di conseguenza incrementato i numeri di sequenza che si aspetta di ricevere e non riuscirà più a tenere traccia dei pacchetti validi successivamente inviati dall'attacker. Il modo per risolvere questa categoria di problemi è quello di avere un IDS abbastanza intelligente da sapere come si comporterà ciascun end-system in ogni singola situazione, garantendo allo stesso tempo delle performance in grado di sopportare elevati carichi di traffico sulla rete. Come contrastare le tecniche di insertion e di evasion è una questione ancora ampiamente dibattuta tra gli studiosi e tra i produttori di IDS: generalmente, come per tutte quelle situazioni in cui bisogna bilanciare affidabilità e prestazioni, la soluzione è quella di un trade-off tra le due (troppo spesso invece l'operazione di testing delle implementazioni del protocollo T sui vari prodotti IDS è un problema troppo costoso e che richiede tempo: è facile per alcuni produttori saltare questa fase quasi totalmente). Evasion con UNICODE Dal sito dell' Unicode Consortium (http://www.unicode.org/): “Unicode provides a unique number for every character, no matter what the platform, no matter what the program, no matter what the language.” Fondamentalmente i computer gestiscono numeri. Essi identificano e trattano le lettere e gli altri caratteri assegnando ad ognuno di essi un numero univoco. Prima che Unicode fosse inventato, vi Pagina 297 di 334

erano centinaia di codifiche differenti per assegnare questi numeri: non esisteva alcuna codifica che contenesse un numero di caratteri sufficienti. Ad esempio, la sola Unione Europea, necessitava di diverse tipologie di codifiche per coprire le esigenze di tutte le lingue presenti, per tutti i simboli tecnici, di punteggiatura etc. Spesso poi queste entravano in conflitto tra di loro: capitava infatti che uno stesso numero identificasse due caratteri diversi. Ogni computer (in special modo i server), necessitava di are diversi encoding, altrimenti vi era il rischio che i dati che assero attraverso molti sistemi con codifiche differenti, arrivassero errati a destinazione. Unicode fornisce un identificatore univoco per ogni carattere di ciascuna lingua, facilitando ed uniformando la rappresentazione dei vari linguaggi del mondo. Viene utilizzato in molti standard moderni come Java, LDAP, XML, CORBA 3.0, WML; è ato inoltre da leader dell'industria quali Apple, HP, IBM, JustSystem, Microsoft, Oracle, SAP, Sun, Sybase, Unisys e molti altri. I caratteri Unicode sono chiamati code points e possono venire rappresentati in questo modo: U+xxxx, dove le 'x' sono cifre esadecimali. UTF-8 UTF-8 è un formato Unicode per la trasformazione dei code-point in una sequenza da uno fino a quattro bytes. UTF-8 permette la compatibilità di Unicode col formato ASCII, una codifica molto utilizzata su Internet. I problemi principali consistono nel fatto che questi caratteri ASCII possono essere rappresentati in maniera non univoca, oppure che determinati code-point possono essere utilizzati per modificare i code-point precedenti. L'Unicode Consortium ha riconosciuto che questa rappresentazione multipla è fonte di problemi di sicurezza ed ha riveduto lo standard, rendendo la rappresentazione multipla di uno stesso codepoint con UTF-8 illegale. L'UTF-8 Corrigendum (http://www.unicode.org/unicode/uni2errata/UTF-8_Corrigendum.html) elenca il nuovo range ammissibile di caratteri UTF-8. Questo cambiamento è stato effettuato solo recentemente, ed ancora molti sistemi e programmi non si sono adeguati. Il problema con l'UTF-8 originale è che esso ri-mappa l'insieme completo dei code-point precedenti ogni volta che la descrizione viene estesa di un byte: quando inizia la rappresentazione su 2 byte, vengono completamente ripetuti anche i code-points presenti in quella su 1 byte. Lo stesso accade utilizzando 3 byte. Con 4 byte si avrà poi la rappresentazione Unicode completa. Ad esempio, il carattere di backslash ' \ ', risulta U+005C. In UTF-8 originale può essere rappresentato con i caratteri esadecimali 5C, C19C e E0819C. Molte vecchie applicazioni accettano ancora tutti e tre questi valori. Un ulteriore problema con Unicode è che alcune applicazioni interpretano allo stesso modo codepoint differenti: viene così meno il principio di univocità dei simboli. Ad esempio, la lettera maiuscola 'A' in alcuni applicativi può essere associata a molteplici code-point: U+0041, U+0100, U+0102, U+0104, U+01CD, U+01DE, U+8721. Molti di questi avranno poi a loro volta Pagina 298 di 334

diverse rappresentazioni. A titolo esemplificativo dell'ambiguità insita in Unicode, segnaliamo che la stringa “AEIOU” può essere espressa in 83.060.640 modi differenti (!). Esempio di attacco: Microsoft IIS e PWS Extended Unicode Directory Traversal Vulnerability Microsoft IIS 4.0 e 5.0 sono entrambi vulnerabili all'exploit dell'attraversamento delle cartelle del server, se viene inserito nel percorso dell'URL di richiesta la sottostringa “../” o “..\” , e se risulta attiva la rappresentazione estesa dei caratteri Unicode. Un attaccante può ad esempio richiedere un URL del tipo: http://target/scripts/../../winnt/system32/cmd.exe?/c+dir+c:

IIS eliminerà la sottostringa “../..” e genererà un errore. Tuttavia, se l'attaccante codificherà in UTF-8 la stringa “../..” facendola diventare “..%C1%9C..” e la inserirà nell'URL, potrà in molti casi aggirare la protezione del server, lanciando altri programmi o avendo accesso ad alcuni files. Con Unicode, inoltre, possono essere utilizzate diverse stringhe di richiesta alternative, al fine di eludere i controlli effettuati dai server e dai sistemi IDS: http://target/scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir http://target/scripts/..%c0%9v../winnt/system32/cmd.exe?/c+dir http://target/scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir http://target/scripts/..%c0%qf../winnt/system32/cmd.exe?/c+dir http://target/scripts/..%c1%8s../winnt/system32/cmd.exe?/c+dir http://target/scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir http://target/scripts/..%c1%pc../winnt/system32/cmd.exe?/c+dir

Questa vulnerabilità è stata sfruttata ad esempio dal Code Blue Worm. Ricordiamo di applicare ai prorpi server la patch fornita da Microsoft nell'advisory MS00-057 (http://www.microsoft.com/technet/security/bulletin/ms00-057.asp) §Naturalmente, una volta resa pubblica questa vulnerabilità, i produttori di IDS hanno rilasciato delle nuove signatures. Ad esempio alcune regole di Snort per identificare questo attacco sono: alert t !$HOME_NET any -> $HOME_NET 80 (msg: "IDS434 - WEB IIS - Unicode traversal backslash"; flags: AP; content: "..|25|c1|25|9c"; nocase;) alert t !$HOME_NET any -> $HOME_NET 80 (msg: "IDS433 - WEB-IIS – Unicode traversal optyx"; flags: AP; content: "..|25|c0|25|af"; nocase;) alert t !$HOME_NET any -> $HOME_NET 80 (msg: "IDS432 - WEB IIS – Unicode traversal"; flags: AP; content: "..|25|c1|25|1c"; nocase;)

Tutte queste regole identificano semplicemente la presenza dei “due punti”, seguiti da una delle rappresentazioni UTF-8 dello slash o del backslash.

Pagina 299 di 334

Un attaccante a quest punto potrebbe utilizzare “%C0%AE“ invece del “punto”, consentendogli di sfruttare ancora l'exploit: risulta evidente come il rischio di non identificare tutti i casi possibili sia molto elevato. L'unica via che un NIDS ha per individuare in maniera efficace questo tipo di attacchi, è quella di implementare un'elaborazione dei caratteri UTF-8, come fa IIS. Una protocol analysis o una normalizzazione dei dati sembrano quindi necessarie per ridurre il rischio di evasion attacks. La parte più rilevante del problema resta comunque quella di avere un'interpretazione univoca da parte del NIDS e da parte del server. In questo caso alcuni IDS host-based sono avvantaggiati in quanto, operando direttamente sui log generati dall'applicazione, possono stabilire con precisione come è stata elaborata una specifica richiesta. Attacchi DOS - Esaurimento delle risorse Esistono molti tipi differenti di attacchi denial of service contro sistemi di intrusion detection. Gli attacchi che tratteremo sono legati all'esaurimento delle risorse. Le risorse che possono essere esaurite da un attacker sono: i cicli di U, la memoria, lo spazio disco, e la larghezza di banda della rete. Le capacità di processo della U di un IDS possono essere esaurite in quanto un IDS utilizza cicli di U per leggere pacchetti, determinare cosa sono, e confrontarli con altre informazioni a disposizione (ad esempio confrontare un frammento IP con gli altri frammenti di un determinato datagram). Un attaccante può determinare quali sono i processi più dispendiosi dal punto di vista computazionale, e forzare l'IDS ad utilizzare tutto il suo tempo in lavoro inutile. La memoria è necessaria per molte cose: le connessioni T necessitano del salvataggio degli stati, del riassemblaggio degli stream, e della creazione di buffers di dati per poi applicarvi gli algoritmi di pattern matching. Il sistema ha bisogno di memoria anche solo per leggere i pacchetti. Un attaccante può determinare quali operazioni necessitano dell'allocazione di memoria e poi allocarla interamente per dati inutili. Ad un certo punto, la maggior parte dei sistemi di ID necessiterà di spazio su disco per memorizzare i propri log. Ogni evento che deve essere memorizzato utilizza una certa quantità di spazio su disco: questo spazio, per grande che possa essere, è comunque una risorsa finita. Un attaccante può generare una serie di eventi senza valore fino ad esaurire lo spazio disco disponibile, rendendo così il sistema incapace di loggare gli eventi reali successivi. In conclusione, i sistemi di network ID, tengono traccia delle attività della rete che monitorano. Per la maggior parte, essi sono in grado di farlo in quanto le reti sono raramente sfruttate per la loro piena capacità. Un sistema di ID, diversamente da un end-system che vede solo il traffico a lui destinato, deve leggere tutti i pacchetti presenti sulla rete. Un attaccante può sovraccaricare la rete con informazioni prive di utilità impedendo all'IDS di tenere traccia di cosa stia realmente accadendo sulla rete.

Pagina 300 di 334

Il problema alla base dell'esaurimento delle risorse di un IDS è che quest'ultimo deve simulare le operazioni compiute da tutti i sistemi che sta monitorando, al fine di conoscere cosa stia effettivamente accadendo su di essi. Questo problema è portato all'estremo dal fatto che molti IDS operano in modalità promiscua e leggono tutto il traffico che a sul filo: le risorse possono quindi essere consumate/sprecate processando del traffico che non è destinato a nessuna macchina reale. Esaurimento delle risorse di U Un obiettivo dell'attaccante consiste nell'esaurire le capacità computazionali del sistema di ID per impedirgli di processare abbastanza velocemente i pacchetti in arrivo; di conseguenza, quando le capacità di buffering del sistema saranno esaurite, alcuni pacchetti sfuggiranno al controllo dell'IDS. Molti sistemi di intrusion detection adottano algoritmi inefficienti per l'elaborazione, il salvataggio, e l'esame del traffico di rete. Un esempio concreto è costituito dalla frammentazione IP. Non appena dei frammenti IP arrivano, devono essere salvati fino a quando tutti i frammenti dello stream siano arrivati. Per facilitare questa operazione, molti sistemi riposizionano i frammenti secondo l'ordine che essi avranno nel pacchetto finale. Questo significa che, non appena ogni frammento arriva, l'IDS deve localizzarne la giusta area di memorizzazione con il relativo posizionamento. Molti sistemi utilizzano delle semplici liste ordinate, con il relativo problema di gestirle in modo efficiente (operazioni di aggiunta e riordino) qualora queste diventino troppo lunghe. Un attaccante potrebbe così forzare questo processo ad operare nel caso peggiore, inviando grandi quantità di traffico utilizzando frammenti di piccole dimensioni. Altri tipi di protocolli necessitano per loro natura di un parsing più dispendioso. Un IDS, ad esempio, che abbia la necessità di monitorare del traffico criptato dovrà impiegare una notevole quantità di tempo di U solo per le operazioni di encryption e decryption del traffico. Sebbene la richiesta di questa tipologia di operazioni non sia attualmente molto diffusa, essa è destinata a crescere nel futuro prossimo (ad es. per tecnologie come IPSec). Esaurimento della memoria I sistemi di ID necessitano di memoria per funzionare. Protocolli differenti hanno diverse necessità di memoria per garantire un'adeguata elaborazione dei dati. Un attacker che stia tentando di esaurire le risorse di memoria esaminerà il sistema, cercando di determinare quali sono i punti in cui viene allocata la memoria; cercherà poi di isolare quegli eventi che provocano un'allocazione di memoria per lunghi periodi di tempo ed infine procederà con un packet flooding. Alcuni IDS implementano un meccanismo di “garbage collection” che automaticamente libera la memoria che non viene utilizzata attivamente. Sfortunatamente, se non viene utilizzato in modo corretto, un garbage collector può essere a sua volta fonte di problemi. Un garbage collector non sufficientemente “aggressivo” nel liberare le risorse riuscirebbe solo a rallentare gli effetti di un attacco, mentre uno troppo aggressivo rischierebbe di togliere risorse a processi legittimi, riducendo l'efficacia dell'elaborazione del traffico di rete . Esempi di attacco consistono nella creazione dei TCB - T control block (nel quale un attaccante genera una raffica di connessioni a diversi host della rete oppure crea delle intere Pagina 301 di 334

connessioni fasulle) e nel riassemblaggio T (nel quale viene generata una notevole quantità di traffico con moltissimi segmenti che devono essere riordinati). Esaurimento della larghezza di banda della rete Probabilmente il metodo più semplice per esaurire le risorse di un IDS è quello di generare più traffico di rete di quello che un'interfaccia di rete è in grado di catturare. Sebbene molte interfacce di rete moderne operino in maniera efficiente anche in situazioni di carico elevato, il vecchio hardware non è in grado di garantire un livello altrettanto elevato di performance. Il punto di saturazione delle vecchie interfacce di rete è notevolmente minore di quello reso disponibile dagli attuali network media. Altre volte è possibile “inondare” di traffico dei target specifici. In alcune reti con switch, infatti, vi è la possibilità di direzionare notevoli quantità di traffico verso l'IDS mantenendo intatta l'abilità di poter comunicare con altri target. In generale non esistono soluzioni generali per prevenire tutti gli attacchi di tipo DOS flooding. Vi è la possibilità di acquistare una serie di connessioni di rete e di server velocissimi, ma un attaccante potrebbe sempre disporre di risorse tali da intasare la rete. Nonostante tutto esistono alcune soluzioni per gli IDS che offrono vari livelli di protezione delle risorse: risposte attive da parte degli IDS. Alcuni IDS hanno l'abilità di aggiungere o modificare le regole di filtraggio dei router o dei firewall. Grazie a questa capacità un sensore può accorgersi della presenza di un flooding attack e riconfigurare velocemente il router appropriato, terminando l'attacco. Esistono però alcuni lati negativi di questa soluzione: 1. gli IDS devono avere il controllo di molti dei router di un'organizzazione 2. il maggior lavoro dei router può diminuire le relative prestazioni 3. il personale adibito alla rete potrebbe non essere disposto a cedere il proprio controllo dei routers 4. l'IDS necessita di un certo intervallo di tempo per scoprire e reagire ad un attacco (talvolta anche di qualche minuto). Un attaccante potrebbe sfruttare questa finestra temporale per disabilitare gli IDS attraverso l'uso di attacchi di tipo flooding . Canali di comunicazione separati. Un'altra soluzione è quella di avere cavi fisicamente separati dalla normale rete, sui quali i sensori IDS possono comunicare tra loro. Attraverso questo meccanismo un sensore può accorgersi se un altro è stato reso inefficace da un attacco e può agire di conseguenza, redistribuendo il carico di traffico tra i rimanenti sensori e/o riconfigurando tempestivamente i router. Questa soluzione spesso non è applicabile in quanto risulta troppo dispendioso per alcune organizzazioni installare una rete dedicata agli IDS. Utilizzo di “normalizzatori” di traffico (traffic normalizers). Il compito di un normalizer è quello di rimuovere tutte le ambiguità presenti in uno stream di pacchetti prima ancora che questi arrivino al sensore IDS ed ai sistemi finali. Il risultato è che i NIDS non hanno più bisogno di considerare eventuali contraddizioni nell'interpretazione dei pacchetti in quanto questo compito è svolto completamente da un altro dispositivo.

Pagina 302 di 334

Un normalizzatore differisce da un firewall in quanto il suo scopo non è quello di prevenire l'accesso ai servizi di alcuni host interni, bensì di consentire l'accesso in maniera univoca e non ambigua. Esistono però anche dei fattori negativi. Il primo consiste nelle performance: il normalizer deve essere in grado di ricostruire ogni stream T in tempo reale. Il secondo è la robustezza: dovendo egli processare ed inoltrare ogni pacchetto rischia a sua volta di esaurire le proprie risorse. La normalizzazione inoltre può potenzialmente modificare la semantica di un flusso di dati: se ad esempio non vengono riconosciute alcune opzioni T che invece l'host accetterebbe, si rischia di avere dei risultati diversi da quelli che ci si aspetterebbe. 4.6.4.3

Errori – Falsi positivi e falsi negativi

I sistemi di intrusion detection network based eseguono un'analisi approfondita dei pacchetti allo scopo di rivelare eventuali attacchi. Durante l'analisi in real time del traffico di rete, i dispositivi di ID possono generare allarmi relativi a possibili attacchi che si stanno subendo e/o rispondere in maniera attiva con azioni che consentono di ridurre gli eventuali danni (ad esempio bloccando alcuni servizi o riconfigurando le regole del firewall). Tuttavia, i NIDS hanno la spiacevole propensione a generare degli allarmi anche quando il rischio reale non esiste oppure, per contro, rischiano di lasciar are un attacco senza rivelarne la presenza. Questi problemi vengono definiti falsi positivi e falsi negativi. Prima di procedere vediamo alcune definizioni: Alert / Alarm (o “allarme reale”) - Un allarme segnala che un attacco ad un sistema ha avuto successo. Tipicamente gli allarmi includono informazioni diagnostiche riguardanti il contesto dell'attacco oppure, più semplicemente, la notifica di eventi anomali. Falsi Positivi – E' un allarme generato dall'IDS quando non è presente nessun attacco reale. Un esempio tipico di falso positivo si ha quando un IDS segnala un “SYN flood” solamente perché vede arrivare un gran numero di pacchetti SYN diretti verso un server molto occupato. Un'altra definizione che descrive più correttamente questo tipo di comportamento è quella di “falso allarme”. Il problema principale dei falsi allarmi consiste nel fatto che essi riducono il valore e l'urgenza degli alert reali. Falsi negativi – “falso negativo” è un termine usato per descrivere l'inabilità di un dispositivo di intrusion detection di rilevare una situazione che dovrebbe generare un avviso legittimo. In altre parole, dell'attività dolosa non viene scoperta e segnalata. Fortunatamente esistono delle azioni che consentono di ridurre la possibilità di incorrere in falsi negativi senza però incrementare il numero di falsi positivi. La difficoltà maggiore nel trovare questo giusto equilibrio è quello di creare un NIDS più affidabile senza dover introdurre del rischio aggiuntivo. Un tipico esempio è quello in cui l'IDS non riesce a catturare tutti i pacchetti necessari per ricostruire le azioni di un attaccante, perdendo così la possibilità di individuare l'attacco che si sta compiendo. Pagina 303 di 334

Rumore (noise) – E' un allarme in cui l'IDS invia un avvertimento in merito ad una condizione che non avrà nessun impatto sul sistema monitorato. In pratica il tentativo di attacco esiste ma, non potendo essere portato a buon fine per svariate ragioni, la sua segnalazione provoca solo del “rumore”. Ad esempio, l'IDS potrebbe identificare correttamente un attacco di buffer overrun specifico per un sistema Windows/Intel, ma che non avrà alcun effetto sulle macchine Solaris/SPARC che sta monitorando in quel momento. Falsi positivi Le categorie più comuni in cui possono essere suddivisi i falsi positivi sono: •

Allarmi generati da altri eventi sulla rete, spesso innocui. Un esempio può essere un NIDS che genera un allarme di tipo ICMP flood quando, in realtà, vi sono effettivamente dei dispositivi guasti sulla rete che provocano l'invio di questo tipo di pacchetti.

•

Allarmi generati dall'invio di pacchetti che l'IDS non riconosce, da parte di alcuni dispositivi di rete (come ad esempio i load-balancers).

•

Violazioni dei protocolli: gli allarmi vengono generati a causa di traffico non riconosciuto, spesso per colpa di software scritto male o di implementazioni ambigue dei protocolli.

•

“Veri” falsi positivi: sono allarmi generati dagli IDS senza alcun motivo apparente. Spesso sono causati da bug nel software.

•

Allarmi innocui: generati da situazioni reali che, però, non sono per loro natura pericolose. Ad esempio potrebbe venir generato un allarme solamente visualizzando una pagina web in cui sia presente il codice sorgente d qualche attacco, mostrato per scopi di analisi o di ricerca.

Falsi positivi e rumore Probabilmente il maggior equivoco circa i falsi positivi risiede nel loro rapporto col concetto di rumore. Spesso quando gli amministratori di rete si lamentano dei falsi positivi generati dai loro IDS, in realtà si stanno riferendo al rumore. Il rumore risulta da alcune cause principali quali: •

Il posizionamento dell'IDS al di fuori del perimetro di sicurezza: l'IDS collocato in un posto in cui può vedere tutti gli attacchi sicuramente genererà centinaia di alert ogni giorno.

•

Politiche troppo restrittive: alcuni amministratori o responsabili degli IDS tendono a considerare sospette un numero troppo elevato di attività, rischiando poi di fare confusione con gli allarmi reali.

•

Mancanza di “consapevolezza” degli IDS: spesso questi ultimi non hanno la possibilità di determinare se l'attacco riconosciuto sarà pericoloso o innocuo per la macchina che stanno monitorando Pagina 304 di 334

Molti amministratori considerano una seccatura gli alert dovuti al rumore. Sfortunatamente questi sono solamente il sintomo che l'IDS sta lavorando correttamente ma che richiede di essere regolato meglio. La risposta di molti produttori di IDS al problema del rumore è spesso quella di disattivare queste firme oppure di modificare il livello di soglia degli allarmi. Per quanto riguarda gli IDS posizionati fuori dal firewall, disattivare le firme renderebbe inutile quel tipo di posizionamento, mentre una riconfigurazione mirata potrebbe portare notevoli vantaggi. La disattivazione completa di alcune firme potrebbe avere maggior senso in situazioni in cui il produttore rilascerà a breve delle firme migliori, oppure durante fasi di riconfigurazione e tuning dell'IDS. La soluzione più efficace per ridurre i falsi positivi consiste nello studio approfondito della topologia della rete. Questo richiede una notevole conoscenza delle reti, esperienza, capacità di analisi ed anche un pizzico di immaginazione. In questo modello un NIDS è posizionato anche all'esterno del firewall con una serie completa di firme. Gli alert verranno analizzati in maniera molto specifica per eliminare i falsi allarmi più comuni, avendo cura di non introdurre dei falsi negativi. Un monitoraggio anche del traffico in uscita consentirà un tuning ancora più efficace. Falsi negativi I falsi negativi, più difficili da individuare dei falsi allarmi, si manifestano quando un dispositivo di intrusion detection non genera un allarme riguardo ad un effettivo attacco. Varie sono le cause: •

Configurazione della rete: possono derivare da problemi di performance sulle mirror ports degli switch, oppure se esistono punti della rete che, per sbaglio, non vengono monitorati da alcun IDS.

•

Traffico criptato: questi problemi derivano dal fatto che un IDS non è in grado di comprendere il contenuto di un certo tipo di traffico criptato.

•

Mancanza di controllo sui cambiamenti: molte condizioni che contribuiscono alla creazione di falsi negativi derivano da una mancanza di coordinamento tra il personale.

•

Signatures errate: sebbene l'attacco sia conosciuto e la firma relativa esista, essa non è in grado di rivelare l'attacco o le sue variazioni.

•

Attacchi non resi pubblici: se l'attacco esiste ma non viene reso pubblico, i produttori di IDS non svilupperanno le relative firme.

•

Dispositivi NIDS mal configurati. Solitamente le cause sono: o

regole usate per ridurre i falsi positivi possono risultare troppo generali, rischiando di far are inosservato anche il traffico non lecito.

o

amministratori di sistema che hanno una limitata conoscenza delle vulnerabilità e delle minacce associate a specifici attacchi.

Per ridurre il rischio di falsi negativi bisogna quindi effettuare una costante manutenzione dei dispositivi e della rete, utilizzare firme corrette ed aggiornate (magari scaricandole in Pagina 305 di 334

automatico dai siti dei produttori), e gestire una comunicazione efficace tra i vari dipartimenti interni.

4.6.5 Fattori che concorrono nella scelta di un IDS Alcuni fattori da tenere in considerazione nella scelta di un IDS sono: •

Costo. Logicamente questo deve essere commisurato in base ai servizi offerti nei punti seguenti.

•

Costo di mantenimento e di aggiornamento delle firme. Un sistema di intrusion detection è come un antivirus: se non viene costantemente aggiornato si rischia di non intercettare i nuovi attacchi. Verificare se vi è la possibilità di scrivere le proprie firme o personalizzare quelle esistenti, oppure se si è vincolati a scaricare quelle messe a disposizione del produttore, e a quale prezzo.

•

Velocità limite nella cattura dei pacchetti, espressa in Mb/s ed in pacchetti/secondo. La velocità deve essere considerata in base al segmento su cui verrà posizionato il sensore: ad esempio, se si dovrà monitorare solamente una connessione ad Internet ad 1,5Mb/s non sarà indispensabile avere l'IDS più veloce presente sul mercato. Dall'altra parte, se vi è ad esempio la necessità di monitorare una server farm, sarà essenziale un IDS veloce e robusto.

•

Individuazione degli attacchi di inserimento e di evasione. Identificare quali e quanti attacchi di questo tipo sono stati risolti dal produttore dell'IDS.

•

Scalabilità.Verificare quanti sensori il sistema a, quali sono i meccanismi di avviso, se esiste o meno una console di amministrazione centralizzata oppure se ogni sensore deve essere configurato localmente e/o singolarmente, cosa succede in caso di sovraccarico della management console etc.

•

Costo di utilizzo e di mantenimento del prodotto. Verificare quanto sono efficaci e chiari i report, se l'output viene salvato in formati standard e portabili oppure se in formati proprietari, quanto è semplice gestire i falsi positivi, quanto tempo è necessario per identificare la situazione reale, quante persone ci vogliono per utilizzare il prodotto.

Altri fattori da considerare (ma dei quali i produttori tendono a fornire dei valori non troppo affidabili) sono: •

Numero delle signatures ate. Sfortunatamente i produttori gonfiano il numero delle firme che il loro prodotto a, rendendo il peso di questa informazione sempre minore.

•

Caratteristiche aggiuntive. Ad esempio, la possibilità di riconfigurare il firewall, può essere dicharata come la soluzione a molti problemi e risultare quindi molto invitante; nella realtà purtroppo, se gestita male, questa feature può diventare molto rischiosa.

Pagina 306 di 334

4.6.6

Un esempio pratico: Prelude-IDS Prelude è un sistema ibrido e completo di intrusion detection, distribuito sotto licenza GPL. Prelude è stato inizialmente sviluppato per GNU/Linux, ma ora a anche la famiglia *BSD, ed ogni altra piattaforma POSIX compliant. E' ottimizzato per ambienti distribuiti, ed è completamente modulare, robusto e veloce. Il progetto di Prelude-IDS nasce nel 1998, con lo scopo di creare un tool di network intrusion detection modulare. I nuovi trend della ricerca hanno portato poi questo progetto a trasformarsi da un “semplice” NIDS in un IDS ibrido. Un Hybrid IDS lavora sia come un IDS host-based, sia come network-based, fornendo una soluzione di intrusion detection più completa. Sebbene un NIDS possa essere molto utile in alcune condizioni, esso non permette ad un amministratore di capire lo stato di sicurezza globale di una grande rete. La necessità di avere un sistema centralizzato, che consenta di correlare in maniera semplice i log generati dai sensori sulla rete e sui singoli sistemi, è uno dei motivi che ha portato a sviluppare Prelude. Qui di seguito introdurremo l'architettura generale di Prelude, individuandone i maggiori punti di forza e le tipologie di attacchi di inserzione ed evasione risolti. Per la procedura di installazione si faccia quindi riferimento alle relative pagine sul sito ufficiale: http://www.prelude-ids.org/article.php3?id_article=4 http://www.prelude-ids.org/article.php3?id_article=6

Compatibilità hardware e di Sistema Operativo Alpha PowerPC X X Y Y Y Y Y Y N/A N/A N/A X X = ato Y = Potrebbe Funzionare N/A = Non Funzionante

Sparc X Y Y Y X N/A

x86 X X X X Y N/A

Itanium X N/A Y N/A N/A N/A

OS Linux* OpenBSD FreeBSD** NetBSD Sun/Solaris MacOsX

* Prelude è incluso in Gentoo, Debian, Mandrake, e Mandrake Security Multi Network Firewall ma può funzionare in tutte le distribuzioni. ** Prelude è incluso come parte dei package standard.

Pagina 307 di 334

Architettura Prelude è costituito da cinque parti principali: I Sensori servono per catturare gli eventi nei punti strategici della rete. Essi sono capaci di riportare alerts di sicurezza dettagliati al Prelude Manager. I Managers sono adibiti all'elaborazione dei dati provenienti dai sensori. Possono inoltrare i dati verso altri Managers, o verso i Counter Measure Agents. In un ambiente distribuito diversi Managers possono agire da “ripetitori” verso un Central Manager. I Counter Measure Agents ricevono dai Managers dei dati riguardanti una particolare anomalia, ed eseguono particolari azioni finalizzate ad interrompere o contrastare le irregolarità riscontrate. Il Frontend serve per visualizzare ed amministrare i dati relativi agli attacchi. I dati sono archiviati, normalizzati, e trasformati in un formato più gestibile e comprensibile. La Prelude Library è stata creata per rendere più semplice l'implementazione di nuovi sensori da parte degli sviluppatori. Sono state fornite funzionalità comuni ed API standard: tutti i programmi di Prelude utilizzano queste librerie (libprelude). Libprelude rende più facile il porting di applicazioni già esistenti, affinché esse possano essere utilizzate per il report verso l'intero sistema Prelude (ad esempio Snort, honeyd, nessus, nagios, systrace ed hogwash sono stati modificati per includere il o a Prelude). Le relative patch sono disponibili sul sito di Prelude. Sia i Sensori che i Manager hanno inoltre la capacità di salvare i dati in locale qualora vi sia un problema sulla rete o di un servizio, che impedisca l'invio dei dati ad un Manager o al Central Manager. IDMEF Il formato di comunicazione utilizzato da Prelude è IDMEF. IDMEF, basato su XML, consente ai componenti “ibridi” di Prelude di inviare allarmi dettagliati, descrivendo un gran numero di eventi: attacchi di rete, buffer overflow locali etc. Tutti i dati vengono inviati in strutture binarie: questo riduce i tempi di elaborazione e la bandwidth utilizzata da IDMEF. Per mantenere basso il carico di U, il team di Prelude ha poi ottimizzato il motore IDMEF. La Prelude Library La libreria di Prelude fornisce le seguenti funzionalità:

Pagina 308 di 334

Gestione delle connessioni con il Manager. La comunicazione tra i Sensori ed il Manager è effettuata tramite la libreria. Periodicamente vengono fatti dei tentativi di collegamento al Manager: se il tentativo non va a buon fine, viene scelto un nuovo Manager a cui verranno inviati i messaggi del Sensore. Se tutti i Managers che il sensore ha configurato come destinatari non sono raggiungibili, allora l'alert viene salvato in un file locale e verrà inviato successivamente. Livello di comunicazione trasparente. Ogni volta che vi è una comunicazione con il Manager, la libreria seleziona automaticamente il protocollo più adeguato (clear-text o SSL). La libreria fornisce un'interfaccia che nasconde questo livello di comunicazione. Coda di eventi generici asincrona. Ad esempio, un messaggio associato ad un oggetto asincrono è inviato senza alcun blocco. Interfaccia di configurazione generica. LibPrelude offre un'astrazione alle opzioni da linea di comando ed ai file di configurazione. Interfaccia all'amministrazione di plug-in generici. Essa offre un modo semplice per creare plug-in di terzi. I sensori collegati con la libprelude utilizzano i propri file di configurazione oppure ereditano le opzioni comuni definite nel file di configurazione globale collocato in /usr/local/etc/prelude-sensors/sensors-default.conf.

Sensori I sensori servono a rivelare attività sospette sugli host o sulla rete in real-time. Un sensore può essere complesso come un motore NIDS completo, oppure semplice come un programma che verifica se una determinata porta è aperta oppure no. Il “legante” è dato dall'utilizzo della libprelude e dei messaggi IDMEF per comunicare le scoperte al Manager. I tre sensori principali sono: • Prelude NIDS – Un motore di Network Intrusion Detection • Prelude LML – Un log analyzer • Libsafe – Una libreria pre-caricabile (solo per Linux), che protegge il sistema da attacchi di tipo buffer overflow. Prelude NIDS Prelude-NIDS è il sensore responsabile della cattura e dell'analisi real-time dei pacchetti sulla rete. Esso utilizza una versione modificata della libreria Pcap. Quando un pacchetto viene ricevuto, il sensore decodifica gli header e li salva in una struttura dati interna; vari test sono effettuati a questo punto per determinare se il pacchetto deve essere considerato valido o meno: dati malformati infatti potrebbero essere stati inseriti nel pacchetto per rendere instabile il sistema. Altri test sono poi effettuati sui flag T ed IP. Se viene riscontrata un'anomalia, il pacchetto verrà scartato per prevenire il fallimento di un' analisi successiva. Dopo una verifica sui flag Pagina 309 di 334

verranno effettuate le operazioni di deframmentazione IP e di T reassembly. Se queste features sono attivate e se il pacchetto in arrivo fa parte di una connessione T attiva, la relativa analisi verrà rinviata fino a quando il riassemblaggio completo del pacchetto avrà luogo. A questo punto, i dati verranno trasmessi ai protocol plug-in. Questi plug-in sono in grado di decodificare molti protocolli di alto livello come quelli descritti qui di seguito. Normalizzatori di dati HTTP Decoding Plugin. Questo plugin cerca richieste HTTP nei pacchetti T; una volta trovata una richiesta, normalizza tutti gli “ escaped characters” ( HTTP escaping, UTF-8 escaping o Unicode escaping), per prevenire gli attacchi di evasione. E' in grado di scoprire un elevato numero di attacchi, sequenze UTF-8 invalide, o sequenze UTF-8 usate per nascondere caratteri ASCII. Escaped Characters Decoding in FTP e TELNET. Questo plugin identifica le opzioni TELNET o FTP nei dati dei pacchetti. Esso cerca di normalizzare queste opzioni per garantire che non vadano ad interferire con l'algoritmo di string matching. Decodifica degli header per la Signature Analysis RPC Decoding. Questo plugin decodifica i pacchetti UDP e T che contengono header RPC, su cui il motore di analisi delle firme effettua un test del tipo "rpc: function, version, program;". Una volta che questo test è stato effettuato, può cominciare l'analisi reale, ed i pacchetti sono trasmessi ai detection plug-ins. Plug-ins Il compito di un plugin è quello di analizzare i protocolli a cui sono dedicati, ed inviare degli alert quando necessario. I plugin sono usati per operazioni di intrusion detection complesse, per le quali non è sufficiente una analisi delle signatures (che è a sua volta un tipo di Detection Plugin). SnortRules Plugin. SnortRules è un plugin che offre la compatibilità con le firme di Snort. Esso utilizza il motore di firme generico di Prelude, fornendo funzionalità aggiuntive di test e di parsing. Scan Detection Plugin. Questo plugin invia un allarme se vengono rilevate troppe connessioni su porte differenti in un dato periodo di tempo. Per essere meno soggetto a falsi positivi, questo plugin determina una differenza tra porte privilegiate e non privilegiate, settando limiti differenti. Le porte più “interessanti” per un attaccante sono solitamente quelle comprese nel range 0-1024. Polymorphic Shell Code Detection Plugin. Nel ato, le istruzioni NOP (0x90) erano utilizzate per gli attacchi di tipo buffer overflow. Era quindi relativamente semplice per un IDS contare il numero di NOP nei dati, o riconoscere una parte dei dati con una firma. Da quando i Polymorphic Shell Codes sono utilizzati con maggior frequenza, questa tecnica è diventata obsoleta. Questi tipi di shell-code utilizzano istruzioni differenti da NOP, ma con lo Pagina 310 di 334

stesso

effetto:

diventa

quindi

impossibile

generare

delle

firme

affidabili.

Il Polymorphic Shell Code Detection Plugin è in grado di scoprire i code paths con differenti opcodes che si comportano come istruzioni NOP. Se il numero di queste istruzioni supera un limite preconfigurato, verrà generato un allarme. ArpSpoof Plugin. Il plugin ArpSpoof verifica la consistenza dei messaggi ARP negli header Ethernet. Esso invia un allarme se: • una richiesta ARP è inviata ad un indirizzo UNICAST (richieste ARP valide sono inviate all'indirizzo BROADCAST) attraverso l'opzione diretta. Una richesta di UNICAST ARP denota spesso un attacco. • l'indirizzo ethernet del mittente è diverso dall'indirizzo di partenza incluso nel messaggio ARP (ARP spoofing) • l'indirizzo di destinazione messaggio ARP

è diverso dall'indirizzo di destinazione incluso nel

• si riscontra un conflitto con il database arpwatch. Arpwatch permette di specificare coppie di indirizzi IP/MAC e di scoprire conflitti nei messaggi ARP. IP Defragmentation stack. Lo stack della frammentazione IP è utilizzato quando più dati di quelli consentiti sono inviati ad un'altra macchina. Il limite è fissato dal MTU (Maximum Transfer Unit). Se la comunicazione attraversa diversi punti, il minimo MTU tra i punti fissa la massima dimensione consentita dei pacchetti. Un attaccante, come abbiamo visto, potrebbe utilizzare la frammentazione IP per evadere il controllo dell'IDS, disturbando l'algoritmo di string matching: Prelude possiede uno stack proprio per la frammentazione IP, copiato dal reassembly stack di Linux, proprio per combattere questi effetti. T stream reassembly. Il riassemblaggio dello stream T è implementato da PreludeNIDS per aiutare a scoprire o fermare tecniche di IDS evasion. Prelude è in grado di riassemblare gli stream T fornendo una protezione contro gli stateless-attacks. Tool come IDSWakeUp (http://www.hsc.fr/ressources/outils/idswakeup/index.html.en), Stick e Snot, inviano pacchetti creati ad hoc per generare molti falsi positivi, rendendo molto più difficile identificare l'attacco reale. Queste applicazioni non attaccano realmente la macchina, ma creano un pacchetto che verrà sicuramente intercettato da una delle regole dell'IDS, che di conseguenza genererà un allarme. Quando il numero di questi falsi allarmi diventa molto elevato, l'operazione di analisi da parte di un amministratore risulterà molto più lunga e complicata. Il team di Prelude ha effettuato alcuni tentativi di evasion-attacks, utilizzando il tool Fragroute (http://www.monkey.org/~dugsong/fragroute/). Fragroute intercetta, modifica, e riscrive il traffico in uscita destinato ad uno specifico host, implementando molti degli attacchi descritti nel paper “Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection” di Thomas H. Ptacek e Timothy N. Newsham (link presente nella bibliografia). Pagina 311 di 334

Gli attacchi provati, un breve commento, ed il risultato di questi test è riportato nella tabella al seguente link: http://www.prelude-ids.org/article.php3?id_article=66#nh1-7 Tabella dei servizi di Prelude NIDS Feature

Progetto

10/100/1000 FullDuplex via Span Port (Mirror port) Stealth Logging sull'interfaccia Monitoraggio di interfacce multiple su singoli host Full Packet Capture Filtro BPF Decodifica HTTP Decodifica RPD PortScan Detection Polymorphic Shell Code Detection ArpSpoof Detection IP Defragmentation ive OS Detection T Flow ReAssembly IP Spoof Detection SMP/Threading Algoritmo E2xb 802.1q (VLAN) Packet Processing 802.11 (WLAN) AP/Station Monitoring * Ruleset Tuning basato sui report di Nessus

Sviluppo

Rilasciata

Note

X/X/? X X X X X X X X X X X X X X X X

Contributo: Sylvain de Tilly Rilascio: gennaio Rilascio: gennaio

X X X

Prelude-LML Prelude LML, o Prelude Log Monitoring Lackey, è la parte del progetto dedicata agli aspetti di host-based intrusion detection. Una funzione è quella di ascoltare sulla rete alla ricerca dei messaggi di Syslog provenienti dai differenti host su piattaforme eterogenee. Ogni sistema che genera log dal Syslog Unix standard e li trasmette all'host LML è quindi in grado di utilizzare il motore di analisi di Prelude-LML. Alcuni esempi di piattaforme sono: • • • • •

Sistemi Unix Switch e routers Firewall Stampanti Altri sistemi che sono in grado di trasformare i propri log nel formato Syslog (come ad esempio MS Windows NT/2K/XP attraverso tools come Ntsyslog) Pagina 312 di 334

In questo modo, posizionando Prelude-LML sulla rete e configurando le altre macchine ad inviare i loro messaggi di log al demone Syslog (simulato da Prelude-LML), è possibile monitorare i log delle macchine di un'intera rete. NOTA: Prelude-LML non salva questi un file. Non è infatti da considerarsi un Syslogd alternativo. Esistono due metodi per abilitare l'analisi locale di Prelude-LML: • Settare il Syslogd del Prelude-LML per ascoltare sulla rete, ed il Prelude-LML potrà analizzare i log come se fossero in locale • Configurare il Prelude-LML su un host Prelude-NIDS, e configurare le regole in modo da generare dei syslog qualora vengano ricevuti dal NIDS dei dati contenenti messaggi syslog. Una volta ricevuti i log si potrà procedere con l'analisi di questi alla ricerca di anomalie: PreludeLML ha un sistema di plugin il cui scopo è quello di gestire ed analizzare i messaggi di log. Uno di questi plugin, chiamato Simple, è un motore per la ricerca di espressioni regolari. Simple è utilizzato da Prelude-LML per analizzare insiemi di espressioni regolari: ogni insieme di regole consente di individuare espressioni specifiche per un particolare scopo. Ad esempio, il ruleset per NetFilter “cercherà” solamente i messaggi netfilter, ed il ruleset GRSecurity “cercherà” solamente i messaggi GRSecurity. Il file di configurazione dirà a PreludeLML quali plugin caricare per l'analisi dei log. Attualmente, il plugin Simple possiede i seguenti insiemi di regole di parsing: • • • • • • • • • • • • • • • • •

IpFw NetFilter IpChains Checkpoint Nokia appliance NtSyslog Cisco’s e Zyxel’s routers logs. GRSecurity Exim Portsentry ProFTPd Qpopper Squid Secure Shell Daemon (sshd) Vigor Vpopmail Log specifici di Unix

La scrittura di nuovi rulesets è costantemente in fase di lavorazione.

Pagina 313 di 334

Prelude-LML utilizza anch'esso la libreria LibPrelude, con la possibilità quindi di trasmettere tutti gli alert attraverso dei tunnel SSL, garantendo l'integrità e la privatezza dei dati. Questo facilita anche l'autenticazione tra i vari sensori ed il Manager. Prelude LML Features Feature Syslog Management centralizzato Stealth Logging sull'interfaccia IPFW Logs NetFilter Logs IPChains Logs Cisco Router Logs Cisco VPN Concentrator Cisco PIX Logs Nagios Logs Zyxel Router Logs WuFtpd Logs ProFtpd Logs Parse SSHD Logs Parse Qpopper Logs GRSecurity Logs Unix Security Logs CheckPoint FW-1 Logs Norton Antivirus Corporate Edition Logs

Progetto

Sviluppo

Rilasciata

Note

X X X X X X X X X X X X X X X X X X

Libsafe Libsafe è differente dai due sensori precedenti, in quanto non è stato originariamente sviluppato dal team di Prelude. Un'altra differenza da Prelude-NIDS e Prelude-LML consiste nel fatto che Libsafe è una libreria che funziona solo su Linux. Libsafe è una libreria “pre-caricabile” (attraverso la direttiva LD_PRELOAD o aggiungendo una entry nel file /etc/ld.so.conf) che protegge un programma contro lo sfruttamento di vulnerabilità quali i buffer overflow o le stringhe malformate. Allo stesso tempo, Libsafe è in grado di verificare chiamate verso funzioni “insicure” che non fanno alcuna verifica delle dimensioni dei buffer che stanno per ricevere, come ad esempio la sprintf, stry e molte altre. Libsafe sostituisce queste funzioni con una implementazione propria, garantendo che non vi siano buffer overflows: per far questo intercetta le chiamate alla funzione originale e modificandone il percorso in modo da sostituirci il proprio. Se viene riscontrato un buffer overflow, libsafe termina l'esecuzione del programma (nel caso di un processo “figlio”, termina solo questo). Se Libsafe viene compilata su un sistema dove è già installata la LibPrelude, allora la Libsafe diventa automaticamente un sensore Prelude. I malfunzionamenti intercettati da Libsafe durante l'esecuzione di un programma genereranno un Prelude Alert, che verrà poi inviato al Prelude Pagina 314 di 334

Manager Centrale. La combinazione LibSafe + LibPrelude consente agli amministratori di ottenere informazioni molto precise sugli attacchi, integrando i dati degli alert del NIDS con quelli della Libsafe. Prelude Manager(s) Il Manager (che possono essere anche molti, in una rete di IDS) accettano connessioni sicure dai sensori, e salvano gli alert che questi ultimi gli inviano. I Managers possono anche inoltrare gli alert ai CounterMeasure Agents, che li processeranno e prenderanno le opportune contromisure. Il Manager provvede a sei funzioni principali: Sottosistema dei Server. Quando un sensore rileva una attività considerata “anormale”, invia un alert. Il processo sul Server, adibito al controllo dei Sensori, rileverà quindi la presenza di nuovi dati e leggerà i relativi messaggi. Una volta che il messaggio sarà ricevuto, verrà poi inviato al sistema di Scheduling. Sottosistema di Scheduling dei messaggi. Lo scheduler dei messaggi, basandosi sui vincoli di memoria e sulla priorità di questi, decide se il messaggio debba venir salvato in memoria (per velocizzare l'operazione) oppure se debba essere scritto temporaneamente su disco (per essere processato in seguito). Sottosistema delle Contromisure. Quando un alert viene processato, il Manager lo inoltra al suo sottosistema per le “contromisure”, che può essere configurato per reagire ad alcuni eventi/attacchi. I triggering plugins contengono la logica di programma necessaria ad analizzare se un alert può essere gestito con una specifica contromisura. Se applicabile, il plugin invierà un ordine ad un Communication Agent remoto, richiedendo che venga applicata una reazione. Sottosistema di Reporting. Una volta che un alert è stato processato, ed è stata attivata una contromisura, il Manager utilizza i plugin per convertire gli alert dal formato IDMEF binario di Prelude, a diversi formati di output. Questi plugin sono chiamati Reporting Plugins. Prelude attualmente possiede vari plugin di reporting: • • • • •

MySQL Database Plugin. PostgreSQL Database Plugin. Oracle Database Plugin (alpha). XML Reporting Plugin. Text Reporting Plugin.

Sottosistema di Ritrasmissione ed Inoltro. I Managers possono anche agire da “ripetitori”. I Relayng Managers controllano un insieme di Sensori e di Counter Measure Agents, e ritrasmettono i dati ricevuti ad un Central Manager. Questa è una caratteristica molto interessante, soprattutto quando una rete è suddivisa in sottoreti.

Pagina 315 di 334

Prelude Manager Feature Feature

Progetto

Comunicazione IDMEF con i Sensori Comunicazione SSL con i Sensori CounterMeasure Control Reporing testuale MySQL Reporting PostgreSQL Reporting XML Reporting Inoltro dei messaggi Console di amministrazione Reporting su Dshield.org

X

Reporting su prelude-ids.org

X

Sviluppo

Rilasciata

Note

X X X X X X X X X

Frontends Uno dei tool più importanti, per un analista nel campo della sicurezza informatica, risiede nel frontend dell'IDS. Quest'ultimo è l'interfaccia adibita alla visualizzazione logica degli alert catturati dall'IDS. Il frontend fornisce una “vista attuale” dello stato di sicurezza della macchina, o della rete di macchine. Per aiutare il security , Prelude fornisce un frontend di amministrazione web-based (PIWI). Esso è web-based per garantire al personale di sicurezza di poter monitorare lo stato del sistema da qualsiasi macchina sulla rete. PIWI PIWI è la parte web-based dell'architettura di Prelude. Il frontend è sviluppato in Perl, spesso disponibile per molti webserver. Lo scopo di questo frontend è quello di leggere le informazioni presenti nel database degli alert, presentandole poi in una forma utile all'utilizzatore finale. Piattaforma Perl è stato scelto per molte ragioni. Una è che Perl è un linguaggio open-source costantemente in sviluppo, con un elevato grado di maturità. Secondariamente, Perl è disponibile per le maggiori piattaforme (Unix e Windows), ed utilizzabile su molti webservers attuali (Apache, IIS, Netscape Enterprise Server, AOLServer). Perl inoltre a molti database (PostgreSQL, MySQL, Oracle, DB2, Informix, etc.), consentendo di incrementarne la portabilità e l'usabilità Features Security Alert Listing. La visualizzazione degli alert può essere modificata selezionando diversi criteri quali: Visualizza per Tipo di Attacco, Source IP, Destination IP , per Servizio (Porta). Pagina 316 di 334

Alert Sorting. L'ordinamento può essere effettuato per: Indirizzo IP di partenza e di destinazione, Codice di attacco/Nome dell'attacco, Servizio, Visualizzazione dei NIDS Alerts o degli Host Alerts. HeartBeat Monitoring. I sensori vengono monitorati attivamente per garantire un recupero affidabile delle informazioni. View By Reports. Attualmente vi sono due tipi di “View reports” in PIWI: visualizza i “20 Top Attacks” ed i “Top 20 Attackers”. Monitor Multiple Databases. Consente di monitorare database multipli con una sola istanza di PIWI. Access Control. Il controllo degli accessi viene effettuato con htaccess. Report Statistics. Vengono creati sommari visuali di Attacchi e Alert. I report possono essere generati in molti formati incluso HTML, tabelle, grafici lineari, a barre e molti altri. View Filters. I filtri permettono agli amministratori di creare delle “viste” personalizzate per quello che vogliono osservare in un dato momento. I filtri sono altamente configurabili, e possono essere generati ed editati nel “Filter Factory”. PIWI Features Progetto

Feature Ordinamento degli alert per categoria Visualizzazione dei Sensor Heartbeat Data Report statistici Top 20 Attacks Top 20 Attacker Genera/salva filtri personalizzati Genera filtri personalizzati dai report di Nessus Visualiz. Delle informazioni complete dei pacchetti Link al Whitehats Advisory Data LibPreludeDB Compliant Esportazione dei Reports in PDF Management HostGroup Managemen Access Control Lists Management delle regole dei NIDS Online Help System Tool di rete integrati

Sviluppo

Rilasciata X X X X X X X X X

X X X X X X X X

Sviluppi futuri Network Tools: integrazione con tool di rete come Nmap, nslookup, whois, etc. Pagina 317 di 334

Note

Autenticazione ed amministrazione di utenti e gruppi: I formati di autenticazione disponibile saranno Database e LDAP. Filtri definiti dagli utenti: questi ultimi potranno definire i loro filtri personali, separatamente da quelli di PIWI. Creazione di filtri “on-the-fly” in base alle risposte di Nmap. Gruppi di host: gli host potranno essere raggruppati insieme per consentire ad uno Group di avere i permessi di visualizzare gli alert che si riferiscono ad un sottoinsieme di host. Ad esempio un gruppo potrebbe voler vedere i log relativi ai router e switch, mentre un altro potrebbe voler monitorare solo i webserver. Access Control Lists: configurando PIWi per essere accessibile solo da alcune macchine sulla rete. Stato di sviluppo dei Package Package LibPrelude LibPreludeDB Prelude Manager Prelude NIDS Prelude LML PFLogger PIWI Correlation PTF

Progetto

Sviluppo

Rilasciata

Note

X X

Rilascio a Dicembre X X X

X X X X

Prelude ed i problemi tipici degli IDS Abbiamo visto nei precedenti paragrafi come Prelude risolva alcuni problemi generali dei sistemi di intrusion detection, come ad esempio la frammentazione IP , il T stream reassembly e gli attacchi con Unicode. Vediamo ora come vengono risolte altre debolezze tipiche degli IDS. Reti switched. L'approccio è identico a quello degli altri IDS: per monitorare tutto il traffico è necessario che il router o lo switch vengano configurati per copiare il traffico di tutte le porte sulla Mirror Port. Reti Gigabit. Prelude non è ancora stato testato per reti con queste velocità. Rumore generato da tool come Snot e Stick. Fino a quando l'opzione di Stream Reassembly è attivata, Prelude NIDS non è vulnerabile a questi tools: questi infatti generano attacchi stateless, basandosi solo sul principio del pattern matching. Falsi positivi e falsi negativi. Il problema è gestito come per gl altri IDS: gli amministratori devono fissare dei livelli adeguati effettuando numerosi test e provando diverse configurazioni. Pagina 318 di 334

Prelude (come gli altri IDS) NON è però in grado di: compensare deboli meccanismi di autenticazione ed identificazione compensare debolezze nelle specifiche (di protocolli di rete) compensare debolezze nei sistemi operativi effettuare, da solo, una investigazione completa (non ancora) creare security policies analizzare TUTTO il traffico di una rete e mantenere infiniti statistici eseguire se stesso

Pagina 319 di 334

APPENDICE A Incident Response Italy CD (basato su F.I.R.E.) release 1.0, 10 Dicembre 2003 Cos'è IRItaly CD? IRItaly CD è un cdrom bootable contentente una distribuzione in grado di rendere disponibile all'utilizzatore un'immediato ambiente di lavoro, basato su Linux, al fine di realizzare una prima analisi forense di risposta all'incidente e quindi: - recupero dati - analisi di immagini forensi - ricerca di virus - valutazione delle vulnerabilità - salvataggio dei dati relativi all'analisi compiuta Iritaly CD fornisce gli strumenti necessari per una analisi forense 'live' su macchine: - win32 - sparc solaris - x86 linux usando i binari statici di fiducia contenuti in /statbins. IRItaly CD è liberamente ispirato a F.I.R.E (Forensic and Incident Response Enviroment Bootable CD) di Dirk Loss, raggiungibile sul web all'indirizzo: http://fire.dmzs.com Cosa posso fare con IRItaly CD? * Eseguire un' immagine forense del sistema compromesso * Analizzare le immagini generate * Creare accurati report dell' indagine svolta * Salvare, anche su dispositivi esterni (es. USB), i log e le relazioni dell' analisi * Eseguire controlli alla ricerca di possibili infezioni da virus * Eseguire test di vulnerabilità del sistema o della rete di sistemi compromessi Ogni strumento utilizzato è compilato staticamente e presente sul CD in sola lettura, assicurando così l' autenticità dei binari. Installazione di IRItaly CD Essendo un CDrom autoeseguibile, una volta scaricata e masterizzata la iso del CD, esso sarà in grado di rilevare l' hardware presente e rendere disponibile un ambiente di lavoro in modo autonomo. Caratteristiche Pagina 320 di 334

* Forensics workstation/Data Recovery Creazione istantanea di una stazione di lavoro forense con strumenti come sleuthkit e autopsy. * Live System Incident Response Disponibili binari per Incident Response live sulle macchine. * Virus Scanning Tramite F-Prot 3.11 beta (http://www.f-prot.com) è possibile eseguire scansioni alla ricerca di virus, worms, trojans e qualsiasi tipo di codice dannoso. * Documentazione Iritaly Visualizzabile dal menù in modalità grafica. * Connettività L' ambiente generato da Iritaly CD consente di connettere in rete il sistema tramite DH o configurazione manuale dell'interfaccia di rete. Requisiti di sistema - macchina Intel x86 compatibile - 68 MB RAM - scheda video che i risoluzione di 800x600 e frame buffer VESA - mouse, per utilizzo del sistema grafico Interfaccia CD IRItaly CD può essere avviato in modalità grafica o testuale tramite un menu di selezione presente al boot del cd. La modalità testuale è più restrittiva, non permette l'esecuzione di tool grafici importanti e richiede la di root 'firefire'. La modalità grafica mette invece a disposizione tutti gli strumenti, sia testuali che grafici. Il sistema X Windows utilizza black box ed è stato configurato un menu col quale raggiungere rapidamente le applicazioni di uso più comune presenti all'interno del cdrom. Strumenti disponibili Gli strumenti più popolari contenuti in IRItaly CD sono: * Nessus, Nmap, whisker, hping2, hunt, fragrouter * Ethereal, Snort, tdump, ettercap, dsniff, airsnort * chkrootkit, F-Prot * Sleuthkit, Autopsy Pagina 321 di 334

* Testdisk, fdisk, gpart * SSH (client e Server), VNC (client e server) * Glimpse e Glimpseserver * Mozilla, ircII, mc, Perl, biew, fenris, gpg Una lista più completa degli strumenti presenti sul cdrom, divisa per tipologie di utilizzo: - Base OS bsed burneye v1.0 cgrep v8.13 io curl v7.10.4 di v3.8 echoping expect fdisk gentoo v0.11.34 gpg v.1.2. Java JRE v1.4 lha links v0.9x lsof v4.66 lufs v0.8.3 macchanger v1.3.0 mc minicom v2.00 Mozilla v0.9.8 partimage v0.6.2 perl 5.8.0 ppp rd v0.9.2 r rpcinfo secure-delete v2.3 snmputils Sonar v1.0BETA sshd v3.1p tdump v3.7.1 telnetd TestDisk v4.4 tftpd upx v1.24 w3m v0.4.1 webfsd v1.19 wipe v2.0 - Forensic/Data REcovery Pagina 322 di 334

AIDE v0.9 argus Autopsy v1.7.4 biew v5.3.2 bsed bwplot chkrootkit v0.40 CmosPwd v4.2 cryptcat dcfldd - (or edd, enhanced dd) dsniff tools v2.3 editreg ethereal v.0.9.11 fatback v1.3 fenris v0.3 foremost v0.64 FTimes v3.2.1 gpart 0.1h hbd v0.2.3 hexedit v1.2.1 LDE - Linux Disk Editor v2.5 logdump v1.0 MAC Daddy mac-robber v1.0 memfetch v0.04b ngrep v1.40 ol2mbox - libPST v1.0.4 - libDBX v1.0.3 partimage v0.6.2 perl 5.8.0 photorec v1.0 pwl9x v0.07 rda v0.2.1 rec (reverse engineering compiler) ree v1.3 snort v2.0 ssldump v0.9b3 StegDetect v0.5 Sleuthkit 1.65 tdstat tdump v3.7.1 tflow v0.20 treplay v1.4 tslice v1.2a1 ttrace v6.2.0 TestDisk v4.4 The Sleuth Kit v1.61 TNEF v1.2.0 VNC Pagina 323 di 334

wipe v2.0 - Incident Response AIDE v0. AINTX angst v0.4b argus Autopsy v1.7.1 biew v5.3.2 bsed bwplot centurion chkrootkit v0.40 CmosPwd v4.2 cryptca ddos-scan dsniff tools v2.3 etherape v.0.8. ettercap v0.6a gpart 0.1h hbd v0.2.3 hexedit v1.2.1 hogwash v0. iptraf v2.4.0 ish_detect v0.1 LDE - Linux Disk Editor v2.5 logdump v1.0 lsof v4.66 MAC Daddy mac-robber v1.0 md5deep v0.16 memfetch v0.04 MemTest86 v2. mtool ngrep v1.40 p0f v1.8.3 PHoss v0.1.13 rec (reverse engineering compiler) rid v1.11 Sentinel v0.91beta snort v2.0 Sonar v1.0BETA4 stunnel v4.03 tdstat tdump v3.7. tflow v0.20 treplay v1.4 tslice v1.2a1 Pagina 324 di 334

ttrace v6.2.0 ttraceroute v1.4 TCT v1.11 TCT The Sleuth Kit v1.6 trafshow v3.1 VNC VNCrack v0.1.17 BETA w3m v0.4.1 - Static Linked Binary AIDE v0.9 lsof v4.66 mac-robber v1. memfetch v0.04b The Sleuth Kit v1.61 - Virus Scanning F-Prot Virus Scanner Strumenti per Win32 Il contenuto, presente nella directory /win32, è strutturato nel seguente modo: /Acquisition /Encase 3.19 (Encase Acquisition Mode V 3.19) /Forensic acquisition utilities (dd, md5sum, netcat, volume_dump, wipe.) /Net WinPcap_3_0_a2.exe(WinPcap: the Free packet Capture Architecture) spade114.exe(Sam Spade is a freeware network query tool) ethereal-setup-0.9.6.exe dumpel.exe (dump log form local or sever in a text file) /Pgp PGPFW703.zip (PGP Freeware Version 7.0.3 for Windows 95, 98, Millenium, NT, and Windows 2000 (no Windows XP) PGP_Hotfix0904_Win32.zip PGPfreeware703Hotfix1.zip PGP 8.0 (PGP Freeware Version 8 for Windows 98, Millenium, NT, and Windows 2000) /Windows 2000 Scripts di analisi del sistema per Windows 2000 /Windows NT Scripts di analisi del sistema per Windows NT /Windows XP Scripts di analisi del sistema per Windows XP /Win32 /AINTX http://www.dwam.net/docs/aintx/ (Unix Commands for Windows) /System analizer fred.bat (scrive un file di analisi del sistema) Pagina 325 di 334

listmodules.exe(visualizza i file/moduli usati da un pid) procinterrogate.exe (analogo di listmodules) winrelay.exe strace-0.1.zip (analizza le chiamate di sistema) acltools(Permettono di modificare gli utenti e i gruppi del sistema) diskinvestigator (http://www.theabsolute.net/sware/dskinv.html) /TestDisk /Biew /SysInternal (utilità di sistema) /Ntsecurity (http://ntsecurity.nu/toolbox/) /Foundstone-forensic /Foundstone-Tools Esempio d’uso di IRItaly CD In questa sezione verrà descritto un caso pratico d'uso del CD. Viene supposto di dover eseguire un' analisi forense di un disco presente sul sistema compromesso. Per motivi di integrità dei dati il disco verrà installato come disco slave (hdb), la destinazione dell'immagine sarà un ulteriore disco (hdc) presente sul canale secondario. Generazione dell' immagine Una volta che Iritaly CD avrà terminato il caricamento, è possibile procedere con la generazione dell' immagine; per ulteriori dettagli in merito a queste operazioni consultare la Documentazione di Iritaly presente sul CD. Esempio d' uso del comando dd per la duplicazione del disco compromesso: # dd if=/dev/hdb of=/dev/hdc nel caso in cui sia necessario generare un' immagine forense da importare in Autopsy: # dd if=/dev/hdb of=/root/immagine.dd Utilizzo dell' immagine generata - autopsy Effettuata l'immagine del disco compromesso, questa potrà essere importata in Autopsy per la relativa analisi. Per lanciare Autopsy digitare in uno dei quattro terminali a disposizione: # autopsy In questo modo viene eseguito il programma. In output è fornito l'indirizzo che permetterà l' esecuzione in modalità grafica tramite browser. Avviare Mozilla dal menù grafico e incollare il link nella barra degli indirizzi. A questo punto è possibile creare un nuovo caso compilando gli appositi campi e importando l'immagine generata in precedenza. Per comprendere il funzionamento dello strumento leggere la Documentazione di Iritaly relativa Pagina 326 di 334

ad Autopsy. Salvataggio dei log Autopsy genera una grande quantità di log per permettere la riscostruzione di ogni o dell' analisi compiuta. Una volta terminata l'investigazione i file generati saranno presenti nella directory: /data/nomedelcaso I log generati possono essere salvati su dischi rigidi presenti nel sistema, ovviamente non quelli di analisi, nonchè su dispositivi USB (scelta consigliata). Il menu grafico fornisce uno script che monta in automatico sia periferiche USB 1 che USB 2. Se tale script non dovesse funzionare procedere come segue: Inserire il device USB nell' apposita porta e digitare in console: # mount /dev/sda1 /destinazione dove "destinazione" è la directory a cui verrà agganciato il contenuto del device USB. Ora è possibile salvare i dati in "destinazione". Terminata tale operazione smontare il device: # umount destinazione Ringraziamenti Tutto il team di Incident Response Italy Links Incident Response Italy Website http://www.iritaly.org/ F.I.R.E. (Forensic e Incident Response Enviroment Bootable CD) http://fire.dmzs.com/

Pagina 327 di 334

APPENDICE B Principi legali di comportamento nella corretta acquisizione delle prove nel c.d. “incident response” In questo documento si evidenziano in maniera molto sintetica alcuni principi basilari, più di buon senso che strettamente giuridici, che qualunque operatore del settore dovrebbe conoscere assolutamente a memoria. 1.

Prove documentali: U

Le prove acquisite nel corso delle analisi secondo il nostro diritto sono da considerarsi come prove documentali, e conseguentemente seguono il regime delle medesime per quanto concerne la valenza probatoria e l’acquisizione – eventuale – in un giudizio. Ovviamente nulla vieta che un “fatto”, che verrebbe evidenziato da una analisi su macchine compromesse, non possa anche essere oggetto (sempre nei limiti di ammissibilità del mezzo istruttorio) di una prova testimoniale, ovvero il soggetto che abbia operato potrebbe essere chiamato a testimoniare sulle risultanze della propria attività. 2.

Non alterabilità delle prove: U

Nel documento sopra menzionato è stata ampiamente trattata la materia concernente la corretta acquisizione e manutenzione dei i contenenti sia direttamente le c.d. “evidenze informatiche”, sia i i sui quali siano eventualmente state effettuate delle analisi. Il tecnico dovrà ragionare cercando sempre di attuare una sorta di “gioco delle parti”; dovrà essere sempre in grado di poter rispondere con certezza alla domanda che egli stesso (qualora fosse il tecnico di controparte) porrebbe al fine di insinuare il dubbio sistematico su quanto sia stato eventualmente eseguito. Esiste un altro modo di condurre la procedura? Se si per quale motivo è stata scelta una procedura piuttosto che un’altra? … Inoltre occorrerà sempre tenere presente che – in caso di giudizio – l’attività dell’avvocato di controparte consisterà principalmente nel mettere sistematicamente in dubbio tutta l’attività svolta nel caso di un “incident response”, per cui quanto appena scritto si rafforza ulteriormente. In questo senso, suggerisco di seguire alcune semplici regole: a. Non effettuare mai alcuna indagine sul o originario, ma sempre su una copia di “dump”. b. Non effettuare alcun intervento di analisi singolarmente, ma sempre in presenza di almeno un testimone qualificato, ovvero di un soggetto con adeguata formazione tecnica che possa testimoniare sulla esecuzione di determinate procedure. c. Utilizzare per quanto possibile strumenti (tipicamente videocamere, ma non solamente) che registrino tutta l’attività, nessuna esclusa, eventualmente riprendendo l’attività medesima da più angolazioni. d. Verbalizzare, al termine dell’attività, quanto si è compiuto, e sottoscrivere il documento insieme agli eventuali testimoni. Pagina 328 di 334

e. Conservare nella maniera più accurata possibile quanto appena descritto, curando in particolar modo che tali documenti non possano essere alterati nel tempo. 3.

Liceità dell’acquisizione della prova. U

Occorre tenere presente che nel processo civile e penale vigono regole diverse per quanto concerne la raccolta delle prove, per cui – semplificando di molto il discorso – nel processo penale le prove acquisite attraverso una attività che possa essere considerata come reato NON SONO ammissibili, mentre la medesima regola non vige nel processo civile. Poiché è abbastanza facile che si possa compiere un reato (ovvero, più esattamente, che questa possa essere l’obiezione che si solleva, con conseguente assoluta inutilizzabilità delle prove raccolte qualora l’eccezione venisse accolta) ritengo che, prima di “esternare” qualunque risultanza della propria attività, si debba agire di concerto con il team legale, al fine di valutare con estrema attenzione cosa “evidenziare” all’esterno, previa accurata analisi del report effettuato. Il rischio non è solamente quello di non vedere ammesse le prove raccolte, ma di essere incriminati per qualche reato commesso. Un esempio pratico può rendere meglio il concetto: non è lecito sottoporre a controllo l’apparecchio telefonico del coniuge anche se al fine di scoprire se il medesimo stia commettendo un adulterio. Inoltre occorre ricordare che dal 2001 esiste in Italia una legge sulle c.d. “indagini difensive”, che ammette lo svolgimento di indagini anche al fine di “prevenire” dei reati, quindi non solamente dopo che i reati siano stati commessi. Però, in unione con il t.u. delle leggi di pubblica sicurezza, tale legge non ammette che vengano svolte investigazioni se non dall’avvocato nominato ovvero dall’investigatore privato nominato. Ricordo inoltre che – sempre ai sensi del t.u. appena citato – è reato svolgere investigazioni senza essere – appunto – un investigatore privato. Un modo abbastanza semplice per ovviare alla situazione è farsi nominare coadiutore tecnico dell’investigatore medesimo, il quale sottoscriverà il rapporto, anche se questo sarà stato – di fatto – eseguito dal tecnico, sotto il diretto controllo dell’investigatore nominato (o dell’avvocato). Al contrario, il medesimo principio di “divieto” non esiste nel processo civile, per cui – di volta in volta – occorrerà effettuare una scelta “strategica” per decidere attraverso quale strumento “legale” perseguire l’attacker. L’attività di investigazione privata – Le c.d. indagini difensive – ecc.35 TP

PT

La prima cosa che viene in mente è l’investigazione privata, poiché l’attività che essi svolgono sembra essere in tutto e per tutto assimilabile a questa, quello che eventualmente risulta differente sono soltanto i mezzi utilizzati. Bisogna quindi solamente vedere se tali soggetti possano rientrare nella categoria suddetta. L’attività di investigazione privata, nel nostro ordinamento è disciplinata dalla legge di P.S. n. 773/31 e dal regolamento n. 365/40 che specificano soprattutto i limiti e gli adempimenti da porre in essere da parte di questi soggetti.36 TP

35 TP

PT

TP

36 PT

PT

Le parti che seguono sono state tratte dal “Manuale di Security Management” di Dario Forte e Luca de Grazia Abbiamo trattato questa figura in maniera più ampia nel capitolo due.

Pagina 329 di 334

In questa sede è importante avere solamente alcune nozioni di base, e quindi conoscere l’esatta portata, per esempio, dell’art. 13437 del Testo Unico di P.S. n. 773/31, e la giurisprudenza in merito. TP

PT

Il dettato della norma ci sembra abbastanza chiaro ed univoco: “… è vietato eseguire investigazioni o ricerche o di raccogliere informazioni per conto di privati..”, e la giurisprudenza appare porsi nel medesimo solco abbastanza restrittivo: Per fortuna da qualche tempo è stata introdotta anche nel nostro sistema giuridico la legge n.7 dicembre 2000, n. 397, c.d. sulle “investigazioni difensive”, attraverso la quale la parte privata (in particolare sia l’imputato, sia il “possibile” imputato, sia la parte offesa (ovvero il soggetto giuridico che ha subito le conseguenze del reato) possono svolgere delle investigazioni per proprio conto e, quel che più conta, il risultato di tali investigazioni può essere utilizzato nel processo come fonte di prova, come per esempio dimostrato dall’articolo riportato in nota38. Di notevole importanza è poi l’articolo 391-nonies C.P.P.39, che prevede la possibilità di svolgere attività investigativa da parte del soggetto privato in via preventiva, in altre parole senza che necessariamente sia avvenuto un reato. Tale possibilità va ovviamente coordinata con quanto statuito dal TU PS sopra richiamato, per cui il discorso risultante dovrebbe essere quello della necessità per il Security Manager di poter fornire adeguato o tecnico al proprio avvocato o investigatore privato professionista che stiano – appunto – ricercando delle prove a favore del comune Cliente. Il nocciolo del problema, rimane, a parere di chi scrive, comprendere da un punto di vista “legale” le attività svolte dal “tecnico”, e viceversa, al fine di poter giungere ad un assetto del sistema informatico conforme ai criteri di sicurezza “tecnici” richiesti, ma altrettanto “compliant” con le TP

PT

TP

TP

37

PT

PT

Art. 134 TU n.773/1931. Senza licenza del Prefetto è vietato ad enti o privati di prestare opere di vigilanza o custodia di proprietà mobiliari od immobiliari e di eseguire investigazioni o ricerche o di raccogliere informazioni per conto di privati. Salvo il disposto dell'art. 11, la licenza non può essere conceduta alle persone che non abbiano la cittadinanza italiana ovvero di uno Stato membro dell'Unione europea o siano incapaci di obbligarsi o abbiano riportato condanna per delitto non colposo. (1) I cittadini degli Stati membri dell'Unione europea possono conseguire la licenza per prestare opera di vigilanza o custodia di beni mobiliari o immobiliari alle stesse condizioni previste per i cittadini italiani. (2) La licenza non può essere conceduta per operazioni che importano un esercizio di pubbliche funzioni o una menomazione della libertà individuale. (1)Comma modificato dall'art. 33, l. 1° marzo 2002, n. 39. (2) Comma aggiunto dall'art. 33, l. 1° marzo 2002, n. 39. 38 Art. 391-sexies - Accesso ai luoghi e documentazione. 1. Quando effettuano un accesso per prendere visione dello stato dei luoghi e delle cose ovvero per procedere alla loro descrizione o per eseguire rilievi tecnici, grafici, planimetrici, fotografici o audiovisivi, il difensore, il sostituto e gli ausiliari indicati nell'articolo 391-bis possono redigere un verbale nel quale sono riportati: la data ed il luogo dell'accesso; le proprie generalità e quelle delle persone intervenute; la descrizione dello stato dei luoghi e delle cose; l'indicazione degli eventuali rilievi tecnici, grafici, planimetrici, fotografici o audiovisivi eseguiti, che fanno parte integrante dell'atto e sono allegati al medesimo. Il verbale è sottoscritto dalle persone intervenute. 39 Art. 391-nonies Attività investigativa preventiva. 1. L'attività investigativa prevista dall'articolo 327-bis, con esclusione degli atti che richiedono l'autorizzazione o l'intervento dell'autorità giudiziaria, può essere svolta anche dal difensore che ha ricevuto apposito mandato per l'eventualità che si instauri un procedimento penale. 2. Il mandato è rilasciato con sottoscrizione autenticata e contiene la nomina del difensore e l'indicazione dei fatti ai quali si riferisce. TP

PT

TP

PT

T

T

TP

HTU

PT

T

UTH

T

HTU

UTH

Pagina 330 di 334

normative di tipo legale. Si tratta di un tema che probabilmente verrà approfondito in altra pubblicazione. Cosa fare in caso di attacco ricevuto E’ sicuramente fondamentale che le procedure, come detto prima, siano state pianificate in precedenza e, ovviamente, “metabilizzate” mediante delle opportune esercitazioni, anche effettuate nell’ambito di una procedura di auditing. Di seguito alcuni consigli sulle operazioni piu’ importanti da compiere: Le procedure devono essere state approvate dal management. Ogni operazione effettuata deve riportare, anche in via riepilogativa, l’indicazione del manager che l’ha autorizzata; solitamente anche la modulistica viene approntata in via preventiva. Il formato elettronico della modulistica viene di solito memorizzato su Cd Rom40, e tenuto pronto per qualsiasi evenienza. Identificare in tempo di pace gli interlocutori di polizia a cui rivolgersi. Per identificazione intendiamo l’acquisizione di recapiti telefonici e fax dei vari uffici, con la loro ubicazione fisica per la successiva presentazione delle denuncie/querele. Identificare in via prioritaria i consulenti/aziende esterne cui rivolgersi per eventuali forniture di servizi correlati alla pratica di incidente. Creazione immagini dischi, forensics iniziale, recovery dei dati, data collecting e quant’altro di correlato; Identificare in via prioritaria, con controllo ciclico durante la procedura, i nominativi e le funzioni aziendali delle persone autorizzate a gestire l’incidente e le informazioni ad esso relative. Solo le persone autorizzate, che firmeranno il relativo Non Disclosure Agreement, potranno accedere alle informazioni concernenti l’attacco avvenuto e ai suoi sviluppi. In realta’ la cosa migliore sarebbe creare un Incident Response Team, sottoporlo ad intense sedute di training e al quale dare l’incombenza di simulare ciclicamente un incidente, per verificare la congruita’ delle procedure. Pianificare a priori il piano di pubbliche relazioni. L’addetto alle PR o chi per lui, infatti, deve conoscere prima le informazioni che possono essere rilasciate e non. Questo e’ un must per banche e istituzioni di tipo governativo. TP

PT

Incident Handling – parte legale In questa parte cercheremo di esaminare le linee guida che devono soccorrere l’ISM 41 nella gestione dei c.d. “incidenti informatici”; in primo luogo riteniamo sia necessario sia ogni soggetto provveda a redigere un elenco ed una catalogazione delle tipologie dei c.d. “incidenti informatici”. Infatti non sempre la concezione tecnico – informatica dell’incidente coincide con quella legale; in linea di massima si può affermare che il livello minimo di allerta viene sollecitato prima da un “incidente” di mero tipo legale, per i motivi che cercherò di spiegare nel prosieguo. La schematizzazione riportata nell’immagine che segue probabilmente può essere utile a circoscrivere il problema. TP

40 TP

PT

TP

41 PT

può anche costituire allegato alla policy di sicurezza a cui si riferisce. Acronimo per Information Security Manager

Pagina 331 di 334

PT

La definizione di “incidente” 1. Definizione da un punto di vista “tecnico” 2. Definizione da un punto di vista “procedurale” 3. Definizione da un punto di vista “legale” G li obblighi e i diritti

1. Verso i terzi 2. Verso i dipendenti

-Clienti - Fornitori - Utenti - Assicurazioni - Autorità !!! - ecc.

-Controllo a distanza -Responsabilità per fatto di altri -Problem i sindacali -Litigiosità aziendale -ecc.

3. Verso l’azienda

-Danno im m agine -Perdita inform azioni -Spionaggio -Interruzione servizio - ecc.

Riteniamo che sia importante chiarire che un “incidente informatico”, che può assumere le più diverse forme (fermo macchina, sospensione e/o interruzione di un servizio, denial of service, diffusione di “virus”, danneggiamento informatico, ecc. ecc.) è portatore di varie responsabilità da parte di chi lo subisce, nel senso che a seguito di tale incidente sorgono diritti e doveri nei confronti di vari soggetti, indicati in maniera esemplificativa nella diapositiva sopra riportata. Cercando di andare più nel dettaglio, è opportuno tenere presente che in queste situazioni vanno a collidere due interessi che sembrano – a prima vista – completamente antitetici l’uno all’altro, in altre parole la necessità di intervenire il più presto possibile per ripristinare la situazione precedente all’incidente stesso, e la necessità di non prestare il fianco – manomettendo le evidenze informatiche che eventualmente abbiano subito un attacco da parte di terzi – a tutta la sequela di eccezioni che potrebbero essere sollevate (sempre da un punto di vista giuridico, che in questo caso non potrebbe non far leva su quelle che sono le risultanze di un’indagine sull’oggetto informatico compromesso) da parte del soggetto che si veda “imputato” dell’attacco stesso. In altre parole, da una parte occorre “non toccare niente”, mentre dall’altra è opportuno intervenire con la massima sollecitudine al fine di porre rimedio al “problema”. A prima vista questo potrebbe apparire un problema di poco conto, ma riteniamo che chiunque si sia trovato in una reale situazione di “allarme rosso” possa ben comprendere quanto le problematiche siano in linea di massima incompatibili. Analizzando prima di tutto i rapporti con i terzi, si può citare – tra i tanti obblighi specificatamente imposti dalla legge – quello di avvisare l’assicuratore del sinistro entro un determinato termine 42 ovvero dalla possibilità che un qualunque incidente informatico possa TP

PT

42

Art. 1913 - Avviso all'assicuratore in caso di sinistro. [I]. L'assicurato deve dare avviso del sinistro all'assicuratore o all'agente autorizzato a concludere il contratto, entro tre giorni da quello in cui il sinistro si e' verificato o l'assicurato ne ha avuto conoscenza. Non e' necessario l'avviso, se l'assicuratore o l'agente autorizzato alla conclusione del contratto interviene entro il detto termine alle operazioni di salvataggio o di constatazione del sinistro. [II]. Nelle assicurazioni contro la mortalita' del bestiame l'avviso, salvo patto contrario, deve essere dato entro ventiquattro ore. TP

PT

Pagina 332 di 334

essere considerato come elemento fondamentale e costituente un aggravamento del rischio, con tutte ciò che ne può conseguire 43. TP

PT

Cenni all’attività d’investigazione privata La prima cosa che viene in mente è l’investigazione privata, poiché l’attività che essi svolgono sembra essere in tutto e per tutto assimilabile a questa, quello che eventualmente risulta differente sono soltanto i mezzi utilizzati. Bisogna quindi solamente vedere se tali soggetti possano rientrare nella categoria suddetta. L’attività d’investigazione privata, nel nostro ordinamento è disciplinata dalla legge di P.S. n. 773/31 e dal regolamento n. 365/40 che specificano soprattutto i limiti e gli adempimenti da porre in essere da parte di questi soggetti. In Italia per svolgere tale attività è richiesta la preventiva licenza della competente Prefettura in cui ha sede l’Istituto d’investigazione, se questa è svolta professionalmente e in modo continuativo, e poi tutta una serie di requisiti che devono essere in possesso dei soggetti che materialmente operano, stabiliti dall’art. 134 del R.D. n. 773/3144: Non essere sottoposto a sorveglianza speciale o misure di sicurezza essere cittadino italiano non aver riportato condanne penali per delitto non colposo dimostrare di possedere la necessaria capacità tecnica non aver subito con provvedimento definitivo l’applicazione di una misura di prevenzione Dato importante è poi costituito dal fatto che nella domanda deve essere indicato il Comune o i Comuni nei quali si intende svolgere l’attività, in quanto la licenza è valida solo per questi, determinandosi al contrario l’esercizio di un’attività abusiva. La licenza è inoltre valida solo per un anno dovendosi poi rinnovarla con richiesta specifica. TP

43

PT

Art. 1898 Aggravamento del rischio. [I]. Il contraente ha l'obbligo di dare immediato avviso all'assicuratore dei mutamenti che aggravano il rischio in modo tale che, se il nuovo stato di cose fosse esistito e fosse stato conosciuto dall'assicuratore al momento della conclusione del contratto, l'assicuratore non avrebbe consentito l'assicurazione o l'avrebbe consentita per un premio piu' elevato. [II]. L'assicuratore puo' recedere dal contratto, dandone comunicazione per iscritto all'assicurato entro un mese dal giorno in cui ha ricevuto l'avviso o ha avuto in altro modo conoscenza dell'aggravamento del rischio. [III]. Il recesso dell'assicuratore ha effetto immediato se l'aggravamento e' tale che l'assicuratore non avrebbe consentito l'assicurazione; ha effetto dopo quindici giorni, se l'aggravamento del rischio e' tale che per l'assicurazione sarebbe stato richiesto un premio maggiore. [IV]. Spettano all'assicuratore i premi relativi al periodo di assicurazione in corso al momento in cui e' comunicata la dichiarazione di recesso. [V]. Se il sinistro si verifica prima che siano trascorsi i termini per la comunicazione e per l'efficacia del recesso, l'assicuratore non risponde qualora l'aggravamento del rischio sia tale che egli non avrebbe consentito la assicurazione se il nuovo stato di cose fosse esistito al momento del contratto; altrimenti, la somma dovuta e' ridotta, tenuto conto del rapporto tra il premio stabilito nel contratto e quello che sarebbe stato fissato se il maggiore rischio fosse esistito al tempo del contratto stesso. 44 Art. n. 134 R.D. 773/31 - Senza licenza del Prefetto è vietato ad enti o privati di prestare opere di vigilanza o custodia di proprietà mobiliari od immobiliari e di eseguire investigazioni o ricerche o di raccogliere informazioni per conto di privati (114). Salvo il disposto dell'art. 11, la licenza non può essere conceduta alle persone che non abbiano la cittadinanza italiana o siano incapaci di obbligarsi o abbiano riportato condanna per delitto non colposo. La licenza non può essere conceduta per operazioni che importano un esercizio di pubbliche funzioni o una menomazione della libertà individuale TP

PT

TP

PT

T

T

Pagina 333 di 334

L’autorizzazione può essere richiesta sia da un privato sia da una società, in questo caso in persona del legale rappresentante che si assume la piena responsabilità in ordine all’attività esercitata. Altri e più specifici obblighi di comportamento sono poi stabiliti dagli articoli seguenti del R.D. in ordine agli adempimenti, ai registri e alle cauzioni da versare45. Dell’attività d’investigazione privata svolta professionalmente si è anche occupato il legislatore per la necessità di coordinarla con la L. 675/96, con l’Autorizzazione n. 6/2000 al trattamento d’alcuni dati sensibili da parte degli investigatori privati, e questo soprattutto a seguito delle modifiche che sono intervenute nel codice penale che hanno riconosciuto un più largo campo d’azione a questi soggetti nella ricerca di fonti di prova atti a consolidare le tesi della difesa nel processo penale. Il nocciolo della nuova disciplina risulta quindi essere questo: TP

PT

TP

PT

quando l’investigatore privato svolge la sua opera professionalmente e al fine di acquisire informazioni utili per far valere o difendere un diritto in sede giudiziaria, dispone di una serie di deroghe alla legge n. 675/96; mentre se le investigazioni sono svolte per fini diversi, ossia come reperimento di dati e notizie che non hanno un esplicito riferimento ad un’attività giudiziaria, al soggetto è applicata integralmente la disciplina dettata a tutela dell’altrui riservatezza della legge in questione. Per quanto riguarda espressamente le deroghe alla 675/96 esse vertono in tema di notificazioni al Garante, autorizzazioni dello stesso, di consenso al trattamento dei dati personali da parte dell’interessato. Per quanto riguarda, invece, l’attività d’investigazione per fini diversi da quelli sopra specificati, il trattamento dei dati raccolti durante detta attività sarà in tutto e per tutto soggetto alla normativa prevista dalla L. 675/96, e quindi l’investigatore privato potrà procedere al trattamento dei dati solo con il consenso scritto dell’interessato e se i dati sono sensibili, con l’autorizzazione del Garante. Ora ritornando all’attività di qualsiasi soggetto che esegua un determinato tipo d’attività di “reperimento informazioni”, sembra potersi affermare che qualora questi sia materialmente incaricato di verificare la sicurezza di un sistema informatico si comporti materialmente come un vero e proprio investigatore privato, solo che per farlo utilizza strumenti informatici. Ci si pone quindi una domanda su quale sia la posizione e quali sono le regole che si devono rispettare nell’espletare tale attività e quali i limiti. Non essendo IRItaly un documento di mera impostazione legale, si rimanda eventualmente ad una trattazione abbastanza approfondita si trova nel Manuale46 citato. TP

PT

45

Art. 137 R.D. 733/31 - Il rilascio della licenza è subordinato al versamento nella cassa depositi e prestiti di una cauzione nella misura da stabilirsi dal Prefetto. La cauzione sta a garanzia di tutte le obbligazioni inerenti all'esercizio dell'ufficio e della osservanza delle condizioni imposte dalla licenza. Il Prefetto, nel caso di inosservanza, dispone con decreto che la cauzione, in tutto o in parte, sia devoluta all'erario dello Stato. Lo svincolo e la restituzione della cauzione non possono essere ordinati dal Prefetto, se non quando, decorsi almeno tre mesi dalla cessazione dell'esercizio, il concessionario abbia provato di non avere obbligazioni da adempiere in conseguenza del servizio al quale l'ufficio era autorizzato 46 Manuale di Information Security Management TP

PT

TP

PT

Pagina 334 di 334