Come fare in modo che il tempo per sé non mentisca, se avete un milione di grandi e piccoli dispositivi che comunicano tramite TCP/IP? Infatti, ognuno di essi ha un orologio, e il tempo deve essere preciso su tutti. Questo problema non può essere risolto senza NTP.
Immaginiamo per un momento che in un segmento di infrastruttura IT aziendale ci siano difficoltà nel sincronizzare i servizi temporali. Immediatamente inizia a fallire il cluster di software Enterprise, si rompono i domini e i nodi master e standby cercano invano di ripristinare lo stato di cose precedente.
Può anche verificarsi una situazione in cui un malintenzionato cerca intenzionalmente di alterare il tempo tramite un attacco MiTM o DDoS. In tale situazione, può succedere di tutto:
- le password degli account utente scadono;
- scade la validità dei certificati X.509;
- l'autenticazione a due fattori TOTP smette di funzionare;
- i backup diventano "obsoleti" e il sistema li elimina;
- si rompe DNSSec.
È chiaro che ogni dipartimento IT è interessato al funzionamento affidabile dei servizi di sincronizzazione temporale, e sarebbe opportuno che fossero sicuri e robusti nell'uso industriale.
Compromettere NTP in 25 minuti
I protocolli di rete — i millennial hanno una particolare caratteristica, sono obsoleti da tempo La principale lamentela riguardo al classico NTP è la mancanza di meccanismi di protezione affidabili contro gli attacchi degli aggressori. Sono stati fatti diversi tentativi per risolvere questo problema. Inizialmente, è stato implementato un meccanismo di chiavi preconfigurate (PSK) per lo scambio di chiavi simmetriche.
Sfortunatamente, questo metodo non ha funzionato per una semplice ragione: non scala bene. Richiede una configurazione manuale sul lato client a seconda del server. Questo significa che non è possibile aggiungere semplicemente un altro client. Se qualcosa cambia sul server NTP, è necessario riconfigurare tutti i client.
Allora è stato ideato AutoKey, ma sono subito emerse diverse gravi vulnerabilità nel design stesso dell'algoritmo, costringendo a rinunciarvi. Il problema è che il numero iniziale (seed) contiene solo 32 bit, un valore troppo ridotto che non offre sufficiente complessità computazionale per un attacco diretto.
Poi è stato inventato AutoKey, ma sono subito emerse diverse gravi vulnerabilità nel design dell'algoritmo e si è dovuto rinunciare. Il problema è che il numero iniziale (seed) è composto da solo 32 bit, una quantità troppo ridotta che non offre sufficiente complessità computazionale per un attacco diretto.
- ID chiave — chiave simmetrica a 32 bit;
- MAC (codice di autenticazione del messaggio) — checksum del pacchetto NTP;
L'Autokey viene calcolato come segue.
Autokey=H(Indirizzo-IP-Mittente||Indirizzo-IP-Destinazione||IDChiave||Cookie)Dove H() è una funzione hash crittografica.
Per calcolare la checksum, si utilizza la stessa funzione per i pacchetti.
MAC=H(Autokey||pacchetto NTP)Pertanto, l'intera integrità dei controlli dei pacchetti si basa sull'autenticità dei cookie. Se un aggressore riesce a ottenerli, può ripristinare l'autokey e poi falsificare il MAC. Tuttavia, il server NTP utilizza un numero iniziale (seed) durante la loro generazione. È qui che si nasconde l'inganno.
Cookie=MSB_32(H(IP Client||IP Server||0||Seed Server))La funzione MSB_32 estrae i 32 bit più significativi dal risultato del calcolo dell'hash md5. Il cookie lato client non cambia finché i parametri del server rimangono invariati. Successivamente, all'aggressore rimane solo da ripristinare il numero iniziale e ottenere la possibilità di generare cookie autonomamente.
Per iniziare, è necessario connettersi al server NTP come cliente e ottenere i cookie. Dopodiché, l'aggressore ripristina il numero iniziale attraverso un semplice algoritmo di tentativi ed errori.
Algoritmo di attacco per il calcolo del numero iniziale tramite tentativi ed errori.
per i=0:2^32 − 1 fai
Ci=H(Server-IP||Client-IP||0||i)
se Ci=Cookie allora
ritorna i
fine se
fine perGli indirizzi IP sono noti, quindi resta solo da creare 2^32 hash fino a quando l'cookie generato non corrisponde a quello ricevuto dal server NTP. Su una normale macchina domestica con Intel Core i5, ci vorranno 25 minuti.
NTS — nuovo Autokey
Non si poteva tollerare tali falle nella sicurezza di Autokey, e nel 2012 è emersa del protocollo. A seguito del compromesso del nome, è stato deciso di fare un rebranding, quindi Autokey v.2 è stato ribattezzato Network Time Security.
Il protocollo NTS è un'estensione della sicurezza NTP e attualmente supporta solo la modalità unicast. Fornisce una solida protezione crittografica contro le manipolazioni dei pacchetti, previene il tracciamento, scala bene, è resistente alla perdita di pacchetti di rete e comporta le minori perdite di precisione durante la protezione della connessione.
La connessione NTS è composta da due fasi, in cui sono utilizzati protocolli di basso livello. Nella prima fase, il client e il server concordano diversi parametri della connessione e scambiano cookie contenenti chiavi con tutto l'insieme di dati associati. Nel secondo la fase in cui avviene effettivamente la sessione NTS protetta tra il client e il server NTP.
NTS è composto da due protocolli a livello inferiore: Network Time Security Key Exchange (NTS-KE), che inizializza una connessione sicura sopra TLS, e NTPv4 — l'ultima incarnazione del protocollo NTP. Maggiori dettagli su questo di seguito.
La prima fase è NTS KE
In questa fase, il client NTP avvia una sessione TLS 1.2/1.3 su una connessione TCP separata con il server NTS KE. Durante questa sessione avviene quanto segue.
- Le parti definiscono i parametri dell'algoritmo per la seconda fase.
- Le parti definiscono il secondo protocollo a livello inferiore, ma per il momento solo NTPv4 è supportato.
- Le parti definiscono l'indirizzo IP e la porta del server NTP.
- Il server NTS KE emette dei cookie per NTPv4.
- Le parti estraggono dalla materia dei cookie una coppia di chiavi simmetriche (C2S e S2C).
Questo approccio ha il grande vantaggio che tutto il carico di trasmissione delle informazioni segrete sui parametri di connessione ricade su un protocollo TLS collaudato e affidabile. In tal modo, non c'è necessità di inventare una propria soluzione per un handshake NTP sicuro.
La seconda fase è NTP protetto da NTS
Nella seconda fase, il cliente sincronizza in modo sicuro l'orario con il server NTP. A questo scopo, invia quattro estensioni speciali (extension field) nella struttura del pacchetto NTPv4.
- L'estensione Unique Identifier contiene un nonce casuale per prevenire attacchi di ripetizione.
- L'estensione NTS Cookie contiene uno dei cookie NTP disponibili presso il cliente. Poiché solo il cliente detiene le chiavi simmetriche AAED C2S e S2C, il server NTP deve estrarle dal materiale del cookie.
- L'estensione NTS Cookie Placeholder è un modo per il cliente di richiedere ulteriori cookie dal server. Questa estensione è necessaria affinché la risposta del server NTP non sia molto più lunga della richiesta. Ciò aiuta a prevenire attacchi di amplificazione.
- L'estensione NTS Authenticator and Encrypted Extension Fields contiene il cifrario dell'algoritmo AAED con la chiave C2S, l'intestazione NTP, i timestamp e le EF menzionate sopra come dati ausiliari. Senza questa estensione, è possibile falsificare i timestamp.
Dopo aver ricevuto la richiesta dal cliente, il server verifica l'autenticità del pacchetto NTP. A questo scopo, deve decifrare il cookie, estrarre l'algoritmo AAED e le chiavi. Dopo una verifica positiva della validità del pacchetto NTP, il server risponde al cliente nel seguente formato.
- Estensione Identificatore Unico copia speculare della richiesta del cliente, misura contro gli attacchi di spoofing.
- Estensione NTS Cookie più cookie per continuare la sessione.
- Estensione dei Campi NTS Authenticator e Cifrati contiene un cifrario AEAD con la chiave S2C.
Il secondo handshake può essere ripetuto molte volte, bypassando il primo passaggio, poiché ogni richiesta e risposta forniscono al cliente cookie aggiuntivi. Questo offre il vantaggio di suddividere le operazioni TLS relativamente intensive in termini di risorse e la trasmissione dei dati PKI in base al numero di richieste ripetute. È particolarmente utile per cronometri FPGA specializzati, dove l'intera funzionalità principale può essere impacchettata in poche funzioni di crittografia simmetrica, trasferendo l'intero stack TLS su un altro dispositivo.
NTPSec
Qual è la particolarità di NTP? Nonostante l'autore del progetto Dave Mills abbia cercato di documentare il proprio codice nel miglior modo possibile, è raro che un programmatore riesca a districarsi nelle complessità degli algoritmi di sincronizzazione del tempo risalenti a 35 anni fa. Parte del codice è stata scritta prima dell'era POSIX, e l'API Unix di quel tempo differiva notevolmente da quella che si utilizza oggi. Inoltre, è necessaria una conoscenza di statistica per ripulire il segnale dai disturbi su linee rumorose.
NTS non è stata la prima iniziativa per riparare NTP. Dopo che i ladri informatici hanno imparato a sfruttare le vulnerabilità di NTP per amplificare attacchi DDoS, è diventato chiaro che erano necessarie trasformazioni radicali. Mentre si preparavano e si perfezionavano le bozze di NTS, nel dicembre 2014 la National Science Foundation degli USA ha urgentemente stanziato fondi per modernizzare l'NTP.
Il gruppo di lavoro era guidato da , uno dei fondatori e dei pilastri della comunità Open Source e autore del libro . Prima di tutto, Eric e i suoi collaboratori hanno cercato di trasferire il codice NTP dalla piattaforma BitKeeper a git, ma non è stato possibile. Il leader del progetto Harlan Stenn si opponeva a questa soluzione e le trattative si sono arenate. Allora si è deciso di fare un fork del codice del progetto, creando così NTPSec.
L'ampia esperienza, compreso il lavoro su GPSD, un background matematico e la straordinaria abilità di leggere codice antico — Eric Raymond era proprio quell'hacker capace di portare avanti un tale progetto. Nel team si è trovato uno specialista nella migrazione del codice e in sole 10 settimane NTP su GitLab. Il lavoro è decollato.
Il team di Eric Raymond ha affrontato la questione così come Auguste Rodin lavorava su un blocco di pietra. Rimuovendo 175 KLOC di codice obsoleto, sono riusciti a ridurre significativamente la superficie di attacco, chiudendo molte falle di sicurezza.
Ecco un elenco non esaustivo degli elementi coinvolti:
- refclock non documentati, obsoleti o difettosi.
- Libreria ICS non utilizzata.
- libopts/autogen.
- Codice obsoleto per Windows.
- ntpdc.
- Autokey.
- Codice C di ntpq riscritto in Python.
- Codice C di sntp/ntpdig riscritto in Python.
Oltre alla pulizia del codice, il progetto aveva anche altre sfide. Ecco un elenco non esaustivo dei risultati:
- La protezione del codice contro il buffer overflow è stata notevolmente rafforzata. Per prevenire il buffer overflow, tutte le funzioni per le stringhe non sicure (strcpy / strcat / strtok / sprintf / vsprintf / gets) sono state sostituite con versioni sicure che implementano un limite alla dimensione del buffer.
- Aggiunta il supporto per NTS.
- La precisione del passo temporale è stata aumentata di dieci volte grazie al legame con hardware fisico. Questo è dovuto al fatto che gli orologi dei computer moderni sono diventati molto più precisi rispetto a quelli al momento della nascita di NTP. GPSDO e stazioni radiocronometriche dedicate ne hanno beneficiato maggiormente.
- Il numero di linguaggi di programmazione è ridotto a due. Invece di script in Perl, awk e persino S, ora c'è solo Python. Questo ha aumentato le possibilità di riutilizzo del codice.
- Invece di un mosaico di script autotools, il progetto ha iniziato a utilizzare un sistema di build del software. .
- Abbiamo aggiornato e riorganizzato la documentazione del progetto. Da una collezione contraddittoria e in parte obsoleta di documenti è stata creata una documentazione accettabile. Ogni opzione della riga di comando e ogni entità di configurazione ora ha una verità unica. Inoltre, le pagine di guida e la documentazione web vengono ora generate dagli stessi file di base.
NTPSec è disponibile per diverse distribuzioni Linux. Attualmente, l'ultima versione stabile è la 1.1.8, mentre per Gentoo Linux è disponibile una versione precedente.
(1:696)$ sudo emerge -av ntpsec
Questi sono i pacchetti che verrebbero installati, in ordine:
Calcolo delle dipendenze... fatto!
[ebuild R ] net-misc/ntpsec-1.1.7-r1::gentoo USE="samba seccomp -debug -doc -early -gdb -heat -libbsd -nist -ntpviz -rclock_arbiter -rclock_generic -rclock_gpsd -rclock_hpgps -rclock_jjy -rclock_local -rclock_modem -rclock_neoclock -rclock_nmea -rclock_oncore -rclock_pps -rclock_shm -rclock_spectracom -rclock_trimble -rclock_truetime -rclock_zyfer -smear -tests" PYTHON_TARGETS="python3_6" 0 KiB
Totale: 1 pacchetto (1 reinstallazione), Dimensione dei download: 0 KiB
Vuoi installare questi pacchetti? [Sì/No]
Chrony
C'è stata un'altra tentativo di sostituire il vecchio NTP con un analogo più sicuro. Chrony, a differenza di NTPSec, è stato scritto da zero ed è progettato per funzionare in modo affidabile in un'ampia gamma di condizioni, incluse connessioni di rete instabili, disponibilità parziale o sovraccarichi di rete, e variazioni di temperatura. Inoltre, chrony presenta altri vantaggi:
- chrony può sincronizzare più rapidamente le ore di sistema con maggiore precisione;
- chrony è più leggero, consuma meno memoria e accede al processore solo quando necessario. Questo rappresenta un grande vantaggio per il risparmio di risorse ed energia;
- chrony supporta i timestamp a livello hardware in Linux, garantendo una sincronizzazione estremamente precisa nelle reti locali.
Tuttavia, chrony manca di alcune funzionalità del vecchio NTP, come il supporto per client/server broadcast e multicast. Inoltre, il classico NTP supporta un numero maggiore di sistemi operativi e piattaforme.
Per disabilitare la funzionalità del server e le richieste NTP al processo chronyd, basta impostare port 0 nel file chrony.conf. Questo avviene nei casi in cui non sia necessario fornire l'ora per i client NTP o per nodi peer. A partire dalla versione 2.0, la porta del server NTP è aperta solo quando l'accesso è consentito dalla direttiva allow o da un comando corrispondente, oppure quando è configurato un nodo peer NTP, o si utilizza la direttiva broadcast.
Il programma è composto da due moduli.
- chronyd è un servizio che opera in background. Riceve informazioni sulla differenza tra l'orologio di sistema e un server di tempo esterno e corregge l'ora locale. Implementa anche il protocollo NTP ed può funzionare sia come client che come server.
- chronyc è un'utilità da riga di comando per monitorare e controllare il programma. Viene utilizzata per ottimizzare diversi parametri del servizio, ad esempio permette di aggiungere o rimuovere server NTP mentre chronyd continua a funzionare.
A partire dalla settima versione di RedHat Linux chrony come servizio di sincronizzazione dell'ora. Il pacchetto è disponibile anche per altre distribuzioni Linux. L'ultima versione stabile 3.5 è in preparazione per il rilascio della v4.0.
(1:712)$ sudo emerge -av chrony
Questi sono i pacchetti che verrebbero installati, in ordine:
Calcolo delle dipendenze... fatto!
[binary N ] net-misc/chrony-3.5-r2::gentoo USE="adns caps cmdmon ipv6 ntp phc readline refclock rtc seccomp (-html) -libedit -pps (-selinux)" 246 KiB
Totale: 1 pacchetto (1 nuovo, 1 binario), Dimensione dei download: 246 KiB
Vuoi unire questi pacchetti? [Sì/No]
Come configurare un proprio server remoto chrony su internet per la sincronizzazione del tempo nella rete dell'ufficio. Ecco un esempio di configurazione su VPS.
Esempio di configurazione di Chrony su RHEL / CentOS su VPS
Ora facciamo un po' di pratica e avviamo il nostro server NTP su VPS. È molto semplice, basta scegliere il piano giusto sul sito RuVDS, ottenere un server pronto e digitare una dozzina di comandi facili. Per i nostri scopi, questa opzione va benissimo.
Passiamo alla configurazione del servizio e per prima cosa installiamo il pacchetto chrony.
[root@server ~]$ yum install chronyRHEL 8 / CentOS 8 utilizzano un diverso gestore di pacchetti.
[root@server ~]$ dnf install chronyDopo aver installato chrony, è necessario avviare e attivare il servizio.
[root@server ~]$ systemctl enable chrony --nowSe lo desideri, puoi apportare modifiche a /etc/chrony.conf, sostituendo i server NTP con quelli locali più vicini per ridurre il tempo di risposta.
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server 0.ru.pool.ntp.org iburst
server 1.ru.pool.ntp.org iburst
server 2.ru.pool.ntp.org iburst
server 3.ru.pool.ntp.org iburst
Procediamo ora con la configurazione della sincronizzazione del server NTP con i nodi del pool specificato.
[root@server ~]$ timedatectl set-ntp true
[root@server ~]$ systemctl restart chronyd.service
È necessario aprire anche il port NTP, altrimenti il firewall bloccherà le connessioni in entrata dai nodi client.
[root@server ~]$ firewall-cmd --add-service=ntp --permanent
[root@server ~]$ firewall-cmd --reload
Dal lato client, è sufficiente impostare correttamente il fuso orario.
[root@client ~]$ timedatectl set-timezone Europe/MoscowNel file /etc/chrony.conf specifica l'IP o il nome host del nostro server VPS, sul quale è attivo il server NTP chrony.
server my.vps.serverE infine avviare la sincronizzazione del tempo sul client.
[root@client ~]$ systemctl enable --now chronyd
[root@client ~]$ timedatectl set-ntp true
La prossima volta parlerò delle opzioni per la sincronizzazione del tempo senza internet.
Fonte: habr.com
