UNIVERSITÀ DI PISA

FACOLTÀ DI SCIENZE MATEMATICHE FISICHE E NATURALI

CORSO DI LAUREA SPECIALISTICA IN TECNOLOGIE

INFORMATICHE

"Centralizzazione e correlazione dei log per la rilevazione di incidenti e per un efficace analisi investigativa. Un caso pratico:CS-MARS(Cisco Security Monitoring Analisys and Response System)"

Tesi di Laurea Specialistica di

Vito Pietrapertosa

Relatori: Candidato: Prof. Fabrizio Baiardi Vito Pietrapertosa

Ing. Emanuele Briganti Controrelatore: Prof. Vincenzo Ambriola

ANNO ACCADEMICO 2005-2006

2

Dedicata ai miei nonni

Donato e Vito

Sommario

SOMMARIO..................................................................................................................................................................... 3

INTRODUZIONE ............................................................................................................................................................ 6

STRUTTURA DELLA TESI ................................................................................................................................................. 9 1.1 CS MARS CONCETTI GENERALI ............................................................................................................................. 10

1.1.1 Il tab Summary è costituito da tre sottotab .................................................................................................... 14 1.2 INCIDENTS INVESTIGATION .................................................................................................................................... 16 1.3 CORRELAZIONE DEGLI INCIDENTI........................................................................................................................... 19 1.4 LA MITIGATION ...................................................................................................................................................... 20 1.5 I FALSI POSITIVI...................................................................................................................................................... 21

1.5.1 Il tab Query/Report .................................................................................................................................. 23 1.6 LE REGOLE ............................................................................................................................................................. 24

1.6.1 Il tab Rules .................................................................................................................................................... 24 1.6.2 Il tab Management ......................................................................................................................................... 28 1.6.3 Il tab Admin................................................................................................................................................... 29

2.1 TEST EFFETTUATI PER LA RILEVAZIONE DELLE SCANSIONI..................................................................................... 30 2.3 OBIETTIVO 1 .......................................................................................................................................................... 35

2.3.1 Test di scansione di tipo 1 .............................................................................................................................. 35 2.4 OBIETTIVO 2 .......................................................................................................................................................... 36

2.4.1 Test di scansione di tipo 2.............................................................................................................................. 36 2.5 OBIETTIVO 3 .......................................................................................................................................................... 39

2.5.1 Test di scansione di tipo 3 .............................................................................................................................. 39 2.6 OBIETTIVO 4 .......................................................................................................................................................... 40

2.6.1 Test di scansione di tipo 4.............................................................................................................................. 40 2.7 OBIETTIVO 5 .......................................................................................................................................................... 42

2.7.1 Test di scansione di tipo 5 .............................................................................................................................. 42 2.8 RISULTATO............................................................................................................................................................. 43 2.9 CONFIGURAZIONE REGOLE PER LA RILEVAZIONE DELLE SCANSIONI....................................................................... 44 2.10 CONCLUSIONI ....................................................................................................................................................... 46

CAPITOLO 3.................................................................................................................................................................. 49

3.1 TEST PER LA RILEVAZIONE DI ATTIVITÀ PEER TO PEER .......................................................................................... 49 3.2 CONFIGURAZIONE DEI DISPOSITIVI ......................................................................................................................... 52 3.3 RILEVAZIONE P2P CON L’AIUTO DELL’IPS ............................................................................................................ 54

3.3.1 Impostiamo il blocco dei peer to peer........................................................................................................... 54 3.3.2 Le contromisure ............................................................................................................................................. 56

3.4 IL PROBLEMA DEI FALSI POSITIVI............................................................................................................................ 59

3

4

CAPITOLO 4.................................................................................................................................................................. 61

4.1 TEST SULLA RILEVAZIONE DI ALCUNI ATTACCHI .................................................................................................... 61 4.2 ANALISI E CONDUZIONE DEGLI ATTACCHI .............................................................................................................. 65 4.3 ANALISI DELLE VULNERABILITÀ RILEVATE............................................................................................................. 66 4.4 VULNERABILITÀ FTP .............................................................................................................................................. 68 4.5 ATTACCO DI TIPO “DENIAL OF SERVICE” AL MAIL SERVER .................................................................................... 70 4.6 ATTACCO DI TIPO “BRUTE FORCE” AL FIREWALL .................................................................................................... 73 4.7 ATTACCO “BRUTE FORCE” AL SERVER WINDOWS 2003 .......................................................................................... 75 4.8 ATTACCO AL WEB SERVER MICROSOFT-IIS/6.0..................................................................................................... 76 4.9 ATTACCO AL DB ORACLE...................................................................................................................................... 79

CAPITOLO 5.................................................................................................................................................................. 82

5.1 ATTACCHI COMPLESSI CONDOTTI IN PIÙ PASSI ....................................................................................................... 82 5.2 TECNICA STATEFULL .............................................................................................................................................. 83 5.3 LA TECNICA BASATA SULLE SIGNATURE ................................................................................................................ 83 5.4 MODELLARE L’ATTACCO ....................................................................................................................................... 84 5.5 ATTACCHI COMPLESSI HOST BASED ........................................................................................................................ 92 5.6 ATTACCHI DINAMICAMENTE MUTEVOLI................................................................................................................ 101

CONCLUSIONI............................................................................................................................................................ 103

APPENDICE A............................................................................................................................................................. 106

BIBLIOGRAFIA .......................................................................................................................................................... 118

SITOGRAFIA............................................................................................................................................................... 120

RINGRAZIAMENTI ................................................................................................................................................... 121

5

6

Introduzione Il valore strategico e la crescente complessità delle reti informatiche rendono sempre

più stringente la necessità di dotarsi di strumenti per la loro gestione e per il controllo

delle risorse coinvolte. L’amministratore di rete e/o gli amministratori delle politiche

di sicurezza devono poter disporre di informazioni affidabili non solo sull’utilizzo

della rete e delle sue componenti, ma anche di quelle necessarie per ottimizzare le

risorse, correggere le configurazioni e inibire comportamenti che possano

compromettere l’efficienza e la sicurezza della rete. Queste informazioni possono

essere dedotte dai messaggi di log, che descrivono tutte le attività effettuate dai vari

dispositivi, sia in maniera autonoma sia per conto degli utenti. L’analisi dei log è

però gravosa, perchè il “volume grezzo” dei dati generati è notevole. Di conseguenza,

la raccolta, il filtraggio e la correlazione dei log deve essere delegata a strumenti

automatici che siano in grado di memorizzare, gestire ed analizzare queste

informazioni per conto dell’utente. Inoltre, l’utente deve poter accedere alle varie

funzioni tramite una opportuna interfaccia. La soluzione adottata deve essere non solo

affidabile, ma anche scalabile, flessibile ed in grado di gestire - con criteri univoci -

dispositivi di costruttori diversi e con diversi obiettivi, sia locali che remoti. In

un’ottica di investimenti a medio-lungo termine, occorre che la soluzione sia inoltre

compatibile con futuri sviluppi ed ampliamenti fisiologici della rete. L’adozione di un

valido sistema di monitoraggio di rete offre vantaggi immediati, quali la possibilità di

quantificare l’uso della banda aziendale, di valutare le attività delle utenze, di

individuare attività a rischio. Contemporaneamente, questa attività è indispensabile

per pianificare interventi di carattere evolutivo della rete, che ne migliorino la

funzionalità e ne ottimizzino i processi. L’adozione di un sistema automatico di

monitoraggio permette di risolvere un paradosso generato dalla crescita delle

piattaforme di sicurezza utilizzate dal gestore di una rete. Infatti, se da un lato gli

strumenti tecnologici sono fondamentali per minimizzare i rischi, dall’altro la mole

dei log che essi generano è talmente elevata che spesso non si è in grado di

controllarli in modo razionale ed efficace con una visione integrata e globale.

Ottenere un'immagine di dello stato complessivo, dal punto di vista delle prestazioni e

della sicurezza, di una infrastruttura ICT è un’attività tutt’altro che facile. Inoltre, la

7

soluzione di utilizzare gli strumenti standard in dotazione ad ogni prodotto è di solito

troppo dettagliata e specifica e non permette una visione completa. Per determinare

correttamente cosa sta avvenendo è infatti necessario integrare le informazioni di più

fonti. Ad esempio, solo osservando lo stato dei firewall e, contemporaneamente,

considerando le informazioni restituite dagli IDS si possono dedurre le informazioni

utili sulla dinamica e l’estensione di un attacco. Queste informazioni, se gestite in

tempo reale, permettono di definire la risposta più adatta per non interrompere i

servizi forniti dai sistemi e di non soffrire delle perdite di tempo causate da falsi

allarmi.

Uno dei rischi significativi della sicurezza informatica è quello di provare un falso

senso di sicurezza: è possibile valutare il grado di sicurezza offerto da una certa

soluzine solo si può valutare il corretto funzionamento delle contromisure. La

gestione degli allarmi in tempo reale permette di evidenziare gli elementi più critici

per la sicurezza, garantendo una elevata reattività anche in presenza di dati

loscamente connessi.. La maggior parte dei danni al sistema informativo, siano essi la

propagazione di un worm che l’attacco ad un database aziendale sono minimizzabili

grazie alla rapidità di intervento. Coniugare il sistema di centralizzazione e

correlazione di base con gli strumenti dell’E-mail, del SMS o della console permette

di controllare tutti i parametri di sicurezza di interesse e reagire di conseguenza.

Oltre ai sistemi di sistemi di correlazione in tempo reale ne esistono altri più

complessi e quindi più lenti nell’elaborazione delle informazioni. Questi sistemi

producono dei report periodici sull’insieme dei dati di sicurezza, permettendo di

evidenziare anche quei segnali più deboli che normalmente possono essere trascurati

come, ad esempio, lo scanning su un’unica porta ma su tutta la rete, la ripetizione di

login sbagliati prima che venga disabilitato l’account, la ripetizione di tentativi di

accesso falliti anche con account differenti ma su uno stesso sistema, tentativi di

escalation di privilegi su macchine di minore importanza. Non è possibile escludere a

priori la possibilità che un nuovo tipo di attacco, o la fiducia mal riposta in un

dipendente, permetta l’accesso non autorizzato, la modifica o la cancellazione delle

informazioni aziendali. In questo caso, la possibilità di gestire in modo appropriato il

consolidamento dei log permette di analizzare i metodi e le tecniche utilizzate violare

le politiche di sicurezza, fornendo le prove non falsificabili di quanto è avvenuto. E’

evidente che risultati come questi non sono ottenibili semplicemente installando un

8

dispositivo, ma serve selezionare e configurare la soluzione che offre il miglior

compromesso tra costo e risultati.

Tutti i vari problemi discussi evidenziano la necessità di monitorare e analizzare le

attività di ambienti sempre più eterogenei, centralizzando l’investigazione e l’analisi

dei dati. CS MARS (Cisco Security Monitoring Analisys and Response System) è un

dispositivo pensato per risolvere i vari problemi evidenziati in precedenza e che.

può avere due ruoli fondamentali per aumentare la sicurezza della rete.

• contribuisce ad aumentare la qualità della sicurezza della rete fornendo un

supporto per la comunicazione tra i vari dispositivi.

• permette di mitigare situazioni critiche con tempi di risposta in tempo reale.

L’obiettivo di questa tesi è quello di valutare tecnicamente le potenzialità del

dispositivo mediante numerosi test qualitativi. Le strategie di valutazione adottate si

basano sulle conoscenze dei protocolli di rete che forniscono la base per le varie

analisi considerate. Abbiamo cercato di misurare sia la capacità di rilevare attività

significative per la sicurezza della rete sia la precisione di MARS in fase di

rilevazione di scansioni, studiando se e come esso era in grado di distingure le

potenziali attività di interesse per la sicurezza complessiva quali, ad esempio, traffico

p2p, attacchi semplici, attacchi complessi, attacchi multistep e host based. La

valutazione dei risultati ha tenuto conto delle seguenti caratteristiche:

• Completezza: rilevamento di tutti gli attacchi (numero di falsi negativi)

• Accuratezza: rilevamento corretto (numero di falsi positivi)

• Performance di processing: numero di eventi analizzati al secondo

• Risposta agli attacchi

• Il grado di personalizzazione del dispositivo

L’ultimo punto sintetizza la capacità di poter modellare, attraverso

personalizzazione della configurazione del dispositivo, quelle attività di rete che non

sono rilevate nella configurazione standard e che dipendono quindi dalla specifica

rete considerata.

9

Struttura della tesi

I vari capitoli della tesi esaminano in maniera più approfondita i concetti presentati in

questa introduzione. La struttura dei capitoli è la seguente:

Capitolo 1: CS MARS concetti generali

Il capitolo descrive CS MARS, un dispositivo che permette di monitorare analizzare e

correlare i log generati da dispositivi firewall, router, switch, e sistemi operativi.

Capitolo 2: Test effettuatati per la rilevazione delle scansioni

Questo capitolo descrive alcune modalità di scansioni, i risultati ottenuti con la

configurazione di base di MARS e quelli ottenuti creando delle regole ad hoc.

Capitolo 3: Test per la rilevazione di attività Peer to Peer

Questo capitolo descrive i vari problemi da affrontare per rilevare le attività peer to

peer, e valuta la precisione di MARS con configurazione standard e con

configurazione personalizzata da regole specifiche.

Capitolo 4: Test sulla rilevazione di alcuni attacchi

Questo capitolo descrive alcune modalità standard di attacco ed analizza la

precisione del dispositivo nella rilevazione delle attività sospette.

Capitolo 5: Attacchi complessi condotti in più passi

Questo capitolo descrive attacchi complessi costituiti da più passi e analizza la

precisione di MARS con una configurazione personalizzata da regole che modellano

tali attacchi.

Conclusioni: questa sezione riassume brevemente il lavoro svolto concludendo con la

nostra valutazione.

10

Capitolo 1

1.1 CS MARS concetti generali In questo capitolo descriveremo uno degli strumenti utilizzati per effettuare alcuni

test relativi ad attacchi sulle reti.

CS MARS è l ’abbreviazione di Cisco Security Monitoring, Analysis and Responce

System, termini che mettono immediatamente in risalto le caratteristiche migliori di

questo dispositivo di terza generazione. MARS è in grado di raccogliere eventi grezzi,

chiamati comunemente “Log”, da altri dispositivi di rete, correla eventi in sessioni e

analizza profili di traffico rilevando anomalie. Inoltre è in grado di analizzare

incidenti di rete e progettare un percorso adeguato per esaminare vulnerabilità di

host e vulnerabilità correlate a scansioni. La maggior parte dei dispositivi di rete quali

firewall, router, switch, etc.., sono equipaggiati di un sistema di monitoring che

permette di tenere traccia delle attività svolte. Tali informazioni sono strutturate in

maniera diversa a seconda delle case produttrici e possono essere archiviate in un file

oppure inviate verso un raccoglitore di log chiamato syslog server. MARS raccoglie e

interpreta i log generati dalla maggior parte dei vendor. Il meccanismo di raccolta è

abbastanza semplice: ogni dispositivo viene configurato settando l’indirizzo ip di

MARS come syslog server. Dall’altra parte, MARS deve conoscere l’indirizzo ip dei

dispositivi generatori di log e un loro account necessario per diverse funzioni descritte

nei capitoli seguenti.

La caratteristica che rende questo dispositivo veramente unico è la cosiddetta

“mitigation” cioè un meccanismo che prevede contromisure immediate a Livello 2 o

a Livello 3 dello, stack dei protocolli,con una tempestività nell’ordine di pochi click.

MARS possiede poi delle caratteristiche che facilitano l’interpretazione delle attività

sulla rete spesso confuse e incomprensibili, tra queste citeremo i meccanismi di

reportistica e di investigazione di un incidenti. Prima di addentrarci nel vivo della

questione sarebbe opportuno dare alcuni cenni circa l’architettura e alcuni concetti

fondamentali che ne facilitano la comprensione. Il dispositivo è costituito da

11

hardware appositamente scelto per sopportare i carichi di traffico che devono essere

analizzati in tempo reale.

Da un punto di vista delle componenti, MARS è corredato di :

• Dischi rigidi Hot-swap RAID 1

• Multiprocessori

• Alimentazione ridondante

• Sistema software watchdog

• Intel Pentium or Xeon processor(s)

• DRAM memoria

• Interfaccia di rete 10/100/1000

• DVD-ROM drive

• Porta seriale

• Software proprietario

• Database Oracle

• Linux kernel v4.1.2

• Tomcat Web Server

Tutta la logica applicativa si basa su quattro concetti fondamentali:

• Gli eventi: messaggi grezzi inviati a MARS da dispositivi di rete.

• Sessioni: gruppi di eventi che hanno caratteristiche simili.

• Gli Incident: sessioni rilevate per inferenza di regole.

• Le regole: modelli che descrivono attività confrontate con le sessioni.

Tenendo presente i concetti appena espressi, è possibile adesso comprendere meglio

come lavora MARS: gli eventi arrivano a MARS da dispositivi di rete,

successivamente vengono bufferizzati, analizzati e formattati. Le informazioni appena

normalizzate vengono ulteriormente controllate e quelle che hanno caratteristiche

simili vengono accorpate in gruppi di sessioni. Le sessioni sono definite insiemi di

eventi, accomunati dallo stesso indirizzo Ip sorgente e lo stesso indirizzo Ip di

destinazione. Occorrenze di sessioni vengono confrontate con il modello descritto

dalle regole e se si verificano delle analogie viene generato un incident. Tali

Incidenti sono tempestivamente visualizzati nella pagina principale della console. Le

informazioni che coincidono con le Drop Rules vengono filtrate mentre tutte le altre

vengono memorizzate nel database. Ricordiamo che le Drop Rules sono regole che

individuano il traffico da filtrare.

Graficamente MARS si presenta con una console centralizzata, mostrata in fig.1,

dove vengono visualizzate tutte le attività in tempo reale:

12

Fig 1 La console presenta diversi tab che si dividono in:

• Summary dove vengono visualizzate le informazioni più importanti.

• Incidents per gestire la “incidents investigation”

• Query/Report per gestire la reportistica e informazioni del database

• Rules per gestire le regole di default e quelle create dall’utente

• Management per la gestione degli account per l’accesso a MARS e la gestione dei ruoli

• Admin per aggiungere, eliminare, registrare, configurare i dispositivi che inviano i log.

• Help che fornisce una documentazione on line

13

1.1.1 Il tab Summary è costituito da tre sottotab

• Il sotto tab Dashboard

• Il sotto tab Network status

• Il sotto tab My report

Il sottotab principale è il Dashboard diviso in quattro aree per una rapida

visualizzazione di tutte le reti connesse. Nella parte principale del dashboard ci sono i

cinque Incidenti più recenti mentre nella parte sinistra sono visualizzate le statistiche

di eventi, incitents, falsi positivi. Sotto gli Incidenti sono visualizzati rispettivamente

il grafo degli attacchi alla rete (fig. 2), il grafo di tutta la topologia della rete e i

report che contengono informazioni statistiche.

Il sotto tab Network status descrive lo stato della rete con grafici che specificano

diverse informazioni. Qui è possibile trovare tutte le informazioni circa il numero di

eventi in tempo reale, gli eventi totali ricevuti in un certo periodo di tempo oppure è

possibile ricavare informazioni sul traffico medio giornaliero, mensile etc.

Il sotto tab My report tiene traccia di quei report che l’utente utilizza frequentemente

oppure di tutti i report personalizzati e che vengono utilizzati di frequete. I report

possono rappresentare qualsiasi tipo di informazione sia in tempo reale sia per un

periodo di tempo ben determinato. I report sono molto utili per capire l’andamento di

grandezze come la quantità degli eventi inviati nell’unità di tempo ma soprattutto

quali eventi vengono generati. I report che rappresentano le medie o le percentuali

degli eventi o dei protocolli utilizzati sono molto importanti per capire le abitudini di

una rete. Eventi, che in media, non sono nella norma, nascondono tentativi di

intrusioni o qualche anomalia nella rete.

fig. 2

14

Il grafo degli attacchi, mostrato in figura 2, mette in risalto gli ultimi cinquecento

eventi relativi agli incident generati nelle ultime ventiquattro ore. Il grafo è costituito

da nodi rappresentati dai dispositivi mentre gli archi orientati rappresentano le

sessioni.

Clickando su un arco è possibile visualizzare tutte le sessioni rappresentate dal link e

il percorso seguito dal flusso del traffico. Clickando su un dispositivo è possibile

avere informazioni generali sul suo stato: indirizzo ip, se è un dispositivo attivo, se sta

inviando correttamente i log.

fig. 3

I grafici, in fig. 3, visualizzano lo stato della rete in tempo reale fornendo

informazioni circa le sorgenti che generano il traffico e le destinazioni, il regime di

