Cum a devenit sincronizarea timpului sigură

Cum a devenit sincronizarea timpului sigură
Cum să facem ca timpul per se să nu mintă, dacă avem un milion de dispozitive mari și mici care interacționează prin TCP/IP? Fiecare dintre ele are un ceas, iar timpul trebuie să fie corect pe toate. Această problemă nu poate fi ocolită fără NTP.

Să ne imaginăm pentru un minut că într-un segment al infrastructurii IT industriale apar dificultăți în sincronizarea serviciilor în timp. Instantaneu, stiva de software Enterprise începe să eșueze, domeniile se desfac, nodurile maestru și Standby încearcă fără succes să restaureze status quo-ul.

De asemenea, poate apărea situația în care un atacator încearcă în mod intenționat să saboteze timpul prin MiTM sau atacuri DDoS. În această situație, se poate întâmpla orice:

  • expirarea parolelor conturilor utilizatorilor;
  • expirarea certificatelor X.509;
  • autentificarea cu doi factori TOTP va înceta să funcționeze;
  • backup-urile devin "îmbătrânite" și sistemul le va șterge;
  • se va strica DNSSec.

Este clar că fiecare departament IT își dorește funcționarea fiabilă a serviciilor de sincronizare a timpului, și ar fi bine ca acestea să fie atât de fiabile, cât și sigure în exploatarea industrială.

Să distrugi NTP în 25 de minute

Protocoalele de rețea – milenialii au o particularitate, ele există de mult sunt depășite și nu mai sunt de folos, dar înlocuirea lor nu este atât de ușoară chiar și atunci când se adună o masă critică de entuziaști și fonduri.

Principala plângere împotriva NTP clasic este absența unor mecanisme de protecție fiabile împotriva atacurilor atacatorilor. S-au făcut diverse încercări de a rezolva această problemă. Pentru aceasta, mai întâi s-a implementat un mecanism de chei preinstalate (PSK) pentru schimbul de chei simetrice.

Din păcate, această metodă nu a funcționat dintr-un motiv simplu – nu se scalează bine. Necesită configurare manuală pe partea clientului în funcție de server. Asta înseamnă că nu poți adăuga pur și simplu un alt client. Dacă ceva se schimbă pe serverul NTP, trebuie reconfigurați toți clienții.

Atunci a fost inventat AutoKey, dar a fost imediat descoperit un set de vulnerabilități serioase în designul algoritmului și a trebuit abandonat. Totul se datorează faptului că numărul inițial (seed) conține doar 32 de biți, ceea ce este prea puțin și nu oferă suficientă complexitate computațională pentru un atac brutal.

  • Key ID – cheie simetrică de 32 de biți;
  • MAC (cod de autentificare a mesajelor) — suma de control a pachetului NTP;

Autokey este calculat în următorul mod.

Autokey=H(Sender-IP||Receiver-IP||KeyID||Cookie)

Unde H() — este o funcție hash criptografică.

Pentru calculul sumei de control, se utilizează aceeași funcție pentru pachete.

MAC=H(Autokey||pachet NTP)

Astfel, întreaga integritate a verificărilor pachetelor depinde de autenticitatea cookie-urilor. Dacă cineva le obține, poate restaura autokey-ul și apoi falsifica MAC-ul. Totuși, serverul NTP folosește un număr inițial (seed) la generarea acestora. Aici este capcana.

Cookie=MSB_32(H(IP client||IP server||0||Server Seed))

Funcția MSB_32 taie cele 32 de biți superioari din rezultatul calculului hash md5. Cookie-ul clientului nu se schimbă atâta timp cât parametrii serverului rămân constanți. Apoi, rămâne doar ca atacatorul să reconstituie numărul inițial și să obțină capacitatea de a genera cookie-uri singur.

La început, trebuie să te conectezi la serverul NTP ca client și să obții cookie-uri. După aceea, atacatorul reconstituie numărul inițial prin metoda încercării și erorilor, urmând un algoritm simplu.

Algoritmul de atac pentru calcularea numărului inițial prin metoda încercării și erorilor.

   for i=0:2^32 − 1 do
        Ci=H(Server-IP||Client-IP||0||i)
        if Ci=Cookie then
            return i
        end if 
    end for

Adresele IP sunt cunoscute, astfel că rămâne doar să creezi 2^32 hash-uri până când cookie-ul creat coincide cu cel obținut de la serverul NTP. Pe o stație obișnuită acasă cu Intel Core i5, acest lucru va dura 25 de minute.

NTS — noul Autokey

Nu se putea tolera astfel de breșe în securitatea Autokey și în 2012 a apărut o nouă versiune protocolul. În scopul de a elimina denumirea compromisă, s-a decis o rebranding, astfel încât Autokey v.2 a fost denumit Network Time Security.

