Elaborato guida luigi n46-766 - Corso di Laurea in Ingegneria

Scuola Politecnica e delle Scienze di Base
Corso di Laurea in Ingegneria Informatica
Elaborato finale in Reti di Calcolatori
Tecnologie per la Sicurezza di Rete:
Un attacco DDos ad infrastruttura Cloud
Anno
no Accademico 2013/2014
Candidato:
Luigi Guida
matr. N46000766
1
2
Indice
Introduzione .................................................................................................................... 4
Capitolo 1 – Denial of Service ........................................................................................ 5
1.1
Generalità ............................................................................................................ 5
1.2
Tipologie ............................................................................................................. 6
Capitolo 2 – Attacco a CloudFlare................................................................................ 10
2.1
Panoramica........................................................................................................ 10
2.2
Cos’è CloudFlare .............................................................................................. 10
2.3
Network Time Protocol..................................................................................... 12
2.3.1
Caratteristiche del protocollo ....................................................................... 14
2.3.2
Descrizione del protocollo ............................................................................ 15
2.3.3
Funzionamento del Protocollo ...................................................................... 16
2.4
Attacco DDoS NTP Amplification da 400Gbps ............................................... 18
2.4.1
Denial-of-Service Riflesso Amplificato ......................................................... 18
2.4.2
NTP Amplification......................................................................................... 20
2.4.3
Dinamica dell’attacco ................................................................................... 23
2.4.4
Sistemi difensivi in risposta all’attacco ........................................................ 25
Capitolo 3 – Prevenzione .............................................................................................. 27
3.1
Contrastare attacchi DDos Ntp ....................................................................... 27
Conclusioni ................................................................................................................... 29
Appendice A ................................................................................................................. 31
Bibliografia e Sitografia ................................................................................................ 35
3
Introduzione
La sicurezza delle reti è da sempre uno degli obiettivi principali che le
organizzazioni, sia pubbliche che private, di qualsiasi ambito, si pongono. “Essere
sicuri” vuol dire essere in grado di fronteggiare qualsiasi evento e, nel caso
specifico, riuscire a garantire l’integrità e la continuità dei processi gestiti dai
sistemi nei confronti degli attacchi informatici, qualsiasi sia la loro natura. In
misura sempre maggiore, l’attenzione nella sicurezza delle reti è focalizzata sullo
sviluppo delle proprie infrastrutture, alle quali viene affidata la funzione di
protezione dai possibili assalti di malintenzionati. Con l’avvento di nuovi scenari,
che vengono a crearsi con la continua evoluzione delle reti e nel caso specifico di
Internet, risultano necessari dei cambiamenti, anche per quanto concerne la
gestione sicura delle reti. Oltre all’ausilio delle consuete apparecchiature, di uso
largamente diffuso, quali firewall, sistemi di rilevamento IDS (Intrusion Detection
System) e di prevenzione delle intrusioni IPS (Intrusion Prevention System), sta
diventando sempre più di uso comune, da parte degli utenti della rete, di affidarsi
per la propria sicurezza a soggetti terzi, aziende cioè, che sviluppano sistemi di
sicurezza
all’avanguardia
servendosi
di
infrastrutture
proprietarie
e
tecnologicamente avanzate. Proprio una di tali aziende si è resa protagonista
dell’attacco DoS che verrà esposto.
Nella prima parte dell’elaborato si definirà cos’è un attacco DoS e inoltre,
verranno descritte le varie tipologie di questo attacco.
In seguito, si esporranno, in primo luogo, alcune informazioni inerenti l’attacco
scelto come oggetto del lavoro svolto. Particolare attenzione verrà rivolta al CDN
che ha subito tale violazione e soprattutto alle caratteristiche principali del
protocollo NTP, dove la sua vulnerabilità ha rivestito un ruolo fondamentale. Si
passerà poi, alla descrizione dettagliata dell’attacco fornendo informazioni, oltre
che sulle dinamiche, sugli strumenti utilizzati e sulle conseguenze provocate.
Infine, verranno delineati i sistemi di sicurezza utilizzati dall’azienda per
fronteggiare l’attacco e come in generale questo tipo di attacco può essere evitato.
4
Capitolo 1 – Denial of Service
1.1 Generalità
L’attacco Denial of Service, che letteralmente vuol dire “negazione del servizio”
provoca il malfunzionamento di un sistema informatico esaurendone le sue risorse
fino ad impedire l’erogazione di servizi.
Sul piano organizzativo ed operativo, quando accade un attacco DoS la situazione
risulta estremamente critica ed è caratterizzata dalla difficoltà di controllare
l’erogazione dei servizi informatici e peggio ancora di riportare quest’ultimi alla
normalità operativa in tempi accettabili.
In generale, questi attacchi possono essere di due tipi:
•
Denial of Service (DoS) è un attacco coordinato da una singola fonte con
l’obiettivo di sopraffare e disabilitare il servizio di destinazione;
•
Distributed Denial of Service (DDoS) è un attacco coordinato e sferrato
simultaneamente da più fonti, con la finalità, anch’esso, di disabilitare il
servizio di destinazione. Le sorgenti, in questo caso, tipicamente fanno
parte di una o più “botnet” (insiemi di computer compromessi) e possono
essere sparse in una regione oppure disseminate in tutto il globo.
Gli attacchi DoS sono universalmente definiti come violazioni delle norme di
comportamento accettabili, contrastano lo spirito e le regole stabilite dal Internet
Activities Board (IAB) nel documento “Ethics and the Internet” (RFC 1087);
nella maggior parte dei paesi sono considerati alla stregua dei reati convenzionali
ed in nessun caso se ne legittima l’utilizzo. Gli attacchi DoS sono utilizzati da vari
gruppi di individui ed organizzazioni per promuovere la rispettiva causa.
Le motivazioni sono l’elemento fondamentale che li contraddistingue:
•
Hacktivisti1 mossi da rivendicazioni sociali e politiche;
•
aggressori che sfidano le leggi e l’operato dei governi;
•
aggressori con motivazioni economiche.
1
Hacktivista: composto dalle parole hacker e activist, è colui che effettua azioni di pirateria informatica
con intenti di attivismo politico
5
1.2 Tipologie
Attualmente si definiscono due macro tipologie di attacchi DoS:
•
DoS di tipo “Network Flood”: conosciuti anche come attacchi volumetrici,
inviano volumi di traffico irrilevante (UDP, TCP o richieste di
connessione SYN). Il loro obiettivo è di consumare la larghezza di banda
della rete e d’inondare i dispositivi presenti su tale rete, rendendo
inaccessibile il soggetto colpito o addirittura l’intera rete.
•
DoS contro le applicazioni: sferrati contro le applicazioni, continuano ad
inondarle con richieste apparentemente legittime (“Application Flood
Attack”) o che sfruttano debolezze di design o implementative delle
applicazioni stesse (“Directed Application Attack”), fino al momento in
cui i sistemi non rispondono più. Solitamente, tali attacchi passano
inosservati, poiché il volume di traffico da essi generato non è rilevante e
determina un consumo lento delle risorse che però metterà fuori servizio
l’applicazione.
Per entrambe le tipologie, alcune tra le tecniche più utilizzate negli ultimi anni per
colpire la rete troviamo:
SYN Flood: adoperato per esaurire le risorse del bersaglio, inondandole
con una massa di connessioni half-open, fino a consumarle del tutto.
L’aggressore invia di continuo richieste di connessioni aperte (TCP/SYN)
al sistema vittima avvalendosi, a tal scopo, di un indirizzo sorgente
falsificato. Il destinatario conferma la ricezione della richiesta (SYNACK)
all’indirizzo sorgente falsificato aprendo così una connessione per ogni
singola richiesta. Il processo TCP standard per la gestione della
connessione (three-way handshake) non viene tuttavia mai completato, in
quanto l’indirizzo sorgente falsificato non invia più alcuna risposta e
quindi la vittima dell’attacco viene generalmente sommersa con
connessioni incomplete (half-open).
HTTP Flood: solitamente, sono indirizzati verso servizi che generano
volumi e carichi ingenti, come operazioni di ricerca all’interno di un sito
oppure attività di database estremamente pesanti, in modo da consumare
6
un numero maggiore di risorse e causando ritardi a livello di risposta ed
eventualmente anche una condizione di fail.
Esistono diverse forme di attacchi di tipo HTTP flood:
-
“GET” o “PUT” flood: in tal caso, l’aggressore invia richieste
HTTP di tipo GET o POST alla pagina principale del sistema
scelto come bersaglio finché i dispositivi di rete (server, pipe di
rete, ecc.) vengono sopraffatti e non sono più in grado di gestire
le richieste. Questo attacco può inoltre prevedere l’aggiunta di
una stringa di query alle richieste HTTP allo scopo di bypassare
i componenti per la trasmissione di contenuti (CDN) o i servizi
di caching; ciò genera un traffico che colpisce direttamente il
sito Web senza passare per i componenti infrastrutturali quali
CDN e caching.
-
Attacchi HTTP “lenti”: simili ai SYN Flood, vengono sferrati
a livello HTTP in modo tale che il server web esaurisca le sue
risorse attraverso connessioni nuove aperte di continuo. Gli
Attacker inviano una richiesta “GET”, riducendo la dimensione
della finestra. Ciò costringe il server web ad inviare la sua
risposta in pacchetti più piccoli rispetto al solito, forzando le
connessioni in modo tale da rimanere aperte più a lungo del
normale e riempiendo la tabella delle connessioni del server. Si
tratta di un attacco “lento e silenzioso”, in quanto non genera
segni evidenti di attacco quali un consumo elevato della CPU o
della banda di rete. Lo stesso attacco può essere sferrato
utilizzando comandi POST, con cui l’aggressore simula di dover
inviare un grande blocco di dati che di fatto non viene mai
inviato.
-
HTTP flood su una risorsa mirata: l’aggressore analizza il sito
della vittima allo scopo di individuare una risorsa che genera un
carico particolarmente pesante sui server come, ad esempio, le
operazioni di ricerca di un sito oppure attività su database molto
pesanti. Generalmente, l’aggressore sferra il proprio attacco
7
contro il servizio con volumi di traffico estremamente ridotti.
Un server configurato per poter gestire migliaia di connessioni
al secondo può essere completamente sopraffatto e messo fuori
servizio da 20 connessioni al secondo di questo tipo di attacco.
-
UDP Flood: vengono inviati alla vittima pacchetti contenenti
datagrammi UDP; la vittima a questo punto controlla la porta di
un’applicazione correlata; non trovandone alcuna, è costretta a
rispondere con un pacchetto ICMP Destination Unreachable.
Tale attacco viene sferrato in modo continuativo finché la pipe
di rete, il firewall oppure altri dispositivi di rete che operano
presso
la
vittima
non
vengono
totalmente
sopraffatti.
L’aggressore può anche falsificare l’indirizzo IP dei pacchetti
UDP, non svelando alcun dato e rimanendo pertanto totalmente
anonimo.
-
ICMP Flood: questo tipo di attacco DoS viene attualmente
bloccato dai firewall e dalla policy dei dispositivi di rete, inoltre
comprende alcune tecniche piuttosto note, quali:
o Ping Flood: dove si sommerge la rete con traffico
ICMP. L’aggressore invia un ingente volume di
richieste “ping” ICMP, falsificando l’indirizzo sorgente
con l’indirizzo della vittima che, a questo punto, viene
sommersa da tutte le risposte.
o Smurf Attack: anche in tal caso si vuole inondare il
bersaglio
con
traffico
ICMP,
ma
ciò
avviene
amplificando l’effetto sfruttando Gateway/Router IP
mal configurati che processano richieste “ping” inviate
ad indirizzi broadcast e con indirizzo mittente
falsificato, corrispondente all’IP della vittima. Gli host
che ricevono il “ping” ICMP risponderanno poi alla
vittima dell’attacco sommergendola interamente.
-
Low rate DoS (LDOS): viene utilizzato per rallentare il
throughput TCP del sistema vittima senza che l’aggressore sia
8
intercettato. Si sfruttano i punti deboli del timing TCP per
generare l’elaborazione TCP presso la vittima, la quale, a causa
di ciò, entra ripetutamente in uno stato di ritrasmissione; questo
si ripercuote negativamente sul throughput del protocollo di
trasporto TCP.
-
Peer-to-Peer: questo attacco è usato per generare un elevato
numero di richieste di connessioni quasi simultanee indirizzate
alla vittima. I bug presenti nel server software peer-to-peer
permettono agli aggressori di dirottare i client negli hub peer-topeer. I client a questo punto andranno a disconnettersi dalla rete
peer-to-peer, connettendosi, così, al sito della vittima; si creerà
in tal modo una vera e propria ondata di richieste di
connessione.
9
Capitolo 2 – Attacco a CloudFlare
2.1
Panoramica
Di recente, per l’esattezza il 10 Febbraio 2014, si è scatenato un attacco DDos di
tipo UDP Flood ai danni di CloudFlare, azienda americana della Silicon Valley,
che offre svariati servizi di cloud. La particolarità di tale attacco è stata l’elevata
proporzione di traffico dati registrata dal CDN (Content Delivery Network)
colpito.
L’attacco ha usato una ben nota falla nel protocollo NTP (Network Time
Protocol), utilizzato per il settaggio degli orologi dei server connessi alla rete.
Tale protocollo basato per l’appunto su UDP, è stato sovvertito usando richieste di
sincronizzazione attraverso il comando MONLIST dove il sistema, scelto per la
sua vulnerabilità, rigetta fuori un gran volume di dati, che saranno utilizzati per la
saturazione delle risorse della vittima.
2.2
Cos’è CloudFlare
CloudFlare è un caching reverse proxy, ovvero un server che si pone tra
l’infrastruttura dove risiede un sito web e il visitatore; inoltre, svolge funzioni di
caching dei contenuti (salva temporaneamente in memoria i contenuti per poterli
servire più velocemente).
Quando arriva una richiesta, CloudFlare controlla se il visitatore è affidabile, e
solo in caso positivo, dopo aver prelevato i contenuti (immagini, CSS e
JavaScript) dalla cache e aver applicato varie ottimizzazioni su tali contenuti, li
restituisce al visitatore stesso che non si accorgerà di tali passaggi.
CloudFlare protegge e accelera qualsiasi sito web online. In pratica il traffico dati,
relativo ad un determinato sito web, viene instradato attraverso tale rete globale
che viene definita “intelligente”.
Il CDN CloudFlare è realizzato in maniera autonoma e differente dalle legacy
solitamente utilizzate, per di più sfrutta una rete indipendente caratterizzata da un
10
posizionamento dei propri edge-points, scelto in maniera molto precisa per
diminuire quanto più possibile i tempi di attesa percepiti dall’utente.
Figura 1 Overview di CloudFlare
www.cloudflare.com
CloudFlare è caratterizzato da 24 centri dati dislocati in tutto il mondo. Il CDN fa
la cache dei file sui nodi periferici della rete, cosi da risultare quanto più vicino
possibile alla posizione dell'utente e allo stesso tempo fornisce ad essi contenuti
dinamici. Attraverso l’instradamento Anycast 2 l’utente accederà ai contenuti
richiesti utilizzando il nodo a lui più vicino.
Da un punto di vista della sicurezza, CloudFlare oltre che a comportarsi da
firewall, sfrutta la conoscenza di una comunità diversificata di siti web per offrire
una modalità all’avanguardia per il proprio servizio di sicurezza. La tecnologia di
CloudFlare rileva automaticamente nuovi attacchi che sorgono contro qualsiasi
sito web sulla sua rete; una volta che viene identificata la presenza di un nuovo
attacco, il CDN lo bloccherà sia per il particolare sito web che per l'intera
comunità. Un'altra importante funzione che esso svolge è quella di eseguire
automaticamente un controllo dell'integrità del browser per tutte le richieste ad un
determinato sito web, valutando le intestazioni HTTP per verificare la presenza di
minacce. Se viene trovata una minaccia, la richiesta verrà negata. I visitatori
indesiderati non vengono catalogati attraverso l’uso di programmi di analisi
2
Indirizzamento Anycast: Avviene un'associazione uno-a-molti tra indirizzi di rete e ricevitori: ogni
indirizzo destinatario identifica un insieme di ricevitori, ma soltanto uno tra questi ricevitori è scelto per
ricevere i dati da una qualsiasi delle sorgenti. Inoltre, consente nel caso si è attaccati di dirottare tutti i
pacchetti destinati all’indirizzo Anycast, mitigando la minaccia.
11
popolari, ma è il sistema stesso che si fa carico di salvare informazioni dalla rete e
di metterle a disposizione degli utenti, in modo da poter utilizzare le risorse
catalogate in database per una migliore gestione e prevenzione nei confronti di
mal intenzionati.
Alcune delle altre funzionalità offerte da CloudFlare sono:
•
Mantere on-line la porzione di sito statica anche se il server di
riferimento va in crash
•
Global Anycast DNS
•
Ottimizzazione
nella
gestione
delle
pagine
(caricamento,
ridimensionamento, ecc.)
•
Sistema di difesa contro attacchi DDos
•
WAF
(Web
Application
Firewall)
con
regole
definite
appositamente
2.3
•
Strumenti di analisi specifici
•
Railgun (ottimizzatore web)
Network Time Protocol
Il Network Time Protocol (NTP) è un protocollo impiegato per sincronizzare gli
orologi di dispositivi differenti collegati tramite una rete a commutazione di
pacchetto, caratterizzata, quindi, da inaffidabilità e tempi di latenza variabili. Il
sistema utilizzato per rappresentare l'ora è l'attuale standard ufficiale per la misura
di tempo nel mondo, il Tempo Universale Coordinato (UTC)3.
L’ora standard UTC viene distribuita sui vari dispositivi, ma dato che risulterebbe
complicato ed oneroso dotarli tutti di ricevitori specifici per la diffusione del
tempo, si preferisce equipaggiare solo un certo numero di computer che facciano
da time-server primari per sincronizzare un numero molto più elevato di server
secondari e client connessi da una rete comune, per esempio su Internet.
NTP permette di leggere l'orologio del server, trasmettere la lettura ad uno o più
client e regolare l'ora di ciascun client come da richiesta. L'accuratezza di ciascun
3
Il tempo coordinato universale: conosciuto anche come tempo civile e abbreviato con la sigla UTC, è
il fuso orario di riferimento da cui sono calcolati tutti gli altri fusi orari del mondo. Esso è derivato dal
tempo medio di Greenwich(GMT),con il quale coincide a meno di approssimazioni infinitesimali.
12
server è definita dallo strato: al livello gerarchicamente posto più in alto (relativo
ai server primari che accedono direttamente ad un orologio campione) è assegnato
il numero 1, poi scendendo nella gerarchia di rete (server secondari) il numero
dello strato verrà incrementato di uno ad ogni successivo livello di
sincronizzazione.
Di solito nelle configurazioni NTP viene utilizzata la tecnica della ridondanza,
dove server multipli e percorsi di reti diversificati,
determinano una grande
accuratezza ed affidabilità. Alcune configurazioni vengono implementate
attraverso l’uso di servizi di autenticazione crittografica per prevenire attacchi
accidentali o dolosi al protocollo.
In figura, viene riprodotta una possibile configurazione di Server Ntp, naturalmente in maniera
molto semplificata:
preso BX, un calcolatore stand-alone, esso viene sincronizzato dal server A1 di strato S1. Nel caso
di BY, invece, per
avere una maggiore
affidabilità
per
la
sincronizzazione,
il
calcolatore
è
stato
configurato con due
possibili server A1 e
A2. Se si considera
un'organizzazione (es
l’insieme di B1 e B2
come in figura 2),
valutando il fatto di
dover sincronizzare i
Figura 2 Schema di una configurazione NTP
vari
calcolatori
della
propria rete locale, in una soluzione classica avremo: definiti due calcolatori della propria rete (B1
e B2), come server locali NTP, essi si sincronizzano su tre server primari (A1, A2, A3), infine
viene sincronizzato il resto dei propri calcolatori dell’organizzazione (C1, C2, ... CN) sui server
locali (B1, B2). Questa configurazione riduce il traffico di rete verso i server primari e rende la
configurazione di tutti i calcolatori della rete locale dipendente solo dai server locali B1 e B2, che
possono essere facilmente riconfigurati su altri server esterni in caso di necessità. B1 e B2
rappresentano quindi server NTP di strato 2.
13
2.3.1 Caratteristiche del protocollo
La RFC958 è stato il primo documento per la standardizzazione del protocollo
NTP e risale al 1985.
Questo è costruito sul modello dell’ User Datagram Protocol (UDP), che fornisce
un meccanismo di trasporto senza connessione. NTP si è evoluto a partire dal
Time Protocol e dal messaggio di Timestamp ICMP risultandone una sostituzione
adeguata per entrambi.
NTP determina i meccanismi per sincronizzare l'ora, teoricamente, fino a
precisioni dell'ordine dei nanosecondi, preservando una data non ambigua, almeno
per questo secolo. Attraverso tale protocollo si specificano la precisione e l'errore
stimato dell'orologio locale e le caratteristiche dell'orologio di riferimento a cui
può essere sincronizzato. Tuttavia, il protocollo in sé definisce solo la
rappresentazione dei dati ed il formato dei messaggi, ma non gli algoritmi di
sincronizzazione o le tecniche di filtraggio.
Il servizio per cui questo protocollo è stato progettato ha l’intento di connettere
alcuni orologi di riferimento primari, sincronizzati agli standard temporali
nazionali, a risorse centrali accessibili come i gateway. Questi dialogano tra di
loro in NTP per controllare mutuamente gli orologi primari e ridurre gli errori
dovuti a guasti o problemi di propagazione. Alcuni degli host appartenenti alla
rete locale e funzionanti da orologi di riferimento secondari, dialogano in NTP
con uno o più dei detti gateway. Per ridurre l'overhead del protocollo, gli host
ridistribuiscono l'ora ai restanti host di rete locale. Gli host selezionati, per
aumentare l'affidabilità, vengono equipaggiati con radio-orologi meno accurati e
costosi, per poi essere utilizzati come backup nel caso di malfunzionamento degli
orologi primari o secondari o dei percorsi di comunicazione tra di essi.
La configurazione standard di una sottorete di orologi primari e secondari è
organizzata gerarchicamente, dove gli orologi più accurati sono vicino al vertice e
quelli meno in basso. NTP fornisce informazioni utilizzate per organizzare la
gerarchia sulla base della precisione o dell'errore stimato, inoltre funge anche da
rudimentale algoritmo di routing nell’organizzazione della sottorete stessa.
14
2.3.2 Descrizione del protocollo
In NTP non vengono menzionati meccanismi di ricerca, acquisizione o
l'autenticazione dei peer. L'integrità dei dati si basa sui checksum IP e UDP.
Inoltre, non si forniscono servizi per la raggiungibilità, la gestione di circuito,
l'individuazione dei duplicati o la ritrasmissione.
Il servizio può operare in due distinte modalità:
•
In modalità simmetrica, i server ed i client risultano indistinguibili, ma
mantengono una piccola quantità di informazione di stato;
•
In modalità asimmetrica, i server non hanno bisogno di mantenere alcuna
informazione di stato sul client se non quella contenuta nella richiesta del
client stesso. Inoltre, risulta necessario un singolo formato di messaggio
NTP, semplificando cosi l'implementazione e permettendo di utilizzare
svariati meccanismi di interrogazione sollecitata o non sollecitata.
Nella modalità più comune (asimmetrica) un client manda un messaggio NTP ad
uno o più server ed elabora le risposte ricevute. Il server scambia indirizzi e porte,
riempie o sovrascrive certi campi del messaggio, ne ricalcola il checksum e lo
rispedisce immediatamente. Attraverso l'informazione inclusa nel messaggio NTP
si permette di determinare, a ciascun peer, client o server, le caratteristiche di
temporizzazione degli altri peer, tra cui il valore atteso delle accuratezze dei loro
orologi. A partire da tale informazione ogni peer è in grado di scegliere l'ora
migliore da differenti orologi, aggiornare il suo orologio locale e stimare la sua
accuratezza.
In generale, la sincronizzazione degli orologi richiede periodi lunghi e confronti
multipli per mantenere una temporizzazione accurata. Se per mantenere l'ora
locale con la precisione di un secondo, è necessario che vengano effettuati pochi
confronti, per regolare l'ora locale con precisioni di alcuni decimi di millisecondo,
invece, sono richiesti periodi di ore o giorni, e decine o centinaia di confronti. Per
fortuna, la frequenza dei confronti può essere ridotta e quasi sempre non disturba
le normali operazioni della rete.
15
2.3.3 Funzionamento del Protocollo
La distinzione tra il client e il server risulta significativa solo per la modalità con
la quale essi interagiscono nello scambio di richieste e risposte. Lo stesso formato
di messaggio NTP è valido per entrambi i peer e racchiude i medesimi dati relativi
all'altro peer.
Nella modalità asimmetrica il client manda periodicamente un messaggio NTP al
server, il quale risponde entro un certo intervallo. Considerando che il server si
limita a scambiare indirizzi e porte, a riempire i campi di informazione richiesti e
a rispedire il messaggio, i server operanti in tale modalità non hanno bisogno di
memorizzare alcuna informazione di stato tra le richieste dei client.
Nella modalità simmetrica, invece, non vi è più alcuna distinzione tra client e
server. Ogni peer mantiene una tabella dove il numero di entrate equivale ai peer
attivi. Per ogni entrata vi è un codice che identifica: il peer in maniera univoca,
l'informazione di stato e una copia dei valori di Timestamp di Origine e Timestamp
di Ricezione, i quali sono stati ricevuti per ultimi da quel peer. Il peer manda
periodicamente un messaggio NTP a ciascuno dei peer in tabella, includendo
l'ultima copia dei Timestamp. L'intervallo per la trasmissione dei messaggi NTP è
regolato dal mittente e non è influenzato dall'eventuale arrivo di messaggi NTP,
provenienti da altri peer.
La modalità con cui un peer opera è data dal controllo dei campi UDP Porta di
Sorgente e Porta di Destinazione :
Se entrambi questi campi contengono il numero della porta di servizio NTP 123
allora il peer sta operando in modalità simmetrica.
Se i due campi sono diversi e il campo Porta di Destinazione contiene 123, si
tratta di una richiesta proveniente da un client ad un server.
Se i due campi sono diversi e il campo Porta di Sorgente contiene 123, si tratta di
una risposta di un server ad una richiesta di un client trasmessa precedentemente.
Un client, quando vuole sincronizzare il proprio orologio manda un pacchetto
NTP con tutti i campi a 0 tranne Indicatore di Intercalare, Stato e Timestamp di
Trasmissione (non è necessario che il suo orologio sia corretto; impostare il valore
del campo Timestamp di Trasmissione è importante, sia come semplice metodo
16
per verificare che la risposta del server sia legittima, sia per i vari calcoli che
vengono effettuati).
Il server, quando riceve un pacchetto di richiesta di sincronizzazione, copia dalla
richiesta il campo Timestamp di Trasmissione nel campo del messaggio di
risposta Timestamp di Origine e riempie i restanti campi in modo opportuno.
Quando
la
risposta
del
server
è
ricevuta,
il
client
determina
un
“DestinationTimestamp” che è il tempo di arrivo in accordo col proprio orologio
nel formato NTP.
Dichiarando:
Timestamp
ID quando viene generato
Timestamp di Origine
richiesta inviata dal client
Timestamp di Ricezione
richiesta ricevuta dal server
Timestamp di Trasmissione
risposta inviata dal server
DestinationTimestamp
risposta ricevuta dal client
possiamo definire due quantità molto importanti: il roundtrip delay(d) e l'offset (t)
dell'orologio:
=
=
−
−
−
−
+
2
−
dove:
d: Rappresenta il tempo che una richiesta impiega per raggiungere il server
sommato al tempo che la risposta impiega per tornare indietro. La prima quantità
della relazione rappresenta il tempo relativo al client, tra la trasmissione della
richiesta e la ricezione della risposta; mentre il secondo addendo rappresenta il
tempo di elaborazione sul server della richiesta, prima che spedisca la relativa
risposta.
17
t: Rappresenta la differenza di tempo tra due orologi ed, in questo frangente, è
l'ammontare di tempo da sommare al proprio orologio per sincronizzarlo con
quello della sorgente di riferimento. Questo valore è il risultato più importante del
protocollo NTP, poiché consente di ottenere la sincronizzazione del proprio
orologio.
Mentre l'offset può normalmente avere segno negativo (l'orologio locale è in
anticipo rispetto all'orologio di riferimento), un delay negativo è possibile soltanto
nelle modalità simmetriche.
2.4
Attacco DDoS NTP Amplification da 400Gbps
Gli attacchi di tipo DDos in rete sono, negli ultimi periodi, all’ordine del giorno.
Essi fino a qualche tempo fa non venivano visti come una vera e proprio minaccia
dato che non lasciavano danni nei sistemi che li subivano; l’unico problema che
comportavano era la congestione temporanea di risorse e sistemi, che finivano per
essere vittima di tali attacchi per un tempo molto limitato, quasi trascurabile. Ciò
che di recente accade, diversamente dal passato, è la quantità di dati che i
Cracker
4
riescono a generare e a convogliare applicando tecniche di
amplificazione, vuoi attraverso l’uso di DNS (attacco a SpamHaus 2013), vuoi,
come nel caso da noi preso in considerazione, attraverso l’Amplificazione NTP.
2.4.1 Denial-of-Service Riflesso Amplificato
In un attacco Denial-of-Service di riflessione, un utente malintenzionato può
inviare un pacchetto con un indirizzo IP sorgente falsificato. Il Cracker falsifica
l'indirizzo d'origine del pacchetto, sostituendo il proprio indirizzo sorgente con
4
Cracker versus Hacker: Anche se hanno alcune tecniche di utilizzo similari, l'hacker è colui che sfrutta
le proprie capacità per esplorare, divertirsi, apprendere, senza creare reali danni. Al contrario, il cracker è
colui che sfrutta le proprie capacità al fine di distruggere (i cracker fanno spesso utilizzo di attacchi DoS),
ingannare e arricchirsi.
18
l'indirizzo della vittima, tale pacchetto verrà inviato ad uno specifico server su
internet che risponderà tempestivamente.
Tutto ciò determina principalmente due effetti: la vera fonte dell'attacco è
nascosta ed è molto difficile da rintracciare e, se si usano molti server Internet, un
attacco può essere costituito da un numero enorme di pacchetti che colpisce la
vittima da tutto il mondo.
Ma ciò che rende gli attacchi Denial-of-Service di riflessione davvero potenti è
quando questi sono anche amplificati: un piccolo pacchetto che viene inviato da
un client suscita una grande risposta dal parte del server (o dei server).
In questo caso, un utente malintenzionato può inviare un piccolo pacchetto da un
indirizzo IP sorgente falsificato ad un server (o a più server) il quale invierà
grandi quantità di dati, come risposta al pacchetto ricevuto, alla vittima.
In Attacchi di amplificazione, un aggressore trasforma una piccola quantità di
banda proveniente da un piccolo numero di macchine in un enorme carico di
traffico atto a colpire una vittima in Internet. Fino ad ora il protocollo più
popolare per gli attacchi di amplificazione è stato DNS(Domain Name System)5,
dove il fattore di amplificazione è quantificato intorno a 8x. Quindi, un utente
malintenzionato può generare un attacco 8x più grande della larghezza di banda a
cui aveva accesso.
Un altro protocollo che spaventa gli esperti del settore, soprattutto in chiave futura
per attacchi di amplificazione, è attraverso l’uso di SNMP, che si stimi abbia un
fattore di amplificazione pari a 650x anche se per ora non è stato ancora possibile
riscontrare effetti del genere.
Nel caso in esame, invece, il protocollo scelto per l’attacco è stato NTP, che ha
determinato un fattore di amplificazione intorno al 200x, come mai visto in
passato.
5
DNS: Meccanismo utilizzato per la risoluzione di nomi degli Host della rete in indirizzi IP e viceversa. Il
servizio è realizzato tramite un database distribuito, costituito dai server DNS.
19
2.4.2 NTP Amplification
Il problema del protocollo NTP, che è stato la causa di quanto accaduto, è
principalmente dovuto all’obsolescenza del protocollo stesso. La sua vulnerabilità
è da attribuire soprattutto alle prime versioni di tale protocollo che però risultano
ancora utilizzate da parecchi dispositivi collegati alla rete. Configurazioni
negligenti di server NTP possono portare a svariati problemi tra i quali quella di
diventare, da parte di tali server, partecipanti inconsapevoli di attacchi DDoS.
I server che eseguono il Network Time Protocol (NTP) sulla base di
implementazioni di ntpd precedenti alla versione 4.2.7p26, che utilizzano la
configurazione di “query senza restrizioni” di default, sono suscettibili di un
attacco Denial-of-Service di tipo Riflessione/Amplificazione.
Un utente malintenzionato, armato di un elenco di “server NTP aperti” su Internet,
può facilmente creare un attacco DDoS con NTP. Infatti, i server NTP che si
prestano a tali scopi non sono difficili da trovare: strumenti comuni come
Metasploit6 e NMAP7 sono in grado di individuare i server NTP che supportano
comandi utili alla causa dei Cracker, comandi cioè capaci di provocare un
amplificazione del messaggio.
Alcuni
messaggi
di
controllo
NTP
forniscono
significativi
fattori
di
amplificazione di larghezza di banda (BAF). Infatti, NTP oltre che per la
sincronizzazione dell'ora, può anche implementare altre funzioni quali la gestione
di server, manutenzione e monitoraggio.
Come già detto NTP si basa sul protocollo UDP (User Datagram Protocol) per
inviare e ricevere messaggi, il quale non convalida la fonte (indirizzo IP) del
mittente. L'attacco NTP DRDOS (distribuited reflective denial-of-service) è simile
agli attacchi DoS riflettenti utilizzati sui“risolutori DNS aperti”.
6
Metasploit : progetto di sicurezza informatica che fornisce informazioni sulle vulnerabilità, semplifica le
operazioni di penetration testing ed aiuta nello sviluppo di sistemi di rilevamento di intrusioni.
7
NMAP: software libero creato per effettuare port scanning.
20
Figura 3 Amplificazione di un attacco
www.cloudflare.com
Colui che genera l’attacco invia un pacchetto sulla porta
orta 123 di un server Ntp
aperto, dove il proprio indirizzo sorgente è l’indirizzo
l’
IP
P della vittima
predestinata.. Il server NTP risponde a questa richiesta, ma il numero di byte
inviati in risposta risulta essere una quantità amplificata rispetto alla richiesta
richi
iniziale, determinando così un attacco Dos ai danni della vittima che si ritroverà a
ricevere questo insieme di risposte inviate da parte del
del server NTP.
NTP Un modo per
amplificare questo tipo di attacco è attraverso
attraver o l’uso del comando MONLIST. Gli
aggressori hanno approfittato proprio di tale comando; MONLIST è un comando
remoto della versione precedente di NTP che trasmette al richiedente un elenco
degli ultimi 600 ospiti che si sono connessi al server (questa
uesta risposta è molto più
grande rispetto alla richiesta
richiesta inviata e così lo rende ideale per un attacco di
amplificazione). Una risposta a tale comando sarà caratterizzata da una lista
contenente informazioni
nformazioni sui client NTP che hanno contattato questo server NTP.
NTP
Tali informazioni consistono nell'indirizzo
nell
o IP del client, la sua versione NTP e il
numero di richieste;
te; quindi come risulta evidente tale comando rappresenta una
funzionalità di debug utile nel caso di uso legittimo.
legittimo In più, un server NTP
localizzato può aiutare a costruire un profilo di rete. Tuttavia,
Tu
, come strumento
DDoS, risulta fondamentale perché con una piccola query si possono reindirizzare
diversi Megabyte
egabyte di traffico dati.
21
Nello
specifico,
i
due
tipi
di
messaggio
REQ_MON_GETLIST
e
REQ_MON_GETLIST_1, amplificano la richiesta originale, rispettivamente, di
un fattore fino a 3660 e 5500. Questo fattore di amplificazione di banda (BAF) è
un moltiplicatore della larghezza di banda, ed è basato sul numero di byte di
payload UDP inviati dal server rispetto ai byte di payload UDP generati dalla
richiesta. In questo attacco possono essere utilizzati anche altri tipi di messaggi,
ma sono REQ_MON_GETLIST e REQ_MON_GETLIST_1 a creare il maggiore
impatto. Da tali considerazioni riusciamo a capire che, se la lista dei client NTP
che un server NTP restituisce risulta completa, questo determina un
amplificazione rispetto al pacchetto iniziale contente la query di circa 206x. In
pratica, un utente malintenzionato con una connessione 1Gbps può teoricamente
generare più di 200Gbps di traffico DDoS.
22
2.4.3 Dinamica dell’attacco
L’attacco subito da CloudFlare è stato, in termini di flusso di dati generato, il più
potente di sempre, infatti, si stima che siano stati inoltrati verso tale azienda circa
400 Gbps di flusso di dati. Ciò vuol dire che i server attaccati hanno ricevuto ogni
secondo 400 Gigabit di dati. La maggior parte delle connessioni di rete sono di
dimensioni nell’ordine di 100 Mbps, 1 Gbps o 10 Gbps, quindi risulta evidente
cosa un attacco di tale portata possa causare. La saturazione dell’intero sistema
risulta inevitabile, infatti si avrebbe rapidamente anche considerando una banda di
notevoli dimensioni.
Per rendere possibile un attacco di tali proporzioni chi lo ha effettuato si è servito
di 4.529 server NTP in esecuzione su 1.298 reti diverse. In media, ciascuno di
questi server mandava 87 Mbps di traffico verso la vittima designata.
La cosa più interessante è che risulta molto probabile che il Cracker abbia
utilizzato, inizialmente, un singolo server in esecuzione su una rete che ha
permesso all'indirizzo IP sorgente contraffatto di dare avvio alle richieste.
Mentre i server NTP, che supportano MONLIST, sono meno comuni dei risolutori
DNS aperti, essi però tendono a girare su server più robusti con un maggior
numero di collegamenti alla rete. In combinazione con il fattore di amplificazione
elevato, questo permette di utilizzare un numero molto inferiore di server NTP per
generare grandi attacchi. Facendo un confronto, l'attacco via DNS a Spamhaus
dello scorso anno aveva utilizzato 30.956 resolver DNS aperti per generare un
attacco DDos con un volume di dati di circa 300 Gbps. Nel nostro caso, con un
numero di server vulnerabili inferiore di circa 7 volte, l’Attacker è stato in grado
di generare un attacco del 33% più grande dell'attacco subito da Spamhaus.
23
Figura 4 Globally Distributed Threat
www.cloudflare.com
La mappa sopra riportata mostra la distribuzione globale dei 4.529 server NTP
utilizzati per l’attacco.
La tabella seguente, invece, elenca i nomi di alcune delle maggiori reti, coinvolte
a livello globale, dalle quali proveniva il traffico dei dati usato per l’attacco, con
accanto il numero di server NTP coinvolti per ognuna di esse.
Figura 5 Principali reti participanti
www.cloudflare.com
24
2.4.4 Sistemi difensivi in risposta all’attacco
Il noto hosting provider francese OVH, paradossalmente, si è reso conto di essere
sotto attacco e mentre mostrava alla rete le proprie informazioni in merito,
simultaneamente, come si evince dalla tabella precedente, risultava essere una
delle maggiori fonti attivamente partecipanti all’attacco NTP su larga scala in
esame. Tutto ciò ha una spiegazione:
Spesso, quando si ha a che fare con questi attacchi, capita che il proprietario di
una rete contenente un server aperto (qualsiasi sia la sua tipologia, NTP, DNS,
etc) si rende conto di ricevere un elevato numero di query verso tale server; di tale
richieste riesce anche a definirne l’indirizzo di origine. In pratica, sta vedendo un
elevato numero di pacchetti UDP con un indirizzo IP sorgente contraffatto e
assume l’host associato a quell’indirizzo come colui che sta lanciando l’attacco. In
realtà, è proprio dal server vulnerabile, posseduto da tale proprietario della rete,
scelto dal Craker per amplificare il suo attacco, che vengono lanciati gli attacchi
all’host intestatario dell’indirizzo IP.
L’attacco a dispetto delle elevate dimensioni, ha provocato la congestione della
rete globale gestita da CloudFlare per un tempo molto inferiore a quanto si
potesse prevedere per quanto detto fino a questo momento. I sistemi di sicurezza
dell’azienda, utilizzati per la gestione di attacchi ai layer 3/4 (strati trasporto e
rete) del modello ISO, sono riusciti a mitigare la minaccia facendo si che i siti
clienti del provider attaccato, avessero le proprie pagine web irraggiungibili per
un tempo relativamente modesto. Dato che attacchi ai Layer 3 e 4 sono difficili se
non impossibili da attenuare con una soluzione locale, con CloudFlare, invece,
tutto il traffico generato dall’attacco che normalmente andrebbe a colpire
l'infrastruttura del server viene mitigato, indirizzandolo automaticamente alla rete
Anycast globale del CDN. La natura della rete Anycast di CloudFlare determina
intrinsecamente l’aumento della superficie di assorbimento dell’attacco. Il sistema
di sicurezza è configurato in modo tale che un attacco deve creare un flusso di dati
superiore ai 5 Gbps per attivare gli allarmi. Anche in tal caso però, le difese di rete
automatizzate fermano gli attacchi senza la necessità di alcun intervento manuale.
Quando il flusso dei dati di un attacco supera le decine di Gigabit di dati al
secondo, un team addetto inizia a monitorare l'attacco, applicando filtri e
25
spostando il traffico per garantire che la sede del cliente aggredito rimanga on-line
e che nessun’altro all’interno della rete ne rimanga influenzato.
Una volta reindirizzato il traffico dell’attacco, viene sfruttata la notevole capacità
globale della rete di ClaudFlare, caratterizzata da un’infrastruttura con i diversi
server sparsi per il globo, di assorbire le inondazioni del traffico dovuto
all’attacco per annientare la minaccia. Ciò significa che CloudFlare è in grado di
impedire, anche ad un singolo pacchetto di traffico appartenete all’attacco, di
raggiungere un sito da esso protetto .
Utilizzando Anycast, ognuno dei 23 centri dati sparsi in tutto il mondo possono
condividere lo stesso indirizzo IP. Quando viene inviata una richiesta a un
indirizzo Anycasted IP, i router si dirigeranno alla macchina sulla rete che è più
vicina alla richiesta. In circostanze normali, questo aiuta a garantire che i visitatori
del sito siano indirizzati automaticamente al più vicino data-center sulla rete, per
garantire le migliori prestazioni. Quando c'è un attacco, invece, l’uso di Anycast
permette di disperdere e diluire il traffico dell’attacco su tutta la rete dei centri dati
in modo efficace. Siccome ogni centro ha lo stesso indirizzo IP per il cliente
CloudFare, il traffico non potrà essere reindirizzato in nessun luogo particolare.
Di conseguenza, invece di un attacco molti-a-uno, si ottiene un attacco molti-amolti evitando cosi che ci sia un single point-of-failure.
26
Capitolo 3 – Prevenzione
3.1
Contrastare attacchi DDos Ntp
La migliore soluzione per contrastare il problema degli attacchi DDoS NTP è
attraverso l’uso della prevenzione.
A seguito dell’attacco massiccio in esame, monitorando le reti precedentemente
elencate, utilizzate dagli aggressori per l’attacco, si è potuto verificare che
l'attenzione al problema ha contribuito nella chiusura di molti dei server NTP
vulnerabili. I risultati sono incoraggianti:
Dopo una settimana e mezzo, più del 75% dei server vulnerabili coinvolti
nell'attacco sono stati riconfigurati e ad ora non sono più vulnerabili.
Il progetto Open NTP è uno dei primi in tal senso, infatti esso mira a evidenziare i
server NTP aperti, in modo tale che una volta messi in luce possano essere
riconfigurati in maniera tale da non contribuire ad attacchi futuri.
NTP e tutti gli altri attacchi di amplificazione basati su UDP si basano su
l'indirizzo IP di origine spoofing (contraffazione). Una corretta configurazione
farebbe si che gli attaccanti non possano falsificare l'indirizzo IP sorgente e quindi
l’attacco si ritorcerebbe contro l’aggressore. Quindi se si sta eseguendo una
configurazione di rete, risulta necessario assicurarsi che tale configurazione si sta
27
attuando seguendo linee guida dettate dal BCP38 per prevenire cosi l’invio di
request provenienti da pacchetti con indirizzi fasulli. È possibile, inoltre,
verificare se una rete attualmente in uso segue BCP38 utilizzando gli strumenti
del MIT di Project Spoofer . Se risulta che tale rete è una rete vulnerabile, e che
permette il profilarsi di pacchetti provenienti da indirizzi IP sorgente corrotti, si
può facilmente porre le modifiche del caso implementando BCP38.
28
Conclusioni
Per comprendere come approcciare le strategie di mitigazione più opportune, di
attacchi Dos in generale, è utile conoscere e valutare le possibilità offerte per
attuare gli attacchi DoS, che del resto sono in continua evoluzione.
In funzione della disgregazione e dell’impatto che un aggressore intende arrecare,
c’è sempre una tecnica o un tool in grado di aiutarlo. È importante considerare che
il ciclo di vita di un tool ha spesso una durata estremamente breve, generalmente
solo di alcuni mesi. Questo ciclo di vita così breve, sottolinea l’importanza e
l’efficacia delle azioni difensive da intraprendere contro gli attacchi DoS, ma
evidenzia anche il grado di resistenza e le grandi capacità della comunità di
aggressori nella creazione di nuove metodologie e tool per gli attacchi DoS.
Considerando lo scenario che attualmente si presenta e le tendenze evolutive del
fenomeno, si comprende che, per potersi difendere adeguatamente non risulta
sufficiente applicare una patch ad una vulnerabilità, bensì nasce la necessità di
creare una ben definita struttura atta a risolvere problematiche di varia natura e a
valutare eventuali scenari non considerati inizialmente.
Anche la dinamica comportamentale di un attacco (multi-vettore, improvviso e
senza sintomi premonitori, con un target globale piuttosto che mirato ad una
singola organizzazione) accresce ulteriormente l’impatto degli attacchi DoS,
rendendo perciò indispensabile prepararsi preventivamente a rispondere con
efficacia.
L’effettiva salvaguardia della sicurezza delle informazioni attraverso un’attenta
gestione dei rischi richiede l’integrazione all’interno di un’organizzazione,
incaricata di creare, aggiornare, eliminare e mantenere tali informazioni, di un
adeguato sistema di gestione della sicurezza sviluppato secondo 3 elementi, quali
processi , organizzazioni e tecnologia.
Diverse aziende di sicurezza stanno nascendo e altre si stanno muovendo in tal
senso, proponendo soluzioni per supportare l’utenza della rete nella definizione
ed attuazione di processi di contrasto nei confronti di quelli che potranno essere i
futuri attacchi DoS.
29
Un modello, in parte già utilizzato da diverse aziende, sul quale basare il proprio
sistema di difesa potrebbe essere il seguente:
•
valutare il livello di rischio (ricadute operative, d’immagine, business)
derivante da eventuali attacchi DoS e conseguentemente identificare lo
scopo e le priorità nel definire il processo di contrasto agli attacchi DoS;
•
strutturare il processo di gestione dell’incidente di sicurezza (DoS Incident
Response Plan);
•
definire come utilizzare gli strumenti di sicurezza presenti e quali ulteriori
funzionalità e strumenti predisporre;
•
definire le architetture IT più idonee a sopperire situazioni di attacco
mirato alla propria azienda o di livello globale (Service Provider, Internet);
•
verificare periodicamente il livello di resistenza delle difese messe in atto
(Security Assessment periodico).
E’ evidente che difendersi dagli attacchi DoS è complesso da un punto di vista
tecnico, ma risulta estremamente critico ed indispensabile per l’impatto
economico che tali attacchi possono avere sul business di tutte le organizzazioni.
30
Appendice A
A.1 Formato dell'intestazione UDP
Un pacchetto NTP consiste dell'intestazione UDP seguita dalla porzione dati NTP.
Il formato dell'intestazione UDP
0
1
2
3
01234567890123456789012345678901
Porta di Sorgente
Porta di Destinazione
Lunghezza
Checksum
Porta di Sorgente
Numero di porta della sorgente UDP. Nel caso di modalità asimmetrica e di
richiesta del client questo campo è assegnato dall'host con ruolo di client, mentre
per la risposta del server viene copiato dal campo Porta di Destinazione della
richiesta del client. Nel caso di modalità simmetrica, ad entrambi i campi Porta di
Sorgente e Porta di Destinazione viene assegnato il numero della porta di servizio
NTP, 123.
Porta di Destinazione
Numero di porta della destinazione UDP. Nel caso di modalità asimmetrica e di
richiesta del client a questo campo è assegnato il numero della porta di servizio
NTP, 123, mentre per la risposta del server viene copiato dal campo Porta di
Sorgente della richiesta del client. Nel caso di modalità simmetrica, ad entrambi i
campi Porta di Sorgente e Porta di Destinazione viene assegnato il numero della
porta di servizio NTP, 123.
Lunghezza
Lunghezza della richiesta o della risposta, compresa l'intestazione UDP, in byte.
Checksum
Somma di controllo standard UDP.
31
A.2 Formato dei dati NTP
Il formato della porzione dati NTP, segue immediatamente l'intestazione UDP
0
1
2
3
01234567890123456789012345678901
II Stato
Tipo
Precisione
Errore Stimato
Tasso di Deriva Stimato
Identificatore dell'Orologio di Riferimento
Timestamp di Riferimento (64 bit)
Timestamp di Origine (64 bit)
Timestamp di Ricezione (64 bit)
Timestamp di Trasmissione (64 bit)
Indicatore di Intercalare
Codice che avverte dell'imminenza di un secondo intercalare, da inserire alla fine
dell'ultimo giorno del mese corrente. I bit sono codificati come segue:
00
nessun avvertimento
01
+1 secondo (il minuto seguente ha 61 secondi)
10
-1 secondo (il minuto seguente ha 59 secondi)
11
riservato per usi futuri
Stato
Codice che indica lo stato dell'orologio locale. I valori sono definiti come segue:
0
l'orologio opera correttamente
1
perdita di portante
2
perdita di sincronismo
3
errore di formato
4
guasto all'interfaccia (Tipo 1) o al link (Tipo 2)
(codici aggiuntivi riservati per usi futuri)
32
Tipo dell'Orologio di Riferimento (Tipo)
Codice che indica il tipo dell'orologio di riferimento. I valori sono definiti come
segue:
0
non specificato
1
riferimento primario (per esempio radioorologio)
2
riferimento secondario che usa un host Internet attraverso NTP
3
riferimento secondario che usa qualche altro host o protocollo
4
occhio e orologio da polso
(codici aggiuntivi riservati per usi futuri)
Precisione
Intero con segno nel range da +32 a -32 indicante la precisione dell'orologio
locale, in secondi arrotondati alla più vicina potenza del due.
Errore Stimato
Numero a virgola fissa che indica l'errore stimato dell'orologio locale nell'istante
in cui è stato regolato per l'ultima volta, in secondi con il punto decimale tra i bit
15 e 16.
Tasso di Deriva Stimato
Numero a virgola fissa con segno indicante il tasso di deriva stimato dell'orologio
locale, in unità adimensionali con il punto decimale alla sinistra del bit più
significativo.
Identificatore dell'Orologio di Riferimento
Codice che identifica lo specifico orologio di riferimento. Nel caso del tipo 1
(riferimento primario), si tratta di una stringa ASCII allineata a sinistra e riempita
con zeri a destra che identifica l'orologio,
Nel caso del tipo 2 (riferimento secondario) si tratta dell'indirizzo Internet a 32 bit
dell'host di riferimento. Negli altri casi il campo è riservato per usi futuri e deve
essere messo a zero.
33
Timestamp di Riferimento
Ora locale in cui l'orologio locale è stato regolato o corretto per l'ultima volta.
Timestamp di Origine
Ora locale in cui la richiesta è partita dal client verso il server.
Timestamp di Ricezione
Ora locale in cui la richiesta è arrivata al server.
Timestamp di Trasmissione
Ora locale in cui la risposta ha lasciato il server per tornare al client.
34
Bibliografia e Sitografia
J.F. Kurose, K.W. Ross, Reti di Calcolatori e Internet. Un approccio top-down,
Mondatori , 2008
ISCOM, La sicurezza delle reti. Dall’analisi del rischio alle strategie di
protezione, AR, 2004
White-paper IKS, Dos Attack, 2013
Cloudflare: www.cloudflare.com
Public Safety Canada – Network Time Protocol Vulnerability:
www.publicsafety.gc.ca/cnt/rsrcs/cybr-ctr/2014/av14-001-eng.aspx
Team Cymru – Secure NTP Template:
www.team-cymru.org/ReadingRoom/Templates/secure-ntp-template.html
InfoSec – NTP reflection attack:
www.isc.sans.edu/forums/diary/NTP+reflection+attack/17300
Network Time Protocol (NTP):
www.web.tiscali.it/zinna_romano/RFC/RFC958InItaliano.htm
NTP Scanning Project:
www.openntpproject.org
Cert – Vulnerability Note VU#348126:
www.kb.cert.org/vuls/id/348126
35