eventi che arrivano al MARS, le regole utilizzate più di frequente, la gestione dei

dispositivi etc. Le modalità di visualizzazione per i grafici sono molteplici ed è

possibile anche modificare il refresh delle visualizzazioni.

Il tab Incidents permette di gestire gli eventuali incidenti. Un utente con sufficienti

diritti accede al tab e può effettuare ricerche per codice, per tipo di Incidente, i quali

15

sono organizzati in ordine cronologico cioè dal più recente al meno recente oppure

per ordine e per tipo di severità. Inoltre è presente una sezione della quale sono gestiti

Incidenti secondo i casi di studio assegnati cioè vengono assegnati agli utenti Analisti

che si occupano della investigazione. Finita l’analisi e compreso il problema,

l’incident è risolto quindi chiuso.

1.2 Incidents Investigation Ogni incident visualizzato è caratterizzato da una serie di informazioni che mettono

in risalto :

• Cosa è successo

• A chi è successo

• Quando e come è successo

L’incident a seconda della regola che lo ha generato può essere più o meno grave. La

fig. 4 mostra le tre tipologie rosso, verde e giallo:

fig. 4

• Rosso segnala un incident di massima allerta che deve immediatamente

essere preso in considerazione.

• Giallo segnala tentativi di attacco che sono stati respinti ma che devono essere

analizzati per capirne meglio la natura.

16

• Verde segnala un Incident che può essere stato causato da errori di

configurazioni, tentativi di scansioni, o variazioni drastiche del volume di

traffico.

A ogni Incidente generato associato un identificativo unico che permette

successivamente di individuarlo ed effettuare controlli incrociati in modo da

investigare sulle attività sospette.

Ovviamente ogni Incidente è accompagnato da una descrizione sia dei tipi di eventi

che lo caratterizzano sia del modello di attacco rappresentato dalla regola che lo ha

generato.

Un esempio di Incidente e di correlazione è un tentativo di scansione seguito da un

tentativo di penetrazione nella rete. L’Incidente include anche una descrizione della

notifica generata dalla regola, un time range cioè l’intervallo di tempo entro il quale si

è verificato, un link che rimanda alla visualizzazione del grafo e un link che rimanda

a una visualizzazione più dettagliata mostrata in fig. 5:

.

fig. 5

Nella figura 5 vengono mostrate in dettaglio tutte le caratteristiche dell’Incident :

è da notare come oltre agli elementi già descritti compaiono anche elementi circa le

sessioni, indirizzi Ip e porta sorgente, indirizzo Ip e porta destinazione, tipo di

protocollo e il tipo di dispositivo che lo genera.

17

18

MARS dispone anche di diversi privilegi di accesso che dipendono dai ruoli assegnati

ai vari utenti:

• Administrator: ha un accesso incondizionato per tutte le modifiche e

configurazioni.

• Security Analist: ha accesso alle funzioni di MARS per quanto riguarda

“l’incident investigation” ma non può effettuare modifiche sulle

configurazioni.

• Operatore: può avere visibilità delle varie visualizzazioni e reportistiche

• Notification Only: non ha accesso al MARS ma riceve notifiche sullo stato

della rete e sulla reportistica

I ruoli sicuramente più interessanti sono quelli di Amministratore e Security Analist.

Quest’ultimo analizza gli Incidenti generati. Lo studio prevede un percorso ben

definito che è caratterizzato da piccoli passi consecutivi che facilitano sia l’utilizzo di

questo strumento sia la comprensione di quello che accade sulla rete.

L’analista quindi accede a MARS e seleziona un Incident nella coda; la quale può

essere ordinata cronologicamente dal più recente al meno recente, oppure è possibile

filtrare gli Incident per livello si pericolosità. Selezionato l’incident si procede

individuando la regola che lo ha generato e l’attività che descrive. L’investigazione

continua studiando il grafo di attacco, il dispositivo sorgente. Successivamente si

passa all’analisi delle sessioni e quindi allo studio degli indirizzi Ip sorgente e

destinazione, delle porte utilizzate dai protocolli e dai servizi. Tutte le sessioni

riportano il tempo esatto in cui sono state generate e l’incident visualizza il periodo di

tempo che abbraccia tutte le sessioni.

1.3 Correlazione degli incidenti

Eventi, sessioni e altri elementi sono contenuti negli Incidenti. A volte però si

verificano attività più complesse che generano diversi Incidenti in tempi diversi. In

questo caso MARS unisce gli Incidenti secondo una specifica correlazione. Ad

esempio un tentativo di penetrazione eseguito in tempi diversi genera un Incidente

che unisce tutti i diversi tentativi. A seconda della frequenza e dal risultato conseguito

dall’attacco, MARS correla gli eventi e genera un Incidente che riassume globalmente

cosa è accaduto. Un esempio è il tentativo ripetuto di login su un sistema; sbagliando

la password per almeno tre volte MARS genera un Incidente che descrive un

tentativo di intrusione. Se invece dopo al più due tentativi, il login va a buon fine

allora MARS notifica un Incident che descrive l’accesso di un utente al sistema. La

figura 6 descrive la regola e la correlazione degli eventi.

fig. 6

19

20

1.4 La mitigation In casi di tentativi di attacco violenti o comunque azioni invasive che creano Denial

of service è possibile scorrere nell’incident e clickando sul link “mitigate”

intraprendere delle azioni di contromisure. La mitigation fornisce una serie di

soluzioni che vanno a modificare la configurazione dei dispositivi interessati da

eventi critici. Se un host di una rete è stato infettato con un worm e se tale worm

cerca di propagarsi, un incident appropriato viene visualizzato. Dal link Mitigate è

possibile scegliere le contromisure da adottare. Tali soluzioni sono scelte dall’utente

ma vengono completamente eseguite da MARS in maniera del tutto automatica.

Questo è possibile perché il dispositivo è stato registrato nel database di MARS con il

suo indirizzo ip e con un accout per l’accesso. Infatti, selezionata la soluzione da

adottare, MARS accede al dispositivo con l’account fornito in fase di registrazione e

modifica la configurazione. Le soluzioni possono essere diverse a seconda del

problema e a seconda delle possibilità dei dispositivi. Se l’host interessato dal worm

si trova in una rete in cui c’è un switch che implementa la mitigation, MARS può

accedervi e creare una access list per l’indirizzo IP dell’ host al fine di bloccare il

traffico maligno. Le soluzioni proposte possono essere drastiche, infatti un evento

di massima allerta che descrive un tentativo riuscito di intrusione può richiedere la

massima tempestività nelle contromisure.

In questo caso “la mitigation” potrebbe non andare tanto per il sottile e suggerire

l’isolamento di tutta la rete così da impedire all’intruso di provocare danni

potenzialmente irreparabili.

Ovviamente da un punto di vista tempistico una “mitigation” immediata presuppone

una soluzione non elegante e brutale talvolta ridotta a un solo comando.

Invece una mitigation più precisa presuppone diversi accorgimenti ma maggior

tempo per metterla in pratica perchè richiede più comandi. Quindi in base alle

esigenze e alle situazioni MARS propone delle soluzioni proporzionali al fattore di

rischio della rete.

In fig. 7 sono riportati alcuni esempi di soluzioni di mitigation proposti da MARS a

seguito di tentativi di intrusione via ssh:

fig. 7

1.5 I falsi positivi Incidenti che analizzati, non costituiscono minacce, possono essere catalogati come

falsi positivi. I falsi positivi sono Incidenti che descrivono attività sospette non vere.

Si possono catalogare tipi di Incidenti:

• Dovuti a traffico che genera un allarme causato da eventi di rete spesso non

malevoli

• Contromisure non adeguate che generano pacchetti considerati sospetti

• Allarmi di violazione di protocollo causati da traffico di rete sconosciuto

spesso dovuto da errori di scrittura di codice client

• Allarmi che vengono generati per qualche strana ragione, spesso dovuti a bug

nel software

• Allarmi generati inconsciamente da qualche azione manuale degli utenti.

21

22

Data la loro varia natura è anche difficile riconoscerli e quindi eliminarli. MARS

fornisce un sistema che fondamentalmente permette di imparare dalla storia: falsi

positivi che si sono verificati in passato possono servire a rilevare futuri falsi positivi.

Quando un Incident viene visualizzato e ci si accorge che è un falso positivo, è

possibile applicare la modulazione, cioè adeguare MARS, verso una rilevazione di

Incidenti quanto più fedele alla realtà. La pagina di modulazione permette di settare

indirizzi, porte, protocolli che conosciamo essere innocui. Molto spesso in alcune

realtà aziendali vengono dedicate delle porte per alcuni servizi. È possibile che per

motivi implementativi alcune porte dedicate ai servizi e conosciute come tali da

MARS, non possono essere utilizzate, quindi se ne utilizzano altre. Il traffico

generato dalle richieste per un servizio su porte sconosciute può generare falsi

positivi. La modulazione permette di far “apprendere ” a MARS che determinati

flussi sono dovuti a traffico di rete normale e quindi non sono tentativi di attacco o di

intrusione.

MARS ricorda la storia dei falsi positivi e in base a questi cerca di eliminarne altri.

Ogni Incident rilevato ha un link per la modulazione dei falsi positivi che vengono

gestiti e divisi in :

• Falsi positivi non confermati che hanno bisogno della notifica per essere

considerare tali.

• Falsi positivi confermati dall’amministratore

• Positivi confermati dall’amministratore cioè attacchi che erano considerati

falsi positivi

• Falsi positivi confermati dal sistema.

Una volta accertato la natura di un evento si può quindi confermare o smentire MARS

in maniera tale da aumentare la qualità del monitoraggio.

Una modulazione con criterio implica una buona conoscenza delle attività, dei

protocolli, dei software e dei servizi utilizzati in modo tale da capire e soprattutto

“far capire a MARS” le abitudini della rete.

23

1.5.1 Il tab Query/Report

Il tab Query/Report permette di effettuare query o report visualizzati in formato

html, pdf oppure cvs. Le query sono divise per gruppi. Ogni query ha una tipologia

associata che rappresenta il tipo di attività che vogliamo utilizzare, ad esempio attività

di tipo peer to peer oppure attività di attacchi DoS etc. A ogni tipologia di query

possono essere associate sotto query che specificano le informazioni da ricavare. Le

sotto query sono di due tipi:

• quelle che specializzano il range di tempo nel quale reperire gli eventi; tale

range può essere:

-un Range di date ad esempio dal 01/04/2006 al 01/05/2006

-un Range predefinito settimanale, mensile, annuo.

-un real time Range per query in tempo reale.

• quelle che specificano le sorgenti degli eventi o i tipi di traffico:

-Indirizzo ip del dispositivo

-Range di indirizzi ip

-Tipo di protocollo

-Numero di porta

Ad esempio per sapere se il dispositivo con indirizzo Ip xxx.xxx.yyy.yxd sta

effettuando del peer to peer eseguiano una query con tipo di eventi “p2p” e per sotto

query i parametri “ip del dispositivo ” e “time range = real time ”.

Oltre alle query in tempo reale è possibile effettuare anche delle batch quary cioè

delle query che hanno bisogno di più tempo per essere eseguite e che quindi vengono

schedulate.

Se si vuole sapere quanti eventi ha generato una rete nell’arco del mese allora la

query da eseguire è una “batch query” in quanto la mole di dati non consente una

elaborazione in tempo reale. Le batch query eseguite sono memorizzate in questo tab

ed è sempre possibile consultarle. Ricordiamo che è possibile anche personalizzare

tipi di query; se vogliamo tenere costantemente sott’occhio alcuni eventi di una

determinata rete, possiamo creare un query personalizzata che mantiene i parametri

24

che altrimenti dovremmo settare ogni volta che si lancia una query. Da un punto di

vista concettuale, la generazione dei report è pressoché identica all’esecuzione delle

query, cambiano ovviamente alcuni parametri.

Per i report ci sono modelli che determinano informazioni sul traffio effettuato, sulla

banda consumata, sui siti più visitati e quant’altro. Come per le query anche per i

report c’è la possibilità di settare alcuni parametri di specializzazione. I report

vengono generati per avere una visione grafica degli andamenti di alcune grandezze

che altrimenti con tabelle e numeri sarebbero meno intuitivi. Graficamente la banda

consumata da un dispositivo, magari divisa per tipo di protocolli utilizzati è molto più

esplicativa di una tabella con dei numeri.

1.6 Le regole

1.6.1 Il tab Rules

Come detto in precedenza tutte le notifiche di Incident vengono generate perché

alcuni eventi inviati a MARS descrivono attività che coincidono con i modelli

rappresentati dalle regole. Entrando più nel dettaglio le regole sono espressioni

regolari che modellano determinate attività. Gli “attacchi”, possono essere facilmente

rilevati in tempo reale se i modelli, rappresentati delle regole, sono simili.Se settate in

maniera opportuna, le regole aiutano a capire se un falso positivo deve essere

cancellato completamente oppure può essere conservato nel database. Queste

decisioni vengono prese in base alle caratteristiche del falso positivo.

Alcuni di essi essere cancellati se esistono incident, generati dagli stessi eventi, in

grado di interpretare correttamente le attività. Quando si analizza il tipo di errore è

conveniente utilizzare l’incident relativo e non quello che è stato dichiarato falso

positivo.

I falsi positivi possono anche essere utilizzati per rilevarne altri, quindi sono tenuti

nel database. In totale MARS dispone di 104 regole di sistema che rilevano

25

anomalie. Altre sono aggiunte dagli aggiornamenti o comunque è possibile crearle

secondo determinate esigenze.

Tutte le regole sono definite come espressioni regolari e operatori logici. Una

espressione rappresenta un modello di attività. Se una regola è descritta da più

espressioni allora tali espressioni sono legate fra loro da operatori logici.

Siano e1, e2, e3 delle espressioni che specificano modelli di attività in qualche modo

collegati. Se la regola modella un’attività il cui comportamento implica il verificarsi

delle sotto attività e1, e2, e3, allora la regola è descritta come l’AND delle sotto

attività:

e1 AND e2 AND e3

Se la regola deve descrivere una attività che implica il verificarsi delle attività e1, e2

oppure dell’attività e3, tale regola diventa:

(e1 AND e2) OR e3

Laddove è necessario esprimere un certo ordine temporale delle attività, ad esempio

se una regola è definita dall’attività e1 successivamente seguita dall’attività e2,

MARS ha a disposizione la keyword FOLLOWED-BY

Dunque la regola diventa:

e1 FOLLOWED-BY e2

Una regola può avere una o più espressioni, in tal caso ogni espressione ha un

proprio id chiamato offset. Se una regola ha tre offset significa che è composta da tre

espressioni. La figura 8 riporta un esempio di regola:

fig. 8

Ogni regola è caratterizzara da:

• Una descrizione che identifica il modello di attività rilevato

• Lo stato della regola cioè se è attivata o meno

• Il time range cioè l’intervallo di tempo ammissibile dentro il quale deve

verificarsi l’espressione regolare

• Una serie di offest collegati da operatori logici

Ogni offset ha le seguenti caratteristiche:

• nessuna o più parentesi secondo la precedenza degli operatori

• Indirizzo IP sorgente

• Indirizzo IP destinazione

• Identificazione del servizio

• Una collezione di eventi che lo determinano

• Il dispositivo da cui sono stati generati gli eventi

• Il livello di allarme che può essere rosso giallo o verde

26

27

• Un contatore settato a un numero che indica quante volte almeno deve

verificarsi l’offset

• Un operatore logico se l’offset è seguito da un altro offset.

In corrispondenza dei campi indirizzi IP sorgente e destinazione possiamo anche

settare delle variabili il cui valore risulta essere un insieme di indirizzi non

necessariamente appartenenti alla stessa rete. Ci sono anche costanti di default che

specificano tutti gli indirizzi: ANY, o variabili che specificano lo stesso ip: SAME.

Allo stesso modo è possibile specificare variabili anche per i servizi e per le porte dei

servizi. Settare una variabile all’interno di un offset significa passare il valore di

queste variabili. La notazione di MARS si avvicina molto a linguaggi di tipo script.

Infatti quando si vuole esprimere il valore di alcune variabili si usa il carattere

speciale “$” seguito dal nome della variabile.

Come detto in precedenza ci sono regole di default cioè già presenti nel database di

MARS, queste regole si chiamano Inspection rule. Le regole che possiamo creare

vengono chiamate User Rule. Le Inspection rules non possono né essere modificate

né essere cancellate. Tuttavia è possibile copiare una Inspection rules facendola

diventare una User rule che può essere modificata o cancellata. Creare una regola è

molto semplice è intuitivo.

La possibilità di lanciare un wizard rende tutto molto semplice, naturalmente creare

una regola vuol dire avere la necessità di modellare e quindi rilevare un’attività

sospetta particolare. In questo caso un buona conoscenza dell’attività in questione in

termini di comportamento è fondamentale per creare una buona regola.

Ad esempio potrebbe essere molto utile creare una regola se vogliamo rilevare attività

particolari di host per determinati protocolli, oppure l’utilizzo di regole “ad hoc” per

rilevare un particolare protocollo o servizio, può aiutare ad evidenziare un problema

che altrimenti sarebbe generalizzato, ancora è possibile aggiornare regole che

descrivono protocolli ormai obsoleti creandone delle simili. E’ il caso dei protocolli

P2P che aggiornano continuamente le porte dei servizi.

28

1.6.2 Il tab Management

Il tab Management permette di gestire al meglio MARS da un punto di vista

amministrativo.

L’interfaccia ha alcuni link che permettono la gestione degli account e dei privilegi da

assegnare agli utenti creati e pattern di ogni genere utilizzati per altri tab.

Nel tab management è possibile creare un utente e assegnargli i privilegi in funzione

del suo ruolo. Se l’utente farà parte del team “incident investigation” allora i suoi

privilegi saranno di “Security Analist”. Inoltre da qui viene gestita tutta la

personalizzazione dei pattern per quanto riguarda le variabili di query, regole e di

eventi. Il Management offre la possibilità di creare variabili che identificano un tipo

di servizio oppure protocolli che utilizzano una determinata porta. Gli eventi hanno

una loro severità e la personalizzazione di questi passa attraverso la creazione o la

modifica alcuni parametri. Ogni gruppo ha un id, una descrizione, un severità, un

identificativo del dispositivo e un insieme di eventi che lo caratterizzano. Per creare

quindi un gruppo occorre settare tutti i parametri descritti.

Creare un gruppo di eventi è molto utile per definire regole che rilevano attività

rappresentate dai log di dispositivi che MARS non conosce, tali dispositivi hanno

formati di log non interpretabili. È possibile creare dei pattern che identificano delle

reti o un range di indirizzi Ip, che si rivelano essere molto utili quando si vogliono

creare delle regole solo per determinati host della rete. Inoltre questo tab offre la

possibilità di gestire azioni di notifica causate da incident. Poiché un incident

potrebbe significare l’inizio di un attacco distruttivo, il sistema di notifica (via sms,

via mail, via telefono) avvisa l’amministratore circa lo stato delle attività in corso.

Ovviamente possiamo settare il sistema in maniera tale da generare notifiche

immediate per incidenti disastrosi e notifiche meno immediate per quelli che non

richiedono particolari interventi.

29

1.6.3 Il tab Admin

Il tab rappresenta l’interfaccia da dove è possibile gestire i dispositivi che inviano

log. Ricordiamo che registrare significa mettere MARS in condizioni tali da dialogare

con il dispositivo per eventuali notifiche o mitigation. Di default, attualmente,

MARS conosce la maggior parte dei dispositivi di rete. Tra i più famosi ricordiamo

Checkpoint, ovviamente Cisco, Junipeer, Net Screen, IIS, McAfee, Snort, Symantec.

Tra questi ci sono anche sistemi Linux, Windows, Solaris cioè sistemi che hanno la

possibilità di inviare dei log interpretabili.

Naturalmente a causa della vasta eterogeneità dei dispositivi, il formato dei log sarà

diverso a seconda dei vendor. La sezione “Device configuration end Discover” offre

la possibilità di aggiungere un dispositivo al database di MARS. Se il dispositivo non

è conosciuto è comunque possibile registrarlo, a patto che sia raggiungibile attraverso

internet. Se il dispositivo non è conosciuto allora i suoi log non sono interpretabili ed

è possibile creare un template che modella il formato degli eventi del dispositivo. Il

template creato sarà registrato con il dispositivo e messo a disposizione per tutti i log

che di quel formato. MARS supporta anche dispositivi che implementano l’intrusion

Prevention System, sistemi in sono in grado di prevenire forme di attacco effettuando

a priori analisi qualitative sui flussi di traffico.

L’IPS è un sistema in grado di bloccare le minacce prima che si diffondano. Un

dispositivo dotato di IPS analizza il contenuto dei pacchetti, controlla la presenza di

