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 supporti 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 Readme 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 download 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à, download).

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 download 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
supporto ha avuto un ruolo fondamentale.
IRItaly incoraggia i feedback da parte di utenti, sviluppatori, legali e law enforcement. Questo supporto
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 supportare 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.
Feedback 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 Supporti 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 TcpTraceroute ............................................................................................................. 54
1.3.2.4 Hogwash...................................................................................................................... 56
1.3.2.5 TCPdump 3.7 .............................................................................................................. 57
1.3.2.6 TCPtrace 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 Password “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 supporti 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 password sui sistemi ove sia stata riscontrata un’intrusione ............................ 179
4.1.1 Password: vulnerabilità e policy ................................................................................... 179
4.1.2 Modifica password 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 supporti
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 Passi 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 – Account senza password o con password
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 – Account senza password o con password 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 passo 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 supporti 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 supporto
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 passato.

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 acceso 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 supporto originale (p.e. mettere in write-
protect i supporti che lo permettono).
L’immagine del supporto 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
registrate le testimonianze dalle forze di polizia. Le immagini sono copiate su CD-ROM che sono
supporti 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 supporti
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 download 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 Supporti Utilizzabili (Media)

I supporti 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 supporto – 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 supporto – 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.
• 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 hard-
disk); tali unità permettevano l'intercambiabilità dei piatti nella medesima unità di lettura-
scrittura. L'operatore poteva cambiare i pacchi di dischi (i cosiddetti "padelloni") mettendo
così in linea dei supporti 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

4
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 supporti;
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 supporto 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 acceso 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 supporto 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 supporti 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 supportano 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 supporto 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 passa 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 supporto magnetico e' un supporto "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 supporto 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 passaggio di corrente
sull'avvolgimento relativo a ciascun bit.
I principali tipi di supporti 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 supporto, 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 contact 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 account 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 download dell’eseguibile da Internet, all’indirizzo
http://www.pgpi.com (download PGP, GPG e tool vari).
Al momento della sua istallazione, viene richiesto di immettere un identificativo e una
passphrase che servirà a limitare l’utilizzo della chiave privata ai soli conoscitori della
passphrase 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 supporto 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 user 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 Programma Chat URL