Protocolul NTS este o extensie de securitate a NTP și în prezent suportă doar modul unidirecțional (unicast). Oferă o protecție criptografică solidă împotriva manipulărilor pachetelor, previne urmărirea, se scalabil bine, este rezistent la pierderea pachetelor de rețea și duce la cele mai mici pierderi de precizie ce apar în procesul de protejare a conexiunii.

Conexiunea NTS constă din două etape, în care sunt utilizate protocoale de nivel inferior. În prima etapă, clientul și serverul se înțeleg asupra diferitelor parametrii ai conexiunii și schimbă cookie-uri, conținând chei cu toate datele corespunzătoare. În a doua etapă, are loc sesiunea NTS protejată între client și serverul NTP.

Cum a devenit sincronizarea timpului sigură

NTS este compus din două protocoale de nivel inferior: Network Time Security Key Exchange (NTS-KE), care inițiază o conexiune sigură deasupra TLS, și NTPv4 — ultima versiune a protocolului NTP. Detalii suplimentare mai jos.

Primul pas — NTS KE

În această etapă, clientul NTP inițiază o sesiune TLS 1.2/1.3 printr-o conexiune TCP separată cu serverul NTS KE. În timpul acestei sesiuni se întâmplă următoarele.

  • Părțile definesc parametrii AEAD algoritmului pentru a doua etapă.
  • Părțile definesc al doilea protocol de nivel inferior, dar în acest moment doar NTPv4 este suportat.
  • Părțile definesc adresa IP și portul serverului NTP.
  • Serverul NTS KE emite cookie-uri pentru NTPv4.
  • Părțile extrag din material cookie o pereche de chei simetrice (C2S și S2C).

Această abordare are un mare avantaj, deoarece toată sarcina de transmitere a informațiilor sensibile ale parametrelor conexiunii revine unui protocol TLS verificat și de încredere. Astfel, nu mai este necesar să inventăm o bicicletă proprie pentru un handshak NTP sigur.

A doua etapă — NTP protejat de NTS

În a doua etapă, clientul sincronizează în mod sigur timpul cu serverul NTP. În acest scop, transmite patru extensii speciale (extension field) în structura pachetului NTPv4.

  • Unique Identifier Extension conține un nonce aleator pentru a preveni atacurile prin repetare.
  • NTS Cookie Extension conține unul dintre cookie-urile NTP disponibile clientului. Deoarece doar clientul deține cheile simetrice AAED C2S și S2C, serverul NTP trebuie să le extragă din materialul cookie.
  • NTS Cookie Placeholder Extension este un mod pentru client de a solicita cookie-uri suplimentare de la server. Această extensie este necesară pentru a evita ca răspunsul serverului NTP să fie mult mai lung decât cererea. Acest lucru ajută la prevenirea atacurilor de amplificare.
  • NTS Authenticator and Encrypted Extension Fields Extension conține algoritmul de criptare AAED cu cheia C2S, antetul NTP, timpii și EF menționați anterior ca date asociate. Fără această extensie, este posibil să se falsifice timpii.

Cum a devenit sincronizarea timpului sigură

După ce primește cererea de la client, serverul verifică autenticitatea pachetului NTP. Pentru aceasta, trebuie să decripteze cookie-ul, să extragă algoritmul AAED și cheile. După ce a verificat cu succes valabilitatea pachetului NTP, serverul răspunde clientului în următorul format.

  • Unique Identifier Extension este o copie a cererii clientului, o măsură împotriva atacurilor prin repetare.
  • NTS Cookie Extension oferă mai multe cookie-uri pentru continuarea sesiunii.
  • Extensia NTS Authenticator și câmpurile de extensie criptate conțin un șifru AEAD cu cheia S2C.

A doua strângere de mână poate fi repetată de mai multe ori, omisând prima etapă, deoarece fiecare cerere și răspuns oferă clientului cookie-uri suplimentare. Acest lucru oferă avantajul că operațiile TLS relativ consumatoare de resurse pentru calcul și transmitere a datelor PKI sunt împărțite între numărul de cereri repetate. Acest lucru este deosebit de util pentru cronometrul FPGA specializat, când întreaga funcționalitate principală poate fi ambalată în câteva funcții din domeniul criptografiei simetrice, transferând întregul stivă TLS pe un alt dispozitiv.

NTPSec

Care este particularitatea NTP? Deși autorul proiectului, Dave Mills, a încercat să documenteze cât mai bine codul său, rar un programator reușește să se descurce în imprevizibilitatea algoritmilor de sincronizare a timpului de acum 35 de ani. O parte din cod a fost scrisă înainte de epoca POSIX, iar API-ul Unix de atunci se deosebea semnificativ de cel utilizat astăzi. În plus, sunt necesare cunoștințe de statistică pentru a curăța semnalele de zgomotele de pe liniile aglomerate.