traffico maligno che viene bloccato. Il sistema di notifica di log permette di informare

MARS circa il tipo di traffico che transita sulle interfacce del dispositivo

aumentandone la qualità e la precisione del monitoraggio.

30

Capitolo 2

2.1 Test effettuati per la rilevazione delle scansioni Oggi la tecnologia internet ha avuto una larga diffusione. Il suo impiego consta di più

svariati usi, da quello prettamente domestico all’uso aziendale. Con l’aumento

dell’utilizzo di questa risorsa si è avuto anche una larga diffusione di minacce che si

traducono in termini di virus, spyware, malware e in ultimo ma non per importanza,

di attacchi mirati. Mentre le minacce di tipo virus/spyware sono invasivi verso la

rete e non mirano a un sistema obiettivo particolare, gli attacchi guidati hanno come

un obiettivo il cosiddetto “sistema target”. Molto spesso il “sistema target” viene

individuato o evidenziato attraverso una fase che precede l’attacco vero e proprio.

È in questa fase che un attaccante utilizza strumenti per la scansione di reti ed è

attraverso questo strumento che ottengono informazioni preziose, fondamentali

per organizzare un attacco.

In questo capitolo ci occuperemo di conoscere e analizzare gli strumenti di scansione

per poi prevedere un meccanismo in grado non solo di bloccare eventuali

informazioni che un attaccante può ricavare ma anche di rilevare i tentativi di

scansione stessa. Infatti conoscere una scansione e individuarne il tipo, risulta essere

un notevole risultato per aumentare le qualità difensive della nostra rete. Le scansioni

possono essere effettuate con una svariata quantità di software “ad-hoc” che a

seconda del modo con cui operano si classificano in strumenti di alta qualità e

precisione e strumenti di bassa qualità.

La qualità di una scansione è sicuramente la precisione del risultato:

una scansione è tanto più precisa quanto più riesce ad avvicinarsi alla vera

topologia del “sistema target” senza però essere rilevata dai sistemi di sicurezza.

31

Infatti alcune tipologie di reti prevedono strumenti in grado di dissuadere le scansioni

in modo che il risultato di quest’ultime sia fuorviante, oppure la scansione risulta

tanto invasiva da essere rilevata facilmente anche da sistemi target che non hanno un

alto coefficiente di sicurezza. Sicuramente tanto più è accurata la sicurezza del

“sistema target” tanto più deve essere accurata il tipo di scansione da effettuare verso

di esso. Quindi per testare sistemi di sicurezza molto accurati dobbiamo ricorrere a

strumenti che forniscano la possibilità di effettuare scansioni accurate. Viceversa un

sistema è qualitativamente sicuro se è in grado di gestire o meglio rilevare scansioni

accurate. Sotto questo punto di vista abbiamo pensato, per i nostri test, di utilizzare

uno dei migliori (se non il migliore) strumenti per le scansioni: Nessus versione

2.2.7.

Per quanto riguarda il “sistema target” abbiamo pensato a una tipologia di rete con un

alto coefficiente di qualità per quanto riguarda il suo sistema di sicurezza. Questo

coefficiente qualitativo risulta essere un apparato costituito da diversi dispositivi in

grado di rilevare, raccogliere, analizzare, correlare tutte le attività. Solitamente una

rete per utilizzare la risorsa internet deve necessariamente avere un dispositivo in

grado di gestire il traffico. Questo dispositivo può essere un modem, per impieghi

domestici, un router per tutti gli impieghi. Noi affiancheremo al router un dispositivo

firewall e un dispositivo per la raccolta, analisi e correlazione delle informazioni. Un

firewall è un dispositivo in grado di bloccare i tentativi di intrusione dall’esterno e di

notificare, tramite un sistema di monitoraggio remoto, tutti gli eventi che interessano

la rete. Il dispositivo in grado di raccogliere, analizzare e correlare i log è il CS

MARS. Per ulteriori chiarimenti si rimanda alla lettura del capitolo descrittivo. Come

detto più volte, MARS può ricevere log da dispositivi: router, firewall, swicth, server,

basta “registrarli”; analizza i log e correla quelli che provengono dalla stessa rete.

L’analisi prevede un meccanismo di matching con le regole di cui dispone.

Quando arrivano i log, MARS li filtra secondo la rete sorgente, apre le sessioni di

NAT e confronta gli eventi con le sue firme e se si creano le condizioni per le quali

un flusso di log “coincide” con un modello descritto da una regola, MARS produce

un evento complesso e suggerisce le contromisure qual’ora ce ne sia la possibilità. Il

primo passo da effettuare è configurare gli apparati di rete e descrivere il nostro

ambiente per test che effettueremo. La prima parte del nostro percorso sarà quindi

quella di illustrare l’ambiente e i passi di configurazioni effettuati.

Fig.1

In fig. 1 viene mostrato la semplificazione del nostro ambiente di test.

Infatti ci siamo limitati a descrivere solo quella parte di topologia della rete che ci

interessa. Molto più complessa risulta essere invece la topologia della rete originale

costituita da più di cento canali VPN verso il MARS utilizzati per la raccolta di

informazioni da altrettanti dispositivi. Il firewall che abbiamo adottato è un cisco Pix

501 con versione del frmware 6.3. Tale firewall ha due interfaccie una outside in rete

192.168.253.0 e una inside in rete 192.168.250.0. Sulla interfaccia Outside è stato

collegato un pc portatile ibm thinkpad t23 con indirizzo IP 192.168.253.169.

32

33

Sulla interfaccia Inside ci sono diversi dispositivi :

• MARS con indirizzo IP 192.168.250.108

• Un PC Linux Distribuzione RedHat 7.3 kernel ver. 2.4.18-3 con indirizzo ip

192.168.250.199. Sul sistema linux abbiamo abilitato il syslog e diretto i log

verso il MARS.

• Sulla rete si sono altri pc e diversi dispositivi di minore importanza.

La configurazione

I passi per registrare un dispositivo sono i seguenti:

Passo 1:

creare un account ssh o telnet in maniere tale da permettere il dialogo tra il

firewall e MARS

Passo 2:

aggiungere il device pix firewall su MARS

Configurati gli apparati e descritti gli strumenti che ci accingeremo ad usare, il nostro

scopo è:

testare il nostro “sistema target” fornendo uno spazio di prove costituite

essenzialmente da tutti i diversi tipi di scansione valutandone i risultati ottenuti.

Da un punto di vista puramente teorico possiamo vedere il nostro scopo come un

insieme di tanti sotto obiettivi. Un obiettivo è raggiunto se il test che lo specifica va a

buon fine, cioè se le ipotesi formulate trovano riscontro nel test. Dunque l’obiettivo

principale è raggiunto se sono raggiunti tutti i sotto obiettivi.

34

Sia Oj un sotto obiettivo che appartiene all’insieme delle prove dell’obiettivo O.

Allora l’insieme O, con cardinalità n, e si scrive |O| = n, è valido se

O = O1 and O2 and ……and On

Ogni sotto obiettivo Oj è caratterizzato da alcuni parametri che costituiscono le

condizioni dei test. Le condizioni sono :

• configurazione MARS di default indicata dalla costante D_C o

personalizzata, identificata dalla variabile c_p

• nessus configurato in modo da non effettuare ping Icmp e Tcp indicato dalla

costante N_C

• scansioni su un range di porte da 0-10000 (le porte di interesse sarebbero da 0

a 1024 su un totale di 65000) indicato dalla costante S_P

- il traffico globale convogliato al MARS indicato dalla variabile t_g

- la frequenza degli eventi al secondo indicato dalla variabile f_g

- il tipo di tecnica utilizzata per effettuare la scansione indicata dalla

variabile s_u

- il rumore generato dalla scansione indicato dalla variabile f_r

Quindi un generico sotto obiettivo è definito come Oj ( D_C|c_p, N_C, S_P, t_g, f_g,

s_u, f_r )

Le costanti D_C, N_C, S_P saranno parametri per tutti i test, salvo che per obiettivi

non raggiunti. In quel caso utilizzeremmo la variabile c_p.

Il risultato è caratterizzato dal modo con cui il sistema di sicurezza rileva o meno la

scansione e quali informazioni ricava.

L’obiettivo finale è dunque :

Costruire un diagramma discreto dello spazio dei test effettuati, risaltando la

precisione del CS MARS al fine di ricavarne un limite qualitativo delle capacità di

rilevare, correlare e interpretare i passi preliminari di un attacco.

2.3 Obiettivo 1

2.3.1 Test di scansione di tipo 1

La scansione di tipo 1 un prevede la seguente configurazione.

Hp rilevare la scansione sotto le seguenti condizioni:

- Il traffico convogliato al MARS in Maga Byte risulta essere in media

nell’ordine di 800 Mb al giorno t_g = 800 mb.

- Il regime degli eventi risulta essere di circa f_g = 75 eventi**/sec

- La tecnica di scansione utilizzata è s_u = “TCP Connect”

- Il rumore generato dalla scansione risulta essere f_r = 8 eventi / sec

Il sotto obiettivo è O1 ( D_C, N_C,S_P, t_g, f_g, s_u, f_r ).

La tecnica TCP Connect definita nella variabile s_u è rumorosa perché Nessus tenta

di stabilire una connessione tcp (3.way.handshake) secondo la rfc relativa, su tutto il

range di porte selezionato. Eseguendo Nessus, MARS interpreta la scansione con un

regola, mostrata in fig. 2 e definita nel seguente modo:

fig. 2

La regola genera un evento se nell’arco di un minuto si hanno almeno 20 eventi di

tipo : “FirewallPolicyViolation/ACL o FirewallPolicyViolation/NAT”.

* si precisa che ogni evento è costituito da un record inviato a MARS vale a dire una riga di log che rappresenta

una generica azione rilevata dal sistema target

35

36

Il risultato ottenuto è il seguente :

per questo tipo di configurazione e sotto queste condizioni il MARS rileva la

scansione fornendo dettagli su tutti i tentativi di connessioni, l’indirizzo IP

dell’attaccante e le porte interessate. Naturalmente un settaggio più accurato dei

parametri della regola aumenta la precisione della rilevazione. Per il momento ci

limitiamo a questa configurazione di base.

2.4 Obiettivo 2

2.4.1 Test di scansione di tipo 2

La scansione di tipo 2 prevede la seguente configurazione

Hp rilevare la scansione sotto le seguenti condizioni:

- Il traffico convogliato al MARS in Maga Byte risulta essere in media

nell’ordine di 800 Mb al giorno t_g = 800 mb.

- Il regime degli eventi risulta essere di circa f_g = 60 eventi†*/sec

- La tecnica di scansione utilizzata è s_u = “Syn Scan”

- Il rumore generato dalla scansione risulta essere f_r = 4 eventi / sec

La tecnica “syn scan” è più discreta della precedente perché non stabilisce

connessioni ma si limita a interpretare solamente i flag di risposta.

* si precisa che ogni evento è costituito da un record inviato a MARS vale a dire una riga di log che rappresenta

una generica azione rilevata dal sistema target

Questa tecnica è stata lanciata con due diversi modi:

• s_u1 = “Insane”, tecnica che massimizza la velocità della scansione a

discapito dell’accuratezza e della discrezione.

Il sotto obiettivo è O2 ( D_C, N_C, S_P, t_g, f_g, s_u1, f_r ).

• s_u2 = “Polite”, tecnica più lenta ma molto più discreta.

Il sotto obiettivo è O2 ( D_C, N_C,S_P, t_g, f_g, s_u2, f_r ).

In entrambi i casi MARS rileva la scansione interpretando la stessa regola, mostrata

in fig. 3, utilizzata per rilevare la scansione con tecnica tcp.

Fig 3

37

In dashboard la scansione viene rilevata con l’incident mostrato in fig. 4:

fig. 4 Il risultato ottenuto è il seguente :

per questo tipo di configurazione e sotto queste condizioni il MARS rileva la

scansione fornendo dettagli su tutti i tentativi di connessioni, l’indirizzo IP

dell’attaccante e le porte interessate.

38

39

2.5 Obiettivo 3

2.5.1 Test di scansione di tipo 3

La scansione di tipo 3 un prevede la seguente configurazione:

Hp rilevare la scansione sotto le seguenti condizioni:

- Il traffico convogliato al MARS in Maga Byte risulta essere in media

nell’ordine di 800 Mb al giorno t_g = 800 mb.

- Il regime degli eventi risulta essere di circa f_g = 65 eventi‡*/sec

- La tecnica di scansione utilizzata è s_u = “Fin Scan”

- Il rumore generato dalla scansione risulta essere f_r = 4-5 eventi / sec

Il sotto obiettivo è O3 ( D_C, N_C,S_P, t_g, f_g, s_u, f_r ).

• La tecnica di scansione utilizzata è “Fin Scan” con modalità “Polite” e

“Paranoica”

• s_u1 = “Polite”,tecnica che massimizza la velocità della scansione a

discapito dell’accuratezza e della discrezione.

Il sotto obiettivo è O3 ( D_C, N_C,S_P, t_g, f_g, s_u1, f_r ).

• s_u2 = “Paranoica”, tecnica più lenta ma molto più discreta.

Il sotto obiettivo è O3 ( D_C, N_C,S_P, t_g, f_g, s_u2, f_r ).

*si precisa che ogni evento è costituito da un record inviato a MARS vale a dire una riga di log che rappresenta una generica azione rilevata dal sistema target

MARS rileva un incident con la seguente regola mostrata in fig. 5:

fig. 5

Risultato: Questo “incident” avverte che esiste un traffico che il firewall ha impedito

ma non rileva la scansione l’obiettivo per tanto non è andato a buon fine perché la

tecnica utilizzata e molto discreta e con la modalità “paranoica” viene generato anche

del traffico fuorviante.

In questo caso utilizziamo una configurazione personalizzata creando un sotto

obiettivo che sostituisce la costante D_C con la variabile c_p.

2.6 Obiettivo 4

2.6.1 Test di scansione di tipo 4

La scansione di tipo 4 un prevede la seguente configurazione:

Hp rilevare la scansione sotto le seguenti condizioni:

- Il traffico convogliato al MARS in Maga Byte risulta essere in media

nell’ordine di 830 Mb al giorno t_g = 830 mb.

- Il regime degli eventi risulta essere di circa f_g = 70 eventi§*/sec

*si precisa che ogni evento è costituito da un record inviato a MARS vale a dire una riga di log che rappresenta una generica azione rilevata dal sistema target

40

- La tecnica di scansione utilizzata è s_u = “Scan TCP Xmas Tree”

- Il rumore generato dalla scansione risulta essere f_r = 2-3 eventi / sec

Il sotto obiettivo è O4 ( D_C, N_C,S_P, t_g, f_g, s_u, f_r ).

• La tecnica di scansione utilizzata “Scan TCP Xmas Tree” detta anche ad

albero di natale, è eseguita in modalità “Polite” e in “Stealth”. Questa

tecnica prevede l’invio di un pacchetto FIN, URG e PUSH alla porta

target. Secondo la RFC-793, il sistema dovrebbe rispondere con RST per

tutte le porte chiuse.

Questa tecnica è stata lanciata con due diversi modi:

• s_u1 = “Polite”, tecnica che massimizza la velocità della scansione a

discapito dell’accuratezza e della discrezione.

Il sotto obiettivo è O4 ( D_C, N_C, S_P, t_g, f_g, s_u1, f_r ).

• s_u2 = “Stealth”, tecnica più lenta ma molto più discreta.

Il sotto obiettivo è O4 ( D_C, N_C, S_P, t_g, f_g, s_u2, f_r)

MARS rileva un incident con la regola mostrata in fig. 6:

fig. 6

Questo “incident” avverte che esiste un traffico che il firewall ha impedito ma non

rileva la scansione.

41

42

Risultato: anche in questo caso MARS non rileva la scansione ma lo stesso incident

del terzo test.

2.7 Obiettivo 5

2.7.1 Test di scansione di tipo 5

La scansione di tipo 5 un prevede la seguente configurazione.

Hp rilevare la scansione sotto le seguenti condizioni:

- Il traffico convogliato al MARS in Maga Byte risulta essere in media

nell’ordine di 830 Mb al giorno t_g = 830 mb.

- Il regime degli eventi risulta essere di circa f_g = 70 eventi***/sec

- La tecnica di scansione utilizzata è s_u = “TCP Null Scan”

- Il rumore generato dalla scansione risulta essere f_r = 2-3 eventi / sec

Il sotto obiettivo è O5 ( D_C, N_C,S_P, t_g, f_g, s_u, f_r ).

La tecnica di scansione utilizzata “TCP Null Scan” Adoperando questa tecnica

disattiveremo tutti i flag. Secondo la RFC-793, il sistema obiettivo dovrebbe

rispondere con RST per tutte le porte chiuse.

Questa tecnica è stata lanciata con due diversi modi: • s_u1 = “Polite”, tecnica che massimizza la velocità della scansione a discapito

dell’accuratezza e della discrezione.

Il sotto obiettivo è O5 ( D_C, N_C,S_P, t_g, f_g, s_u1, f_r ).

*si precisa che ogni evento è costituito da un record inviato a MARS vale a dire una riga di log che rappresenta una generica

azione rilevata dal sistema target

• s_u2 = “Paranoica”, tecnica più lenta ma molto più discreta.

Il sotto obiettivo è O5 ( D_C, N_C,S_P, t_g, f_g, s_u2, f_r). MARS rileva un incident con la regola mostrata in fig. 7:

fig. 7

Questo “incident” avverte che esiste un traffico che il firewall ha impedito ma non

rileva la scansione. È da notare come questa regola sia più restrittiva.

2.8 Risultato Anche in questo caso MARS non rileva la scansione ma lo stesso incident del terzo test. NOTA: è possibile modificare le regole in modo da individuare anche il tipo

specifico di scansione. In particolare è possibile modificare la condizione temporale

e del quantificatore degli eventi in base al tipo di scansione, ovvero modificare il

range di tempo e il numero gli eventi che si verificano.

In tal modo è possibile creare delle regole simili ma che mettono che rilevano non

solo una scansione generica ma anche se si tratta di una scansione aggressiva o una

scansione discreta.

43

2.9 Configurazione regole per la rilevazione delle

scansioni Analizzando i manuali, editando/aggiungendo alcune regole o semplicemente

mettendo in evidenza gli eventi impliciti (in questo caso modificando gli eventi

rilevati da MARS ma che non determinano la scansione) è stato possibile configurare

MARS in maniera da far rilevare queste ultime scansioni. Da un punto di vista teorico

abbiamo sostituito negli obiettivi O3, O4, O5 il parametro costante D_C con la

variabile c_p modificando alcuni settaggi sulle regole.

I passi che sono stati effettuati sono i seguenti: 1. sono stati individuati gli eventi impliciti generati dal firewall in relazione alla

scansione. Tali eventi venivano generati, a seconda del tipo di scansione, con

ritmi e frequenze diverse.

2. una volta capito il modo e la frequenza con cui gli eventi sono stati generati è

stata aggiunta la seguente regola “generale”*:

Gli obiettivi O3, O4, O5 diventano rispettivamente:

O3 ( c_p, N_C,S_P, t_g, f_g, s_u, f_r )

O4 ( c_p, N_C, S_P, t_g, f_g, s_u, f_r )

O5 ( c_p, N_C, S_P, t_g, f_g, s_u f_r )

fig. 8

*la regola ha come condizione di rilevazione di un incident l’intersezione di tutte le modalità si scansione viste

negli obiettivi 3,4,5. In pratica abbiamo settato in “time range” e il rate count degli eventi in modo da rilevare tutte

le scanzioni. Per aumentare la precisione è consigliato di creare una regola per ogni caratteristica scansione.

44

La regola genera l‘Incident in (fig. 8) se nell’arco di 12 minuti si verificano almeno

dieci eventi di tipo “ConfigError/CiscoPix ecc”(sono gli eventi in figura ) con

protocollo di tipo tcp, stesso indirizzo IP sorgente e stesso indirizzo IP destinazione.

Una volta effettuata l’attivazione della regola, sulla dashboard, mostrata in Fig 9, compare:

Fig 9 Poiché nella regola creata è possibile aggiungere eventi generati da diversi dispositivi

in relazione alle azioni di scansioni, ulteriori test di scansione sono stati rilevati. Altri

test sono stati effettuati utilizzando strumenti diversi (Nmap, Looklan) e

sottoponendo alla scansione anche altri dispositivi (cisco 877, router zyxel 650 ). In

sostanza abbiamo provveduto a rieseguire il test modificando i sotto obiettivi che non

sono stati raggiunti a causa della configurazione di standard di MARS.

Formalmente questo significa sostituire ai sotto obiettivi in questione la costante D_C

con la variabile c_p. L’obiettivo principale diventa:

