Sei sulla pagina 1di 28

Università degli Studi di Trieste

Facoltà di Ingegneria
Anno Accademico 2007/2008

PROGETTO E REALIZZAZIONE DELL'INFRASTRUTTURA


DI CONTROLLO IN UNA FARM PER LA RILEVAZIONE DI
ATTACCHI WEB A SITI REMOTI

Relatore:
Prof. Alberto Bartoli
Correlatore: Laureando:
Ing. Eric Medvet Enrico Sorio
Il problema…

 Un numero enorme di organizzazioni in


tutto il mondo basa il proprio business
sulla rete e sulle tecnologie web

 L’immagine e la solidità di una


organizzazione dipendono anche dalla
qualità della sua presenza in rete
… quindi
Ogni intrusione in un sito può arrecare seri
danni di immagine alla azienda, aggravati
ulteriormente dal passare del tempo
Defacement: cos’è?
 Nella accezione più classica consiste nella
sostituzione della home-page originale di un sito web
con un contenuto arbitrario

 Molto spesso i contenuti inseriti sono di


rivendicazione o di propaganda politico/religiosa

 Possono essere fatti anche in maniera automatizzata


con software ad hoc

 Gli “invisible defacement” sono l’evoluzione di questo


tipo di attacchi, volti a realizzare sistemi di pishing o a
diffondere software malevolo
Qualche esempio reale (I)
http://sfa.nasa.gov/nmiscalendar/

11/04/2009
Qualche esempio reale (II)
http://www.archeopd.beniculturali.it

27/01/2009
Statistiche: quanti (I)
Dai dati forniti da zone-h.org si può
rilevare:

 Più di 490.000 di defacement nel 2006

 Più di 1,7 milioni di defacement nel


2005-2007

Il numero è in costante aumento…


Statistiche: quanti (II)

Nella prima metà del mese di aprile 2009


sono stati rilevati:
 767 defacement di web site solo fra i
domini .it
 36027 defacement globalmente

Non è un caso, sempre fra i domini .it:


 Dal 1 al 15 Ottobre 2008: 608
Statistiche: quanto durano (III)
Altro dato di analisi interessante è la durata di un defacement
Si può notare il tempo medio di reazione decisamente alto
Soluzioni esistenti (I)
Si basano (quasi) tutte sullo stesso approccio:

 Mantenere una copia della risorsa richiesta,


considerata affidabile, in una locazione
sicura
 Prima di rispondere ad una richiesta
confrontare la risorsa con la copia
considerata affidabile
Soluzioni esistenti (II)
Sebbene funzionanti, poco utilizzate…
Perché?

È necessario:

Acquistarle
Installarle
Configurarle
Modificare l’attuale approccio all’aggiornamento del web-site per integrarlo
con il sistema di monitoring
La soluzione del
“Laboratorio Reti di Calcolatori”

Un servizio di rilevamento di
defacement che possa avere realmente
un vasto utilizzo.

Dotato di alcune caratteristiche…


La soluzione proposta
caratteristiche (I)

Non è necessario installare software sul sito


da monitorare
• il sistema analizza semplicemente le pagine
dall’esterno come un qualsiasi visitatore

Semplicità di aggiunta di un nuovo sito al


monitoring (nessuna configurazione richiesta)
• è sufficiente specificare l’url da monitorare e il
contatto a cui segnalare eventuali problemi
La soluzione proposta
caratteristiche (II)
Nessuna interferenza con le normali operazioni di
aggiornamento del web-site
• nessuna necessità di mantenere una copia delle risorse
considerata affidabile e costantemente sincronizzata con
le modifiche fatte

Economizza le risorse

• una sola istanza del nostro sistema può monitorare


centinaia di risorse
La soluzione proposta
approccio generale (I)
Web-Server remoti…

INTERNET

Prelevare la risorsa monitorata ad intervalli regolari

Se si rileva un cambiamento sospetto viene inviata una mail o un sms


La soluzione proposta
alert generati
Amministratore:
 Riceve alert (email/sms)
◦ Content alert
possibile defacement (contenuto anomalo)
◦ Network alert
problema nel prelevare la risorsa

 Può accedere ad applicativo web


per analizzare alert / snapshot
La soluzione proposta
approccio generale (II)
LEARNING MONITORING
(alcuni giorni)
t
Viene generato un Viene generato un alert se la risorsa si discosta
profilo dal profilo generato

Normale
o
Sospetto
Sperimentazione degli algoritmi
Test set (I)
Gli algoritmi di rilevazione sono stati testati
su un archivio di 300 web-resources,
scaricate ogni 6 ore per 4 mesi (ogni
versione della risorsa è chiamata snapshot).

Usato sia per simulare


 la fase di learning (prime 50 rilevazioni)
 la fase di monitoring
Sperimentazione degli algoritmi
Test set (II)
L’archivio contiene web-site di vario tipo (news, tecnici, e-
commerce, università…)

Quasi tutti hanno porzioni dinamiche che si modificano ad ogni


accesso, ad esempio:
Sperimentazione degli algoritmi
Test set (III)
In aggiunta all’archivio delle web-resources
è stato creato un archivio di 900
differenti defacement (attack set) reperiti
dall’archivio di zone-h.org

sono stati selezionati defacement con varie caratteristiche:


• dimensione
• lingua
• con o senza immagini
• con o senza script
Sperimentazione degli algoritmi
Indici di performance (I)

False Positive Rate (FPR)


• Si sottopone al sistema gli snapshot successivi al learning-set
• Si misura la percentuale di alert generati dal sistema qualificati come un falso allarme
FPR dovrebbe essere zero

False Negative Rate (FNR)


• Si sottopone al sistema tutti gli snapshot dell’attack set
• Si misura la percentuale di defacement non rilevati su tutto il set
FNR dovrebbe essere zero

...

LEARNING MONITORING
Sperimentazione degli algoritmi
Risultati (I)
L’esito del test è:

 False Negative Rate (FNR) è


esattamente zero
Sperimentazione degli algoritmi
Risultati (II)
 False Positive Rate (FPR) dopo alcune
ottimizzazioni si è attestato sullo 0,24%
Architettura del sistema
In queste tesi è stata implementata una
infrastruttura scalabile basata su questi
algoritmi di rilevazione così composta:

Istanze

Controllore

Interfaccia utente
Architettura del sistema
HTML

alerts
Alert
ICEFaces
fetcher
alerts task
Instance task warden Facelets
db checker
warden snapshot
Repair
Lazy Load
thread snapshot
cache

db load index
heartbeat
fetcher

timer
dep.
download feeder sensors aggregator
analizer
Architettura del sistema (I)

Istanze (fino a varie decine)

• Effettua il download delle risorse (snapshot)


• Implementa gli algoritmi di learning e
monitoring
• Genera gli alert in caso di possibile
defacement
Architettura del sistema (II)

Controllore

• Coordina il lavoro delle istanze e ne controlla lo


stato
• Gestisce gli utenti
• Inoltra gli alert generati agli utenti responsabili
• Permette il colloquio fra l’interfaccia grafica e le
istanze
Architettura del sistema (III)

Interfaccia grafica

• permette di ottenere informazioni sullo stato


delle risorse monitorate
• permette di aggiungere nuove risorse da
controllare
• permette di visualizzare lo storico degli
snapshot
• permette di visualizzare gli alert