Network Time Protocol (NTP): de­fi­ni­zio­ne e fun­zio­na­men­to

Gli orologi dei sistemi in­for­ma­ti­ci for­ni­sco­no un valido supporto a chiunque voglia sapere che ora è e non ha né un orologio da polso, né uno smart­pho­ne a portata di mano. In pochi sanno, però, che l’orologio di sistema non è rilevante solo per l'utente, ma anche per i computer stessi. Nello scambio co­mu­ni­ca­ti­vo tra due o più sistemi e in par­ti­co­la­re per il corretto fun­zio­na­men­to dei processi e dei servizi che si svolgono in rete, le marcature temporali rivestono un ruolo decisivo. Per evitare com­pli­ca­zio­ni di sistema dovute a orologi asincroni, nel 1985 è stato pub­bli­ca­to il co­sid­det­to Network Time Protocol (NTP).

Il Network Time Protocol (NTP) è il risultato dello sviluppo di David L. Mills, pro­fes­so­re al­l'U­ni­ver­si­tà del Delaware. La prima de­scri­zio­ne ufficiale del pro­to­col­lo, che fa parte della famiglia dei pro­to­col­li Internet, è stata pub­bli­ca­ta nel settembre 1985 all’interno del documento RFC 958. Qui l’NTP viene descritto come un pro­to­col­lo per la sin­cro­niz­za­zio­ne di più orologi di rete at­tra­ver­so un insieme di­stri­bui­to di client e server.

I pre­de­ces­so­ri di questo pro­to­col­lo sono il Time Protocol e l’ICMP Timestamp message, le cui funzioni sono state inglobate nel Network time protocol. NTP si basa sul pro­to­col­lo User Datagram Protocol (UDP), che consente un tra­sfe­ri­men­to dati senza con­nes­sio­ne. Il numero di porta UDP previsto per questo scopo è 123.

L’NTP fornisce mec­ca­ni­smi di pro­to­col­lo fon­da­men­ta­li, necessari per sin­cro­niz­za­re l’ora di diversi sistemi con una pre­ci­sio­ne al na­no­se­con­do. Contiene, inoltre, spe­ci­fi­ca­zio­ni sull’ac­cu­ra­tez­za e sulle probabili fonti d’errore dell'ora del sistema locale, nonché sulle proprietà del­l'o­ro­lo­gio di ri­fe­ri­men­to. Tuttavia, il pro­to­col­lo delinea solo il tipo di rap­pre­sen­ta­zio­ne dei dati e dei formati dei messaggi senza fornire algoritmi di sin­cro­niz­za­zio­ne e di fil­trag­gio.

Per sin­cro­niz­za­re gli orologi dei computer con una pre­ci­sio­ne al na­no­se­con­do il Network Time Protocol utilizza il tempo coor­di­na­to uni­ver­sa­le (ab­bre­via­to con la sigla UTC, dall’inglese Coor­di­na­ted Universal Time), valido dal 1972. Questo è de­ter­mi­na­to in vari modi, ad esempio at­tra­ver­so i sistemi radio e i sistemi sa­tel­li­ta­ri. Servizi im­por­tan­ti come il Global Po­si­tio­ning System (GPS) sono dotati di speciali ri­ce­vi­to­ri per ricevere i segnali cor­ri­spon­den­ti. Poiché non sarebbe né economico né fattibile dotare ogni singolo computer di tali ri­ce­vi­to­ri, esistono i co­sid­det­ti Primary Time Server, che di­spon­go­no, appunto, di un ri­ce­vi­to­re UTC. At­tra­ver­so pro­to­col­li come NTP, questi server sin­cro­niz­za­no gli orologi dei computer nella loro rete.

In questo processo di sin­cro­niz­za­zio­ne ci sono diversi livelli ge­rar­chi­ci di distanza dall’UTC sorgente, noti anche come strata (termine latino per "strati"). Tutti i di­spo­si­ti­vi tecnici che ottengono il loro orario da un Primary Time Server o da un sistema di na­vi­ga­zio­ne sa­tel­li­ta­re sono clas­si­fi­ca­ti nella categoria strato 0. Tra questi vi sono gli orologi atomici e quelli ra­dio­con­trol­la­ti. Un computer che ottiene l'UTC da un orologio atomico o da uno ra­dio­con­trol­la­to cor­ri­spon­de allo strato 1 e così via. Ogni sistema è client dello strato pre­ce­den­te e al contempo server per i sistemi dello strato suc­ces­si­vo (almeno po­ten­zial­men­te).