O = O1 and O2 and (O3.1 or O3.2) and (O4.1 or O4.2) and (O5.1 or O5.2)

Dove con O3.1 ,O4.1, O5.1 indichiamo rispettivamente i sotto obiettiv1 O3, O4, O5

con parametro D_C e con O3.2, O4.2, O5.2 gli stessi sotto obiettivi con parametro

c_p

Inoltre aumentando lo spazio di prove e studiando gli andamenti del traffico generato

dalle scansioni abbiamo aumentato la precisione creando un regola che si avvicina

quanto più possibile al modello reale. In figura 10 è mostrata la nuova regola:

45

Fig.10

La regola della fig.10 introduce alcuni elementi utili per modellare in maniera più

accurata un tentativo di scansione. La keyword “DISTINCT_ANY_DEST_PORT” è

stata utilizzata per tenere traccia delle tipiche sessioni di scansione che sondano le

porte in maniera incrementale o comunque porte diverse tra loro. Nello stesso record

è possibile notare che abbiamo filtrato le sessioni con porta sorgente 80 e 110 perché

non sono di scansione ma rispettivamente utilizzate dai protocolli http e pop3. Con

questi accorgimenti abbiamo ridotto drasticamente il numero dei falsi positivi.

2.10 Conclusioni MARS dispone di meccanismi che permettono facilmente la personalizzazione

dell’analisi delle attività.

Studiando una metodologia empirica che prevede simulazioni di attività specifiche e

personalizzazione dell’analisi, risulta quindi possibile rilevare qualsiasi tipo di attività

e conseguentemente progettare contromisure che possono offrire vantaggi in termini

di tempo e di costi. Per tutti i test abbiamo volutamente eliminato la possibilità di

effettuare il ping sia a livello di protocollo ICMP sia a livello TCP.

• Le modalità di scansione sono ordinate in modo decrescente rispetto al

fattore rumore.

• Le tecniche di scansione sono ordinate secondo la loro caratteristica

implementativa.

46

Una scansione di tipo “tcp connect “ è, di per se, facilmente rilevabile. Quindi non

avrebbe avuto senso impostare per questa tecnica diverse modalità. La tecnica di tipo

syn scan è meno invasiva delle prime due, quindi si è scelto per questa due modalità

di scansione intermedie da un punto di vista della rumorosità. Per la tecnica di tipo

“fin scan” abbiamo diminuito ulteriormente il livello di rumorosità, settando una

modalità “polite” e “stealth”. Per l’ultimo test abbiamo utilizzato il tipo di scansione

qualitativamente più precisa settando una modalità Stealh e “paranoica”. Lo spazio

degli obiettivi coperto secondo le condizioni precedentemente esposte risulta essere:

Gli obiettivi contrassegnati in nero sono quelli che hanno avuto esito positivo con

configurazione MARS di default. Quelli contrassegnati in verde sono gli obiettivi

che hanno avuto buon esito con una configurazione personalizzata cioè che hanno

come parametro la variabile c_p al posto della costante D_C. Quelli contrassegnati in

arancione sono obiettivi che con la configurazione di default non sono andati a buon

fine.

47

48

I valori assegnati alle variabili più significative sono riassunte nella seguente tabella:

Parametri t_g f_g s_u f_r

Obiettivi

O1 800 MB 75 Tcp Connect 8

O2.1 800 MB 60 Syn Scan Insane 4

O2.2 800 MB 60 Syn Scan Polite 4

O3.1 800 MB 65 Fin_Scan Polite 4-5

O3.2 800 MB 65 Fin_Scan Paranoica 4-5

O4.1 830 MB 70 Scan Xmas Tree Polite 2-3

O4.2 830 MB 70 Scan Xmas Tree Stelth 2-3

O5.1 830 MB 70 Tcp Null Scan 2-3

O5.2 830 MB 70 Tcp Null Scan 2-3

Abbiamo voluto classificare i sotto obiettivi in base alle modalità e alle tecniche più

significative fornendo uno spazio bidimensionale. Le altre variabili sono meno

rilevanti in quando o dipendono fortemente da quelle che abbiamo evidenziato o sono

costanti per tutti i sotto obiettivi. Le modalità di configurazioni che abbiamo testato

coprono, sufficientemente, tutto lo spazio di prove perché inglobano i risultati di

quelle che non sono state testate; ad esempio, la configurazione definita nell’obiettivo

O3.2, permette rilevare scansioni con caratteristica Tcp Connect, utilizzata

nell’obiettivo O1, in modalità Aggressiva, Insane, Polite, Stelth e Paranoica.

49

Capitolo 3

3.1 Test per la rilevazione di attività Peer to Peer Il Peer to Peer è sicuramente una dei protocolli più diffusi nelle applicazioni internet

degli ultimi anni. Molte applicazione fanno uso di questa tecnologia per implementare

la condivisione di risorse. Sicuramente il suo utilizzo trova ampio spazio nelle

applicazioni che permettono di condividere file multimediali. Tali applicazioni

risultano eterogenee da un punto di vista architetturale rilevare, dunque bloccare le

attività P2P non è cosi banale. In una realtà aziendale le attività di condivisione di

files multimediali via internet oltre ad essere il collo di bottiglia delle prestazioni

della rete è soprattutto una falla di sicurezza macroscopica. Il nostro obiettivo in

questo capitolo è quello di rilevare attività di peer to peer utilizzando come strumento

MARS. Il seguente test ha lo scopo di studiare la bontà qualitativa dell’applience

cisco MARS nei confronti di una rete nella quale viene generato del traffico di tipo

P2P.

Definizione e descrizione dell’ambiente per il test

Fig 1 L’ambiente mostrato in Fig 1 è costituito da due linee adsl il cui traffico è gestito

rispettivamente da un router/firewall cisco 877 Series e un router Cisco 827 con

un firewall cisco pix 515.

Le RETE 1 è costituita dal Cisco 877 series e dal pc4 sul quale gira un sistema

operativo Windows XP professional. Sul pc4 è stato installato un software che

permette lo scambio e la condivisione dei dati con altri utenti connessi alla rete

internet. Possiamo trovare diversi software di file sharing ad esempio:

Kaaka, Edonky, Gnutella, Bit Torrent ed Emule.

Si è scelto di installare Emule versione 0.47 a, perché attualmente risulta essere il

più usato, dunque fornisce più file in fase di ricerca e quindi anche in fase di

download.

50

51

Il pc4 è connesso a internet tramite un router/firewall 877.

La scelta di questo device è stata dettata soprattutto perché dispone del sistema IPS

(intrusion prevention system), caratteristica già descritta nei capitoli precedenti e che

ha il grande vantaggio di analizzare i pacchetti e capirne la natura. Sui dispositivi

cisco che lo supportano, l’IPS non è abilitato di default, in questo modo sarà possibile

testare il traffico peer to peer sia con il sistema ISP sia senza. In un primo momento

effettueremo il test senza abilitare l’IPS, in questo caso il dispositivo invia al MARS

solo log grezzi. In questo primo test vogliamo osservare come MARS analizza e

correla log generici di un traffico peer to peer.

In un secondo momento abiliteremo il sistema IPS. Questo significa che il

dispositivo analizzerà il contenuto dei pacchetti e invierà informazioni peer to peer,

più dettagliate. Il log generato dall’IPS, per lo stesso tipo di traffico, è molto diverso

dal log generico, infatti mentre il generico riporta informazioni di connessioni, porte

e indirizzi, l’IPS, oltre queste specifica il tipo di P2P ad esempio bit torrent.

La RETE 2 è costituita da un router 827 cisco e un firewall cisco pix 515 con IP

inside 192.168.250.1. In questa rete toviamo MARS con Ip 192.168.250.108 e altri

dispositivi. Per la comunicazione, è stato configurato un tunnel vpn tra i due firewall.

52

3.2 Configurazione dei dispositivi

Questa sezione prevede i passi preliminari necessari per configurare i dispositivi. Le

configurazioni sono state effettuate in funzione dello specifico test:

“vogliamo monitorare e analizzare il traffico generato dal pc4 della RETE 1, per capire

se il dispositivo cisco MARS rileva, attraverso i log inviati, il tipo attività e nello specifico,

un’attività di tipo peer to peeer”

• Passo 1: configurare il cisco 877 per inviare in vpn tutto il traffico generato

dal pc4

• Passo 2: configurare il firewall pix 515 per accettare il traffico in vpn dal

cisco 877

• Passo 3:configurare il Cisco 877 per comunicare con MARS, ciò significa

creare un account ssh o telnet da passare come parametro in fase di

registrazione del dispositivo

• Passo 4: configurare MARS per comunicare con Cisco 877 ciò significa

effettuare la registrazione con l’account creato al passo tre

Il test è stato eseguito sotto se seguenti condizioni: -il traffico del canale dovuto al peer to peer circa 80 Mb in un ora

-il traffico globale convogliato al MARS circa 220 Mb in un ora

-la frequenza globale degli eventi al secondo convogliati al MARS circa 80

eventi al secondo

-il grado di rumore cioè il traffico non P2P generato nello stesso canale della

rete del P2P

-il dispositivo 877 cisco configurato senza IPS

Il MARS rileva in dashboard attività mostrata in fig. 2: .

fig. 2 L’attività che viene evidenziata descrive un generico “Incident” dove si rileva

un’attività di tipo “file sharing”. Clickando sull’incident è possibile osservare tutte le

righe che interessano quest’attività. In particolare è possibile osservare, dalla figura 3,

la sorgente dell’incident (10.10.10.4 cioè l pc4 ), le porte del servizio interessato (la

4662 la classica porta di servizio di emule ), il tipo di evento IP di destinazione,il

numero di sessioni:

fig. 3

Poiché la regola che genera l’incident è costituita da una serie di variabili che

identificano tutte le porte utilizzate da tutti i programmi peer to peer, tale incident

rileva un’attività peer to peer generica. In altre parole, se avessimo utilizzato un altro

programma ad esempio “torrent”, avremmo avuto lo stesso tipo di evento in

“dashboard”.

Ovviamente da un indagine più accurata, effettuando una investigazione sull ’incident

e osservando i parametri di quest’ultimo (in particolare ip destinazione, porte e

53

54

protocollo), è sempre possibile capire l’attività file sharing specifica, cioè se l’evento

è stato causato da emule o da torrent oppure è un falso positivo.

In conclusione con questa configurazione e quindi con log “grezzi” occorre un

ulteriore piccolo passo in più per scoprire il tipo specifico di ”file-sharing”.

3.3 Rilevazione P2P con l’aiuto dell’IPS La seconda parte del test, come pre annunciato, si basa sulla stessa configurazione

usata per il primo test con la differenza che è stato abilitato sul router 877 il sistema

IPS (intrusion prevention system). Il sistema IPS (Intrusion Prevention System)

consente di gestire il rilevamento di intrusioni. Sul sistema operativo del router è

possibile importare delle definizioni per le firme IPS. Una firma IPS è costituita da

un insieme di caratteristiche che specificano un tipo di peer to peer.

Il nostro router dispone di quattro firme che rispettivamente identificano i peer to peer

kaaza, Torrent, Edonky e Gnutella. Da Notare che per abilitare il sistema IPS si sono

effettuati ulteriori passi di configurazione sia sul router 877. Per uno studio più

approfondito delle configurazioni si rimanda alla consultazione i manuali Cisco.

3.3.1 Impostiamo il blocco dei peer to peer

Ora in dashboard, fig. 4, compare un nuovo “incident” che correla i log “grezzi ”

ricevuti precedentemente e i nuovi:

Fig 4

La differenza è che con il log IPS, MARS è in grado di riconoscere a priori il tipo

specifico di filesharing. Eseguendo una query per visualizzare i log IPS inviati in dal

nostro router è possibile osservare informazioni mostrate in fig. 5:

Fig 5

55

56

Chiaramente la voce Edonky Client si riferisce al client Emule che deriva

storicamente da Edonky. Con questo nuovo incident siamo in grado di riconoscere

subito di quale P2P si tratta e adottare le specifiche contromisure.

3.3.2 Le contromisure

Le contromisure che possono essere effettuate sono diverse a seconda delle scelte di

politiche aziendali e a seconda del tipo di file sharing che analizziamo.

Ad esempio per situazioni in cui rileviamo file sharing di tipo Kaaza o

Napster/Morpheus è possibile creare un filtro sulle porte di interesse e quindi bloccare

l’attività.

Con Emule, Torrent, il blocco risulta più difficile perché il loro funzionamento si

basa sul protocollo Kademlia.

Kademlia è un protocollo P2P ideato da Petar Maymounkov e David Mazières per

una rete di computer decentralizzato. I nodi sfruttano il protocollo di trasporto UDP.

Ogni nodo di questa rete è identificato con un # ID necessario per:

• Identificazione del nodo

• Calcolo distanza tra 2 nodi (non geografica, ma di rete) in uno spazio di ID

calcolata mediante l’or esclusivo dei 2 nodi.

Non ci sono server che tengono traccia dei client e dei file che condividono, ciò

viene fatto dai client presente in rete. Ogni client è anche un piccolo server.

Poiché ogni client è identificato da un valore di hash univoco, l’idea di Kademlia è di

associare una certa RESPONSABILITA’. Ogni client nella rete Kademlia agisce

come server per certe parole o fonti. L’hash del client determina la parola o le fonti

specifiche.

Obiettivo ricerca: trovare quei client che hanno la responsabilità relativa

all’argomento della ricerca in corso.

Le porte principali di emule sono mostrate in fig. 6:

fig. 6

In caso queste porte vengono bloccate da un firewall, il client emule si dice riceve dal

server un ID basso. Questo significa che non può comunicare direttamente con altri

nodi dunque effettua una connessione (inside to outside, consentita dal firewall )

verso un server e attraverso questa connessione riesce a condividere files (con

performance chiaramente basse).

Da qui nasce l’esigenza di studiare in maniera approfondita tutte le architetture

P2P al fine di modellare un sistema che permette il blocco totale.

Le soluzioni pensate possono essere di due tipi:

1. inibire tutto il traffico del pc su cui è installato emule.

2. abilitare su un device con caratteristiche IPS una firma “ad hoc”.

La prima soluzione è brutale: al pc viene inibito l’accesso totale alla rete. Questa

soluzione può essere seguita qualora non disponiamo di device con caratteristiche

IPS. Tale soluzione viene adottata da MARS attraverso la “mitigation”. La mitigation

è una soluzione possibile se MARS, nella topologia della rete, è in grado di accedere

57

a un dispositivo di “Layer 2” solitamente “switch”. L’accesso allo switch si ottiene

aggiungendolo nello stesso modo con cui è stato aggiunto il router cisco 877:

• Selezionare dalla dashboard del MARS Admin > System Setup > Security

and Monitor Devices > Add

Aggiunto il device di layer2, è possibile effettuare la “mitigation” cliccando dalla

“dashboar” sull’evento e poi su path mitigate (fig. 7):

fig. 7

Si aprirà una schermata dove è possibile effettuare la scelta del blocco del pc con un

semplice click.

La seconda soluzione è più elegante ma necessita che nella rete ci sia un device con

IPS contenente la firma “ad hoc”. Attualmente sul nostro router cisco 877 sono

caricate solo firme P2P per Torrent, Kazaa, Gnut

ella, Edonky.

Nulla vieta di scaricare dal sito della cisco le firme aggiornate per emule è bloccare

totalmente il traffico.

58

59

3.4 Il problema dei falsi positivi

Poiché il protocollo Peer to Peer non è solo utilizzato da applicazioni che

condividono file multimediali ma anche da applicazioni che lavorano in rete, la

rilevazione del “Peer to Peer multimediale “ risulta ancora più difficile. Le cause che

possono generare falsi positivi sono tante. Ci possono essere falsi positivi dovuti ad

altre applicazioni; nel nostro sistema target, per esempio, abbiamo una console

centralizzata che gestisce da remoto agent antivirus installati su diversi client. Gli

agent comunicano con la console e scaricano gli aggiornamenti, tutte attività

supportate dal protocollo peer to peer. È naturale quindi che MARS rilevi queste

attività come tali. Oppure possono verificarsi falsi positivi a causa di trasferimenti in

rete di file che in qualche modo generano, secondo il meccanismo di analisi delle

firme di MARS, attività di tipo peer to peer. Per fortuna MARS dispone di opzioni

per filtrare i Peer to Peer conosciuti o ritenuti lecite. Queste opzioni “educano”

MARS a riconoscere lo specifico traffico “innocuo” e a non targare tale traffico

come Peer to Peer. L’approccio al filtraggio dei cosiddetti falsi positivi deve essere

fatto con cura e solo quando si è sicuri che quel tipo di attività lo sia veramente. Altra

considerazione da fare è che il filtraggio educa MARS a riconoscere il falso positivo

specifico e non generalizzato,ciò significa che MARS riconoscerà solo sessioni simili

del falso positivo cioè sessioni costituite dallo stesso range di Ip sorgente e dallo

stesso range di Ip di destinazione.

Basta che ci sia un’attività simile ma diversa da un punto di vista di indirizzi IP

interessati che il problema si ripresenta. Un approccio, per risolvere questo problema,

potrebbe essere quello di creare delle regole “ad-hoc” per riconoscere il tipo di “peer

to peer multimediale”. Creare delle regole dunque che fanno lavorare MARS

esattamente come se ricevesse eventi da dispositivi dotati di IPS. Le regole possono

essere create in base alle porte utilizzate dalle applicazioni P2P, (ad esempio

sappiamo che emule adotta le porte tcp 4661, 4662 e udp 4671, 4672, etc..) e in base

agli eventi che l’applicazione specifica genera. Per capirci Emule, in una prima fase

genera traffico udp per la ricerca del server e per la ricerca di file, poi traffico tcp con

indirizzi IP sorgenti e destinazioni di tipo pubblico.

Quindi una regola per Emule, potrebbe essere creata filtrando le classi degli Indirizzi

privati e fornendo due offset sequenziali rispettivamente per traffico udp e tcp.

60

Una regola è tanto più efficace quanto più si conosce la natura dell’applicazione da

rilevare.

Quindi il metodo da seguire è studiare bene l’attività che vogliamo rilevare e poi

creare una regola che la rappresenti. Con questo approccio siamo riusciti ad ottenere

risultati soddisfacenti che implicano un affinamento ulteriore delle qualità di MARS.

In sostanza la dove si evidenzia un limite qualitativo di MARS è possibile spingersi

oltre con la personalizzazione delle regole in modo da allontanare questo limite.

Un grande aiuto in questo viene fornito dal supporto Cisco che in tempi brevi eroga

aggiornamenti in grado di facilitare alcuni problemi a qualsiasi livello di

configurazione.

61

Capitolo 4

4.1 Test sulla rilevazione di alcuni attacchi Questo capitolo descrive e valuta alcune modalità di attacco che utilizzano i processi

di “fingerprinting” per sfruttare le eventuali vulnerabilità dei sistemi.

Il caso considerato è quello di aziende che erogano servizi on line e che devono

permettere alla propria utenza di raggiungere determinate risorse, diverse a seconda

del tipo di servizio erogato: portali web, server di posta, server ftp, accounting di

dominio, protocolli ad-hoc per determinati software etc. Per fare in modo che tali

risorse siano fruibili dagli utenti, devono necessariamente essere pubblicate.

Pubblicare una risorsa significa fare in modo che un utente interessato possa

raggiungere il servizio da qualunque parte del mondo si trovi.

Un attaccante può sfruttare la raggiungibilità del servizio per scoprire le vulnerabilità

connesse e conseguentemente, costruire un attacco che le sfrutti. Se il dominio di

utenza è ben ristretto, allora è possibile aumentare la sicurezza di questi servizi

utilizzando la tecnologia delle vpn (virtual private network) cioè una connessione

autenticata e cifrata per ogni utente che vuole accedere ai servizi. Purtroppo per

motivi di costi e di gestione, le vpn sono applicabili solo a determinati tipi di servizi

ed a un ristretto numero di utenti, quindi non per servizi forniti su larga scala.

Assunta la presenza di vulnerabilità, alcune delle quali non note a priori, un buon

approccio alla loro gestione è quello di aggiornare continuamente i servizi o le

applicazioni e monitorare le attività che spesso vengono classificati come attacchi.

L'aggiornamento per quanto possa essere una prima barriera per gli attacchi non può

essere sufficiente per la sicurezza della rete aziendale perché aggiornare un servizio o

un software significa renderlo più robusto agli attacchi ma non elimina tutte le

possibili vulnerabilità. É probabile che un attacco possa sfruttare una vulnerabilità

non ancora eliminata. Ad esempio un database di virus può non contenere definizioni

62

di recenti “malware” o “trojan horse” quindi è un sistema vulnerabile perché esposto

a nuovi virus

Dove esiste un servizio pubblico è possibile scoprire le corrispondenti vulnerabilità,