Windows mIRC ( http://www.mirc.com )
UNIX xchat ( http://www.xchat.org )
MacOS Ircle ( 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 user (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 TCP 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 TCP/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 passante 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 passante 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 username 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 passato 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
TCP/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 audio-
video 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 TCP/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
supporto 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 useranno 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 “passo” (“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 supporta 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.

Gprs Umts
Bandalarga no Sì
Velocità max teorica 171.2 Kbps 2 048 Kbps
Velocità reale* 30 Kbps 300 Kbps
Simile ad un
Navigazione su Web modem analogico
Simile all’Adsl
Durata reale download
400 secondi 40 secondi
(1,5Mb)
Multimedialità interattiva No Sì
Streaming audio Sì Sì
Streaming video No Sì
Download Sì Sì
Videotelefonia No Sì
Qualità video A scatti Fluida
Visualizzazione 3D No Sì
Livello di interattività Near real time Real time
Popolazione attiva max** 6 000 000 (15%) 40 000 000 (100%)
Interfaccia utente dei
Testo / Grafica Video / Grafica
terminali
Applicazioni simultanee
No Sì
(multisession)
Memoria terminali > 2 MB < 8 MB
Sicurezza transazioni Bassa Alta
Integrazione satellitare No 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 bypassa 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 Windows-
Based.
Il tool è un Browser HTML in grado di visualizzare l’immagine di dischi compromessi, è in grado
di supportare 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 supportati 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 supporto 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. Supporta molte delle opzioni di agrep,
versione modificata di grep, è in grado di effettuare ricerche consentendo un numero arbitrario di
errori nel pattern inserito, supporta 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 i-
node, 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, downloading 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
 • Il nome della System Call
• I parametri in ingresso
• 3 punti (…)
• I parametri in uscita
• Il codice di ritorno

1.3.2 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 tcpdump.
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):
# tcp port 23 and host 10.0.0.5
Per la creazione dei filtri è possibile utilizzare operatori logici:
# tcp 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 tcp.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:

• tcpdump
• 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 TCP/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 tcpdump), packet logger o nids, e analizza tre tipi
di protocolli: tcp, 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
• Pass – 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 TcpTraceroute
http://michael.toren.net/code/tcptraceroute/
(GNU General Public License (GPL) for Unix)
TcpTraceroute è una implementazione di traceroute che usa TCP.
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
TcpTraceroute utilizzando quindi il protocollo TCP rende possibile la generazione del percorso
anche in presenza di normali sistemi di filtraggio.
TcpTraceroute 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 passato il flag –sS.
Sintassi:
tcptraceroute [-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 TcpTraceroute:

$ tcptraceroute -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 TCP 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
passato.
Cinque tipi base di regole da poter usare:
• pass
• drop
• sdrop
• alert
• log
pass
significa che il pacchetto è sempre buono, quindi ignora qualsiasi cosa che fa matching; l’uso
comune di una pass rule è per permettere un qualunque traffico tra sviluppatore e analisti.
Esempio: pass tcp $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 tcp $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 tcp $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 tcp $EXTERNAL_NET any -> $HOME_NET 21 (content: "site exec"; nocase;)

1.3.2.5 TCPdump 3.7

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

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.
TCPdump prevede molte importanti opzioni, così come l'abilità di specificare un'espressione per
restringere la serie di pacchetti che si desidera studiare.
Sintassi:
tcpdump [ -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 / tcp / 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, tcpdump
seleziona la prima interfaccia presente nella lista delle interfacce di sistema, escluso il
loopback)
-n non converte gli indirizzi (indirizzi di host, numeri di porto, ecc.) in nomi
-N non stampa il nome del dominio dell’host (in questo modo tcpdump 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:
- tcpdump host A
- tcpdump dst host A and \ (port ftp or ftp-data\)
- tcpdumpport smtp
- tcpdump gateway A and \(port ftp or ftp-data\)
- tcpdump net 140.123.0.0
tcpdump -i lo
(lo=interfaccia di loopback, è un dispositivo di rete virtuale che permette di riferirsi a se stesso)

Pagina 59 di 334
 tcpdump -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 tcp sull'interfaccia di rete eth0 e destinati alla porta 23
(telnet) e salvare tutto l'output su un file si può digitare:

tcpdump -i eth0 -w file tcp port 23

Digitando tcpdump -r file si visualizza l'output in maniera standard.

1.3.2.6 TCPtrace 6.2.0

http://irg.cs.ohiou.edu/software/tcptrace/download.html
Tool scritto da Shawn Ostermann per l’analisi dei file di TCPdump.
Può prendere come input file prodotti da diversi programmi “cattura pacchetti”, incluso
tcpdump, 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
TCPtrace può produrre molti tipi differenti di output, in base agli argomenti che riceve.
In primo luogo legge i relativi argomenti dal file "$$HOME/.tcptracerc" e poi dalla
variabile d’ambiente TCPTRACEOPTS, infine legge gli argomenti passati da linea di
comando .
Output Options
TCPtrace 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
Tcptrace 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 user deve passare in modalità expert (-x): in questo modo lo user 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 ).
• "not found": il comando da testare non è disponibile;
• "Vulnerable but disabled": comando infettato ma non in uso.

1.3.2.8 SSLdump 0.9b3

http://www.rtfm.com/ssldump/
Analizzatore di protocollo di rete SSLv3/TLS, identifica le connessioni TCP
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 TCPdump, 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 password ] [ 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 TCP

New TCP connection #3: localhost(3638) <-> localhost(4433)

3 1 0.0738 (0.0738) C>S Hand shake ClientHello
3 2 0.0743 (0.0004) S>C Hand shake ServerHello
3 3 0.0743 (0.0000) S>C Hand shake Certificate
3 4 0.0743 (0.0000) S>C Hand shake ServerHelloDone
3 5 0.0866 (0.0123) C>S Hand shake ClientKeyExchange
3 6 0.0866 (0.0000) C>S ChangeCipherSpec
3 7 0.0866 (0.0000) C>S Hand shake Finished
3 8 0.0909 (0.0043) S>C ChangeCipherSpec
3 9 0.0909 (0.0000) S>C Hand shake Finished
3 10 1.8652 (1.7742) C>S application_data
3 11 2.7539 (0.8887) C>S application_data
3 12 5.1861 (2.4321) C>S Alert warning close_notify
3 5.1868 (0.0007) C>S TCP FIN
3 5.1893 (0.0024) S>C TCP FIN

1.3.2.9 p0f
http://www.stearns.org/p0f/
Tool per determinare il sistema operativo, usa sei campi per il riconoscimento: window
size, TTL, opzioni TCP 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.
Supporta TCPdump 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

1.3.3 Tools immagini dei dischi 5

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=<dst>

dove, <src> e <dst> 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
TCP/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 ==> (In attesa sulla porta 30000 su <server> )

client% nc <server> 30000 ==> (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 Start End Blocks Id System
/dev/sda1 1 9 72261 83 HPFS/NTFS
/dev/sda2 10 75 530145 82 Linux swap
/dev/sda3 76 467 3148740 fd Linux raid
autodetect
/dev/sda4 468 2200 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 Start End Blocks Id System

/dev/sdb1 1 9 72261 83 HPFS/NTFS
/dev/sdb2 10 75 530145 82 Linux swap
/dev/sdb3 76 467 3148740 fd Linux raid
autodetect
/dev/sdb4 468 2200 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://users.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. User 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 user.
K Risposte date dallo user all’input.
Sono supportate 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 --verifymd5
--md5out=d:\images\PhysicalDrive0.img.md5
dd if=\\?\Volume{87c34910-d826-11d4-987c-00a0b6741049} of=d:\images\e_drive.img –md5sum
–verifymd5 md5out=d:\images\PhysicalDrive0.img.md5
dd.exe if=\\.\PhysicalMemory of=d:\images\PhysicalMemory.img bs=4096 --md5sum --verifymd5 --
md5out=d:\images\PhysicalMemory.img.md5
dd.exe if=\\.\D: of=d:\images\d_drive.img conv=noerror --sparse --md5sum --verifymd5 –
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 --verifymd5 –
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 --verifymd5 –
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 supportate6:

PCI Cards supported: SCSI Controller Cards supported:

(auto e /or manual loading) (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

6
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

• ADMTEK PCI 10/100 Series • Initio INI-9XXXU/UW

• AMD PCNet Series • Initio INI-A100U2W

• BROADCOM NetXtreme Gigabit • Symbios 53C8xx

• COMPAQ 10/100 e Gigabit PCMCIA Cards Supported:

(manual loading)
• COMPAQ Gigabit 6134/6136 (Intel)
• 3COM 3CCFE574 Family
• COMPAQ NetFlex-3
• 3COM 3CCFE575 Family
• D-LINK DFE-530TX+ 10/100 Series
• INTEL 16 BIT Series
• D-LINK DFE-550TX 10/100 Series
• INTEL 32 BIT Series
• DAVICOM PCI Based Series
• XIRCOM CE3B-100BTX (non-CardBus)
• DIGITAL 2104x/2114x 10/100 Series
• XIRCOM RealPort & Realport2 R2BEM56G-100
• HP 10/100VG

• INTEL PRO Series

• INTEL PRO/1000 Server Series

• LITE-ON PNIC-10/100 Series

• MACRONIX MX987xx Series

• NATIONAL DP83815 10/100 MacPhyter 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

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 Support

Esiste anche la possibilità di acquisire il contenuto della memoria di un computer palmare.

Palms supported
• 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 passerà 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.

1.3.4 Gestione del dump della ram 8

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 User 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 User 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 <pid> <filename>

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://users.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 --verifymd5 --
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
• Supporto Fast Ethernet
• Possibilità di connettersi con svariati tipi di media (IEEE1394, USB 2.0, UWSCSI e ATA133)
• Ulteriori supporti 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 members 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 TCP 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 Administrator 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 TcpDump/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 supporti 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, supporti 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 supporto 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 Password “robuste”

Configurazioni ottimali possono rivelarsi completamente inutili, se non sono sostenute da una
intelligente politica d’uso e creazione delle password. Esistono, infatti, programmi che
permettono ad un eventuale intruso di scoprire con una relativa facilità alcune password, 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 supporto 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 password di determinati servizi “delicati”, o addirittura la password 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 password identica allo username. La soluzione ideale è l’uso di parole alfanumeriche,
contenenti caratteri speciali e mixed-case.
Una password 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 password c$p5nt0O!.
Molte volte la precauzione di costruire una password 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 password 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 TCP 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, rlogin,
rcp) 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 TCP/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, slogin,
scp) 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 supportati da ssh (IDEA, DES, 3DES, Arcfour, Blowfish) e si passa 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 README.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 password, infatti, se se il campo
per immettere la password 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, WinSCP 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 TCP 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
password 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 supporta 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 TCP 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 supporto 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 supporta 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 download 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 supportano 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 TCP. 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:
• 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.

1.4.2.13 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 password) spesso è lasciata al valore di default “public”o
“private”. Inoltre, molte implementazioni, prevedono account 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 TCP/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 password per controllarne
l’accesso. I problemi nascono dal fatto che tali password 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 password estremamente semplici;
Pagina 90 di 334
 • impedire che le password vengano eliminate;
• impedire che le password non vengano mai cambiate;
• mantenere la segretezza delle password;
• utilizzare periodicamente degli strumenti chiamati “password scanner” per verificare la
qualità delle password (utilizzabile solo sotto autorizzazione scritta ed esplicita);
• utilizzare meccanismi che permettano la scelta della password da parte del sistema;
• utilizzo di sequenze one-time-password;
• proteggere tali password 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 password “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
 • installare patch;
• progettare l’architettura di rete e la dislocazione dei server in modo tale da confinare gli
effetti di una intrusione.

1.4.3 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 passato 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); /* per inizializzare la struttura MD5_CTX */
- void MD5_Update( MD5_CTX *c;
unsigned char *data;
unsigned long len);

/* 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:

$ cp 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
C++
• tarred & gzipped form versione 1.02.
Delphi
• supporto MD5 in una collezione di componenti Delphi
Javascript
• creata da Paul Johnston (GPL)
Miva
• Petr Kutil e Ivo Truxa
Perl5
• modulo Perl creato da Neil Winton, questa Perl Exstension richiede compilazione
aggiuntiva
PHP
• http://www.php.net/manual/en/function.md5.php

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

1.4.3.7 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/passwd
30eeb9e940c0c743682da53e41defb15 /etc/skel/.kde/Autostart/Autorun.desktop
68d9a46c4ec07ac828458815d4b3cfad /etc/skel/.kde/Autostart/.directory
d19bbbed9d713f97f487b9ed9ec3f62f /etc/skel/.bash_logout
c03dade4bb0152c9d0b6d871b4c082f4 /etc/skel/.bash_profile

Download
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, DHCP 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 (tcpdump, 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 supporti 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 Procedure di spegnimento

MS DOS
• Fotografare lo schermo e documentare i programmi che
sono attivi

• Staccare la spina dalla presa di corrente

UNIX/Linux
• 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 user root, portarsi in tale stato

digitando su –

• Se la password di root non è disponibile, staccare la

spina dalla presa di corrente

• Se la password di root è disponibile, inserirla. Al segnale

# digitare sync;sync;halt ed il sistema effettuerà lo
shutdown

• Staccare la spina dalla presa di corrente

Mac
• 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

Windows
• Fotografare lo schermo e documentare i programmi che
3.X/95/98/NT/2000/XP
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
CPU (per esempio laddove ci sia il sospetto dell’esistenza di un programma di auto-distruzione
oppure se è in fase di esecuzione la formattazione dei supporti 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:
• 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 supporti 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.

2.1.2 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 cp – 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 passi 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
supporti 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 passo 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 Id System
/dev/hda1 1 255 2048256 b Win95 FAT32
/dev/hda2 * 256 638 3076447+ 83 Linux
/dev/hda3 639 649 88357+ 82 Linux swap
/dev/hda4 650 1582 7494322+ f Win95 Ext'd (LBA)
/dev/hda5 650 1453 6458098+ b Win95 FAT32
/dev/hda6 1454 1582 1036161 b 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ù user 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 <file to be split> <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 supporti (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 read-
write 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 supporto 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 Size Used by
Loop 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 userà 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 passo 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 useranno anche alcune opzioni per rendere l’output di grep più
fruibile:
grep –options <pattern> <search_range>

Pagina 110 di 334

 Il primo passo 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 userà
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’ <image.disk1 | grep –abif searchlist.txt > 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, bypassare 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
TCP 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 TCP, si creano reazioni dipendenti dalle singole implementazioni dello stack TCP.
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 log in 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à:
Supporto 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 log in 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/passwd;
• controllare il file /etc/inetd.conf;
• se gli “r-command s” (rlogin, 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:
• 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.

2.3.5 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

 • archivi FTP;
• file nelle home directory degli utenti;
• ogni altro file di dati nel sistema.

2.3.6 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:
• Network sniffer;
• Trojan horse;
• backdoor;
• vulnerability exploit;
• altri (Denial-Of-Service, utilizzo delle risorse computazionali);
• sistemi di comunicazione con altri sistemi compromessi.

2.3.7 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 log in 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/adm/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
uploadati dall’attacker nella directory htdocs, root o / per verificare la riuscita del
defacement. È anche possibile memorizzare i website log in 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 uploadati sul sistema
dall’intruso e le informazioni downloadate 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 login, dei logout 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 login 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 account del sistema
potrebbero essere stati compromessi.
• secure
ogni volta che viene stabilita una connessione con uno dei servizi che usa un tcp 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 account e password 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 user.
È 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 password 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

2.4 Green circle17: identificazione dell’attacco ad un sistema
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à passate. 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 account 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 passato 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 supporto 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 e-
mail, 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 supportati.

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 traffico proveniente da indirizzi inaspettati o che utilizza porte o protocolli non usuali
o traffico diretto verso indirizzi imprevisti o che utilizza porte o protocolli insoliti
o 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 TCP invalidi,
numeri di sequenza errati in un pacchetto TCP, flag invalidi in un pacchetto TCP (ACK
prima di SYN), e frammenti errati. Non c'è nessuna buona ragione di violare le specifiche
IP, TCP, 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 TCP 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 TCP 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 password e ad altre informazioni non crittate
spedite sulla rete.
• traffico di DHCP/BOOTP insolito. Un intruso può usare un host per la spedizione di
risponde DHCP 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
 • uso insolito di Internet Relay Chat (IRC), un mezzo di comunicazione usato dagli intrusi.

2.4.2 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 login e il
logout, 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 (CPU, 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 (CPU, 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 CPU, 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 password 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
• account inattivi che stanno generando processi e utilizzando risorse di CPU
• 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 login/logout (ubicazione, tempo): tentativi riusciti, falliti, login tentati con
account privilegiati
• informazioni di login/logout 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 password)
• 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 login falliti e ripetuti, inclusi quelli che utilizzano account privilegiati
• login 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 password 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 password è da considerare come parte
integrante della valutazione delle vulnerabilità. Queste analisi includono l’identificazione di
password 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 password tali da effettuare la creazione non autorizzata di
nuovi account e di account senza password
• 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 supportano 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, account e informazioni relative alle password. 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
password (per esempio telnet, rlogin, 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
passaggio.
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 CPAN
(http://www.cpan.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 login e password 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, passwd e login: 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;
• tcpd, 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 #;
• .login - .logout - .prfile - .cshrc - .forward facendo attenzione a eventuali comandi “strani”;
• file in /etc/passwd controllando se esistono nuovi account, se account di sistema non sono
disabilitati come invece dovrebbero essere, se sono presenti account con uid/gid errati e/o 0 ed
infine se vi sono account vecchi con nuove password;
• inetd.conf per verificare che non siano attivati servizi non richiesti, anche se apparentemente
innocui;
• file di startup ( rc.local – sh.login – 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 tcpdump 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
password creata in fase di installazione. Sono richieste due password:

Pagina 143 di 334

 • la site password, di carattere generale, utilizzata per il file di configurazione e policies; può
essere utilizzata per altre macchine esportando il file site.key;
• la local password 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 password 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 passati, 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 passa nel cavo, fa
passare 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 TCP 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 log in 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.
22
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.
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
registrate 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 TCP 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 “TCP 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 “TCP 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 password (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 TCP 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 passaggio.

Per una chain of custody corretta è necessario:

• Tener traccia di ogni prova;
• Documentare in modo completo il passaggio di consegne da una persona a un’altra;
• Documentare in modo completo il passaggio 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, login 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/security-
improvement/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

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

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:
• tcp wrapper - http://www.cert.org/security-improvement/implementations/i041.07.html
• tcpdump - 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
 • cpm (Check Promiscuous Mode) - ftp://ftp.cerias.purdue.edu/pub/tools/unix/sysutils/cpm/
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 Administrator Tool for Analyzing Networks) -
ftp://ftp.porcupine.org/pub/security/
• saint (Security Administrator'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 account, come le informazioni

sull’autenticazione e sull’autorizzazione, sono:
• cops (Computer Oracle and Password System) -
ftp://ftp.cerias.purdue.edu/pub/tools/unix/scanners/cops/
• tiger - ftp://ftp.cerias.purdue.edu/pub/tools/unix/scanners/tiger/
• checkXusers -
http://www.rge.com/pub/security/coast/tools/unix/sysutils/checkXusers/checkXusers.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 login, tentativi
ripetuti e falliti di login, login da postazioni insolite, login 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/security-
improvement/implementations/i005.03.html
• spar (Show Process Accounting Records) - http://www.cert.org/security-
improvement/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/
• loginlog - ftp://ftp.cerias.purdue.edu/pub/tools/unix/logutils/loginlog/
• 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 Administrator Tool for Analyzing Networks) -
ftp://ftp.porcupine.org/pub/security/
• saint (Security Administrator'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 Risposta

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

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

3.2.1.7 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.
29
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.
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
passato 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
acceso, 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
Trattasi del principio della correlazione.
31
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 passi 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
registrate 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 passi 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 supporti 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 supporti 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 registrate 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 supporti 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 supporti 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 supporti 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 CPU è il contenitore originale fornito dal produttore, anche se
raramente se ne ha la disponibilità.
Se la confezione originale non risulta disponibile la CPU 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 supporto 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 supporti 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 supporti, 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 supporti 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 supporti 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 supporti di memorizzazione è necessario: vi è infatti il
bisogno di ridurre la possibilità, insita nei supporti 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 supporti 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 supporti 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 supporti 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: 6 mesi

• Media Imprese: 12 mesi
• Grandi Imprese: 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 supporti 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 Aspetti legali

3.3.6.1 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 passi 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 password sui sistemi ove sia stata riscontrata un’intrusione
La modifica delle password è un’operazione di fondamentale importanza, soprattutto nel caso in
cui si abbiano prove dell’accesso dell’intruso a password file o dell’utilizzo da parte del soggetto
di sniffer in grado di catturare password 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 password non possono essere
cambiate, bisognerà bloccare gli account compromessi e crearne di nuovi.

4.1.1 Password: vulnerabilità e policy

In questo paragrafo verranno brevemente trattati i problemi di vulnerabilità delle password 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 password 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 password di tutti i sistemi e anche far
modificare le password 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 password possono essere vittime di molteplici attacchi, tra i quali
ricordiamo:

• Guessing: le password possono essere facilmente indovinate da chi tenta di ottenere un

accesso illegittimo. Un metodo per prevenire questa tipologia di attacchi è quello di
scegliere una password robusta;

• Snooping: le password 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 password in rete;

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

Va ricordato che una delle maggiori cause di vulnerabilità delle password è rappresentata dalla
scelta e dalla gestione delle stesse da parte degli utenti.

I comportamenti errati degli utenti possono essere così schematizzati:

• le password non vengono quasi mai modificate;

• le password vengono condivise con colleghi;

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

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

• le password vengono annotate su fogli di carta, agende per non dimenticarle.

Pagina 179 di 334

Le Password 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
password policy insufficiente. Questi includono anche problemi di denial-of-service e di
formazione degli utenti.

E’ necessario ricordare, nella stesura di una password 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 password policy devono essere in accordo con questioni
legali e devono essere elastiche e reattive ai cambiamenti aziendali.

E’ importante, nella redazione di una password 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 password 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 password dovrebbe essere redatta considerando tutti gli aspetti
sopra citati, ossia le vulnerabilità alle quali sono soggette le password, il comportamento degli
utenti, gli asset aziendali e il trade-off costi/benefici.

Una policy delle password dovrebbe considerare le seguenti linee guida:

• Lunghezza: una password dovrebbe essere di almeno 8 caratteri e comprendere caratteri

speciali;

• Complessità: dovrebbe essere richiesto, nella fase di creazione della password, l’utilizzo di
un mix di caratteri. Le password 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 password dovrebbero essere periodicamente modificate dagli utenti (almeno ogni
30-120 giorni);

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

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

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

• Riutilizzo: spesso gli utenti, se obbligati a modificare la password, tendono a riutilizzare le

password già usate in precedenza, bisognerebbe poter proibire questo comportamento agli
utenti;

Pagina 180 di 334

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

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

• Conservazione: le password 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 password dovrebbe considerare la possibilità degli amministratori di
settare a priori dei controlli sulle caratteristiche delle password, dovrebbero essere perciò
previste:
• restrizioni sulla lunghezza e sul numero minimo di caratteri da utilizzare;

• obbligatorietà di inserire nella password 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
password;

• scadenza della password, onde obbligare gli utenti ad una modifica periodica;

• controllo sulla storia recente delle password utilizzate, onde evitare la ripetizione delle
stesse da parte degli utenti
Infine, bisogna ricordare che la password 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 password e creazione di una semplice policy

In questo paragrafo verranno analizzate la creazione di un utente, la modifica della password ed il
settaggio di una password 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 password 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 account 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 passi 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:

• User name: login che verrà utilizzata dall’utente durante l’autenticazione al

sistema;

• Nome completo;

• Descrizione;

• Password: si segnala che è possibile impostare una password contenente un

massimo di 127 caratteri.

5. Selezionare o deselezionare le seguenti caselle di controllo:

• Cambiamento obbligatorio password all'accesso successivo: obbliga l’utente

a modificare la password al primo login. Permette all’amministratore di
impostare password “standard”, facilitando la comunicazione delle
credenziali di accesso a molteplici utenti;

• Cambiamento password non consentito: non permette all’utente di modificare

la propria password;

• Nessuna scadenza password;

• L'account è disattivato.

Pagina 182 di 334

 Figura 23: Proprietà utente

Per modificare le password di un utente, un amministratore, deve effettuare i seguenti passi:

1. Aprire Gestione computer

2. Nella struttura della console in Utenti e gruppi locali fare clic su Utenti.

3. Selezionare l'account utente da modificare.

4. Scegliere Impostazione password dal menu Azione.

Per impostare una password 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 password : 10 caratteri;

• criterio relativo al riutilizzo: non consentire l’utilizzo delle ultime 10 password;

• scadenza password: 40 giorni;

• complessità password: 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 Password Policy.
In figura 23 si può notare l’alberatura del Security Template esplosa nella parte relativa alle
Account Policy, dove si trova la Policy di nostro interesse.

Figura 24: Security Template

La figura 24, mostra il dettaglio della Password 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 password policy sono:
• storia delle password utilizzate precedentemente;
• età massima delle password;
• età minima delle password;
• lunghezza minima delle password;
• complessità delle password;
• utilizzo di reversibile encryption delle password.

Pagina 185 di 334

 Figura 26: Password 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 “Password shadow” e
analizzeremo brevemente le differenze con /etc/passwd.
Il meccanismo delle password shadow si basa su un principio molto semplice: nascondere le
password cifrate ai processi che non hanno i privilegi dell'utente root. Infatti, nei sistemi in cui
le password shadow non sono attivate, è il file /etc/passwd, leggibile a tutti i tipi di utenti, che
contiene tali le password cifrate.
Il formato del file /etc/passwd non “oscurato” è il seguente:
utente:pwd:UID:GID:nome_completo:directory:shell

dove:

• utente: login dell’utente;

• pwd: password 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 login dell'utente (percorso completo).

Se si utilizza la shadow suite, il formato del file /etc/passwd non cambia, ma non contiene più
la password 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: login dell'utente;

• pwd_cifrata: password cifrata;

• mod: data di ultima modifica della password (espressa in numero di giorni trascorsi dal
01/01/1970);

• val_min: numero di giorni di validità minima della password; entro questo periodo, l'utente
non può cambiarla;

• val_max: numero di giorni di validità massima della password; 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 password;

• tempo_riserva: durata massima di validità dell’account dopo la scadenza della

password;

• scad: data di scadenza dell’account (espressa in numero di giorni trascorsi dal

01/01/1970);

• ris: campo riservato per usi futuri.

Si procederà ora con un esempio esplicativo, come effettuato per la parte Microsoft, di creazione
dell’utente e di gestione di una password policy.
Per creare un utente si utilizza il comando useradd. Tramite questo comando, si possono anche
modificare le impostazioni predefinite dell’utente.
Vengono effettuate differenti operazioni:
• visualizzazione delle impostazioni predefinite dell’utente: useradd –D

Figura 27: useradd -D

• modifica delle impostazioni predefinite, settando il gruppo predefinito (-g100) a 100, la
scadenza dell’account al 7 gennaio 2004 (-e07/01/04) e il fatto di non voler bloccare
Pagina 187 di 334
 l’account in caso di scadenza della password (-f0): useradd –D –g100 –e07/01/04 –
f0

Figura 28: modifica delle impostazioni predefinite di useradd

• Creazione dell’utente “iritaly”: useradd –c “IRItaly” iritaly

Figura 29: creazione utente

In figura 30, si può vedere il record creato nel file /etc/passwd e si nota la “x” al posto della
password.

Figure 30: /etc/passwd

Nel file /etc/shadow, (figura 31), si può notare che il record relativo all’utente creato non ha
ancora la password impostata (al posto della password si trova “!!”), si procede perciò ad inserire
una password per quest’utente.

Figure 31: /etc/shadow

Pagina 188 di 334

Per settare una password ad un utente viene utilizzato il comando passwd, seguito dal nome
utente per il quale desideriamo inserire la password (figura 32).

Figure 32: impostazione password

Il file /etc/shadow viene modificato e la password impostata (figura 33).

Figure 33: /etc/shadow, dopo l'inserimento della password

Si crea ora una password policy utilizzando il comando passwd.

I criteri che si vogliono impostare sono i seguenti:

• massimo numero di giorni di validità di una password: il suo valore viene stabilito
utilizzando il parametro “-x”, in questo esempio sarà posto uguale a 40;

• minimo numero di giorni tra cambiamenti della password: si setta utilizzando il parametro
“-n”. Il suo valore verrà posto uguale a 10;

• numero di giorni di avviso prima della scadenza di una password: si imposta utilizzando il
parametro “-w”, in questo esempio sarà posto uguale a 7;

• numero di giorni dopo la scadenza della password, prima che l'account 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
Data di Fine giorni di Inizio giorni Scadenza Fine tempo Disattivazione
modifica password riserva account
validità di preavviso

“mod” 10 33 40 55 “scad”

Tempo
(giorni)

Giorni di riserva
Giorni di validità
della password
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 password, il campo “40” relativo alla validità della
password, i campi “7”, e “15”, relativi alla scadenza della password.

Figure 35: /etc/shadow dopo la modifica dei parametri

L’amministrazione degli utenti ed il settaggio un password policy possono essere effettuati più
agevolmente utilizzando un unico file di configurazione: /etc/login.defs.

Pagina 190 di 334

 Questo file permette di stabilire alcune caratteristiche predefinite degli utenti che utilizzano le
password shadow.
Il file /etc/login.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 password, ossia:

• PASS_MAX_DAYS: permette di stabilire la durata massima, predefinita, di validità di una

password;

• PASS_MIN_DAYS: serve a stabilire la durata minima di una password;

• PASS_MIN_LEN: permette di impostare il numero minimo di caratteri;

• PASS_WARN_AGE: il periodo di preavviso prima della scadenza di una password.

Volendo impostare un Password Policy simile a quella utilizzata

nel paragrafo dedicato ai sistemi Operativi Microsoft, si
inseriranno i seguenti valori:
• PASS_MAX_DAYS = 40;
• PASS_MIN_DAYS = 0;
• PASS_MIN_LEN = 10;
• PASS_WARN_AGE = 7 (parametro non impostato nel paragrafo
precedente).
La figura 36 mostra la parte del file /etc/login.defs, modificata.

Figure 36: /etc/login.defs

4.1.2 Modifica password e organizzazione

In seguito ad un’intrusione, è necessario pianificare minuziosamente il cambio delle password dei
propri sistemi. L’effettuazione di quest’operazione prevede, in primis la decisione di quali
password 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 passo 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 password è uno dei
primi step da compiere.
In primo luogo andranno modificate le password 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 account, si avranno ripercussioni organizzative.
Gli amministratori potrebbero decidere, in seguito anche alla rilevazione della presenza di sniffer
sulla rete, di modificare tutte le password 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
password, stilando una lista dei servizi offerti dall’azienda e dagli account 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 password di login 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 password legate a servizi
erogati esclusivamente al personale interno dell’azienda.
Il primo passo da compiere è relativo alla modifica di tutte le password di amministrazione dei
sistemi. Il processo non coinvolge gli utenti comuni, ma solo gli amministratori, la modifica
perciò sarà breve. Bisogna ricordarsi che le password 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 passi riguardano la modifica delle password di tutti gli account 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 password;
Pagina 192 di 334
2. gli utenti non possono autonomamente modificarsi la password.
Nel primo caso, gli amministratori potrebbero reimpostare tutte le password di tutti i sistemi ad
un valore di default e conseguentemente obbligare gli utenti ad inserire una nuova password 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
password in autonomia, non dimenticando i criteri di scelta di una password 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 password, 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 password differente
per ogni utente; gli utenti potranno collaborare nello svolgimento di quest’operazione recandosi
dall’amministratore e digitando personalmente la nuova password: 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 user.
Se invece si decidesse di non coinvolgere gli utenti, gli amministratori dovranno modificare tutte
le password e successivamente comunicarle. In questo caso si creerebbe un problema relativo al
canale di comunicazione da utilizzare per lo “smistamento” delle password; 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 supporti 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 CD-
ROM o su di un'unità esterna (ad esempio un supporto 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 supporto 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 supporta 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 supportati 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 supportata 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 user
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 accounting 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 user
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 accounting 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 "passata" 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 supporto 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 supporto 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 CP/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 passo 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 download.

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 password 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 supporti 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. 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 log in 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 passaggio.
2. 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 / -user 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 supportano l’opzione
“-xdev” che permette di evitare la ricerca in queste tipologie di gerarchie. Per esempio:

find / -user 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 login, 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 supporto 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

 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.
4. 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 password.
5. 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.
6. 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.
7. Esaminare il file /etc/passwd del sistema e controllare che non siano state effettuate modifiche al
file. Controllare in modo particolare che non siano stati aggiunti nuovi account utente, account
senza password, o cambiamenti di UID (specialmente a UID 0, quella di root) di account
esistenti.
8. 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, uucp, ftp, e altri account 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.
9. 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 password cracking, file di password relativi ad altri sistemi, etc.).
Una tecnica comune sui sistemi UNIX è quella di creare una directory nascosta all’interno di un
account 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.passwd’ o
‘rpc.yppasswdd’ potrebbero essere in esecuzione.

4.3.2 Punti chiave per la rilevazione dell’intrusione su sistemi Windows NT

1. 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à.
2. Controllare account o gruppi di utenti insoliti. E’ possibile utilizzare User Manager o i
comandi ‘net user’, ‘net group’ e ‘net localgroup’ dalla linea di comando. Assicurarsi che
l’account guest sia disabilitato se il sistema non lo richiede.
3. Controllare tutti i gruppi per la presenza di eventuali membership di utenti non valide. Alcuni
dei gruppi di default in NT forniscono speciali privilegi ai membri di quel gruppo. I membri
del gruppo Administrators possono compiere qualsiasi attività sul sistema, i Backup Operators
possono leggere qualsiasi file del sistema. I Power Users possono creare condivisioni.
4. Controllare se esistono inappropriati permessi utente, tramite User Manager sotto le voci
Policy, User Rights. Ci sono 27 differenti permessi che possono essere assegnati a utenti o
gruppi. Solitamente la configurazione di default per questi permessi è sicura.
5. 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 Users”
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.

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

 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.
7. 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 TCP/IP Ports
http://support.microsoft.com/support/kb/articles/q150/5/43.asp
SMS: Network Ports Used by Remote Helpdesk Functions
http://support.microsoft.com/support/kb/articles/q167/1/28.asp
XGEN: TCP Ports and Microsoft Exchange: In-depth Discussion
http://support.microsoft.com/support/kb/articles/q176/4/66.asp
How to Configure a Firewall for Windows NT and Trusts
http://support.microsoft.com/support/kb/articles/q179/4/42.asp
8. 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.
9. 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).
10. 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.
11. 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.
12. 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.
13. Scandire il sistema alla ricerca di eventuali file insoliti o nascosti, file che possono contenere
programmi per il crack delle password, file di password 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”.
14. 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
 il sistema, controllando una configurazione precedentemente definita. Questo aiuta a
determinare se sono stato apportate eventuali modifiche.
15. 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.
16. 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.

4.3.3 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 supporti 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 supporti 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ò passare 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 Passi 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 passare 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 supporti di
distribuzione originali.
Alcuni binari sostituiti da Trojan horse nei sistemi UNIX: telnet, in.telnetd, login, 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 supporti 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/passwd alla ricerca “valori” estranei;
• controllare se /etc/inetd.conf è stato modificato;
• se è consentito “r-commands” (rlogin, 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 username e password, 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 username e
password, 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.

6. Output dei tool d’intrusione

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 account 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 login ls lsof
mail mingetty netstat named passwd pidof pop2 pop3 ps pstree rpcinfo rlogind
rshd slogin sendmail sshd syslogd tar tcpd tcpdump 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 login ls lsof mail mingetty netstat named passwd pidof
pop2 pop3 ps pstree rpcinfo rlogind rshd slogin sendmail sshd syslogd tar tcpd tcpdump 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/login), 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 passphrase 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: user@domain.com
From: user <user@domain.com>
Subject: Test email message from Tripwire

If you receive this message, email notification

from Tripwire is working correctly

Utilizzo dello strumento

Alcuni semplici passi 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 passare per tutti gli step necessari per installare lo strumento.
Il primo passo è eseguire lo script:

# /etc/tripwire/twinstall.sh

La prima cosa che fa è chiedere la “site keyfile passphrase”:

Enter the site keyfile passphrase:

Verify the site keyfile passphrase:
Generating key (this may take several minutes)...

In un secondo momento viene richiesta una “local keyfile passphrase”:

Enter the local keyfile passphrase:

Verify the local keyfile passphrase:
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 passphrase” a ogni passaggio di questo procedimento:

Signing configuration file...

Please enter your site passphrase:
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.
----------------------------------------------
Signing policy file...

Pagina 221 di 334

Please enter your site passphrase:
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 twadmin 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 ‘twadmin’ 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 passaggio successivo è l’inizializzazione del database. Tripwire a questo punto passerà 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 passphrase:
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 supporti 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 login “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 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 passano 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 passo 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.

4.4.2 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 TCP, 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 TCP:

Pagina 225 di 334

Essendo di 16 bit il campo relativo alle porte sorgente e destinazione dell’ header TCP 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 20/tcp
ftp 21/tcp
ssh 22/tcp # SSH Remote Login Protocol
smtp 25/tcp mail
domain 53/udp nameserver
www 80/tcp http # WorldWideWeb HTTP
www 80/udp # HyperText Transfer Protocol
pop3 110/tcp pop-3 # POP version 3
irc 194/tcp # Internet Relay Chat
x11 6000/tcp x11-0 # 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 TCP 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 TCP 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 TCP 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.

Supporto 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 supporta 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 : User 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 passo relativo alla configurazione del server, identificato anche come “nessusd”, è l’
aggiunta degli utenti. Il comando utilizzato per questa operazione è:

# nesuss-adduser

nessus-adduser è un semplice programma che permette di inserire nel file configurazione di

nessusd gli attributi degli utenti creati, in particolare verrà richiesto di inserire:

• Login
• Password
• Autentication Type
• Rules

Benché l’ uso di login e password 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-rmuser

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 tcp --dport 1241 -m state --state ESTABLISHED -j ACCEPT

###OUTPUT###
$IPTABLES -A OUTPUT -o $EXTIF -p tcp --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 <config-file>, specifica un file di configurazione

-a <address>, 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
• Login e Password dell’ utente creato
• Pulsante LOGIN, 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 upload 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 login e password
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 Un singolo host

10.163.156.1-254 Un range di host
10.163.156.1-10.163.159.254 Un range di host (come sopra diversa notazione)
10.163.156.1/24 (Range di host notazione binaria )
hope.fr.nessus.org (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 User si può affinare la sezione target escludendo da un range di ip un particolare
host, sintassi:

reject <ip>
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, login e password 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/username/kbs/

dove username è il login 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/username/

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, è passibile 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:
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

1
“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,
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.

4.5.1.2 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://support.microsoft.com/support/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’account di amministrazione di default (noto come “sa”) abbia
una password sufficientemente robusta,
Eseguire il servizio MSSQLServer e l’SQL Server Agent sotto un account
valido di dominio con privilegi minimi, non come amministratore del dominio
o con l’account SYSTEM (su NT) o LocalSystem (su 2000 o xp),
Abilitare l’Autenticazione Windows NT, abilitare la verifica dei login 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 TCP 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

 • 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 TCP dalla 137
alla 139, le UDP dalla 137 alla 139, la 445 TCP e la 445 UDP.

4.5.1.5 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’account SYSTEM, noto su Windows 2000 e XP come
LocalSystem. Questo account possiede privilegi virtualmente illimitati e non richiede alcuna
password; poiché non può connettersi ad altri sistemi con UserID e password, 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 TCP/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 supporto LAN
Manager (LM), Microsoft memorizza per default in locale gli hash delle password 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 password del LAN Manager possono essere violate in
brevissimo tempo. Anche le password 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 password sono troncate a 14 caratteri;
• le password utilizzano lo spazio come carattere di riempimento per raggiungere i 14
caratteri;
• i caratteri usati nelle password vengono convertiti tutti in caratteri maiuscoli;
• le password 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 password 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 "brute-
force" 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 password.
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 password 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
 • 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.

4.5.1.7 Autenticazione generica di Windows – Account senza password o con password deboli
In quasi tutte le interazioni tra gli utenti e i sistemi informativi vengono utilizzate password, 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 password 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 password 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 account, a macchine vicine e forse
anche ad ottenere privilegi di amministrazione. Nonostante questi pericoli, gli account con
password deboli o addirittura senza password rimangono estremamente diffusi e le società con una
buona policy sull’utilizzo delle password ancora troppo rare.
Le più comuni vulnerabilità delle password sono dovute (a) ad account senza password o con
password deboli, (b) al fatto che, a prescindere dalla robustezza delle password, spesso gli utenti
non le proteggono, (c) al fatto che il sistema operativo o il software applicativo creano account di
amministrazione con password deboli o privi di password (d) al fatto che gli algoritmi di hashing
delle password 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 password e che riassuma i comportamenti corretti per
conservarne la riservatezza, unita a una verifica proattiva dell’integrità delle password.
Per quanto vi siano alcuni sintomi osservabili di una generale debolezza delle password, come la
presenza di account 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 password sia
sufficientemente robusta è quello di verificare tutte le password con gli stessi strumenti per la
determinazione delle password utilizzati dagli aggressori.
La difesa migliore e la più corretta contro la debolezza delle password è una solida policy che
includa le istruzioni su come generare buone password e descriva i comportamenti corretti per
mantenerne la sicurezza, assieme ad una verifica proattiva dell’integrità delle password.
o Assicursi che le password siano sufficientemente robuste. I meccanismi di definizione delle
password riportate nella policy di sicurezza devono essere sufficientemente articolati;
o Proteggere le password robuste. Anche se le password sono robuste, gli account possono
essere ugualmente compromessi se gli utenti non proteggono adeguatamente la propria
password. Una buona policy include sempre istruzioni che specificano come gli utenti
devono comportarsi nella gestione della propria password ;
o Controllare rigorosamente l’utilizzo degli account. Devono essere verificati continuamente
tutti i requisiti che giustifichino l’esistenza degli account (corrispondenza con utenti reali,
verifica dei diritti di accesso degli account);

Pagina 244 di 334

 o Implementate una solida policy per le password 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 password.

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 download 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 passivamente 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 passando 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 (TCP 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, Sadmind, 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 passato 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’account nobody, perché questo account è utilizzato per mappare l’account 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 login, l’esecuzione di comandi e il
trasferimento di file attraverso una rete. La maggior parte dei sistemi utilizza il pacchetto open-
source 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 passi consigliati per prevenire i rischi di intrusione sono:
o Passare 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 TCP/IP moderni. Anche se SNMP è supportato
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 supporto 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 CA-
2002-03;
iv. Filtrate SNMP (porte 161 TCP/UDP e 162 TCP/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 TCP-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 password. 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 TCP/UDP e 162 TCP/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 username e
password. I servizi FTP anonimi non richiedono una password univoca (vale per tutti) e tutti gli
utenti usano lo stesso nome di login ("anonymous" o "ftp"), così da permettere a chiunque l’accesso
al servizio.
Il servizio FTP autenticato richiede invece un username e una password, 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 login 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 passi alla versione più recente dell’FTP. I più conosciuti server FTP gratuiti sono WU-
FTPD (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/ftpusers e si aggiungano gli username "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 password;
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 username valido e di una password 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 TCP
wrappers. TCP 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/tcp_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 TCP 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 account di amministrazione (come root, daemon, sys, ecc.) al file
/etc/ftpusers in modo che tali account non possano essere accessibili in FTP;
vii. Si consideri la possibilità di sostituire FTP con soluzioni software più sicure come SFTP o
SCP (componenti del pacchetto Secure Shell) e si utilizzi un web server per distribuire file a
un pubblico vasto;

Pagina 253 di 334

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

4.5.2.6 Servizi R – Relazioni di Trust

Remote shell (rsh), remote copy (rcp), remote login (rlogin), 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.rlogind, in.rexecd) in modo che gli utenti possano spostarsi da una macchina all’altra senza
inserire ogni volta uno user ID e una password. 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, rcp, rlogin 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, rcp, rlogin 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 password 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 rcp 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 rlogin una voce per "in.rlogind." 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 scp e sftp. Se i servizi R sono assolutamente necessari, si disabilitino le
relazioni di trust e si utilizzi TCP 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 TCP
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 TCP Wrappers. Non si utilizzi mai ~/.rhosts
per permettere l’autenticazione senza password.

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 TCP 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 TCP Wrappers.
Ci si può garantire una certa protezione dai buffer overflow abilitando uno stack non eseguibile sui
sistemi operativi che supportano 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 passato 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 passi 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/anti-
spam.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 è
passibile 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 – Account senza password o con password deboli
In quasi tutte le interazioni tra gli utenti e i sistemi informativi vengono utilizzate password, 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 password 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 password 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 account, a macchine vicine e forse anche ad
ottenere privilegi di amministrazione. Nonostante questi pericoli, gli account con password deboli o
addirittura senza password rimangono estremamente diffusi e le società con una buona policy
sull’utilizzo delle password ancora troppo rare.
Le più comuni vulnerabilità delle password sono dovute (a) ad account senza password o con
password deboli, (b) al fatto che, a prescindere dalla robustezza delle password, spesso gli utenti
non le proteggono, (c) al fatto che il sistema operativo o il software applicativo creano account di
amministrazione con password deboli o privi di password, (d) al fatto che gli algoritmi di hashing
delle password 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 password e che riassuma i comportamenti corretti per
conservarne la riservatezza, unita a una verifica proattiva dell’integrità delle password.
Sul sistema locale le password vengono salvate in either /etc/passwd o in /etc/shadow.
/etc/passwd: 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 password, allora
ogni utente con accesso al sistema può leggere gli hash e provare a violarli con un password
cracker.
Per custodire gli hash si può utilizzare in alternativa /etc/shadow, che deve essere leggibile solo
da root. Se i vostri account locali non sono protetti da /etc/shadow, allora il rischio per le vostre
password diventa molto alto.

Pagina 258 di 334

 Se utilizzate NIS, gli hash delle password 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 password sono protetti, le password possono essere indovinate in altri
modi. Per quanto vi siano alcuni sintomi osservabili di una generale debolezza delle password,
come la presenza di account 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
password sia sufficientemente robusta è quello di verificare tutte le password con gli stessi
strumenti per la determinazione delle password utilizzati dagli aggressori. ATTENZIONE: Non si
utilizzi mai un password 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 password senza autorizzazione.
I migliori strumenti per la determinazione delle password sono:
• Crack
• John the Ripper
• Symantec NetRecon
La difesa migliore e la più corretta contro la debolezza delle password è una solida policy che
includa le istruzioni su come generare buone password e descriva i comportamenti corretti per
mantenerne la sicurezza, assieme ad una verifica proattiva dell’integrità delle password.
i. Ci si assicuri che le password siano sufficientemente robuste;
ii. Una volta fornite agli utenti le corrette indicazioni su come generare buone password,
possono essere messe in opera le procedure per controllare che queste indicazioni
vengano seguite. Il modo migliore per farlo è quello di convalidare le password ogni
volta che l’utente le cambia. La maggior parte dei tipi di Unix può usare Npasswd come
front-end per verificare le password 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 password deboli o assenti è quello di utilizzare forme
alternative di autenticazione come token generatori di password o sistemi di
autenticazione biometria;
iv. Proteggere le password robuste;
v. Controllare rigorosamente gli account;
vi. Implementare una solida policy per le password in azienda.

4.5.3 Porte vulnerabili

In questa sezione, sono elencate le porte che sono generalmente esaminate e attaccate. Bloccando il
traffico che passa 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 login – telnet (23/tcp), SSH (22/tcp), FTP (21/tcp), NetBIOS (139/tcp), rlogin e altri
(da 512/tcp a 514/tcp);
b) RPC e NFS – Portmap/rpcbind (111/tcp e 111/udp), NFS (2049/tcp e 2049/udp), lockd
(4045/tcp e 4045/udp);
c) NetBIOS in Windows NT – 135 (tcp e udp), 137 (udp), 138 (udp), 139 (tcp). Windows 2000 -
le prime porte più la 445(tcp e udp);
d) X Windows – da 6000/tcp a 6255/tcp;
e) Naming Services – DNS (53/udp) per tutte le macchine che non sono server DNS, trasferimenti
di zona DNS (53/tcp) eccezion fatta per le external secondaries, LDAP (389/tcp e 389/udp);
f) Mail – SMTP (25/tcp) per tutte le macchine che non siano relay di posta esterni, POP (109/tcp e
110/tcp), IMAP (143/tcp);
g) Web – HTTP (80/tcp) e SSL (443/tcp) eccezion fatta per i server Web esterni, e potreste anche
bloccare le comuni porte HTTP più significative (8000/tcp, 8080/tcp, 8888/tcp, ecc.);
h) "Small Services" – porte al di sotto di 20/tcp e 20/udp, time (37/tcp e 37/udp);
i) Varie – TFTP (69/udp), finger (79/tcp), NNTP (119/tcp), NTP (123/udp), LPD (515/tcp),
syslog (514/udp), SNMP (161/tcp e 161/udp, 162/tcp e 162/udp), BGP (179/tcp), SOCKS
(1080/tcp);
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 supportare 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 TCP/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, passa 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
bypassare 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 passare).

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 passo 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 login per prendere nota di quando è stato fatto un tentativo di
accesso con una password non corretta.
Monitoraggio dell'attività di login.
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 password (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 login e logout, 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-user (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 user-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, Bypass 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
password 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 passivi 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 passivamente, 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:

• 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

4.6.3.2 Classificazione in base al momento dell'analisi delle informazioni

Possiamo catalogare le varie tipologie di IDS in base all'intervallo di tempo che passa 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 supporto, 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:

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

4.6.3.3 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 livello-
soglia 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 CPU, 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 supporto 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|userid == tr.userid]
4. [?|se.terminal != tr.terminal]
5. ==>
6. [!|printf("SimuLogon: user %s at terminals %s, %s\n",
tr.userid, 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 login, viene effettuata una transazione, e l'evento viene
memorizzato.
La regola verifica quindi se sono presenti altre sessioni con lo stesso userID: 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 supporto 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 stato-
transizioni.
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 passare dallo stato iniziale a quello finale. Dopo aver
identificato lo stato iniziale il passo 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, login falliti, ascolto passivo

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' <IPv4>
E <TCP>
E la porta di destinazione E' <2222>
E il payload CONTIENE la stringa <foo,>
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 TCP. 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 TCP:
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 login 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 login-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 passo 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 passo 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 passo 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 passo.

4.6.3.4 Il passo 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 passa 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 TCP, 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 passa 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 CPU 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 passante 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 front-
end 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 passeranno 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 passare 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 TCP. 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 TCP 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 TCP
Un gran numero di attacchi scoperti dai sistemi di ID avvengono in connessioni TCP. Questo
impone che l'IDS sia in grado di ricostruire il flusso di dati che passa attraverso uno stream TCP.
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 TCP è uno dei
maggiori problemi dei sistemi di intrusion detection network-based.
Introduciamo alcuni concetti legati alle sessioni TCP. Ogni connessione TCP 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 TCP.
Ci riferiremo a queste informazioni con il termine di “parametri della connessione”.

Pagina 294 di 334

Le specifiche del protocollo TCP (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 TCP 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 “TCP 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 TCP

• nel momento in cui viene deciso di eliminare un TCB

Il primo punto in cui il monitoraggio di una sessione TCP 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 TCP (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 “passivo” 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 TCP
Uno dei compiti più difficili per un network IDS è quello di garantire un'accurata ricostruzione
dei dati scambiati durante una connessione TCP. Il TCP 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 TCP/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 passivo della comunicazione, è molto facile perdere alcuni
dati.
Questo problema diventa ancor più importante nel momento in cui il riassemblaggio di uno
stream TCP 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 de-
sincronizzata.
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'end-
system: 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 TCP) 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 TCP 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 TCP 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 supportare diversi encoding, altrimenti
vi era il rischio che i dati che passassero 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; è
supportato 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 code-
point 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 code-
point 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 tcp !$HOME_NET any -> $HOME_NET 80 (msg: "IDS434 - WEB IIS - Unicode

traversal backslash"; flags: AP; content: "..|25|c1|25|9c"; nocase;)

alert tcp !$HOME_NET any -> $HOME_NET 80 (msg: "IDS433 - WEB-IIS – Unicode
traversal optyx"; flags: AP; content: "..|25|c0|25|af"; nocase;)
alert tcp !$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 CPU, la memoria, lo spazio disco, e la larghezza di banda
della rete.
Le capacità di processo della CPU di un IDS possono essere esaurite in quanto un IDS utilizza
cicli di CPU 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 TCP 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 passa sul filo: le risorse
possono quindi essere consumate/sprecate processando del traffico che non è destinato a nessuna
macchina reale.
Esaurimento delle risorse di CPU
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 CPU 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 - TCP 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 TCP (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 TCP 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 TCP 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 passare 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 passare 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 supporta, 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 supportate. Sfortunatamente i produttori gonfiano il numero

delle firme che il loro prodotto supporta, 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 supporta 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 Sparc x86 Itanium OS

X X X X X Linux*
Y Y Y X N/A OpenBSD
Y Y Y X Y FreeBSD**
Y Y Y X N/A NetBSD
N/A N/A X Y N/A Sun/Solaris
N/A X N/A N/A N/A MacOsX
X = Supportato
Y = Potrebbe Funzionare
N/A = Non Funzionante
* 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 supporto 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 CPU, 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 TCP 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 TCP reassembly. Se queste features
sono attivate e se il pacchetto in arrivo fa parte di una connessione TCP 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 TCP; 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 TCP 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 passato, 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 è diverso dall'indirizzo di destinazione incluso nel

messaggio ARP

• 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.
TCP stream reassembly. Il riassemblaggio dello stream TCP è implementato da Prelude-
NIDS per aiutare a scoprire o fermare tecniche di IDS evasion. Prelude è in grado di
riassemblare gli stream TCP 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 Sviluppo Rilasciata Note

10/100/1000 X/X/?
FullDuplex via Span Port (Mirror port) X
Stealth Logging sull'interfaccia X
Monitoraggio di interfacce multiple su singoli host X
Full Packet Capture X
Filtro BPF X
Decodifica HTTP X
Decodifica RPD X
PortScan Detection X
Polymorphic Shell Code Detection X
ArpSpoof Detection X
IP Defragmentation X
Passive OS Detection X
TCP Flow ReAssembly X
IP Spoof Detection X Contributo: Sylvain de Tilly
SMP/Threading X Rilascio: gennaio
Algoritmo E2xb X Rilascio: gennaio
802.1q (VLAN) Packet Processing X
802.11 (WLAN) AP/Station Monitoring * X
Ruleset Tuning basato sui report di Nessus 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 log in 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: Prelude-
LML 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 Prelude-
LML 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 Progetto Sviluppo Rilasciata Note

Syslog Management centralizzato X
Stealth Logging sull'interfaccia X
IPFW Logs X
NetFilter Logs X
IPChains Logs X
Cisco Router Logs X
Cisco VPN Concentrator X
Cisco PIX Logs X
Nagios Logs X
Zyxel Router Logs X
WuFtpd Logs X
ProFtpd Logs X
Parse SSHD Logs X
Parse Qpopper Logs X
GRSecurity Logs X
Unix Security Logs X
CheckPoint FW-1 Logs X
Norton Antivirus Corporate Edition Logs 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 diret