Come assicurarsi che il tempo di per sé non menta se si dispone di un milione di dispositivi grandi e piccoli che comunicano tramite TCP/IP? Dopotutto, ognuno di loro ha un orologio e l'ora deve essere corretta per tutti. Questo problema non può essere aggirato senza ntp.
Immaginiamo per un minuto che in un segmento dell'infrastruttura IT industriale ci siano difficoltà con la sincronizzazione dei servizi nel tempo. Immediatamente lo stack del cluster del software aziendale inizia a fallire, i domini si disintegrano, i nodi master e standby tentano senza successo di ripristinare lo status quo.
È anche possibile che un utente malintenzionato cerchi deliberatamente di alterare l'ora tramite un attacco MiTM o DDOS. In una situazione del genere, tutto può succedere:
- Le password degli account utente scadranno;
- I certificati X.509 scadranno;
- L'autenticazione a due fattori TOTP smetterà di funzionare;
- i backup diventeranno obsoleti e il sistema li eliminerà;
- DNSSec si interromperà.
È chiaro che ogni reparto IT è interessato al funzionamento affidabile dei servizi di sincronizzazione dell'ora e sarebbe bello se fossero affidabili e sicuri nel funzionamento industriale.
Interrompi NTP in 25 minuti
Protocolli di rete: i millennial hanno una particolarità: lo sono stati e non servono più a nulla, ma sostituirli non è così facile anche quando si accumula una massa critica di appassionati e di finanziamenti.
La principale lamentela sull’NTP classico è la mancanza di meccanismi affidabili per la protezione dagli attacchi degli intrusi. Sono stati fatti vari tentativi per risolvere questo problema. Per raggiungere questo obiettivo, abbiamo innanzitutto implementato un meccanismo di chiave precondivisa (PSK) per lo scambio di chiavi simmetriche.
Sfortunatamente, questo metodo non ha dato i suoi frutti per un semplice motivo: non è ben scalabile. La configurazione manuale è richiesta sul lato client a seconda del server. Ciò significa che semplicemente non puoi aggiungere un altro client in questo modo. Se cambia qualcosa sul server NTP, tutti i client devono essere riconfigurati.
Poi hanno inventato AutoKey, ma hanno subito scoperto una serie di gravi vulnerabilità nella progettazione dell'algoritmo stesso e hanno dovuto abbandonarlo. Il fatto è che il seme contiene solo 32 bit, è troppo piccolo e non contiene abbastanza complessità computazionale per un attacco frontale.
- ID chiave: chiave simmetrica a 32 bit;
- MAC (codice di autenticazione del messaggio) - checksum del pacchetto NTP;
La chiave automatica viene calcolata come segue.
Autokey=H(Sender-IP||Receiver-IP||KeyID||Cookie)Dove H() è una funzione hash crittografica.
La stessa funzione viene utilizzata per calcolare il checksum dei pacchetti.
MAC=H(Autokey||NTP packet)Si scopre che l'intera integrità dei controlli dei pacchetti si basa sull'autenticità dei cookie. Una volta che li hai, puoi ripristinare la chiave automatica e quindi falsificare il MAC. Tuttavia, il server NTP utilizza un seed durante la generazione. È qui che sta il problema.
Cookie=MSB_32(H(Client IP||Server IP||0||Server Seed))La funzione MSB_32 elimina i 5 bit più significativi dal risultato del calcolo dell'hash md32. Il cookie del client non cambia finché i parametri del server rimangono invariati. Quindi l'aggressore può solo ripristinare il numero iniziale ed essere in grado di generare cookie autonomamente.
Innanzitutto è necessario connettersi al server NTP come client e ricevere i cookie. Successivamente, utilizzando un metodo di forza bruta, l'aggressore ripristina il numero iniziale seguendo un semplice algoritmo.
Algoritmo per attaccare il calcolo del numero iniziale utilizzando il metodo della forza bruta.
for i=0:2^32 − 1 do
Ci=H(Server-IP||Client-IP||0||i)
if Ci=Cookie then
return i
end if
end forGli indirizzi IP sono noti, quindi non resta che creare 2^32 hash finché il cookie creato non corrisponde a quello ricevuto dal server NTP. Su una normale stazione domestica con Intel Core i5 ci vorranno 25 minuti.
NTS - nuova chiave automatica
Era impossibile sopportare tali buchi di sicurezza in Autokey e nel 2012 è apparso protocollo. Per compromettere il nome, hanno deciso di rinominare, quindi Autokey v.2 è stata soprannominata Network Time Security.
Il protocollo NTS è un'estensione della sicurezza NTP e attualmente supporta solo la modalità unicast. Fornisce una forte protezione crittografica contro la manipolazione dei pacchetti, previene lo snooping, è ben scalabile, è resistente alla perdita di pacchetti di rete e comporta una minima perdita di precisione durante la sicurezza della connessione.
Una connessione NTS è composta da due fasi che utilizzano protocolli di livello inferiore. SU il primo In questa fase, il client e il server concordano diversi parametri di connessione e scambiano cookie contenenti chiavi con tutto il set di dati associato. SU secondo In questa fase avviene la vera e propria sessione NTS protetta tra il client e il server NTP.
NTS è costituito da due protocolli di livello inferiore: Network Time Security Key Exchange (NTS-KE), che avvia una connessione sicura su TLS, e NTPv4, l'ultima incarnazione del protocollo NTP. Maggiori informazioni su questo argomento di seguito.
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 accade quanto segue.
- Le parti determinano i parametri algoritmo per la seconda fase.
- Le parti definiscono un secondo protocollo di livello inferiore, ma al momento è supportato solo NTPv4.
- Le parti determinano l'indirizzo IP e la porta del server NTP.
- Il server NTS KE emette cookie sotto NTPv4.
- Le parti estraggono una coppia di chiavi simmetriche (C2S e S2C) dal materiale dei cookie.
Questo approccio ha il grande vantaggio che l'intero onere della trasmissione di informazioni segrete sui parametri di connessione ricade sul protocollo TLS collaudato e affidabile. Ciò elimina la necessità di reinventare la propria ruota per un handshake NTP sicuro.
Seconda fase: NTP sotto protezione NTS
Nella seconda fase il client sincronizza in modo sicuro l'ora con il server NTP. A questo scopo trasmette quattro estensioni speciali (campi di estensione) nella struttura del pacchetto NTPv4.
- L'estensione dell'identificatore univoco contiene un nonce casuale per impedire attacchi di riproduzione.
- NTS Cookie Extension contiene uno dei cookie NTP disponibili per il client. Poiché solo il client dispone delle chiavi AAED simmetriche C2S e S2C, il server NTP deve estrarle dal materiale del cookie.
- NTS Cookie Placeholder Extension è un modo con cui un client richiede cookie aggiuntivi dal server. Questa estensione è necessaria per garantire che la risposta del server NTP non sia molto più lunga della richiesta. Ciò aiuta a prevenire attacchi di amplificazione.
- L'estensione dei campi di estensione crittografati e autenticatore NTS contiene la cifratura AAED con la chiave C2S, l'intestazione NTP, i timestamp e l'EF precedente come dati di accompagnamento. Senza questa estensione è possibile falsificare i timestamp.
Dopo aver ricevuto una richiesta da un client, il server verifica l'autenticità del pacchetto NTP. Per fare ciò, deve decrittografare i cookie, estrarre l'algoritmo e le chiavi AAED. Dopo aver verificato con successo la validità del pacchetto NTP, il server risponde al client nel seguente formato.
- L'estensione dell'identificatore univoco è una copia speculare della richiesta del client, una misura contro gli attacchi di riproduzione.
- NTS Cookie Extension altri cookie per continuare la sessione.
- L'estensione NTS Authenticator e Encrypted Extension Fields contiene la cifratura AEAD con una chiave S2C.
Il secondo handshake può essere ripetuto più volte, ignorando il primo passaggio, poiché ogni richiesta e risposta fornisce al client cookie aggiuntivi. Ciò ha il vantaggio che le operazioni TLS relativamente dispendiose in termini di risorse di elaborazione e trasmissione di dati PKI vengono divise per il numero di richieste ripetute. Ciò è particolarmente utile per i cronometristi FPGA specializzati, quando tutte le funzionalità principali possono essere raggruppate in diverse funzioni dal campo della crittografia simmetrica, trasferendo l'intero stack TLS su un altro dispositivo.
NTPSec
Cosa c'è di speciale nell'NTP? Nonostante il fatto che l'autore del progetto, Dave Mills, abbia cercato di documentare il suo codice nel miglior modo possibile, è raro un programmatore che sarà in grado di comprendere le complessità degli algoritmi di sincronizzazione temporale che hanno 35 anni. Parte del codice è stato scritto prima dell'era POSIX e l'API Unix allora era molto diversa da quella utilizzata oggi. Inoltre, è necessaria la conoscenza della statistica per eliminare il segnale dalle interferenze su linee rumorose.
NTS non è stato il primo tentativo di correggere NTP. Una volta che gli aggressori hanno imparato a sfruttare le vulnerabilità NTP per amplificare gli attacchi DDoS, è diventato chiaro che erano necessari cambiamenti radicali. E mentre le bozze dell’NTP venivano preparate e finalizzate, la National Science Foundation statunitense alla fine del 2014 ha stanziato con urgenza una sovvenzione per la modernizzazione dell’NTP.
Il gruppo di lavoro non era guidato da chiunque, ma - uno dei fondatori e pilastri della comunità Open Source e autore del libro . La prima cosa che Eric e i suoi amici hanno provato a fare è stata spostare il codice NTP dalla piattaforma BitKeeper a Git, ma non ha funzionato in questo modo. Il responsabile del progetto Harlan Stenn era contrario a questa decisione e le trattative si sono bloccate. Poi si è deciso di effettuare un fork del codice del progetto ed è nato NTPSec.
Solida esperienza, compreso il lavoro su GPSD, un background matematico e la magica abilità di leggere codici antichi: Eric Raymond era esattamente l'hacker che poteva portare a termine un simile progetto. Il team ha trovato uno specialista nella migrazione del codice e in sole 10 settimane NTP su GitLab. Il lavoro era in pieno svolgimento.
La squadra di Eric Raymond ha affrontato il compito allo stesso modo di Auguste Rodin con un blocco di pietra. Rimuovendo 175 KLOC del vecchio codice, sono riusciti a ridurre significativamente la superficie di attacco chiudendo molte falle di sicurezza.
Ecco un elenco incompleto di quelli inclusi nella distribuzione:
- Refclock non documentato, obsoleto, obsoleto o rotto.
- Libreria ICS inutilizzata.
- libopts/autogeno.
- Vecchio codice per Windows.
- ntpdc.
- Chiave automatica.
- Il codice C ntpq è stato riscritto in Python.
- Il codice C sntp/ntpdig è stato riscritto in Python.
Oltre a ripulire il codice, il progetto aveva altri compiti. Ecco un elenco parziale dei risultati ottenuti:
- La protezione del codice contro l'overflow del buffer è stata notevolmente migliorata. Per prevenire overflow del buffer, tutte le funzioni di stringa non sicure (strcpy/strcat/strtok/sprintf/vsprintf/gets) sono state sostituite con versioni sicure che implementano i limiti di dimensione del buffer.
- Aggiunto il supporto NTS.
- Precisione del passo temporale migliorata di dieci volte collegando l'hardware fisico. Ciò è dovuto al fatto che gli orologi dei computer moderni sono diventati molto più precisi di quelli al momento della nascita dell'NTP. I maggiori beneficiari di questo sono stati il GPSDO e le radio a tempo dedicato.
- Il numero dei linguaggi di programmazione è stato ridotto a due. Invece di Perl, awk e persino gli script S, ora è tutto Python. Per questo motivo, ci sono più opportunità di riutilizzo del codice.
- Invece di noodles di script di autotools, il progetto ha iniziato a utilizzare un sistema di creazione del software .
- Documentazione di progetto aggiornata e riorganizzata. Da una raccolta di documenti contraddittori e talvolta arcaici, hanno creato una documentazione abbastanza accettabile. Ogni opzione della riga di comando e ogni entità di configurazione ora ha un'unica versione della verità. Inoltre, le pagine man e la documentazione web vengono ora create dagli stessi file principali.
NTPSec è disponibile per numerose distribuzioni Linux. Al momento l'ultima versione stabile è la 1.1.8, per Gentoo Linux è la penultima.
(1:696)$ sudo emerge -av ntpsec
These are the packages that would be merged, in order:
Calculating dependencies... done!
[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
Total: 1 package (1 reinstall), Size of downloads: 0 KiB
Would you like to merge these packages? [Yes/No]
Croni
C'è stato un altro tentativo di sostituire il vecchio NTP con un'alternativa più sicura. Chrony, a differenza di NTPSec, è scritto da zero ed è progettato per funzionare in modo affidabile in un'ampia gamma di condizioni, comprese connessioni di rete instabili, disponibilità parziale o congestione della rete e cambiamenti di temperatura. Inoltre, Chronicy presenta altri vantaggi:
- chrony può sincronizzare l'orologio del sistema più velocemente e con maggiore precisione;
- chrony è più piccolo, consuma meno memoria e accede alla CPU solo quando necessario. Questo è un grande vantaggio per il risparmio di risorse ed energia;
- chrony supporta i timestamp hardware su Linux, consentendo una sincronizzazione estremamente accurata sulle reti locali.
Tuttavia, chrony manca di alcune delle funzionalità del vecchio NTP, come 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 scrivere la porta 0 nel file chrony.conf. Questo viene fatto nei casi in cui non è necessario mantenere il tempo per client o peer NTP. A partire dalla versione 2.0, la porta del server NTP è aperta solo quando l'accesso è consentito da una direttiva di autorizzazione o da un comando appropriato, oppure è configurato un peer NTP o viene utilizzata una direttiva di trasmissione.
Il programma è composto da due moduli.
- chronyd è un servizio che viene eseguito in background. Riceve informazioni sulla differenza tra l'orologio di sistema e il server temporale esterno e regola l'ora locale. Implementa anche il protocollo NTP e può fungere da client o server.
- chronyc è un'utilità della riga di comando per il monitoraggio e il controllo del programma. Utilizzato per ottimizzare vari parametri di servizio, ad esempio consentendo di aggiungere o rimuovere server NTP mentre chronyd continua a essere eseguito.
Dalla versione 7 di RedHat Linux chrony come servizio di sincronizzazione dell'ora. Il pacchetto è disponibile anche per altre distribuzioni Linux. L'ultima versione stabile è la 3.5, in preparazione al rilascio della v4.0.
(1:712)$ sudo emerge -av chrony
These are the packages that would be merged, in order:
Calculating dependencies... done!
[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
Total: 1 package (1 new, 1 binary), Size of downloads: 246 KiB
Would you like to merge these packages? [Yes/No]
Come configurare il proprio server chrony remoto su Internet per sincronizzare l'ora su una rete aziendale. Di seguito è riportato un esempio di configurazione di un VPS.
Esempio di configurazione di Chrony su RHEL / CentOS su VPS
Facciamo ora un po' di pratica e configuriamo il nostro server NTP su un VPS. È molto semplice, basta scegliere la tariffa appropriata sul sito RuVDS, procurarsi un server già pronto e digitare una dozzina di semplici comandi. Per i nostri scopi, questa opzione è abbastanza adatta.
Passiamo alla configurazione del servizio e installiamo prima il pacchetto chrony.
[root@server ~]$ yum install chronyRHEL 8/CentOS 8 utilizza un gestore di pacchetti diverso.
[root@server ~]$ dnf install chronyDopo aver installato chrony, è necessario avviare e attivare il servizio.
[root@server ~]$ systemctl enable chrony --nowSe lo si desidera, è possibile apportare modifiche a /etc/chrony.conf, sostituendo i server NPT con quelli locali più vicini per ridurre i tempi 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
Successivamente, impostiamo la sincronizzazione del server NTP con i nodi del pool specificato.
[root@server ~]$ timedatectl set-ntp true
[root@server ~]$ systemctl restart chronyd.service
È inoltre necessario aprire la porta NTP verso l'esterno, altrimenti il firewall bloccherà le connessioni in entrata dai nodi client.
[root@server ~]$ firewall-cmd --add-service=ntp --permanent
[root@server ~]$ firewall-cmd --reload
Lato client è sufficiente impostare correttamente il fuso orario.
[root@client ~]$ timedatectl set-timezone Europe/MoscowIl file /etc/chrony.conf specifica l'IP o il nome host del nostro server VPS che esegue il server NTP chrony.
server my.vps.serverE infine, avviando la sincronizzazione dell'ora sul client.
[root@client ~]$ systemctl enable --now chronyd
[root@client ~]$ timedatectl set-ntp true
La prossima volta ti dirò quali opzioni ci sono per sincronizzare l'ora senza Internet.
Fonte: habr.com
