Mappa Globale#
Cosa fa#
NTP (Network Time Protocol) sincronizza i clock di tutti i dispositivi della rete su una fonte temporale comune. Usa UDP porta 123. Senza NTP, ogni dispositivo ha il proprio orologio che deriva nel tempo, rendendo impossibile correlare eventi di sicurezza e rompendo protocolli che dipendono dal tempo come Kerberos.
TL;DR#
NTP e' invisibile quando funziona. Diventa critico quando viene attaccato o mal configurato. Due impatti principali per la security:
- Senza NTP corretto - i log di 10 macchine diverse non sono correlabili, il SIEM non puo' ordinare gli eventi, la forensics post-incidente diventa un puzzle impossibile
- Con NTP attaccato - Kerberos smette di funzionare, i certificati TLS risultano expired, tutta l'infrastruttura di autenticazione collassa
Perche' NTP e' critico per la Security#
Log e Correlazione SIEM#
Il SIEM correla eventi da sorgenti eterogenee (firewall, endpoint, server, applicazioni) ordinandoli nel tempo. Se gli orologi di queste sorgenti sono sfasati anche di pochi minuti, la correlazione produce falsi positivi e falsi negativi.
Scenario: un attaccante esegue lateral movement tra tre server in 2 minuti. Se il clock del server A e' indietro di 8 minuti rispetto al server B, il SIEM vede gli eventi in ordine sbagliato e non li correla come un unico attacco.
SIEM come Wazuh e Splunk richiedono timestamp sincronizzati per funzionare correttamente. Il drift accettabile e' in genere sotto i 500ms. Piu' di qualche secondo inizia a creare problemi di correlazione.
Kerberos e la Finestra di 5 Minuti#
Kerberos usa i timestamp come difesa contro il replay attack: un ticket Kerberos vale solo se il timestamp e' entro 5 minuti dall'orologio del server. Oltre i 5 minuti (skew), il ticket viene rifiutato come potenzialmente replayed.
| Skew del clock | Impatto Kerberos |
|---|---|
| < 5 minuti | Funziona normalmente |
| 5 minuti esatti | Soglia limite - ticket accettati marginalmente |
| > 5 minuti | Tutti i ticket rifiutati - autenticazione AD impossibile |
| > 15 minuti | Ambiente di fatto inutilizzabile |
Un attacco NTP che sposta il clock di un domain controller o di un client di 6 minuti puo' bloccare l'intero accesso a un'infrastruttura Windows.
TLS e Validita' dei Certificati#
I certificati X.509 hanno campi Not Before e Not After. Se il clock del client e' nel futuro, un certificato valido appare come non ancora valido. Se e' nel passato, un certificato scaduto da anni appare come valido.
Dev parallel: Come un sistema di event-sourcing distribuito dove i microservizi non hanno un clock sincronizzato: gli eventi arrivano fuori ordine al message broker, la ricostruzione dello stato dell'aggregato e' corrotta. NTP per i dispositivi di rete e' esattamente la sincronizzazione degli orologi che garantisce l'ordine causale degli eventi nel tuo sistema Kafka/RabbitMQ.
Attacchi NTP#
NTP Amplification Attack#
L'NTP Amplification e' un attacco DDoS di tipo reflection. Il principio e' identico agli altri reflected DDoS (DNS, Memcached): l'attaccante spofa l'IP della vittima come sorgente delle richieste, i server NTP rispondono alla vittima con risposte molto piu' grandi delle richieste.
Il vettore specifico NTP e' il comando monlist (o MON_GETLIST): restituisce gli ultimi 600 client che si sono connessi al server NTP. Una richiesta di ~100 byte genera una risposta di ~48.000 byte.
sequenceDiagram participant ATK as Charlie (Attaccante) participant NTP as Server NTP (internet) participant V as Franco (Vittima) Note over ATK: Spoofa l'IP della vittima come sorgente ATK->>NTP: UDP request monlist (src: IP vittima) ~100 byte ATK->>NTP: UDP request monlist (src: IP vittima) ~100 byte ATK->>NTP: (x1000 server NTP mal configurati) NTP-->>V: Response monlist ~48000 byte NTP-->>V: Response monlist ~48000 byte NTP-->>V: (x1000 response convergono sulla vittima) Note over V: Flood da ~48 GB/s su 100 MB request Note over V: Connessione satura - servizi inaccessibili
Fattore di amplificazione: fino a 600x. Un attaccante con 1 Gbps di banda puo' generare 600 Gbps sulla vittima.
Difesa: disabilitare monlist sui server NTP pubblici (aggiornare a versione recente di ntpd, abilitata per default da ntpd 4.2.7p26 in poi). I provider NTP moderni come pool.ntp.org hanno gia' disabilitato monlist.
NTP Spoofing#
L'NTP Spoofing inietta risposte NTP false per alterare il clock di un client. L'obiettivo e' spostare il clock abbastanza da rompere i meccanismi di sicurezza time-dependent.
sequenceDiagram participant C as Client participant ATK as Charlie (MITM) participant NTP as Server NTP legittimo C->>ATK: NTP Request (Charlie e' in posizione MITM) ATK->>NTP: Forwarda la request (opzionale) ATK-->>C: Risposta NTP falsa: "sono le 3:00 AM del 2020-01-01" Note over C: Clock aggiornato a 3 anni fa Note over C: Certificati TLS "non ancora validi" Note over C: Kerberos ticket rifiutati - clock skew > 5 min Note over C: Log timestamp falsati - forensics compromessa
Effetti di un NTP Spoofing riuscito:
- Certificati TLS risultano "not yet valid" o "expired" in base alla data falsa
- Kerberos blocca tutte le autenticazioni (skew > 5 minuti)
- I log registrano timestamp falsi - la timeline dell'incidente e' falsata
- Sessioni SSL/TLS possono essere invalidate
Gerarchia Stratum#
NTP usa una gerarchia a livelli chiamata stratum per indicare la distanza dalla sorgente primaria (atomic clock o GPS).
| Stratum | Descrizione | Esempio |
|---|---|---|
| 0 | Riferimento primario - non e' un server NTP | Atomic clock (cesio), GPS, WWVB radio |
| 1 | Server direttamente connesso a Stratum 0 | time.nist.gov, time.apple.com |
| 2 | Sincronizzato da server Stratum 1 | Pool NTP pubblici (pool.ntp.org) |
| 3-14 | Sincronizzati dal livello superiore | Server NTP aziendali interni |
| 15 | Ultimo livello accettabile | |
| 16 | Non sincronizzato / inutilizzabile |
Architettura enterprise tipica:
- 2-3 server Stratum 2 interni sincronizzati da Stratum 1 pubblici
- Tutti i dispositivi aziendali puntano ai server Stratum 2 interni
- Non esporre mai i dispositivi aziendali direttamente a internet per NTP
NTPsec e Network Time Security (NTS)#
Il protocollo NTP classico (RFC 5905) non autentica il server: un client non puo' verificare che la risposta provenga da un server fidato. Questo rende facile lo spoofing.
NTPsec e' la versione moderna e sicura di ntpd, con una codebase ridotta (meno superficie di attacco) e varie mitigazioni. Sostituisce il vecchio ntpd su sistemi moderni.
NTS (Network Time Security, RFC 8915) aggiunge autenticazione TLS alle sessioni NTP:
- Il client verifica il certificato del server NTP prima di accettare i timestamp
- Impedisce l'NTP Spoofing: le risposte non autenticate vengono rifiutate
- Usa TLS 1.3 per il key exchange, poi passa a AEAD per i pacchetti NTP
- Supportato da server moderni:
time.cloudflare.com,time.apple.com
Scenario Reale#
Un incident response team viene chiamato dopo un blackout di Active Directory in un'azienda di 2000 dipendenti. Tutti gli utenti non riescono ad autenticarsi da un'ora. Il team verifica il domain controller: clock in anticipo di 18 minuti rispetto al tempo reale. Kerberos rifiuta tutti i ticket. L'attaccante aveva sfruttato un server NTP interno mal configurato (versione vecchia con monlist attiva e NTP MD5 auth disabilitata) per iniettare un timestamp falso via pacchetti UDP. Fix immediato: sincronizzare manualmente il DC con w32tm /resync /force. Fix permanente: aggiornare i server NTP interni a NTPsec, abilitare NTS, bloccare UDP 123 inbound dall'internet.
Collegato a#
- sso-kerberos-saml - Kerberos dipende criticamente da NTP per l'anti-replay
- ddos-reflected - NTP Amplification e' una variante dei reflected DDoS
- ssl-tls - i certificati TLS dipendono dal clock corretto per la validazione
- siem-soar - SIEM richiede timestamp sincronizzati per la correlazione
- logging - log con timestamp corretti sono la base della forensics
