Che ora è? Quando il tempo rompe (silenziosamente) tutto

C’è una dipendenza che nessuno disegna mai negli schemi di rete, eppure regge tutto il resto: l’ora esatta. Ci pensiamo solo quando qualcosa si rompe in modo assurdo — gli utenti non si autenticano più, i codici dell’app di sicurezza risultano «sbagliati» anche se sono giusti, il browser dichiara «certificato non ancora valido» su un sito perfettamente in regola, e — il caso peggiore — durante un’indagine le tracce nei log di sistemi diversi non combaciano. Basta qualche minuto di scarto tra due orologi e il castello traballa.

Nel mio lavoro c’è un principio che vale doppio qui: in un’indagine, se gli orologi mentono, mente la cronologia — e la cronologia è l’indagine. Il tempo è il metro con cui misuriamo tutto il resto; quando quel metro è tarato male, ogni misura successiva è falsata, e — correlazione non è causazione — insegui sintomi che sembrano di autenticazione, di cifratura, di applicazione, mentre la causa è un orologio alla deriva. Vale la pena capire come le macchine tengono l’ora, e perché è un tallone d’Achille tanto silenzioso quanto insidioso.

Come le reti tengono l’ora

Gli orologi al quarzo dentro i computer non sono precisi: derivano, chi più chi meno, di frazioni di secondo al giorno. Su una singola macchina è un dettaglio; su centinaia di sistemi che devono concordare sull’ora, diventa un problema serio. La soluzione, elegante e antica, è NTP — il Network Time Protocol, ideato da David Mills nel 1985 e tuttora uno dei protocolli più vecchi e più usati di Internet.

NTP organizza il tempo in una gerarchia a livelli, gli stratum. In cima, allo stratum 0, ci sono le sorgenti di riferimento: orologi atomici e ricevitori GPS. I server di stratum 1 sono collegati direttamente a quelle sorgenti; quelli di stratum 2 si sincronizzano sui primi, e così via a scendere fino alle tue macchine. Ogni livello è un po’ meno preciso del precedente, ma tutti convergono verso la stessa ora. Dove serve precisione estrema — finanza, telecomunicazioni, automazione industriale — si usa un cugino più raffinato, il PTP, capace di scendere sotto il microsecondo.

Il tempo, poi, non è nemmeno una grandezza così pulita come sembra. Ogni tanto viene inserito un secondo intercalare per riallineare l’ora atomica alla rotazione irregolare della Terra: un singolo secondo in più che, negli anni, ha fatto inciampare più di un sistema impreparato a gestirlo. È il promemoria che persino la scala del tempo è una convenzione da manutenere, non una costante immutabile.

Come funziona, in breve

Un client NTP non si limita a «chiedere l’ora». Scambia una serie di marche temporali con i server, misura il ritardo di andata e ritorno e calcola lo scarto tra il proprio orologio e quello di riferimento. Poi — ed è la parte sottile — non salta all’ora giusta, ma la corregge gradualmente accelerando o rallentando l’orologio, perché moltissimi sistemi detestano che il tempo torni indietro di colpo. Interroga più sorgenti insieme e scarta quelle che mentono, i cosiddetti falseticker.

La conseguenza pratica è che l’ora non si imposta una volta per tutte: si mantiene, di continuo. Ed è qui che nascono i guai silenziosi. Una macchina con il servizio NTP morto sembra a posto per giorni, mentre deriva un pezzetto alla volta; nessuno se ne accorge finché lo scarto non supera una soglia critica e, di colpo, qualcosa si rompe — senza un legame apparente con «il tempo».

Un classico che ho visto ripetersi: una macchina virtuale clonata o ripristinata da uno snapshot riparte con l’orologio indietro di ore. Nessuno ha toccato l’autenticazione, eppure gli accessi a quel sistema iniziano a fallire a intermittenza e i suoi log raccontano una storia sfasata rispetto a tutti gli altri. Per mezza giornata si cerca il colpevole ovunque, tranne dove si nasconde — perché il primo comando che dovremmo lanciare, confrontare gli orologi, è quasi sempre l’ultimo che viene in mente.

C’è anche un intreccio elegante con il resto di questa serie: le firme DNSSEC hanno una finestra di validità temporale, e la verifica dei certificati dipende dall’ora esatta. Così un solo orologio sbagliato può far «fallire» insieme la risoluzione dei nomi e la cifratura — due sospetti diversi per un’unica causa. È il bello, e il brutto, delle fondamenta invisibili: si reggono a vicenda, e quando una cede tende a trascinarsi dietro le altre.

Dove la deriva colpisce (e non te lo aspetti)