basta avere a disposizione l’indirizzo ip della macchina su cui è allocato il servizio e

ovviamente un software in grado di effettuare scansioni.

In questo contesto è facile comprendere come possa essere utile cercare di monitorare

le attività delle macchine critiche al fine di rilevare attacchi e agire in maniera

tempestiva. Scoprire un attacco in corso su un server non è facile, occorrono

strumenti di monitoraggio ed analizzatori di eventi in grado di filtrare e visualizzare

all'amministratore di rete le informazioni nel giro di pochi minuti.

MARS è stato concepito per risolvere e gestire questi problemi quindi per valutare le

prestazioni possiamo simulare attacchi che sfruttino vulnerabilità riscontrate

attraverso scansioni. Il problema delle scansioni è gia stato ampiamente trattato nei

capitoli precedenti per cui ci soffermeremo soprattutto sulla fase di attacco

supponendo che la fase di scoperta dei sevizi e quindi delle vulnerabilità sia già stata

rilevata.

La figura 1 illustra l’ambiente creato per la simulazione costituito dai seguenti dispositivi:

Fig.1

La rete 1 con indirizzo 192.168.253.0 ha i seguenti dispositivi:

- router zyxel 650 h IP 88.44.155.33 Mask 255.255.255.248

- firewall cisco pix 510 IP outside 88.44.155.34 mask 255.255.255.248 inside

192.168.253.1

- switch cisco catalyst 500 express IP 192.168.253.2

- ibm e@Series Xeon bi_processore IP 192.168.253.100

- linux red hat 7.3. IP 192.168.253.4

63

64

Il server ibm e@series esegue il sistema operativo Windows 2003 Server.

Il monitoraggio e la notifica degli eventi di sistema sono gestiti dal tool Snare, che

permette la comunicazione con MARS. I servizi installati e configurati sono:

• Database oracle 9.2i

• Server ftp CesarFtp versione 0.93a

• Servizio IIS 6.0 per web server

• Mail server generico

I servizi su cui è stato possibile attivare il sistema di notifiche da remoto, sono :

• oracle db, riconosciuto dalla firme di MARS. La configurazione di oracle è

stata suggerita dai manuali sia di oracle sia di MARS. Il sistema di notifiche

funziona attraverso un meccanismo di query periodiche (ogni 3 secondi) che

MARS effettua sul DataBase autenticandosi con credenziali fornite in fase di

configurazione.

• IIS 6.0; il meccanismo di event logging è gestito da un tool Snare IIS

configurato per raccogliere eventi e inviarli a MARS su a intervalli periodici.

• Gli altri servizi sono monitorati attraverso il log si sistema.

Tutti questi servizi sono stati pubblicati, cioè resi accessibili dall’esterno assegnando

al server un indirizzo pubblico disponibile del pool 88.44.155.32 Mask

255.255.255.248. Poichè gli ip 88.44.155.33 e 88.44.155.34 sono stati assegnati

rispettivamente al router e al firewall nell'interfaccia outside, al server è stato

assegnato l'ip pubblico 88.44.155.36. Sul firewall è stata configurata una regola che

permette di accettare richieste dall'esterno per l'indirizzo 88.44.155.36 verso i servizi

installati. Al solito il compito di rilevare, analizzare, correlare i log è affidato al

MARS configurato in rete2.

65

4.2 Analisi e conduzione degli attacchi

Abbiamo già detto che l’esecuzione di un attacco richiede la conoscenza a priori del

sistema obiettivo dell’attacco stesso.

La conoscenza del sistema odiettivo è importante perché l’efficacia dell’attacco

dipende specificatamente dalle informazioni ricavate precedentemente.

Una scansione con software appropriati permette di ottenere informazioni utili che

determinano il tipo di attacco da sferrare, sfruttando la versione del sistema

operativo, le eventuali vulnerabilità, i servizi e le applicazioni.Gli attacchi considerati

in questa sezione, adottano le metodologie descritte e quindi sfruttano le vulnerabilità

che possono essere rilevate mediante scansioni. I software utilizzi per scoprire le

vulnerabilità sono:

Nessus 3.0 con definizioni delle plug in 2.0 aggiornate a settembre 2006.

Nmap v.4.00

66

4.3 Analisi delle vulnerabilità rilevate

Con la configurazione appena descritta abbiamo eseguito nessus e nmap da remoto.

I risultati ottenuti sono stati seguenti :

Host host36-155-static.44-88-b.business.telecomitalia.it trovate le seguenti falle si

sicurezza:

Trovata vulnerabilità per host36-155-static.44-88-b.business.telecomitalia.it ftp

(21/tcp)

Trovata vulnerabilità per host36-155-static.44-88-b.business.telecomitalia.it smtp

(25/tcp)

Trovata vulnerabilità per host36-155-static.44-88-b.business.telecomitalia.it http

(80/tcp)

Trovata vulnerabilità per host36-155-static.44-88-b.business.telecomitalia.it pop3

(110/tcp)

Trovata vulnerabilità per host36-155-static.44-88-b.business.telecomitalia.it ncube-lm

(1521/tcp)

In dettaglio:

Host 88.44.155.36

Tipo Porta Caratteristiche

Vulnerabilità

ftp (21/tcp)

Synopsis : Il server ftp è affetto da alcune falle di sicurezza Il server ftp è CesarFTP e gira su sistema Windows. Il suo banner è: 220 CesarFTP 0.99g Server Welcome !

Informazioni

smtp (25/tcp)

Un server Smtp è in esecuzioe su questa porta Il suo banner è : 220 *****************************0*****************************200************0*00

Informaz http Un web server è in esecuzione su

67

ioni (80/tcp) questa porta

Il server web remoto è : Microsoft-IIS/6.0

Informazioni

pop3 (110/tcp)

Un server pop3 è in esecuzione su questa porta

Vulnerabilità

https(443)

Un host remoto potrebbe usare una versione di OpenSSL che è obsoleta rispetto alle versioni 0.9.6m o 0.9.7d. Ci sono diversi bug in queste versioni che potrebbero a un hacker di causare un attacco “brute force”

Vulnerabilità

ncube-lm (1521/tcp)

IL Database remoto Oracle è vulnerabile al buffer overflow nella query SET TIME_ZONE. Un attaccante provvisto si un accaunt potrabbe usare questa falla per ottenere il controllo del database da remoto.

Vulnerabilità

ncube-lm (1521/tcp)

IL Database remoto Oracle è vulnerabile all'esecuzione di un comano remoto che permette a un attaccante di eseguire codice SQL arbitrario

Vulnerabilità

ncube-lm (1521/tcp)

IL Database remoto Oracle è vulnerabile all'attacco denial of service relativo a SOAP and XML. Un attaccante potrebbe sfruttare questa falla per disabilitare il database da remoto

Vulnerabilità

ncube-lm (1521/tcp)

Il Database remoto Oracle tnslsnr non ha password assegnata. Un attaccante potrebbe utlizzare questa falla per effetuare uno shut down.

. Abbiamo usato Nessus per simulare attacchi e testare la robustezza dei sistemi.

4.4 Vulnerabilità ftp

La prima simulazione di attacco è stata attuata con nessus configurato per testare i

server ftp e quindi le vulnerabilità del nostro sistema target su cui è installato il server

ftp Cerar versione 0.99g. L’attacco consiste nel provare ripetutamente via ftp

l’accesso alla url del server Cesar ftp.

Dopo aver mandato in esecuzione Nessus abbiamo osservato la dashboard di MARS.

Il risultato è riassunto in Fig 2.

Fig.2 Tra gli Incidenti è stato osservato il seguente n 134367878 che descrive un probabile

accesso non consentito a una url o a uno spazio ftp.

Entrando più nel dettaglio e clickando sull’Incidente è possibile notare, come

visualizzato in figura 3, tentativi di connessione verso il server windows 2003 da

parte dell’indirizzo 85.45.142.154, ip pubblico della rete nella quale è stato eseguito

Nessus.

68

Fig.3

La regola ha permesso di rilevare quest’attività, genera Incidente se vi sono più di

venti connessioni in un minuto. Inoltre dal campo dell’ora e della data è possibile

dedurre come tali connessioni siano correlate tra di loro. Infatti in fig. 3 e fig.4 in ogni

riga vi sono due tipi eventi diversi generati in tempi differenti ma con lo stesso ip

sorgente e stesso ip destinazione. Immaginando l’andamento del traffico e tenendo

presente il funzionamento del protocollo ftp è possibile stabilire che i due eventi

sono, rispettivamente, la connessione di controllo dei dati e la connessione di

trasferimento dati. Poiché tali tentativi si ripetono molte volte l’Incidente rilevato è di

livello giallo.

Fig. 4

69

70

In questo caso la rilevazione degli Incidenti ha permesso di effettuare una serie di

controlli e analisi che suggeriscono un’attività ftp anomala.

4.5 Attacco di tipo “denial of service” al mail server

Un attacco di tipo DoS (Denial of Service) non è un virus ma un metodo utilizzato

dagli hacker per impedire o negare agli utenti legittimi l'accesso a un computer.

Gli attacchi DoS vengono eseguiti di solito mediante degli strumenti DoS che inviano

molti pacchetti di richieste al server Internet preso di mira (di solito un server Web,

FTP, o di posta), saturando le risorse del server e rendendo il sistema instabile.

Qualunque sistema collegato a Internet e fornito di servizi di rete basati su TCP è

esposto ad attacchi.

Molti strumenti DoS sono in grado di eseguire attacchi distribuiti. Si immagini ad

esempio che un hacker installi di nascosto il proprio programma su molti computer

connessi a Internet. In questo modo otterrebbe un effetto ancora maggiore perché ci

sarebbero più computer che generano traffico. In questo caso è anche molto più

difficile individuare l'aggressore poiché il programma non viene eseguito

direttamente dal computer dell'aggressore; quest'ultimo infatti sta solo controllando il

computer su cui ha installato il programma di nascosto. Una simile situazione

descrive un attacco DoS distribuito (DDoS). I metodi per saturare le risorse variano a

seconda degli strumenti DoS utilizzati. Ad esempio, Smurf DoS attack utilizza una

richiesta echo ICMP (Internet Control Message Protocol) falsificata. Altri strumenti

DoS, come quelli della serie TFN (Tribe Flood Network), utilizzano la tecnica di

invasione SYN, che satura le risorse creando connessioni aperte a metà.

Nel nostro caso, il servizio pubblicato é quello della posta elettronica, quindi un

metodo valido per saturare le risorse del mail server è l’invio di numerose mail verso

il server.

Grazie alle firme di Nessus è stato possibile simulare un attacco “Worm” al server

mail sulla porta 25. In effetti questo tipo di attacco può anche essere catalogato come

un attacco di tipo “Denial of service” in quanto si cerca di impedire il servizio di

posta.

Comunque trattandosi di un attacco che utilizza come strumento la mail

continueremo a chiamarlo “mail worm”. Mandando in esecuzione nessus abbiamo

ottenuto il risultato illustrato in fig. 5 e in fig. 6.

Fig. 5 In dashboard subito compare l’Incidente del worm, a differenza dell’attacco ftp,

l’attacco “mail worm” è stato rilevato da MARS praticamente in tempo reale.

Infatti la tempestività della rilevazione dipende molto dal tipo di attacco: se l’attacco

è rumoroso perchè genera tanto traffico, la rilevazione è più facile. Al contrario, un

attacco discreto genera poco traffico e la rilevazione viene ritardata. La tempestività

dipende anche dal carico della rete se un attacco viene sferrato in una situazione di

carico consistente, la rilevazione sarà ritardata perché le code saranno sature e di

conseguenza il tempo di completamento aumenta. Comunque, grazie alla gestione

degli Incidenti secondo il livello di priorità (rosso, giallo, verde), gli eventi che

vengono considerati più importanti sono processati prima rispetto ad eventi che lo

sono meno. In figura 5 è possibile notare che l’Incidente relativo all’attacco ftp è stato

notificato prima dell’evento che descrive l’attacco al server di posta, anche se

quest’ultimo è stato eseguito prima.

71

La ragione per cui MARS cataloga l’attacco ftp con priorità maggiore rispetto

all’attacco mail sta nel fatto che mentre il flusso di mail viene bloccato dal firewall

impedendo così il successo dell’attacco, l’attività ftp non viene bloccata dal firewall

ma semplicemente rilevata come anomala.

Fig.6

La figura 6 mostra la regola che ha generato l’evento. La semantica della regola dice

che se vengono inviate più di venti mail in un minuto da un singolo host verso il mail

server, l’attività è considerata sospetta. Da notare che, in questo caso,gli eventi sono

stati rilevati attraverso l’analisi dei log del firewall. Infatti, fino a questo momento

non abbiamo sollecitato alcun servizio configurato per inviare notifiche verso il

MARS. Ancora il meccanismo di correlazione degli eventi ci ha permesso di capire

con facilità, e soprattutto in tempo reale il tipo di attività sospetta. Il firewall ha

bloccato le attività di tipo “ worm”, impedendo all’attacco di saturare le risorse del

mail server, MARS ha correlato gli eventi del firewall.

Concludendo, possiamo dire che questa simulazione di attacco è stata rilevata in

maniera soddisfacente.

72

73

4.6 Attacco di tipo “brute force” al firewall

E' un tipo di attacco banale per la tecnica usata ma che ha ancora un margine di

successo di circa il 60%, grazie alle password statiche e facili da indovinare. Esistono

in rete, facilmente reperibili sui più comuni siti underground, dei veri e propri

dizionari di password che contengono le stringhe più utilizzate dagli utenti. Nomi

propri, nickname, combinazioni alfanumeriche e tutto ciò che gli utenti usano

comunemente per impostare le proprie password. Esistono diversi dizionari a seconda

della lingua di appartenenza dell'utente, questo perchè ovviamente un nostro

connazionale sarà più portato ad usare parole italiane laddove un americano agirà

utilizzando termini in slang. L'attacco Brute Force prevede l'uso di un tool automatico

che ha in input le coordinate dell'account da craccare (indirizzo ip del server,

tipologia dell'account e username), oltre che ovviamente il dizionario delle password.

Alcuni tool sono addirittura in grado di effettuare delle combinazioni delle parole

presenti nel dizionario, ad esempio anagrammandole o invertendole specularmente.

Nel nostro scenario tentiamo di effettuare un attacco “brute force” per cercare di

penetrare nell’interfaccia inside del firewall sfruttando le vulnerabilità del protocollo

https. Ovviamente questo tipo di attacco è stato condotto da un pc posto all’interno

della lan in quanto l’interfaccia di configurazione del firewall è abilitata solo

dall’interno della rete locale. Modificando la configurazione è possibile anche

effettuare l’accesso dall’esterno cioè selezionando come sistema target l’indirizzo

pubblico del firewall 88.44.155.34 ma per il nostro scopo, la direzione dell’attacco

outside o inside non influisce. L’attacco è molto semplice ed è stato condotto “a

mano” semplicemente aprendo una finestra di internet explorer all’indirizzo

https://192.168.253.1. Appare un pop up dove viene richiesta di inserire la password

di accesso al firewall. L’attacco consiste nel provare a inserire diverse password

nell’arco di poco tempo.

Esistono dei tool che permettono di effettuare molti tentativi nell’ordine di pochi

secondi ma per le nostre prove è sufficiente effettuare a mano un decina di tentativi.

In Fig 7 viene mostrato l’Incidente che viene generato per il tentativo di attacco.

Fig. 7

Il livello di severità dell’Incidente è verde perché l’attacco è stato sferrato dalla rete locale.

Fig. 8

In fig. 8 viene mostrata la regola che genera l’Incidente, strutturata con tre offset. Il

primo e il secondo sono coordinati dall’operatore “FOLLOWED-BY”, il terzo legato

ai primi due dall’operatore “OR”. Gli eventi degli offset sono di tipo “penetrate”e la

semantica della regola dice che un Incidente è generato se un tentativo “penetrate ” e

seguito da almeno altri tre tentativi nell’arco di un minuto.

74

4.7 Attacco “brute force” al server windows 2003 Lo stesso tipo di attacco “brute force” è stato simulato per il server windows 2003

tentando di violare il sistema attraverso il tentativo di login degli utenti specificati di

default dal sistema: Administrator, Guest. L’attacco è stato eseguito in rete locale da

un pc con indirizzo ip 192.168.253.23. Il tool utilizzato per simulare l’attacco è

Nessus.

Fig. 9

In fig. 9 viene mostrato l’Incidente in dashboard rilevato. Il sistema classifica

l’incidente con severità gialla perché oltre al semplice tentativo di login si è verificato

un tentativo di disabilitare lo user account da remoto.

Fig. 10

In fig. 10 è mostrata la regola che ha generato l’Incidente. Notiamo che il dispositivo

che ha generato il log è il sistema operativo. La regola ha un solo offset con eventi

“Penetrate/GuessPassword/All”, tali eventi permettono di rilevare un Incidente se

75

76

nell’arco di dieci minuti si verificano per almeno tre volte. Gli eventi che sono stati

correlati in seguito alla rilevazione sono almeno undici e sono tutti dello stesso tipo.

Anche in questo caso la rilevazione è stata tempestiva: dopo tre minuti dall’inizio

della simulazione è stato visualizzato il primo Incidente in dashboard.

4.8 Attacco al web server Microsoft-IIS/6.0

La vulnerabilità di IIS possono essere divise in tre grandi categorie: gestione di

richieste inattese, "buffer overflow" e legate alle applicazioni di esempio. Ognuna di

queste categorie verrà qui brevemente trattata.

1. 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. Costruendo una richiesta che sfrutti una di

queste vulnerabilità, un aggressore può da remoto:

• Visualizzare il codice sorgente di programmi non compilati.

• Visualizzare file che si trovano oltre la radice del Web server.

• Visualizzare file che il Web server non dovrebbe rendere accessibili.

• Eseguire comandi arbitrari sul server (che possono avere come

conseguenza, per esempio, la cancellazione di file di importanza

critica o l’istallazione di una backdoor).

2. Buffer overflow. Molte estensioni ISAPI (incluse le estensioni ASP, HTR,

IDQ, PRINTER, e SSI) sono vulnerabili ai buffer overflow. Un ben noto

esempio è la vulnerabilità dell’estensione ISAPI.idq, che viene sfruttata dai

worm Code Red e Code Red II. Una richiesta costruita in modo particolare da

un aggressore remoto può portare a:

77

• Interruzione del servizio.

• Esecuzione di codice arbitrario e/o di comandi da parte degli account

predefiniti del Web server (es. gli account IUSR_nomeserver or

IWAM_nomeserver).

3. Legate 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 solo

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, si capisce come esse siano

gli obiettivi preferiti degli exploit. Le conseguenze dovute a tali exploit

possono essere gravi; ad esempio:

• Una applicazione di esempio, newdsn.exe, permette a un aggressore

remoto di creare o sovrascrivere dei file sul server.

• Alcune applicazioni permettono di vedere da remoto qualsiasi file, e

questo fatto può essere sfruttato per raccogliere informazioni come gli

user id e le password dei database.

• Una applicazione iisadmin, ism.dll, permette l’accesso remoto a

informazioni riservate del server, tra le quali la password di

amministratore.

Abbiamo simulato gli attacchi descritti al punto uno e tre. Più in dettaglio, l’attacco

tenta di modificare le credenziali di sicurezza tentando di accedere alle informazioni

riservate quali password, user id ecc. Il metodo prevede l’invio di richieste http

anomale verso il server. In questo scenario il sistema di notifiche cambia perché non è

più il firewall a notificare gli eventi al MARS ma il sistema operativo. Infatti,

l’attacco è costituito da richieste anomale via http verso l’indirizzo pubblico del

server 88.44.155.36. Per motivi di configurazione scelta, il firewall accetta queste

richieste come se fossero normali attività web.

La figura 11 evidenzia la regola che genera questo evento in dashboard

Fig. 11

Come detto in precedenza, è possibile notare sotto la voce “Reporting Device” che il

dispositivo generante l’evento è il sistema operativo. In particolare, si tratta di una

sonda installata per i servizi IIS che permette il monitoraggio delle attività per il

server web verso il MARS. La descrizione della regola evidenzia il tentativo di

modificare le impostazioni di sicurezza del server relative al server web. L’evento è

stato generato dopo che la simulazione dell’attacco ha tentato di eseguire del codice

per cercare di ottenere password e user id. Poiché l’attacco consiste di più richieste

http, il sistema rileva l’Incidente dopo due tentativi di richieste anomale. Grazie al log

della sonda IIS, è possibile anche monitorare altre azioni come ad esempio lo stato

del web server e i tentativi di login. La figura 12 mostra una serie di notifiche del

sistema

Fig. 12

In conclusione, possiamo dire che il tentativo di attacco al web server è stato rilevato