NTS nu a fost prima încercare de a remedia NTP. După ce atacatorii au învățat să exploateze vulnerabilitățile NTP pentru a amplifica atacurile DDoS, a devenit clar că sunt necesare schimbări radicale. În timp ce schițele NTS erau pregătite și perfecționate, National Science Foundation din Statele Unite a acordat, la sfârșitul anului 2014, un grant urgent pentru modernizarea NTP.

Grupul de lucru a fost condus de nimeni altul decât Eric Steven Raymond — unul dintre fondatorii și pilonii comunității Open Source și autor al cărții Katedrala și Bazarul. Primul lucru pe care Eric și colegii săi au încercat să-l facă a fost să migreze codul NTP de pe platforma BitKeeper pe git, dar nu a fost așa simplu. Liderul proiectului, Harlan Stenn, s-a opus acestei soluții, iar negocierile au intrat într-un impas. Atunci s-a decis să se fork-eze codul proiectului, ceea ce a dus la apariția NTPSec.

Experiența solidă, inclusiv munca la GPSD, fundamentele matematice și abilitatea magică de a citi codul vechi — Eric Raymond a fost exact hackerul care putea duce un astfel de proiect la bun sfârșit. În echipă s-a găsit un specialist în migrarea codului și în doar 10 săptămâni NTP s-a stabilitpe GitLab. Munca a început cu entuziasm.

Echipa lui Eric Raymond a abordat problema la fel cum Auguste Rodin lucra cu un bloc de piatră. Eliminând 175 KLOC de cod vechi, au reușit să reducă semnificativ suprafața de atac, închizând numeroase breșe de securitate.

Iată o listă parțială a celor afectați:

  • Referințe într-documentate, învechite, depășite sau defecte.
  • Bibliotecă ICS neutilizată.
  • libopts/autogen.
  • Cod vechi pentru Windows.
  • ntpdc.
  • Autokey.
  • Codul C pentru ntpq a fost rescris în Python.
  • Codul C pentru sntp/ntpdig a fost rescris în Python.

Pe lângă curățarea codului, proiectul a avut și alte sarcini. Iată o listă incompletă a realizărilor:

  • Protecția codului împotriva depășirii bufferului a fost semnificativ întărită. Pentru a preveni depășirea bufferului, toate funcțiile de șir nesigure (strcpy / strcat / strtok / sprintf / vsprintf / gets) au fost înlocuite cu versiuni sigure, care implementează restricții de dimensiune a bufferului.
  • S-a adăugat suport pentru NTS.
  • Precizia pasului de timp a fost mișcată de zece ori prin legarea echipamentului fizic. Aceasta se datorează faptului că ceasurile computerizate moderne au devenit mult mai precise decât cele de la începuturile NTP. Cel mai mult au beneficiat GPSDO și stațiile radio de timp dedicate.
  • Numărul de limbaje de programare a fost redus la două. În loc de scripturi Perl, awk și chiar S, acum totul este Python. Acest lucru oferă mai multe oportunități de reutilizare a codului.
  • În loc de haosul scripturilor autotools, proiectul a început să utilizeze un sistem de construire a software-ului. waf.
  • Documentația proiectului a fost actualizată și reorganizată. Dintr-o colecție contradictorie și în multe locuri învechită de documente, s-a creat o documentație acceptabilă. Fiecare opțiune de linie de comandă și fiecare entitate de configurare are acum o versiune unică a adevărului. În plus, paginile manualului și documentația web sunt acum generate din aceleași fișiere de bază.

NTPSec este disponibil pentru o serie de distribuții Linux. În prezent, ultima versiune stabilă este 1.1.8, iar pentru Gentoo Linux — versiunea precedentă.