Il bello, si fa per dire, è che un orologio sbagliato non si presenta mai come un problema di orologio. Si traveste.

Kerberos, il cuore dell’autenticazione in ambienti Active Directory, tollera per impostazione predefinita uno scarto di cinque minuti: oltre quella soglia rifiuta i ticket e gli utenti «non riescono più ad accedere». MFA e TOTP: i codici a sei cifre della tua app di autenticazione sono calcolati sull’ora, in finestre di trenta secondi — se il telefono o il server sono fuori sincrono, il secondo fattore «giusto» viene respinto. La validazione TLS controlla che un certificato sia dentro il suo intervallo di validità: un orologio spostato in avanti fa risultare «scaduto» un certificato valido, uno spostato indietro lo dichiara «non ancora valido». È lo stesso notBefore/notAfter che manda giù la produzione quando un certificato scade davvero — solo che qui a scadere, in un certo senso, è l’orologio.

E poi c’è il terreno che mi sta più a cuore: la correlazione dei log. Durante un’indagine si ricostruisce una sequenza di eventi mettendo in fila ciò che è successo su firewall, server, endpoint. Se quei sistemi non concordano sull’ora, la sequenza è inservibile: un evento sembra precedere la sua causa, un attacco pare arrivare «dopo» i suoi effetti. Senza tempo sincronizzato e attendibile, la threat detection perde il filo e l’incident response parte già zoppa. A questi si aggiungono i sistemi distribuiti, che sull’ordine temporale basano lease, token e coerenza, e la banale pianificazione dei job.

Vale anche il contrario, in positivo: proprio perché la deriva è lenta e silenziosa, tenere d’occhio lo scarto di ogni sistema rispetto alla sorgente di riferimento è uno dei segnali di salute più economici e sottovalutati di un’infrastruttura. Un allarme quando l’offset supera una soglia costa pochissimo e intercetta un intero genere di guasti futuri prima che diventino un incidente.

Il tempo come superficie d’attacco

Se tutto dipende dall’ora, allora manipolare l’ora è un’arma. Sul piano della disponibilità, per anni NTP è stato uno dei vettori preferiti per i DDoS di amplificazione: una piccola richiesta che genera una risposta enorme, sfruttata per travolgere una vittima. Sul piano dell’integrità, un attaccante che riesca a falsificare le risposte NTP può spostare l’orologio di un bersaglio: in avanti per far «scadere» in anticipo un certificato o un token, indietro per far rivivere qualcosa che sarebbe dovuto morire, o quel tanto che basta per mandare in crisi Kerberos e bloccare gli accessi.

Difendere il tempo significa non darlo per scontato: usare NTP autenticato — lo standard NTS, Network Time Security — per non fidarsi ciecamente di qualunque risposta; avere sorgenti interne affidabili, tipicamente un ricevitore GPS che alimenta i propri server di riferimento, invece di appoggiarsi a server pubblici casuali presi da Internet; e garantire un tempo tracciabile, perché in ambito forense e di conformità la catena di custodia di una prova vale quanto vale l’orario che porta impresso. È una scelta di architettura, non un’impostazione da lasciare al default.

Non è un caso che diversi standard di sicurezza e conformità richiedano esplicitamente la sincronizzazione degli orologi verso una sorgente attendibile e la conservazione di log con marche temporali coerenti: senza, un registro degli eventi ha un valore probatorio dubbio. In questi contesti il tempo affidabile smette di essere un dettaglio sistemistico e diventa un requisito.

Perché capirlo fa la differenza

Il tempo è il substrato invisibile su cui poggiano autenticazione, cifratura e ricostruzione degli eventi. Resta impercettibile finché regge, e quando cede lo fa travestito da tutt’altro: un accesso negato, un certificato «non valido», una timeline che non torna. I tecnici bravi lo scoprono nel modo più frustrante — dopo aver escluso tutto il resto. Chi invece conosce questa dipendenza la mette tra i primi controlli: un semplice confronto tra gli orologi, all’inizio di un’indagine, fa risparmiare ore.

Negli ambienti critici un tempo sincronizzato e attendibile non è un vezzo da puristi: è una fondazione, tanto delle operazioni quanto della capacità di dire con certezza cosa è successo e quando. Perché «che ora è?» è la domanda più banale del mondo — e la risposta sbagliata mette in ginocchio, in silenzio, l’autenticazione, la cifratura e la tua capacità di ricostruire i fatti.

Fa parte della serie «È sempre…» sulle fondamenta invisibili dell’infrastruttura. Leggi anche È sempre il DNS, È sempre colpa del firewall e Non è scaduto il certificato.