con successo.

78

79

4.9 Attacco al DB Oracle

L’analisi delle vulnerabilità suggerisce di simulare un attacco che tenta di sfruttare

il modulo tnslsnr da remoto per entrare nel sistema e creare un utente attivabile al

prossimo avvio del servizio. OracleHomeTNSListener è il servizio che sulla porta

standard 1521 (o nella porta indicata nel file tnsnames.ora) ascolta se qualche client

vuole collegarsi al database. Oracle in versione 9.02 è stato configurato per inviare gli

eventi relativi alle attività del database a MARS. La configurazione prevere la

creazione di un utente con diritti per la vista della tabella “dba_audit_trail”. Per

abilitare i log delle attività del database è stato modificato il file “cataudit.sql” nel

quale è stata aggiunta la seguente opzione “AUDIT_TRAIL=DB”. Il log non viene

direttamente inviato a MARS ma viene memorizzato nella tabella “dba_audit_trail”.

Sarà poi il MARS che, a intervalli di 3 secondi, accederà al database, con credenziali

dell’utente, effettuerà l’interrogazione sulla tabella e ricaverà tutte le informazioni

relative alle attività registrate. Il plug-in di Nessus permette di capire come viene

condotto l’attacco. Fondamentalmente, si tratta di costruire un pacchetto “ad-hoc” che

simuli la richiesta di accesso con esecuzione di un comando. Se la richiesta viene

accettata, è inviato un pacchetto con comando COMMAND=STATUS per rilevare se

il servizio di accesso remoto non ha password. In questo caso l’attacco ha avuto

successo e quindi viene notificata la vulnerabilità, altrimenti viene notificata una

situazione di errore o di conferma che il servizio di accesso remoto ha la password

settata. In fig. 13 e 14 mostriamo rispettivamente l’Incidente dell’attacco in dashbord

e la regola che lo ha generato:

Fig.13

Come possiamo vedere, gli Incidenti che vengono generati sono più di uno in quanto

la plug in di Nessus ripete diverse volte il tentativo. L’Incidente ha come priorità di

minaccia il livello giallo, in figura 9, si vede che il dispositivo che ha generato gli

eventi è il sistema operativo su cui è installato Oracle, anche se la creazione vera e

propria delle notifiche è affidata al sistema di logging del database. Il motivo per cui

è il sistema operativo ad essere visto come dispositivo sorgente delle notifiche è

dovuto alla struttura della gestione dei dispositivi di MARS. Infatti in fase di

registrazione dei dispositivi, il database Oracle e il servizio IIS sono visti come

moduli aggiuntivi del sistema operativo, quindi ne fanno parte.

Fig. 14

80

81

La regola che genera l’Incidente “Password attack” è costituita dall’inferenza di

un’azione di rilevazione del servizio seguita da un tentativo di penetrazione nel

sistema. Infatti i primi due offset della regola descrivono eventi cosiddetti di “probe”,

cioè eventi che indicano un tentativo da parte di un attaccante di rilevare informazioni

sui servizi. Gli offset tre o quattro seguono i primi due con l’operatore

“FOLLOWED-BY” e descrivono tentativi di penetrazione nel sistema.

Ovviamente, gli offset sono correlati solo se hanno gli stessi campi, cioè se hanno

stesso indirizzo ip sorgente, stesso indirizzo ip destinazione e stesso protocollo.

Considerando la plugin di Nessus è possibile verificare che la regola che genera

l’Incidente è strutturata con due tipi di eventi che rispecchiano esattamente la

semantica della plug in.

Infatti, il programma implementato nella plug in, invia un pacchetto di sonda e

successivamente un comando che ricava l’informazione sullo lo stato di settaggio

della password.

82

Capitolo 5

5.1 Attacchi complessi condotti in più passi

Nei capitoli precedenti abbiamo considerato la rilevazione di attività di rete atomiche

cioè costituite da uno o più eventi generati per una stessa azione o Incidente.

Ad esempio il tentativo di scansione è di per se un’attività che presuppone diversi

eventi simili tra di loro a meno del parametro porta di destinazione, oppure il peer to

peer viene visto come un numero elevato di connessioni tcp su alcune porte note.

Anche gli stessi attacchi fino ad ora considerati sono isolati cioè costituiti da una sola

azione. Per tutte queste attività la rilevazione è semplice, in quanto il sistema deve

solamente analizzare eventi e, in tempo reale, generare un Incidente qualora ce ne sia

la necessità.

Questo capitolo considera il problema della rilevazione degli attacchi complessi,

costituiti da più passi in relazione tra di loro. Gli attacchi cosiddetti “Multi-step” sono

attività che richiedono una serie di passi consecutivi e non necessariamente immediati

per essere portati a termine. Le azioni che fanno parte di un singolo passo non

necessariamente sono maligne. Infatti è possibile che il passo di un attacco, se

eseguito da solo, possa non essere maligno mentre lo diventa se eseguito nella

sequenza corretta che definisce l’attacco.

Gli attacchi “multi-step” introducono due problematiche fondamentali:

• Se il sistema non è in grado di ricordare gli eventi analizzati in precedenza,

l’attacco non può essere rilevato.

• I singoli passi che fanno parte di un attacco possono non essere intrusivi; se il

sistema viene configurato in modo da tenerne traccia, è possibile che si

generino diversi falsi positivi

83

Da un punto di vista teorico ci sono due tecniche per affrontare il problema: tecnica

statefull e tecnica basata sulle signature.

5.2 Tecnica Statefull

Il sistema ricorda tutti gli eventi accaduti e controlla, per ogni nuovo evento, se

esistono correlazioni tra esso ed i precedenti. Di conseguenza, l’effetto di un certo

evento è dipendente dalla sua posizione rispetto a quella della coda degli eventi.

Tuttavia, questo tipo si approccio aumenta la complessità del motore inferenziale e

risulta soggetto ad attacchi di tipo “alert storm” che hanno come obiettivo quello di

generare falsi positivi.

Alcune attività di rete possano generare allarmi ripetuti che incidono sulle prestazioni

del dispositivo stesso, questo accade quando il dispositivo non è configurato in modo

appropriato. Un’attaccante può sfruttare questa situazione generando del traffico che

crea falsi allarmi cos’ da aumentare i tempi di risposta degli apparati e il

deterioramento delle prestazioni complessive.

5.3 La tecnica basata sulle signature

In un sistema basato sulle signature, il modello che descrive un attacco è memorizzato

in un database. Le signature riassumono in una espressione logica tutte le

informazioni necessarie per descrivere il tipo di attacco.

Questo tipo di approccio non aumenta la complessità del motore inferenziale, ma la

difficoltà di modellare il tipo di attacco.

84

Il processo di correlazione di più attività per di rilevare attacchi complessi multi-step,

attualmente, è manuale e richiede molto tempo e risorse umane.

La possibilità di automatizzare la rilevazione di questi attacchi è un campo che pone

sfide significative:

• E’ necessario conoscere bene l’attacco che si vuole modellare, prescindendo

da modelli che descrivono casi particolari.

• I potenziali eventi che potrebbero nascondere attività sospette sono

eterogenei e molteplici.

• Modellare attacchi multi-step può portare alla generazione di molti falsi

positivi

• Un attacco può essere eseguito in modi diversi ma equivalenti. Per esempio,

l'ordinamento temporale di alcuni passi potrebbe essere cambiato, o a un

passo potrebbe sostituirne uno equivalente da un punto di vista semantico

Il nostro obiettivo è quello di progettare un modello di correlazione per attacchi

multi-step utilizzando le tecniche e soprattutto gli strumenti forniti da MARS.

In particolare, vogliamo creare un modello di attacco che possa in qualche modo

descrivere diverse attività.

5.4 Modellare l’attacco

Il nostro modello di attacco prende in considerazione le seguenti linee guida:

• Vulnerabilità: un difetto o errore in un sistema o in una procedura che

permette di eseguire operazioni che violano, esplicitamente o implicitamente,

le politiche di sicurezza del sistema.

• Exploit: un singolo passo (atomico) che sfrutta una singola vulnerabilità.

• Attacco: singolo step o elementare: un attacco che raggiunge un obiettivo

intermedio

• Attacco composto: la concatenazione dei passi che costituiscono l’attacco .

Il modello deve comprendere la logica degli attacchi in quanto un attacco può essere

composto da tanti attacchi elementari, con altrettanti obiettivi intermedi e deve essere

rilevato attraverso l’osservazione di alcuni eventi. Il modello deve specificare le

relazioni tra le diverse sotto attività: ad esempio se un’azione accade prima di

un’altra, e/o l’ausilio degli stessi parametri come sistema target. Secondo quanto

detto e utilizzando gli strumenti forniti da MARS, abbiamo creato una regola che

tiene conto fondamentalmente di due passi di un attacco:

1. Analisi delle vulnerabilità attraverso strumenti di scansione.

2. Attacco che sfrutta le vulnerabilità rilevate.

In figura 1 è mostrata la definizione della regola che abbiamo creato.

Fig. 1

La regola tiene conto sia della generalizzazione sia del dei falsi positivi. La struttura

da un punto di vista logico prevede l’attività “scansione” seguita da una qualsiasi

attività. Sia SC l’attività scansione e At1, At2, At3,.., At6, le attività che seguono SC,

allora la regola R è definita come

SC FOLLOWED_BY (AT)

85

86

dove AT rappresenta l’unione di tutti i possibili sotto attacchi Ati con i=1 to 6

AT = (AT1 or AT2 or AT3 or AT4 or AT5 or AT6 or AT7)

Nel campo ip sorgente di SC, sono state utilizzate le variabili “ANY” non

conoscendo a priori l’indirizzo ip dell’attaccante e la variabile “$TARGET01”,

fondamentale per tenere traccia, dell’indirizzo ip da cui è stata lanciata.

Nel campo ip destinazione la variabile “SAME” permette di tracciare tutti gli eventi

con ip “sistema target” in SC. La variabile “$TARGET02” tiene traccia del sistema

obiettivo in AT. Il campo “Service name” contiene la keyword

“DISTINCT_ANY_DEST_PORT” per visualizzare e correlare solo gli eventi con

porte di destinazione diverse.

Questo fa si che vengano filtrata tutte le richieste verso alcuni servizi aventi le stesse

porte di destinazione. Il campo “Event” definisce gli eventi che genera SC,

solitamente un tentativo di scansione genera gli eventi “Deny paket to due security

policy” e “Deny tcp/udp request ”. Tali eventi, insieme con la condizione di

cardinalità (Il campo della regola count impostato a venti) modellano in generale il

comportamento di software per scansione. Nel campo device è definita la variabile

“DEVICE01”, per correlare tutti gli eventi di SC e AT generati dallo stesso

dispositivo. La keyword “FOLLOWED_BY” vincola l’attività SC ad essere

necessariamente seguita dall’attività AT. In effetti l’Incidente generato da R non è

altro che la soluzione di un sistema le cui condizioni sono espresse in termini di

indirizzi Ip, porte, eventi, e variabili ausiliarie quali “$TARGET01”, “TARGET02”e

”DEVICE01”. AT è definito come l’unione degli offset O2, O3, O4, O5, O6 che

differiscono tra di loro per gli eventi che rappresentano. Rispettivamente, tali eventi

sono di tipo Denial of service, Penetrate, Probe, e Propagate, Persist. Gli eventi di

tipo Dos sono tutti eventi che possono generare un disservizio, gli eventi Penetrate

rappresentano tentativi di brute force o password attack etc, eventi Probe descrivono

tentativi di login verso servizi aperti dall’esterno, il gruppo di eventi Propagate

descrive attività spesso riconducibili a propagazione di worm o tentativi di conessioni

verso indirizzi casuali, tipico dei trojan o delle back doors, gli eventi del gruppo

Persist descrivono situazioni in cui si verificano aumenti drastici del traffico di rete

dovuti ad anomalie. Ogni offset contiene la condizione “!=Deny packet due to

security policy” per filtrare gli eventi che vengono generati per l’attività SC.

Da un punto di vista semantico la regola R tiene conto di alcune proprietà di tipo

euristico:

• In media un tentativo di scansione produce da venti a mille eventi in un

tempo che va da pochi secondi fino a dieci minuti. Il campo “count” di SC ha

un limite inferiore di venti eventi necessariamente con “porta destinazione”

diversa. La precisione e l’accuratezza della rilevazione discende dal fatto che

è estremamente improbabile che un’attività con queste caratteristiche non sia

un’attività si scansione.

• Assunto che SC modelli con precisione accettabile una scansione, è

estremamente improbabile che un’attività, nel caso specifico definita come

AT

o segue SC

o sia generata dallo stesso dispositivo di SC

o hanno lo stesso indirizzo ip sorgente e lo stesso indirizzo ip di

destinazione

Le prove effettuate hanno dimostrato l’efficacia della regola R. Abbiamo effettuato

prima una scansione, utilizzando come strumento Nessus. Successivamente lo

abbiamo eseguito in modalità check vulnerability, cioè senza effettuare la scansione.

Il test è stato eseguito su un reale sistema target con pool di indirizzi ip

82.191.150.219 Mask 2585.255.255.248.

In figura 2 è mostrato l’Incidente rilevato in dashboard:

Fig. 2

87

La figura permette di notare in sequenza temporale prima la rilevazione della

scansione e poi la rilevazione della regola R che comprende sia la scansione sia il

tentativo di attacco.

Da un punto di vista cronologico l’attacco è stato eseguito due minuti dopo la

scansione. La regola è stata configurata per accettare eventi in un arco di tempo di 23

ore, è possibile anche configurare un lasso di tempo più ampio (giorni, mesi) ma

statico (data iniziale, data finale ). La scelta di scegliere un periodo di 23 ore è stata

adottata soprattutto per motivi pratici.

In fig. 3 e 4 sono mostrati gli eventi che fanno parte dell’Incidente.

Fig 3

La Fig. 3 illustra il match degli eventi: 100 generati dal dispositivo a seguito di una

scansione e i seguenti 62 generati a seguito del controllo delle vulnerabilità eseguito

da Nessus.

Fig..4

Come mostrato in fig.4, gli eventi di tipo “Deny packet due to security policy” sono

stati generati e inviati a MARS prima degli eventi “Deny connection no xlate”.

88

Da notare come l’indirizzo destinazione risulta essere privato 192.168.0.98, a

seguito di una traslazione di indirizzo pubblico 82.191.150.219.

Sono considerati attacchi complessi anche quelli che arrivano al sistema target

eseguendo passi elementari su host intermedi. Per alcuni tipi di attacchi MARS

dispone già di alcune regole, per tutti gli altri invece abbiamo creato una regola

generica che modella, a partire da una scansione, il passo successivo verso un sotto

sistema target.

Fig. 5

Sia R1 la regola mostrata in figura 5, costituita da tre offset di cui il primo risulta

essere SC. Sia NS l’offset che modella un’attività successiva a SC. NS contiene nel

campo “Source IP” le variabili SAME e $TARGET01 che permettono

rispettivamente di correlare occorrenze di eventi che hanno lo stesso indirizzo IP

nell’offset o stesso IP sorgente dell’offset SC. Stessa cosa dicasi per il campo

“Destination IP”, in particolare la variabile “SAME” permette di modellare situazioni

in cui ci sono diversi passi intermedi caratterizzati da diversi Host mentre la variabile

“TARGET03” permette la correlazione con il passo successivo. La variabile ANY

utilizzata nel campo “Service Name” e nel campo “EVENT” indica che devono far

parte di NS eventi generici non vincolati dal tipo o numero di porta sorgente e

destinazione. Tale scelta si basa sul principio di modellare comportamenti di attività

generali che prescindono dal tipo di protocollo. Per lo stesso motivo anche il campo

“DEVICE” contiene sia la variabile $DEVICE01 sia la variabile SAME. Il passo

finale, verso il sistema obbiettivo, è rappresentato dall’offset NS1 che ha come IP

sorgente lo stesso valore del campo “Destination IP” di NS. Il campo “Destination

IP” di NS1, contiene la variabile “TARGET02”, inserita anche nel campo di SC,

perchè è possibile che il sistema obiettivo venga attaccato senza passi intermedi.

89

Formalmente, R1 può essere vista come una stringa prodotta da una grammatica:

R1 :=SC(A)NS1 ;

A:= {}| NS | ANS ;

SC := scansione ;

NS := passo intermedio;

NS1:= passo conclusivo;

Alcuni esempi di regole che modellano situazioni particolari di attacchi sono riportati

in seguito

Fig.6

La fig. 6 illustra una regola creata esplicitamente per una attività sospetta di una back

door dove è stato effettuato un primo passo di attacco “brute force” verso l’host

“target01” seguito da un passo in cui si evidenzia il tentativo di attacco worm o dos

verso lo stesso host o verso il sistema obiettivo.

90

Fig 8.

La fig. 8 illustra la regola che descrive l’attività del worm sasser.

http://www.nod32.it/pedia/s/sasser-a.htm

http://www.symantec.com/region/it/techsupp/avcenter/venc/data/it-

w32.sasser.e.worm.html

La regola modella un attacco sulla porta 445 seguito da un qualsiasi commando di

connessione verso il sistema target sulla posta 9996 o da una connessione ftp sulla

posta 5554 oppure eventi che rappresentano un eccessivo numero di connessioni sulla

porta 445. Ciò indica che sia la sorgente sia la destinazione sono state infettate dal

Worm sasser.

Fig.9

Questa regola descrive un modello di attacco di tipo “Password Guess” verso un

database server. L’attacco prevede un consistente numero di tentativi di login falliti.

91

5.5 Attacchi complessi host based Sono considerati attacchi complessi anche gli attacchi”host based” cioè attacchi che

cercano di compromettere un host da utilizzare successivamente come trampolino di

lancio verso altri sistemi o server della stessa rete. Come già detto, le modalità con le

quali un attaccante ricava le informazioni possono essere sia dirette, tramite

scansioni e tecniche di fingerprint, sia indirette sfruttando il web come motore di

ricerca o attraverso archivi di mailing list o informazioni ricavate da elenchi

telefonici. Ricavate quante più possibili informazioni, un malintenzionato potrebbe

attaccare un qualsiasi host della rete internet oppure un host che fa parte della stessa

rete del server o del sistema target. Se l’obbiettivo raggiunto non è quello prefissato,

l’accattante può continuare a raccogliere informazioni di altri host critici sfruttando la

posizione di vantaggio acquisita. I passi compiuti dagli hacker da un attaccante per

compromettere una rete sono essenzialmente rappresentati in figura 10:

fig. 10

1. Identificare il sistema da attaccare e trovare le vulnerabilità e le modalità di

attacco.

2. Ottenere un accesso utente penetrando nel sistema e tentare di ottenere

accessi privilegiati

3. Ottenere un accesso privilegiato per controllare totalmente il sistema target.

92

93

4. Coprire le tracce in modo che non sia possibile risalire all’attaccante

attraverso l’analisi dei log di sistema

5. Installare BackDoors per rientrare nel sistema qualora venga individuato e/o

eliminato il precedente metodo di penetrazione.

6. Attaccare altri sistemi dall’host compromesso per agire in modo anonimo.

7. Penetrare o alterare informazioni presenti sulla macchina e sulla rete

8. Attuare altre attività non autorizzate al fine di procurarsi un vantaggio o un

profitto

L’importanza di rilevare in tempo reale queste attività diventa fondamentale per

proteggere una rete costituita da file server, mail server, web server.

La natura complessa e non deterministica dell’attacco aumenta notevolmente la

complessità di modellare la regola che lo descrive. I principali problemi da affrontare

sono:

• Rilevare attacchi a sistemi critici prima di quelli non critici.

• Tracciare attacchi con un numero indefinito di host intermedi.

• Rilevare attività anomale analizzando le credenziali di accesso di utenti

sospetti

• Gestire con cura e precisione i potenziali falsi positivi.

La soluzione dei problemi al primo punto richiede un’adeguata conoscenza del

traffico permesso e del traffico da bloccare. Molto spesso, data la grande quantità di

dati scambiati è difficile comprendere la natura del traffico, quindi capire se siamo in

presenza di anomalie. In queste circostanze, è difficile scegliere gli eventi che

modellano il comportamento dell’attaccante ed ancora più difficile è distinguere le

attività generate da host critici e quelle da host non critici. Un buon approccio è

quello di specificare, per ogni situazione, l’indirizzo IP degli host. Il metodo descritto

richiede però la creazione di una regola per ogni ambiente diverso che vogliamo

controllare. Un altro approccio è quello che creare una regola generica che tenga

conto non solo dei log del firewall ma anche di quelli delle macchine critiche. In

questo modo è possibile rilevare in maniera più accurata gli attacchi verso gli host su

cui abbiamo abilitato i log del sistema operativo. Quest’ultima considerazione