Le ca­rat­te­ri­sti­che fon­da­men­ta­li del Network Time Protocol, at­tual­men­te di­spo­ni­bi­le nella quarta versione (NTPv4), possono essere riassunte come segue:

• NTP fornisce un orologio di ri­fe­ri­men­to che funge da punto fisso per tutti i processi di sin­cro­niz­za­zio­ne. Tutti gli orologi si allineano, quindi, a questo orologio o orario. Fin dal­l'i­ni­zio è stato uti­liz­za­to a tal fine il Coor­di­na­ted Universal Time (UTC), ri­co­no­sciu­to come orologio mondiale uni­ver­sa­le.
• NTP è un pro­to­col­lo che compensa gli errori cercando au­to­ma­ti­ca­men­te le fonti migliori per la sin­cro­niz­za­zio­ne. Per ridurre al minimo l'errore ac­cu­mu­la­to è persino in grado di combinare diverse fonti tra loro. Laddove possibile, il Network Time Protocol rileva e ignora le fonti che for­ni­sco­no valori for­te­men­te di­ver­gen­ti nel breve e nel lungo termine.
• NTP è altamente scalabile: possono esserci più orologi di ri­fe­ri­men­to in ogni rete di sin­cro­niz­za­zio­ne. Inoltre ogni nodo di rete è in grado di tra­smet­te­re in­for­ma­zio­ni temporali in una struttura ge­rar­chi­ca bi­di­re­zio­na­le (punto a punto) o uni­di­re­zio­na­le (in una direzione).
• NTP ha un forte grado di ac­cu­ra­tez­za. Grazie alla pos­si­bi­li­tà di se­le­zio­na­re il miglior candidato per la sin­cro­niz­za­zio­ne, è possibile ottenere una ri­so­lu­zio­ne in un in­ter­val­lo di na­no­se­con­di (pari a 2^-32 secondi).
• NTP è in grado di superare i problemi di con­nes­sio­ne di rete tem­po­ra­nei: in questo caso il pro­to­col­lo si serve di dati del passato per de­ter­mi­na­re l'ora attuale o le de­via­zio­ni.

Ori­gi­na­ria­men­te il Network Time Protocol è stato svi­lup­pa­to ap­po­si­ta­men­te per i sistemi UNIX, nei quali ancora oggi è im­ple­men­ta­to sotto forma di processo in back­ground (Daemons) ntpd. Questo funge tanto da client, che sin­cro­niz­za il sistema locale, quanto da server NTP per altri sistemi. Per molto tempo il servizio è stato anche la prima scelta di im­ple­men­ta­zio­ne di NTP nelle di­stri­bu­zio­ni Linux. Per la sin­cro­niz­za­zio­ne temporale le versioni più recenti uti­liz­za­no sempre più spesso l'ap­pli­ca­zio­ne client timesyncd, che fa parte del System Manager systemd. Anche i sistemi operativi macOS e Windows uti­liz­za­no il Network Time Protocol per ottenere l'UTC con processi di sistema semplici e senza software ag­giun­ti­vi via Internet.

Sebbene NTP sia con­si­de­ra­to in tutto il mondo come lo standard di sin­cro­niz­za­zio­ne temporale, non è in­fal­li­bi­le, spe­cial­men­te in termini di sicurezza. Poiché si basa sul pro­to­col­lo UDP senza con­nes­sio­ne, un ag­gres­so­re potrebbe, per esempio, inviare pacchetti con un indirizzo del mittente fal­si­fi­ca­to (IP spoofing) a un server NTP.

L'in­di­riz­zo del mittente è l'in­di­riz­zo del sistema da attaccare. Il server invia la sua risposta, che è molto più grande della richiesta inviata dal­l'ag­gres­so­re, al presunto mittente (sistema degli attacchi). Se l'ag­gres­so­re procede in questo modo su larga scala, inviando una mol­ti­tu­di­ne di richieste ma­ni­po­la­te, può so­vrac­ca­ri­ca­re il sistema di de­sti­na­zio­ne. Si veda in merito il nostro articolo su DoS e DDoS: schemi di attacco in sintesi.

Di con­se­guen­za sono stati portati avanti diversi progetti per lo sviluppo di soluzioni al­ter­na­ti­ve più sicure uti­liz­za­bi­li al posto delle soluzioni comuni di client e server NTP:

• tlsdate: tlsdate è stato svi­lup­pa­to nel 2012 da Jacob Appelbaum e pub­bli­ca­to su GitHub. Al posto di UDP, tlsdate utilizza il pro­to­col­lo TCP per il tra­sfe­ri­men­to dati. Il servizio cripta la con­fi­gu­ra­zio­ne della con­nes­sio­ne tramite TLS per impedire la ma­ni­po­la­zio­ne dei pacchetti di dati. Inoltre tlsdate utilizza le funzioni TLS "Ser­ve­rHel­lo" e "Clien­tHel­lo" per sin­cro­niz­za­re l'ora. L'al­ter­na­ti­va a NTP funziona uni­ca­men­te con TLS 1.1 e 1.2.
• Ntimed: Ntimed è un'im­ple­men­ta­zio­ne di NTP che si concentra spe­ci­fi­ca­men­te sulla sicurezza e sulle pre­sta­zio­ni. Per questo scopo il codice di pro­gram­ma­zio­ne di ntpd, su cui si basa Ntimed, è stato “sem­pli­fi­ca­to” e ot­ti­miz­za­to. Il pacchetto software, che comprende client, server e file master, è a libera di­spo­si­zio­ne nella directory ufficiale Ntimed di GitHub .
• NTPsec: NTPsec è sempre una variante del servizio ntpd tra­di­zio­na­le. Cio­no­no­stan­te sono state ri­spar­mia­te oltre 175.000 righe di codice rispetto al­l'o­ri­gi­na­le. Inoltre il team di sviluppo ha so­sti­tui­to una serie di ope­ra­zio­ni sulle stringhe non sicure come "strcpy", "sprintf" o "gets" con equi­va­len­ti sicure. Queste e altre dif­fe­ren­ze possono essere viste in maniera più det­ta­glia­ta sul sito ufficiale del progetto open source.

Oltre alle al­ter­na­ti­ve al software, c'è anche il Precision Time Protocol (PTP). A dif­fe­ren­za del Network Time Protocol, questo pro­to­col­lo di rete per i sistemi Linux si concentra espli­ci­ta­men­te su una pre­ci­sio­ne di sin­cro­niz­za­zio­ne par­ti­co­lar­men­te elevata. In PTP quest’ultima si realizza in un in­ter­val­lo di mi­cro­se­con­di, ri­ve­lan­do­si superiore alla pre­ci­sio­ne di NTP. Inoltre il pro­to­col­lo richiede requisiti minimi per quanto riguarda le pre­sta­zio­ni del pro­ces­so­re e la larghezza di banda di rete, ren­den­do­lo ideale per di­spo­si­ti­vi semplici ed economici.

Il progetto pool.ntp.org, avviato da Adrian von Bidder e gestito da Ask Bjørn Hansen da luglio 2005, consiste in un grande cluster virtuale con oltre 4.000 Time Server NTP. La maggior parte dei server di­stri­bui­ti in tutto il mondo e uti­liz­za­ti da milioni di sistemi si trovano in Europa. Il fatto che il pool di NTP sia cresciuto co­stan­te­men­te nel tempo è dovuto alla comunità del progetto di successo: chiunque abbia un server con indirizzo IP statico per­ma­nen­te­men­te connesso a Internet può ag­giun­ger­lo al cluster. No­no­stan­te la domanda crescente, il servizio può essere uti­liz­za­to gra­tui­ta­men­te e senza alcuna re­stri­zio­ne.

Se si desidera uti­liz­za­re il pool-server NTP per sin­cro­niz­za­re l'ora di sistema dei propri di­spo­si­ti­vi, è possibile farlo in UNIX oppure in Linux con il servizio ntpd. Tutto ciò che serve è la seguente con­fi­gu­ra­zio­ne per l’NTP Drift File:

Il pre­re­qui­si­to è che l’ora di sistema sia impostata almeno ap­pros­si­ma­ti­va­men­te. Per re­cu­pe­ra­re lo stato del servizio ntpd, inserire il seguente comando dopo pochi minuti:

Il client NTP presenta un elenco degli indirizzi IP dei time server uti­liz­za­ti ca­sual­men­te dal pool. Se uno di questi server è con­tras­se­gna­to da un asterisco (*), d'ora in poi l'ora di sistema sarà sin­cro­niz­za­ta come de­si­de­ra­to.