(1:696)$ sudo emerge -av ntpsec
Acestea sunt pachetele care ar fi integrate, în ordine:
Calculând dependențele... gata!
[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 pachet (1 reinstalare), Dimensiunea descărcărilor: 0 KiB
Doriți să îmbinați aceste pachete? [Da/Nu]

Chrony

A mai fost o încercare de a înlocui vechiul NTP cu un analog mai sigur. Chrony, spre deosebire de NTPSec, este scris de la zero și este conceput pentru a funcționa fiabil într-o gamă largă de condiții, inclusiv conexiuni de rețea instabile, disponibilitate parțială sau suprasarcini ale rețelei și schimbări de temperatură. În plus, chrony are și alte avantaje:

  • chrony poate sincroniza mai rapid ceasurile sistemului cu o precizie mai mare;
  • chrony este mai mic, consumă mai puțină memorie și accesează procesorul doar atunci când este necesar. Acest lucru este un mare avantaj pentru economisirea resurselor și energiei;
  • chrony suportă marcajele de timp la nivel hardware în Linux, asigurând o sincronizare extrem de precisă în rețelele locale.

Cu toate acestea, chrony nu dispune de unele funcționalități ale vechiului NTP, cum ar fi clientul/serverul de broadcast și multicast. În plus, NTP clasic suportă un număr mai mare de sisteme de operare și platforme.

Pentru a dezactiva funcționalitatea serverului și cererile NTP către procesul chronyd, este suficient să specificați port 0 în fișierul chrony.conf. Aceasta se face în cazurile în care nu este necesar să se furnizeze timpul pentru clienții NTP sau noduri peer. Începând cu versiunea 2.0, portul serverului NTP este deschis doar atunci când accesul este permis prin directiva allow sau comanda corespunzătoare, ori când un nod peer NTP este configurat, sau se utilizează directiva broadcast.

Programul constă din două module.

  • chronyd — un serviciu care rulează în fundal. El primește informații despre diferența ceasurilor sistemului față de un server extern de timp și corectează timpul local. De asemenea, implementează protocolul NTP și poate acționa ca client sau server.
  • chronyc — o unealtă de linie de comandă pentru monitorizarea și controlul programului. Este folosită pentru a ajusta diverse setări ale serviciului, de exemplu, permite adăugarea sau eliminarea serverelor NTP în timp ce chronyd continuă să funcționeze.

Începând cu versiunea 7 a RedHat Linux folosește chrony ca serviciu de sincronizare a timpului. Pachetul este disponibil și pentru celelalte distribuții Linux. Ultima versiune stabilă este 3.5, iar v4.0 este planificată pentru lansare.

(1:712)$ sudo emerge -av chrony
Acestea sunt pachetele care ar fi fuzionate, în ordine:
Calculând dependențele... gata!
[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 pachet (1 nou, 1 binar), Dimensiunea descărcărilor: 246 KiB
Doriți să fuzionați aceste pachete? [Da/Nu]

Cum să configurezi un server de sincronizare a timpului cron pentru internet, destinat rețelei de birou. Iată un exemplu de configurație pe VPS.

Exemplu de configurare a Chrony pe RHEL / CentOS pe VPS

Hai să ne antrenăm puțin și să ridicăm propriul nostru server NTP pe VPS. Este foarte simplu, trebuie doar să alegi un plan potrivit pe site-ul RuVDS, să obții un server gata configurat și să execuți o duzină de comenzi simple. Pentru scopurile noastre, această variantă este suficientă.

Cum a devenit sincronizarea timpului sigură

Trecem la configurarea serviciului și, prima dată, instalăm pachetul chrony.

[root@server ~]$ yum install chrony

RHEL 8 / CentOS 8 folosesc un alt manager de pachete.

[root@server ~]$ dnf install chrony

După instalarea chrony, trebuie să pornești și să activezi serviciul.

[root@server ~]$ systemctl enable chrony --now

Dacă dorești, poți face modificări în /etc/chrony.conf, înlocuind serverele NPT cu cele mai apropiate locale pentru a reduce timpul de răspuns.

# 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

Apoi, configurăm sincronizarea serverului NTP cu nodurile din poolul specificat.

[root@server ~]$ timedatectl set-ntp true
[root@server ~]$ systemctl restart chronyd.service

De asemenea, trebuie să deschizi portul NTP, altfel firewall-ul va bloca conexiunile externe de la nodurile client.

[root@server ~]$ firewall-cmd --add-service=ntp --permanent 
[root@server ~]$ firewall-cmd --reload

Din partea clientului, este suficient să setezi corect fusul orar.

[root@client ~]$ timedatectl set-timezone Europe/Moscow

În fișierul /etc/chrony.conf, indică IP-ul sau numele gazdei VPS-ului nostru, pe care rulează serverul NTP chrony.

server my.vps.server

Și în final, pornește sincronizarea timpului pe client.

[root@client ~]$ systemctl enable --now chronyd
[root@client ~]$ timedatectl set-ntp true

Data viitoare voi vorbi despre opțiunile de sincronizare a timpului fără internet.

Cum a devenit sincronizarea timpului sigură

Cum a devenit sincronizarea timpului sigură

Sursa: habr.com

Cumpără un hosting fiabil pentru site-uri cu protecție DDoS, servere VPS VDS 🔥 Cumpără un hosting fiabil pentru site-uri cu protecție DDoS, servere VPS VDS | ProHoster