introduce il vincolo di installare sulla macchina critica un agent che invii i log al

94

MARS. Se non è possibile installare un agent, si può configurare il sistema operativo

per inviare gli eventi verso un host remoto, in questo caso il MARS, ma la

configurazione non è sempre agevole. Di contro bisogna considerare:

• la compatibilità dell’agent con il sistema operativo del host su cui

viene eseguito.

• il carico della rete all’aumentare del traffico dovuto ai log generati.

• i tempi di risposta e performance del server dopo l’installazione.

I problemi di compatibilità sono semplificata dall’esistenza di agent per quasi tutti i

sistemi operativi. Ad esempio dell’agent SNARE

(www.intersectalliance.com/projects/Snare) esiste una versione per tutti i sistemi

operativi Solaris, Windows 2000/NT/XP/2003, Novell Netware, AIX, e tutte le

distribuzioni Linux. Una buona configurazione dei filtri degli eventi può ridurre

drasticamente il volume dei log da inviare. Data la natura delle operazioni di raccolta

e invio degli eventi di sistema, possiamo dire che non si hanno degradi significativi

delle prestazioni. In sostanza è possibile utilizzare un agent per la gestione dei log,

senza effetti collaterali sul sistema.

Inoltre, adottando questa metodologia vengono risolti anche tutti i problemi degli

altri punti in quanto:

• il modello rileva un’attività sospetta che è suggerita dall’host stesso

passando per un numero indefinito di host intermedi.

• Gli eventi del sistema operativo creano eventi contenenti informazioni

sulle credenziali di accesso degli utenti e le relative operazioni (figura 11).

• La correlazione tra i log del sistema operativo e i log del firewall permette

un’analisi più accurata e precisa minimizzando i falsi positivi.

Fig. 11

La regola è stata implementata tenendo presente tutte le problematiche viste

precedentemente e cerca di modellare un tipo di attività piuttosto generalizzata

rispetto a un attacco specifico.

fig. 12

La fig.12 mostra la regola costituita da tre offset rispettivamente o1, o2, o3. Gli offset

o1 e o2 sono legati dall’operatore “AND” e rappresentano attività generiche di

attacchi su uno o più host. L’offset o3 è legato, tramite l’operatore logico

“FOLLOWED-BY”, agli offset o1 e o2 e rappresenta un’attività sospetta su un host

critico. Da un punto di vista logico la regola ha la forma:

95

96

((o1 AND o2) FOLLOWED-BY o3)

Nel campo “Source IP” di o2 sono specificate le stesse variabili di “Destination IP”

presenti in o1, infatti:

• un generico attacco, verso un generico nodo della rete, può essere eseguito

su altri nodi partendo da quello precedentemente compromesso

(correlazione delle variabili $TARGET01 tra o1 e o2)

• un generico attacco può essere eseguito su un numero indefinito di nodi

intermedi (correlazione, in o2, della variabile SAME in “Source IP” e

delle variabili “SAME” e “ANY” in “Destination IP” )

La generalizzazione dell’attacco deriva dalla generalizzazione dei servizi interessati

(Variabile “SAME_ANY_DEST_PORT” in o2) e dai possibili eventi che possono

interpretare un qualsiasi attacco (definiti nel campo “Event” in o2).

Nel campo “Source IP” di o3 sono specificate le variabili “SAME” “$TARGET02”

che fanno parte anche del campo “Destination IP” in o2. La correlazione tra queste

variabili modella l’ultimo passo dell’attacco verso il sistema target.

Nel campo “Event” in o3 compare la variabile “$EVENT_TYPE01” che richiama

tutti gli eventi espressi in o2. Sono anche stati aggiunti altri eventi, che espandono il

dominio delle possibili attività affinché si aumenti la sensibilità dalla rilevazione

verso il sistema target.

Alcuni degli eventi vengono generati solo dal sistema operativo, ciò implica che tale

regola genera Incidenti diversi (con eventi diversi) a seconda che si tratti di host che

eseguono l’agent o meno. Questa regola rilevare attività anomale generiche, se

volessimo rilevare attività specifiche esistono delle regole di sistema “ad hoc”.

fig.13

La regola in Fig. 13 rappresenta un modello di rilevazione di attacco basato un host

localmente loggati con permessi utente, seguito da attività anomale verso il server

che includono denial of service, scansioni, connessioni a backdoors e tentativi di

proparazione di worm e trojan horse.

fig. 14

97

La regola in Fig. 14 rileva uno specifico attacco su un generico server FTP seguito da

una sospetta attività sul sistema target. Tali attività comprendono, host scan,

generazione di molti allarmi del firewall e connessioni a backdoor. Gli attacchi al

server ftp comprendono buffer overflows, esecuzione di comandi da remoto tentativi

di ottenere privilegi di administrator, denial of service.

Fig 15

La regola in Fig. 15 rileva un modello di attacco basato su login verso i servizi si un

host (Telnet, SSH, R-protocol tipo Rsh, Rlogin, Rexec etc.) seguito da attività

sospette verso il sistema target. L’attacco al server include buffer owerflows,

esecuzione remota di comandi usando i privilegi del server, tentativi di denial of

service.

98

fig. 16

La regola in Fig. 16 modella uno specifico attacco verso i servizi mail (SMTP, POP,

IMAP) su un host seguito da sospette attività verso il server. Le attività sospette

includono scansione, eccessivo traffico negato dal firewall, connessioni a backdoor.

L’attacco include buffer owerflow, esecuzione di comandi da remoto, tentativi di

utilizzare i privilegi del server e denial of service.

99

Fig 17

La regola della Fig. 17 rileva attacchi a diversi servizi ( DNS, FTP, HTTP, Mail, FTP,

RPC, Telnet, SSH, R-protocols) verso un generico host seguiti da attività sospette

verso il server. Sono comprese tutte le attività della regola mostrata in Fig. 16.

100

101

5.6 Attacchi dinamicamente mutevoli Le politiche di sicurezza basate su intrusion detection system (IDS) rilevano gli

attacchi definiti da uno o più modelli che descrivono i comportamenti intrusivi di

interesse. Un sistema IDS è costituito da un database di attacchi descritti come attività

sospette. L’abilità di questi sistemi, dipende fortemente dalla qualità dei modelli di

attacco chiamati “signatures”.

Tanto più una signature descrive in maniera fedele un attaccho tanto più il sistema

IDS è performante.

Un modello perfetto dovrebbe disporre di segnature perfette e quindi essere in grado

di riconoscere tutte le istanze di un attacco. Purtroppo produrre un modello perfetto è

molto complesso perchè è difficile definire fedelmente tutte le possibili varianti di un

attacco.

Attualmente, il progetto di sistemi IDS è ancor più complesso perché esistono

attacchi in grado di mutare il loro comportamento in modo non deterministico,

eludendo cosi una qualsiasi signature. Questo tipo di attacco comprende una serie di

meccanismi che implementano la mutazione e sono quindi in grado di offuscare un

exploit che sfrutti una vulnerabilità di un servizio. La tecnica di mutazione può

operare a diversi livelli:

• Mutazione a livello rete: si sfrutta una classe di tecniche che operano sia a livello

rete sia a livello di trasporto. Queste mutazioni possono essere applicate

indipendentemente da quelle a livelli più alti. Ad esempio, una di queste tecniche

sfrutta l’attuale coesistenza del protocollo IPv4 con IPv6 offrendo la possibilità a

un attaccante, di eludere i sistemi IDS inviando dei pacchetti su IPv6. Alcuni

sistemi IDS controllano la lunghezza del pacchetto IP per scoprire eventuali

attacchi. In alcuni casi, è sufficiente inviare pacchetti più piccoli per eludere le

signatures di un IDS.

• Mutazioni a livello applicativo: queste mutazioni si verificano a livello di

sessione, presentazione e applicazione. Ad esempio è possibile inserire una certa

sequenza di controllo telnet in uno stream di comandi FTP. Alcuni IDS

normalizzano i comandi FTP identificandoli o estrapolandoli da una sequenza di

controllo. Usando quindi, un controllo di sequenza alternativo è possibile eludere

102

un IDS. Ancora, le differenze implementative tra web server e sistemi IDS fanno

si che un attaccante possa beffare le signature violando un web server. Alcuni web

server, per esempio, tollerano errori o richieste non formattate correttamente. Le

richieste incorrette verso i web server potrebbero essere non considerate dai

sistemi IDS. Alcune implementazioni del protocollo SSL permettono di inviare un

numero arbitrario di records NULL tra le sequenze di possibili messaggi

scambiati tra client e server. Un attaccante potrebbe manipolare una sequenza di

handshake tra client e server che a questo punto dovrebbe essere non valida ma

che viene normalmente accettata by-passando cosi l’IDS.

L’importanza della problematica richiede una riflessione più accurata che deve

essere affrontata in altri ambiti. Il nostro scopo è quello di valutare un sistema di

intrusion prevention system (IPS) che si basa sull’analisi e correlazione di log inviati

da altri dispositivi. Le tecniche che permettono di eludere i sistemi IDS sono problemi

che devono essere affrontati dai dispositivi che generano log e non da quelli che li

analizzano. MARS raccoglie informazioni inviate da altri dispositivi e analizza con

alto grado di correlazione gli eventi ricevuti. I modelli IDS e IPS che oggi sono

implementati nei dispositivi prendono in considerazione tutte queste problematiche in

maniera esaustiva.

(http://www.cisco.com/application/pdf/en/us/guest/products/ps5769/c1244/cdccont_0

900aecd8030e502.pdf)

103

Conclusioni Le attività di rete sono sempre più complesse e quindi più difficili da comprendere se

analizzate attraverso la lettura e l’interpretazione dei log. In questo senso MARS è

uno strumento efficace che facilita sia la lettura, attraverso il filtraggio di eventi, sia

l’interpretazione, attraverso l’inferenza generata da regole che permettono di

evidenziare le attività critiche. Le metodologie di analisi utilizzate in questa tesi

hanno cercato di valutare, in particolare, il grado di rilevazione e la precisione di

MARS.

Il grado di rilevazione è la capacità di MARS di riconoscere quindi rilevare,tutte le

attività sospette della rete.

La precisione misura l’attendibilità delle informazioni restituite dalle regole ed, in

particolare, dell’incidente generato cioè se esso descrive un’attività che

effettivamente può essere considerata sospetta.

Per quanto riguarda la rilevazione di attività sospette, MARS utilizza un insieme di

regole che le modellano. Non è possibile rilevare anomalie sulla rete se non esistono

regole che le modellano. I test effettuati hanno mostrato che nella sua configurazione

di base, MARS non rileva alcune scansioni (il 60%) e attacchi complessi generici

(100%) mentre rileva attività peer to peer generiche. Le possibili cause possono

essere attribuite ai dispositivi, utilizzati nei test, i quali generano un tipo di log poco

espressivo e verboso. Sarebbe opportuno ripetere tutti i test di scansione, su

dispositivi di costruttori diversi per confrontare i risultati. Le scansioni si

caratterizzano soprattutto per la rumorosità e per i tipi di pacchetti che inviano,

dunque, i parametri interessati sono la quantità di eventi inviati nell’unità di tempo e i

tipi di eventi generati dai diversi dispositivi bersaglio (ogni dispositivo di un diverso

costruttore ha un tipo caratteristico di log). Questa diversità è la principale causa del

basso grado di rilevazione delle scansioni. Infine è stato possibile rilevare tutte le

scansioni creando un'unica regola che sintetizza tutte le categorie di eventi interessati

e con un rapporto numero-eventi / range di tempo che abbraccia tutti i possibili gradi

di rumorosità.

104

Gli attacchi complessi si distinguono per la loro caratteristica di effettuare operazioni

sequenziali diverse in un periodo di tempo indefinito, in questo caso, abbiamo creato

una regola che modella il tipo di attività permettendone la rilevazione.

La precisione di MARS dipende fortemente dall’attendibilità degli incidenti generati;

la rilevazione di un incidente, deve perciò essere accompagnata da un’adeguata

investigazione, sotto questo aspetto abbiamo avuto ottimi risultati per le scansioni.

MARS nella configurazione di base, riesce a rilevare solo generiche attività p2p, che

a volte può anche comprendere del normale traffico ftp o traffico p2p consentito dalle

politiche aziendali. Creando una regola che modella l’attività di un client Emule,

siamo riusciti a individuare, quindi, differenziare, il traffico anomalo da quello

consentito. Tenendo presente parametri come la stima del numero di sessioni di

connessioni e le porte di servizio utilizzate da Emule è stato possibile rilevare traffico

con un’attendibilità del 100%. Il risultato ottenuto può anche essere raggiunto

facilmente utilizzando dei dispositivi in grado di riconoscere ed inviare informazioni

circa il tipo di peer to peer. La nostra soluzione comunque è applicabile in qualsiasi

realtà aziendale senza sostenere costi aggiuntivi per dispositivi IDS.

Gli attacchi semplici sono stati rilevati con una precisione dell’90% dei casi, gli

attacchi complessi sono stati rilevati con un precisione dell’80%, in particolare è stato

necessario implementare una soluzione che correlasse non solo le informazioni

provenienti dai dispositivi di frontiera, quali firewall e router, ma anche tutte le

informazioni provenienti da server critici quali file server, server mail o web server. I

fattori che influiscono sulle difficoltà di programmare MARS, per aumentarne la

precisione, sono soprattutto legati alla “logica del giusto compromesso” tra la

descrizione completa dello spazio di attività anomale dello stesso genere (Kaaza,

Emule, Napster) e quella di diminuire i falsi positivi in modo da escludere dallo

spazio attività generate da altre attività legali.

Relativamente a questo ultimo aspetto, il nostro approccio è stato quello di

configurare MARS attraverso regole sia generiche sia specifiche che tenessero

rispettivamente traccia di determinati tipi attività (attacchi complessi, scansioni, p2p )

e di attività specifiche (attacco complesso all’ftp, scansioni lente, Emule).

L’intersezione degli eventi generati da una regola generica e di quelli dovuti ad una

specifica ci ha permesso di capire gli eventi che potevano generare errori nella

rilevazione fornendo un forte contributo alla scoperta di falsi positivi.

105

Concludendo, possiamo affermare che MARS è un strumento adeguato per rilevare,

analizzare, correlare e definire efficaci contromisure nei confronti di minacce sempre

più sofisticate; è però fondamentale che MARS sia correttamente configurato

secondo le necessità e le caratteristiche delle reti aziendali. A tal proposito, è

necessario conoscere tutti i dispositivi di rete, gli host critici e tutte le attività

permesse dalle politiche di sicurezza aziendali al fine di implementare una soluzione

efficace ed efficiente per la sicurezza.

Le politiche aziendali richiedono di specificare regole che rilevano particolari attività

tra quali l’instant messaging, streaming multimediale e altri tipi di file sharing.

Per i nostri test sono stati utilizzati in prevalenza dispositivi Cisco. Sarebbe opportuno

utilizzare nei test ulteriori dispositivi di rete di altri costruttori per analizzarne le

diversità. Inoltre MARS non supporta alcuni dispositivi e i loro eventi non sono

possono essere interpretati. Per superare questa limitazione è necessario creare nuovi

eventi associati a tali dispositivi, ad esempio, la diffusione della tecnologia voip

introduce nuove problematiche di sicurezza. Lo studio e l’analisi di attività, generate

dal traffico voip, e la comprensione, di tali problematiche, sono possibili purchè

vengano definite delle opportune regole capaci di interpretare gli eventi che le

descrivono.

È doveroso soffermarci anche sulle problematiche sollevate dai sistemi di IPS che

popolano, sempre più, le reti e, se non regolati, forniscono un contributo inadeguato

alla sicurezza. I sistemi IPS analizzano il contenuto dei pacchetti che transitano sulle

interfacce dei dispositivi di rete e se il loro contenuto, è dichiarato anomalo, vengono

generate notifiche; poichè l’analisi del traffico è limitata al solo ambito delle sessioni,

il sistema IPS ha una visione relativa e non globale delle attività della rete, dunque, è

molto probabile che siano generati falsi allarmi. Attualmente questo sembra essere

uno dei problemi più sentiti nell’ambito della sicurezza e affiancare a un sistema IPS

le caratteristiche di MARS significherebbe avere un monitoraggio più preciso grazie

al meccanismo di correlazione delle informazioni e alla capacità di analisi e studio

dei falsi positivi.

106

Appendice A

Plug in dell’attacco al database Oracle

# # oracle_tnslsnr_security.nasl - NASL script to do a TNS STATUS # command against the Oracle tnslsnr and grep out "SECURITY=OFF" # # James W. Abendschan <jwa@jammed.com> # if (description) { script_id(10660); script_version ("$Revision: 1.12 $"); script_name(english: "Oracle tnslsnr security"); script_description(english: "The remote Oracle tnslsnr has no password assigned. An attacker may use this fact to shut it down arbitrarily, thus preventing legitimate users from using it properly. Solution: use the lsnrctrl SET PASSWORD command to assign a password to, the tnslsnr. Risk factor : High" ); script_summary(english: "Determines if the Oracle tnslsnr has been assigned a password."); script_category(ACT_GATHER_INFO); script_family(english: "Misc.", francais:"Divers"); script_copyright(english: "James W. Abendschan <jwa@jammed.com> (GPL)"); script_dependencie("oracle_tnslsnr_version.nasl"); script_require_ports("Services/oracle_tnslsnr"); exit(0); } include('global_settings.inc'); function tnscmd(sock, command) { # construct packet command_length = strlen(command); packet_length = command_length + 58; # packet length - bytes 1 and 2 plen_h = packet_length / 256; plen_l = 256 * plen_h; # bah, no ( ) ? plen_l = packet_length - plen_h; clen_h = command_length / 256; clen_l = 256 * clen_h; clen_l = command_length - clen_l; packet = raw_string(

107

