Protocollo NTP
Un altro protocollo di supporto all’uso della rete è rappresentato da NTP (Network Time Protocol).
Il servizio consente di realizzare la sincronizzazione dei clock dei computer connessi a una rete TCP/IP attraverso lo scambio di messaggi UDP (la porta riservata al servizio è la 123/udp) tra una o più sorgenti di riferimento e i singoli apparati.
Lo standard definisce oltre al formato dei messaggi scambiati anche la struttura gerarchica che deve essere adottata per organizzare le sorgenti di riferimento del clock.
Le fonti primarie (definite Stratum 0) consistono in componenti hardware dedicate, in possesso di orologi interni e/o fonti GPS, e rappresentano il punto da cui tutti gli altri sistemi devono attingere il clock.
Tali elementi non sono generalmente connessi alla rete e non utilizzano il protocollo NTP per sincronizzare altri sistemi.
Le fonti Stratum 0 sono connesse direttamente a server (Stratum 1) che agiscono da fonti di riferimento per la sincronizzazione via rete.
Il protocollo NTP interviene nella comunicazione tra questi server Stratum 1 e tutti i sistemi che ambiscono a diventare server di riferimento locali (Stratum 2).
Ogni rete Corporate dovrebbe provvedere ad attivare uno o più server Stratum 2 locali attingendo a server Stratum 1 di fiducia tramite NTP ed eventualmente utilizzando collegamenti dedicati con una fonte primaria (Stratum 0).
I computer degli utenti, i dispositivi di rete e ogni altro device che desidera sincronizzare il proprio clock a quello di riferimento viene configurato come elemento Stratum 3, ed è chiamato a comunicare via NTP con i server Stratum 2.
Lo schema gerarchico, il meccanismo per giungere alla sincronizzazione dei clock e il formato dei messaggi scambiati tra le diverse entità sono definiti nella RFC 1305.
La versione 3 del protocollo NTP è oggi adottata anche dalla Microsoft nei propri sistemi operativi più recenti.
Esistono inoltre alcune implementazioni disponibili della versionte NTPv4.
Nella versione 3 le stazioni si scambiano un timestamp di 64 bit.
Di questi, 32 bit rappresentano i secondi intercorsi a partire dalla data convenzionale del 1 gennaio 1900, 32 bit rappresentano invece la frazione di secondo (la risoluzione teorica massima è quindi di 2-32 secondi).
La scala temporale definita da NTP prevedeuna re-inizializzazione ogni 232 secondi (circa 136 anni).
La prossima re-inizializzazione è pianificata per il 2036.
In coincidenza di tale evento sono prevedibili problemi di sincronizzazione e disservizi.
Ma se prima di giungere a tale data, sarà stato effettuato il passaggio al protocollo NTPv4, il problema non sussiste, in quanto nella nuova versione del protocollo, per rappresentare i secondi è riservato un campo da 64 bit.
NTP prevede l’uso del protocollo UDP (porta riservata 123/udp).
Anche se è stato scelto di adottare un protocollo di trasporto di natura stateless, la ricezione di un singolo messaggio NTP malformato non compromette la sincronizzazione.
L’effetto di ciascuna informazione ricevuta sul clock del sistema locale è infatti solo parziale e, solo dopo aver ricevuto diversi timestamp consecutivi concordi, l’orologio viene aggiornato.
Per evitare che il ritardo di attraversamento della rete possa influire sull’allineamento dei clock, il protocollo implementa espliciti accorgimenti in grado di compensare eventuali variazioni nel ritardo di propagazione.
Il risultato medio che si riesce a ottenere è una precisione intorno a 10 millisecondi, se si usa una fonte di riferimento posta su Internet pubblica, o di 0,2 millisecondi nel caso di una fonte attestata alla stessa LAN.
Per arrivare a questi valori di accuratezza occorre memorizzare numerosi messaggi consecutivi validi.
La capacità computazionale necessaria per eseguire la formula per il calcolo del clock e la dimensione del buffer di memoria richiesto per eseguire il protocollo NTP sono da ritenersi un fattore critico per l’implementazione del servizio su dispositivi di limitata complessità (dispositivi di rete, IP phone, Smart devices e dispositivi IoT)
Per evitare che questi fattori finiscano con il rappresentare una limitazione all’introduzione del protocollo, è stata definita una variante più elementare del protocollo denominata SNTP (Simple Network Time Protocol), in cui non si è costretti a memorizzare le informazioni una volta che queste sono state usate.
La robustezza e l’affidabilità di SNTP è inferiore a quella di NTP.
L’importanza di utilizzare NTP, per la sincronizzazione dei clock dei sistemi tramite server di rete è fuori discussione.
L’aspetto che può essere messo in discussione è la robustezza del protocollo da attacchi mirati.
Un attaccante che mira a compromettere il servizio può sfruttare la natura connectionless del protocollo UDP per investire un server legittimo con un considerevole numero di richieste NTP.
Anche se un simile attacco DoS non è in grado di bloccare una fonte primaria (Stratum 0) in quanto non direttamente raggiungibile via NTP, è chiaro che anche bloccando i server di gerarchia inferiore è possibile interrompere il servizio per una larga popolazione di client NTP.
Un client NTP legittimo può essere configurato con gli indirizzi IP di più server NTP alternativi. In questo modo se il client non riceve risposta alle query inviate al server NTP principale, può provare a inviare le successive richieste a un altro server della lista.
In caso di mancata risposta, il clock del client locale continuerà a essere aggiornato in base a un sincronismo interno (con un’accuratezza che è destinata a peggiorare nel tempo).
Talvolta sono gli stessi dispositivi client NTP che agiscono involontariamente da attaccanti DoS (a causa di errate configurazioni e/o implementazioni arbitrarie del protocollo da parte degli sviluppatori software).
Per scongiurare la possibilità che un client possa contribuire a un DoS è stato definito un apposito pacchetto (Kiss-of-Death) che dovrebbe servire a sospendere l’invio di richieste malformate da parte dei client.
Naturalmente una simile opportunità può essere utilizzata anche da un attaccante per bloccare il canale di comunicazione tra server e client perfettamente funzionanti.
Un altro problema è legato alla manipolazione di messaggi NTP da parte di un attaccante.
Anche se l’invio di un singolo messaggio malevolo non è sufficiente per modificare il clock di sistema, il perdurare dell’avvelenamento delle informazioni contenute nelle Response NTP ricevute, può convincere il client ad aggiornare il proprio clock, in accordo al timestamp trasmesso dall’attaccante.
Per evitare che un server NTP legittimo, con le sue risposte, possa complicare il successo dell’attacco, normalmente il tentativo di desincronizzazione ha inizio dopo che il server legittimo è stato messo fuori servizio.
Essendo basato su UDP è relativamente semplice per l’attaccante operare anche in condizione di Blind IP Spoofing.
Anche se si utilizza IPSec per creare un canale sicuro tra client e server su cui veicolare i messaggi NTP, tutte le versioni più recenti del protocollo prevedono la possibilità di utilizzo di soluzioni crittografiche per garantire l’integrita delle informazioni trasmesse.
Nella versione 3 è previsto solo l’uso di uno schema crittografico basato sull’utilizzo di una chiave simmetrica per cifrare tramite DES in modalità CBC il messaggio.
Il risultato viene poi trasmesso sotto forma di hash MD5 a 128bit nel payload del messaggio NTP.
Lo standard non descrive alcun meccanismo per negoziare, installare e rimuovere le chiavi segrete condivise.
Lo schema richiede che tutti i client configurati per accedere allo stesso server siano messi a conoscenza del comune segreto.
Pertanto si può affermare che la soluzione può essere implementata solo tra entità mutuamente fidate.
Nella versione 4, il problema dell’uso di un unico segreto è stato risolto implementando un meccanismo per verificare l’integrità delle informazioni trasmesse e l’originalità della fonte, basato su uno schema a chiave pubblica e privata.
Questa soluzione, denominata Autokey Security Architecture, è stata pensata per essere compatibile con il payload NTP, e pertanto produce un MAC (Message Authentication Code) di 128 bit, utilizzando la chiave privata del sorgente.
Lo schema prevede l’uso di certificati digitali X.509 lato server e la gestione di molteplici gruppi di utenti legittimi.