plen_h, plen_l, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01, 0x36, 0x01, 0x2c, 0x00, 0x00, 0x08, 0x00, 0x7f, 0xff, 0x7f, 0x08, 0x00, 0x00, 0x00, 0x01, clen_h, clen_l, 0x00, 0x3a, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x34, 0xe6, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, command ); send (socket:sock, data:packet); r = recv(socket:sock, length:8192, timeout:5); return (r); } function oracle_tnslsnr_security(port) { sock = open_sock_tcp(port); if (sock) { cmd = "(CONNECT_DATA=(COMMAND=STATUS))"; reply = tnscmd(sock:sock, command:cmd); close(sock); if ( ! reply ) return 0; if ("SECURITY=OFF" >< reply) { security_hole(port:port); } else { if ("SECURITY=ON" >< reply || "ERROR=(CODE=1169)" >< reply ) { # FYI report = string ( "This host is running a passworded Oracle tnslsnr.\n" ); security_note(port:port, data:report); } else if ( "ERROR=(CODE=12618)" >< reply && report_verbosity == 2 ) { report = string( "This host has an incompatible version of tnslsnr for the plugin. This cannot be checked.\n"); security_note(port:port, data:report); } } } } # tnslsnr runs on different ports . . . port = get_kb_item("Services/oracle_tnslsnr"); if ( isnull(port)) exit(0); if(get_port_state(port)) { oracle_tnslsnr_security(port:port);}

Plug in dell’attacco al IOS CISCO per Denial of service

108

# # (C) Tenable Network Security # if(description) { script_id(20807); script_bugtraq_id(15401); script_version("$Revision: 1.1 $"); name["english"] = "IOS IPSec IKE Traffic Denial of Service Vulnerability"; script_name(english:name["english"]); desc["english"] = " Synopsis : The remote router can be crashed remotely. Description : The remote host is a CISCO router containing a version of IOS which is vulnerable to a denial of service vulnerability. An attacker may exploit this flaw to crash the remote device by sending a malformed IKE packet to the remote device. Solution : http://www.cisco.com/warp/public/707/cisco-sa-20051114-ipsec.shtml Risk factor : Medium / CVSS Base Score : 4 (AV:R/AC:H/Au:NR/C:N/A:C/I:N/B:A)"; script_description(english:desc["english"]); summary["english"] = "Uses SNMP to determine if a flaw is present"; script_summary(english:summary["english"]); script_category(ACT_GATHER_INFO); script_copyright(english:"This script is (C) 2006 Tenable Network Security"); script_family(english:"CISCO"); script_dependencie("snmp_sysDesc.nasl", "snmp_cisco_type.nasl"); script_require_keys("SNMP/community", "SNMP/sysDesc", "CISCO/model"); exit(0); } include('cisco_func.inc'); os = get_kb_item("SNMP/sysDesc"); if(!os)exit(0); hardware = get_kb_item("CISCO/model"); if(!hardware)exit(0); version = extract_version(os); if ( ! version ) exit(0); if ( check_release(version:version, patched:make_list("12.2(18)SXD7"),

109

newest:"12.2(18)SXD7") ) vuln ++; # # 12.3 # if ( deprecated_version(version, "12.3TPC", "12.3XD", "12.3XE", "12.3XF", "12.3XG", "12.3XH", "12.3XI", "12.3XJ", "12.3XK", "12.3XM", "12.3XQ", "12.3XR", "12.3XS", "12.3XU", "12.3XW", "12.3XX", "12.3YA", "12.3YD", "12.3YF", "12.3YG", "12.3YH", "12.3YI", "12.3YJ", "12.3YK", "12.3YS", "12.3YT", "12.3YU", "12.3YX") ) vuln ++; if ( check_release(version:version, patched:make_list("12.3(11)T9", "12.3(14)T5"), newest:"12.3(14)T5") ) vuln ++; if ( check_release(version:version, patched:make_list("12.3(14)YM4"), newest:"12.3(14)YM4") ) vuln ++; if ( check_release(version:version, patched:make_list("12.3(14)YQ4"), newest:"12.3(14)YQ4") ) vuln ++; # 12.4 if ( deprecated_version(version, "12.3XA")) vuln ++; if ( check_release(version:version, patched:make_list("12.4(1c)", "12.4(3b)"), newest:"12.4(3b)") ) vuln ++; if ( check_release(version:version, patched:make_list("12.4(2)T2"), newest:"12.4(4)T2") ) vuln ++; if ( check_release(version:version, patched:make_list("12.4(2)XB"), newest:"12.4(2)XB") ) vuln ++; if ( vuln == 1 ) security_warning(port:161, proto:"udp"); else if ( vuln > 1 ) display("Problem in script $Id: CSCed94829.nasl,v 1.1 2006/01/25 18:02:07 renaud Exp $\n");

Plug in dell’attacco al server FTP per directory traversal

# # This script was written by Erik Tayler <erik@digitaldefense.net> # # See the Nessus Scripts License for details # if(description) { script_id(11206); script_bugtraq_id(2444); script_version("$Revision: 1.6 $"); script_cve_id("CVE-2001-0295"); script_xref(name:"OSVDB", value:"874"); name["english"] = "War FTP Daemon Directory Traversal"; script_name(english:name["english"]);

110

desc["english"] = " The version of WarFTPd running on this host contains a vulnerability that may allow a potential intruder to gain read access to directories and files outside of the ftp root. By sending a specially crafted 'dir' command, the server may disclose an arbitrary directory. Solution: Visit the following link and download the latest version of WarFTPd: ftp://ftp.jgaa.com/pub/products/Windows/WarFtpDaemon/ Risk factor: Low"; script_description(english:desc["english"]); summary["english"] = "WarFTPd Directory Traversal"; script_summary(english:summary["english"]); script_category(ACT_ATTACK); script_copyright(english:"This script is Copyright (C) 2003 Digital Defense, Inc."); family["english"] = "FTP"; script_family(english:family["english"]); script_dependencies("find_service_3digits.nasl"); script_require_ports("Services/ftp", 21); exit(0); } include("ftp_func.inc"); port = get_kb_item("Services/ftp"); if(!port)port = 21; if(get_port_state(port)) { r = get_ftp_banner(port:port); if(!r)exit(0); if( (egrep(pattern:"WAR-FTPD 1\.(6[0-5]|[0-5].*)",string:r)) || ("WAR-FTPD 1.67-04" >< r) ) { security_hole(port); } }

Plug in vulnerabilità servizi IIS di Windows

# # This script is Copyright (C) 2003 SensePost"); # # Modification by David Maciejak # <david dot maciejak at kyxar dot fr> # based on 404print.c from Digital Defense # desc["english"] = " Synopsis : The remote web server is running Microsoft IIS.

111

Description : The Patch level (Service Pack) of the remote IIS server appears to be lower than the current IIS service pack level. As each service pack typically contains many security patches, the server may be at risk. Note that this test makes assumptions of the remote patch level based on static return values (Content-Length) within a IIS Server's 404 error message. As such, the test can not be totally reliable and should be manually confirmed. Solution: Ensure that the server is running the latest stable Service Pack. Risk factor : None"; if(description) { script_id(11874); script_version("$Revision: 1.15 $"); name["english"] = "IIS Service Pack - 404"; script_name(english:name["english"]); script_description(english:desc["english"]); summary["english"] = "IIS Service Pack Check"; script_summary(english:summary["english"]); script_category(ACT_GATHER_INFO); script_copyright(english:"This script is Copyright (C) 2003 SensePost & Copyright (C) 2004 David Maciejak"); family["english"] = "Web Servers"; script_family(english:family["english"]); script_dependencie("find_service.nes", "http_version.nasl", "www_fingerprinting_hmap.nasl"); script_require_ports("Services/www", 80); exit(0); } # Check starts here include("http_func.inc"); include("http_keepalive.inc"); port = get_http_port(default:80); sig = get_http_banner(port:port); if ( sig && "IIS" >!< sig ) exit(0); if(! get_port_state(port)) exit(0); r1 = http_get(item:"/nessus" + rand(), port:port); r = http_keepalive_send_recv(data:r1, port:port); if ( r == NULL ) exit(0); if (!ereg(pattern:"^HTTP.* 404 .*", string:r))exit(0); v4 = egrep(pattern:"^Server:.*Microsoft-IIS/4\.0", string:r); v5 = egrep(pattern:"^Server:.*Microsoft-IIS/5\.0", string:r); v51 = egrep(pattern:"^Server:.*Microsoft-IIS/5\.1", string:r); v6 = egrep(pattern:"^Server:.*Microsoft-IIS/6\.0", string:r); cltmp = eregmatch(pattern:".*Content-Length: ([0-9]+).*", string:r); if (isnull(cltmp)) exit(0);

112

cl=int(cltmp[1]); ver = string("The remote IIS server *seems* to be "); #if(v4) #{ # if (102 == cl) # ver = ver + string("Microsoft IIS 4 - Sp0\n"); # if (451 == cl) # ver = ver + string("Microsoft IIS 4 - SP6\n"); # if (461 == cl) # ver = ver + string("Microsoft IIS 4 - SP3\n"); #} if(v5) { #?? # if(111 == cl) # ver = ver + string("Microsoft IIS 5 - SP4\n"); if(3243 == cl) ver = ver + string("Microsoft IIS 5 - SP0 or SP1\n"); if(2352 == cl) ver = ver + string("Microsoft IIS 5 - SP2 or SRP1\n"); if(4040 == cl) ver = ver + string("Microsoft IIS 5 - SP3 or SP4\n"); } if(v51) { if (1330 == cl) ver = ver + string("Microsoft IIS 5.1 - SP2\n"); if (4040 == cl) ver = ver + string("Microsoft IIS 5.1 - SP0\n"); } if(v6) { if (2166 == cl) ver = ver + string("Microsoft IIS 6.0 - SP0\n"); if (1635 == cl) ver = ver + string("Microsoft IIS 6.0 - w2k3 build 3790\n"); } if ( ver != "The remote IIS server *seems* to be " ) { report = string( desc["english"], "\n\n", "Plugin output :\n", "\n", ver ); security_note(port:port, data:report); }

113

PlugIn per il discovery dei servizi

# # This script was written by Michel Arboi <arboi@alussinan.org> # # It is released under the GNU Public Licence. # # if(description) { script_id(14773); script_version ("$Revision: 1.24 $"); name["english"] = "Identifies services like FTP, SMTP, NNTP..."; script_name(english:name["english"]); desc["english"] = " Synopsis : This plugin performs service detection. Description : This plugin is a complement of find_service.nes. It attempts to identify services that return 3 ASCII digits codes (ie: FTP, SMTP, NNTP, ...) Risk factor : None"; script_description(english:desc["english"]); summary["english"] = "Identifies services that return 3 ASCII digits codes"; script_summary(english:summary["english"]); script_category(ACT_GATHER_INFO); script_timeout(0); script_copyright(english:"This script is Copyright (C) 2004 Michel Arboi"); script_family(english:"Service detection"); script_dependencie("find_service.nes"); # cifs445.nasl # "rpcinfo.nasl", "dcetest.nasl" # Do *not* add a port dependency on "Services/three_digits" # find_service2 must run after this script even if there are no # '3 digits' services exit(0); } # include("misc_func.inc"); include("global_settings.inc");

114

port = get_kb_item("Services/three_digits"); if (! port) exit(0); if (! get_port_state(port)) exit(0); if (! service_is_unknown(port: port)) exit(0); if (thorough_tests) retry = 3; else retry = 1; function read_answer(socket) { local_var r, answer, i; repeat { for (i = 0; i <= retry; i ++) { r = recv_line(socket: socket, length: 4096); if (strlen(r) > 0) break; } answer += r; } until (! r || r =~ '^[0-9]{3}[^-]' || strlen(answer) > 1000000); return answer; } soc = open_sock_tcp(port); if (! soc) exit(0); banner = read_answer(socket: soc); if (banner) replace_or_set_kb_item(name: "FindService/tcp/"+port+"/spontaneous", value: banner); else debug_print('Banner is void on port ', port, ' \n'); # 500 = Unknown command # 502 = Command not implemented # If HELP works, it is simpler than anything else send(socket: soc, data: 'HELP\r\n'); help = read_answer(socket: soc); if (help) { replace_or_set_kb_item(name: "FindService/tcp/"+port+"/help", value: help); if (! banner) banner = help; # Not normal, but better than nothing } if (help !~ '^50[0-9]') { if ("ARTICLE" >< help || "NEWGROUPS" >< help || "XHDR" >< help || "XOVER" >< help) { report_service(port:port, svc: 'nntp', banner: banner); exit(0); } # nb: this must come before FTP recognition. if ( egrep(string:banner, pattern:"^220.*HylaFAX .*Version.*") || egrep(string:help, pattern:"^220.*HylaFAX .*Version.*") ) { report_service(port: port, svc: 'hylafax', banner: banner); exit(0); } if ( "220 Sharp - NetScan Tool" >< banner ) { report_service(port: port, svc: 'ftp', banner: banner); exit(0); }

115

if ("PORT" >< help || "PASV" >< help) { report_service(port:port, svc: 'ftp', banner: banner); exit(0); } # Code from find_service2.nasl if (help =~ '^220 .* SNPP ' || egrep(string: help, pattern: '^214 .*PAGE')) { report_service(port: port, svc: 'snpp', banner: banner); exit(0); } if (egrep(string: help, pattern: '^214-? ') && 'MDMFMT' >< help) { report_service(port: port, svc: 'hylafax-ftp', banner: banner); exit(0); } } send(socket: soc, data: 'HELO mail.nessus.org\r\n'); helo = read_answer(socket: soc); if ( egrep(string: helo, pattern: '^250')) { report_service(port:port, svc: 'smtp', banner: banner); exit(0); } send(socket: soc, data: 'DATE\r\n'); date = read_answer(socket: soc); if (date =~ '^111[ \t]+2[0-9]{3}[01][0-9][0-3][0-9][0-2][0-9][0-5][0-9][0-5][0-9]') { report_service(port: port, svc: 'nntp', banner: banner); exit(0); } ftp_commands = make_list("CWD", "SYST", "PORT", "PASV"); ko = 0; foreach cmd (ftp_commands) { send(socket: soc, data: cmd + '\r\n'); r = read_answer(socket: soc); if (egrep(string: r, pattern: '^50[0-9]')) ko ++; debug_print('Answer to ', cmd, ': ', r); if (cmd == "SYST") { # We store the result of SYST just in case. Most (>99%) FTP servers answer # "Unix Type: L8" so this is not very informative v = eregmatch(string: r, pattern: '^2[0-9][0-9] +(.*)[ \t\r\n]*$'); if (! isnull(v)) set_kb_item(name: 'ftp/'+port+'/syst', value: v[1]); } } if (! ko) { report_service(port: port, svc: 'ftp', banner: banner); exit(0); } # Code from find_service2.nasl: # SNPP, HylaFAX FTP, HylaFAX SPP, agobot.fo, IRC bots, WinSock server, # Note: this code must remain in find_service2.nasl until we think that # all find_service.nes are up to date #

116

if (egrep(pattern:"^220 Bot Server", string: help) || raw_string(0xb0, 0x3e, 0xc3, 0x77, 0x4d, 0x5a, 0x90) >< help) { report_service(port:port, svc:"agobot.fo", banner: banner); exit(0); } if ("500 P-Error" >< help && "220 Hello" >< help) # or banner? { report_service(port:port, svc:'unknown_irc_bot', banner: banner); exit(0); } if ("220 WinSock" >< help) # or banner? { report_service(port:port, svc:'winsock', banner: banner); exit(0); } # Try poppasswd if (egrep(pattern:"^200 .* (Password service|PWD Server|poppassd)", string:banner)) { report_service(port:port, svc:"pop3pw", banner:banner); exit(0); } if (substr(banner, 0, 3) == '200 ') { close(soc); soc = open_sock_tcp(port); if (soc) { banner = read_answer(socket: soc); send('USER nessus\r\n'); r = read_answer(socket: soc); if (strlen(r) > 3 && substr(r, 0, 3) == '200 ') { send('PASS ', rand(), 'nessus\r\n'); r = read_answer(socket: soc); if (strlen(r) > 3 && substr(r, 0, 3) == '500 ') { report_service(port:port, svc:"pop3pw", banner:banner); close(soc); exit(0); } } close(soc); } } # Give it to find_service2 & others register_service(port: port, proto: 'unknown'); set_unknown_banner(port: port, banner: banner); if (report_paranoia > 1) { security_warning(port: port, data: 'Although this service answers with 3 digit ASCII codes like FTP, SMTP or NNTP servers, Nessus was unable to identify it. This is highly suspicious and might be a backdoor; in this case, your system is compromised and a cracker can control it remotely. ** If you know what it is, consider this message as a false alert ** and please report it to the Nessus team. Solution : disinfect or reinstall your operating system Risk factor : High'); }

117

118

Bibliografia [1] Constrained Automata: a Formal Tool for ICT Risk Assesment F. Baiardi, L. Ricci, C. Telmon diartmento informatica Università di Pisa F.Martinelli Istituto di Informatica e Telecomunicazioni, CNR, Pisa [2] Automatic Generation and Analysis of NIDS Attacks Shai Rubin, Somesh Jha, and Barton P. MillerUniversity of Wisconsin, Madison Computer Sciences Department {shai,jha,bart}@cs.wisc.edu [3] Testing Networkbased Intrusion Detection Signatures Using Mutant Exploits Giovanni Vigna vigna@cs.ucsb.edu William Robertson wkr@cs.ucsb.edu Davide Balzarotti balzarot@cs.ucsb.edu Reliable Software Group University of California, Santa Barbara Santa Barbara, CA 93106 [4] A Graph-Based Network-Vulnerability Analisys System Laura Painton Swiler, Cynthia Phillips, Timothy Gaylor [5] Modeling Multistep Cyber Attacks for Scenario Recognition Steven Cheung Ulf Lindqvist Martin W. Fong System Design Laboratory SRI International 333 Ravenswood Ave, Menlo Park [6] Cisco IPS-4240 v.6.0 technical evaluation Cisco System Inc. www.cisco.com [7] Le principali tipologie di attacco ai sistemi aziendali e personali INFOSEC [8] On the Completeness of Attack Mutation Algorithms Shai Rubin, Somesh Jha, and Barton P. Miller University of Wisconsin, Madison Computer Sciences Department {shai,jha,bart}@cs.wisc.edu [9] Xeno-ttacks: Near-Future Attack Mutation By Andrew Berkuta [10] Buffer overflow attack detect, exploit, prevent James C. Foster, Vitality Osipov, Nish Bhalla, NIels Heinen [11] Anti-Hacker Tool Kit, Second Edition by Mike Shema and Bradley C. Johnson McGraw-Hill © 2004 (808 pages) [12] Hacker’s programming book Flavio Bernardotti amc [13] Remote Timing Attacks are Practical Brumley, Boneh

119

[14] Syngress - Aggressive Network Self-Defense Neil Archibald, Seth Fogie, Chris Hurley, Dan Kaminsky, Johnny Long, Luke McOmie, Haronn Meer, Bruce Potter, Roelof Temmingh [15] Syngress,.Writing.Security.Tools.and.Exploits James C. Foster, Vincent T. Liu. [16] CISCO PIX Firewall and VPN Configuration Guide, Version 6.3 Cisco System Inc. www.cisco.com [17] Cisco ASA: All-in-One Firewall, IPS, and VPN Adaptive Security Appliance By Jazib Frahim Cisco System Inc.www.cisco.com [18] ] Ethereal Packet Sniffing by Angela Orebaugh [19] Cisco.Press,.The.Complete.Cisco.VPN.Configuration.Guide By Richard Deal [20] Cisco_Pix_6.3_Commands guide Cisco System Inc. www.cisco.com [21] Mcgraw Hill - Cisco Tcp-Ip Routing Professional Reference by Chris Lewis [22] Syngress - Sniffer Pro Network Optimization and Troubleshooting Handbook Robert Shiminski, Wally Eaton, Umer Khan, yuri Gordienko [23] Syngress,.Nessus.Network.Auditing Sence Post, Jay Beale, Raven Alder, Jimmy Alderson, Andy Johnston, Gorge A. Theall [24] Syngress,Nessus.Snort and Ethereal Power Tools Customizing Open Source Security Applications Gilbert Ramirez, Brian Caswell, snort.org, Noam Rathaus, Jay Beale

120

Sitografia

1. http://www.google.it

2. http://www.cisco.com

3. http://www.nessus.org

4. http://insecure.org/nmap/

5. http://www.looklan.com

6. http://www.ethereal.com

7. http://www.zyxel.com

8. http://www.redhat.it/fedora/

9. http:// www.kiwisyslog.com

10. http://www.oracle.com/

11. http://www.apache.org

12. http://www.tomcat.apache.org

13. http://www.intersectalliance.com/projects/Snare/

14. http://www.networkworld.com/weblogs/security/005784.html

15. http://www.seifried.org/security/ids/20020107-honeypot-vmware-basics.html

16. http://www.cis.udel.edu/~sunshine/F03/CIS659/mitigation.pdf

17. http://www.windowsitpro.com/WindowsSecurity/Article/ArticleID/49076/4907

6.html

18. http://www.windowsitpro.com/WindowsSecurity/Article/ArticleID/49076/4907

6.html

19. http://www.p2pforum.it/forum/showthread.php?t=110423

20. http://www.petri.co.il/forums/showthread.php?t=8386

21. http://www.emule-project.net/home/perl/general.cgi?l=18

22. http://www.afterdawn.com/guides/archive/little_emule_tutorial.cfm#02

23. http://www.sci.unich.it/~bista/didattica/reti-sicurezza/seminari2005-

06/Funzionamento_di_emule.ppt

24. http://it.wikipedia.org/wiki/EDonkey

25. http://it.wikipedia.org/wiki/EMule

26. http://www.cisco.com/en/US/products/hw/routers/ps380/products_installation_g

uide_chapter09186a0080471070.html

121

Ringraziamenti

Vorrei ringraziare di cuore i miei relatori Fabrizio Baiardi ed Emanuele Briganti che

mi hanno sostenuto e consigliato durante l’elaborazione e la stesura di questo lavoro.

Ringrazio Marco Misitano e Marco Voi, di Cisco Systems, che mi hanno aiutato per

problemi tecnici del dispositivo MARS.

Un grazie alla Pc System s.r.l, in particolare, a Flavio Casini che ha sostenuto i costi,

per me proibitivi, di MARS e dei dispositivi utilizzati nei test.

Grazie infinite a Papà e Mamma che mi hanno appoggiato e sostenuto nelle mie

scelte, a Donatella e Maria, sorelle fantastiche e particolarmente vicine durante

l’esperienza universitaria.

Un grazie reciproco ai miei inseparabili amici Giuseppe “il Rosso” e “Michele

l’uomo Nero”, persone vere, disponibili in qualsiasi momento, soprattutto in quelli

meno fortunati e che, come me, ora sono impegnati a scrivere i loro ringraziamenti.

Grazie agli amici di Genzano, in particolare, Pierino che ha abbandonato Roma per

stare con noi a Pisa.

Grazie alla banda di Peppe “la Mente”, Gianfranco “il Brigante”, Raffaele “Zampy”,

Enza, Alberto “u’ Boss”, Passeretta e a tutti gli amici “Lopez”, compagni di notti

brave a piazza dei Cavalieri.

Un particolare ringraziamento a Maria Teresa, dolce compagna, capace, come

sempre, di farmi sorridere nei momenti, come questi, fatti di tensioni.

Colgo l’occasione per esprimere tutta la mia felicità e soddisfazione per aver

raggiunto, nella vita, un così grande traguardo.

Un forte abbraccio a tutti quelli che hanno creduto in me e che mi vogliono bene.