🥇Hoe tijdsynchronisatie veilig werd

Hoe zorg je ervoor dat de tijd op zich niet ligt, als je een miljoen grote en kleine apparaten hebt die via TCP/IP communiceren? Want op elk van hen zijn er klokken, en de tijd moet op allemaal correct zijn. Dit probleem is zonder NTP niet op te lossen.

Stel je voor dat er in één segment van de industriële IT-infrastructuur problemen zijn met de synchronisatie van services op tijd. Onmiddellijk begint de clusterstack van de enterprise-software te falen, domeinen vallen uit elkaar, en de master- en standby-knooppunten proberen zonder succes de status quo te herstellen.

Er kan ook een situatie zijn waarin een aanvaller opzettelijk probeert de tijd te verstoren via een MiTM-aanval of een DDoS-aanval. In zo'n situatie kan er van alles gebeuren:

de geldigheid van gebruikersaccountwachtwoorden verloopt;
de geldigheid van X.509-certificaten verloopt;
twee-factorauthenticatie TOTP stopt met werken;
back-ups worden 'verouderd' en het systeem verwijdert ze;
DNSSec valt uit.

Het is duidelijk dat elke IT-afdeling geïnteresseerd is in een betrouwbare werking van tijdsynchronisatieservices, en het zou goed zijn als ze betrouwbaar en veilig zijn voor industriële toepassingen.

NTP in 25 minuten kraken

Netwerkprotocollen — millennials hebben één eigenschap, ze zijn al lang verouderd en totaal niet meer geschikt, maar ze vervangen is niet zo eenvoudig, zelfs niet wanneer er een kritische massa van enthousiastelingen en financiering is.

De belangrijkste klacht over klassiek NTP is het ontbreken van betrouwbare beschermingsmechanismen tegen aanvallen van kwaadwillenden. Er zijn verschillende pogingen ondernomen om dit probleem op te lossen. Eerst werd een mechanisme van vooraf ingestelde sleutels (PSK) geïmplementeerd voor de uitwisseling van symmetrische sleutels.

Helaas heeft deze methode zich niet bewezen om een eenvoudige reden: het schaalt slecht. Handmatige configuratie aan de clientzijde is nodig, afhankelijk van de server. Dit betekent dat je niet zomaar een extra client kunt toevoegen. Als er iets verandert op de NTP-server, moeten alle clients opnieuw worden ingesteld.

Toen werd AutoKey bedacht, maar er werden meteen een aantal ernstige kwetsbaarheden in het ontwerp van het algoritme ontdekt, waardoor men er vanaf moest zien. Het probleem is dat het initiële getal (seed) slechts 32 bits bevat, wat te klein is en niet voldoende rekenkundige complexiteit biedt voor een brute force-aanval.

Key ID — een symmetrische 32-bits sleutel;
MAC (message authentication code) — controlegetal van een NTP-pakket;

Autokey wordt als volgt berekend.

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

Waar H() — een cryptografische hash-functie is.

Voor de berekening van de controlegetal worden dezelfde functies voor pakketten gebruikt.

MAC=H(Autokey||NTP-pakket)

Hieruit blijkt dat de integriteit van pakketten afhankelijk is van de authenticiteit van cookies. Zodra iemand deze in handen krijgt, kan hij autokey herstellen en vervolgens MAC vervalsen. Echter, de NTP-server gebruikt een startgetal (seed) tijdens hun generatie. Dit is waar het probleem ligt.

Cookie=MSB_32(H(Client IP||Server IP||0||Server Seed))

De MSB_32-functie snijdt de 32 meest significante bits van het resultaat van de berekening van de MD5-hash af. De clientcookie verandert niet zolang de serverparameters onveranderd blijven. Daarna blijft het voor de aanvaller alleen nog maar over om het startgetal te herstellen en zelf cookies te genereren.

Eerst moet je verbinding maken met de NTP-server als client en cookies verkrijgen. Daarna kan de aanvaller door middel van brute force het startgetal herstellen volgens een eenvoudig algoritme.

Het aanvalsalgoritme voor het berekenen van het startgetal door brute force.

   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

De IP-adressen zijn bekend, dus het enige dat overblijft is om 2^32 hashes te creëren totdat de aangemaakte cookie overeenkomt met die van de NTP-server. Op een normale thuiscomputer met een Intel Core i5 kost dit ongeveer 25 minuten.

NTS — nieuwe Autokey

Het was onaanvaardbaar om zulke gaten in de beveiliging van Autokey te laten bestaan, en in 2012 verscheen nieuwe versie de protocollen. Om de gecompromitteerde naam te verhelpen, werd besloten tot rebranding, waardoor Autokey v.2 werd omgedoopt tot Network Time Security.

Het NTS-protocol is een veilige uitbreiding van NTP en ondersteunt momenteel alleen unicast-modus. Het biedt sterke cryptografische bescherming tegen manipulatie van pakketten, voorkomt tracking, schaalt goed, is resistent tegen verlies van netwerkpakketten en leidt tot de minste precisieverliezen tijdens het beveiligen van de verbinding.

Het NTS-verbinding bestaat uit twee fasen, waarin gebruik wordt gemaakt van protocollen op een lager niveau. In de eerste fase komen client en server overeen over verschillende verbindingsparameters en wisselen cookies uit die sleutels en bijbehorende gegevens bevatten. In de tweede fase vindt de eigenlijke beveiligde NTS-sessie plaats tussen de client en de NTP-server.

NTS bestaat uit twee laag-niveau protocollen: Network Time Security Key Exchange (NTS-KE), welke een veilige verbinding initieert bovenop TLS, en NTPv4 - de laatste versie van het NTP-protocol. Iets meer informatie hierover volgt hieronder.

Eerste fase - NTS KE

In deze fase initieert de NTP-client een TLS 1.2/1.3 sessie via een aparte TCP-verbinding met de NTS KE-server. Tijdens deze sessie gebeurt het volgende.

De partijen bepalen de parameters AEAD van het algoritme voor de tweede fase.
De partijen bepalen het tweede laag-niveau protocol, maar momenteel wordt alleen NTPv4 ondersteund.
De partijen bepalen het IP-adres en de poort van de NTP-server.
De NTS KE-server verstrekt cookies onder NTPv4.
De partijen extraheren uit de cookies een paar symmetrische sleutels (C2S en S2C).

Deze aanpak heeft als groot voordeel dat de hele last van het verzenden van gevoelige informatie over de verbindingsparameters op een bewezen en betrouwbaar TLS-protocol rust. Hierdoor is er geen behoefte om een eigen systeem voor veilige NTP-handshaking uit te vinden.

Tweede fase - NTP onder bescherming van NTS

In de tweede fase synchroniseert de client veilig de tijd met de NTP-server. Hiervoor verzendt hij vier speciale extensies (extension field) in de structuur van het NTPv4-pakket.

Unique Identifier Extension bevat een willekeurige nonce om herhalingsaanvallen te voorkomen.
NTS Cookie Extension bevat een van de cookies die de client heeft. Aangezien alleen de client over de symmetrische AAED-sleutels C2S en S2C beschikt, moet de NTP-server deze uit de cookies extraheren.
NTS Cookie Placeholder Extension is een manier voor de client om extra cookies van de server aan te vragen. Deze extensie is nodig zodat het antwoord van de NTP-server niet veel langer is dan het verzoek. Dit helpt herhaling-aanvallen te voorkomen.
NTS Authenticator and Encrypted Extension Fields Extension bevat de cipher van het AAED-algoritme met de C2S-sleutel, de NTP-header, tijdstempels, en de eerder genoemde EF als aanvullende gegevens. Zonder deze extensie is het mogelijk om tijdstempels te vervalsen.

Na ontvangst van het verzoek van de client verifieert de server de authenticiteit van het NTP-pakket. Hiervoor moet hij de cookies ontsleutelen, het AAED-algoritme en de sleutels extraheren. Na een succesvolle validatie van het NTP-pakket reageert de server op de client in het volgende formaat.

Unique Identifier Extension is een spiegelbeeld van het verzoek van de client, als maatregel tegen herhalingsaanvallen.
NTS Cookie Extension meer cookies voor het voortzetten van de sessie.
NTS Authenticator en Encrypted Extension Fields Extension bevat een AEAD-codering met een S2C-sleutel.

De tweede handshake kan meerdere keren worden herhaald, waarbij de eerste fase kan worden overgeslagen, omdat elke aanvraag en reactie extra cookies aan de klant geeft. Dit heeft het voordeel dat de relatief resource-intensievere TLS-operaties voor het berekenen en verzenden van PKI-gegevens worden verdeeld over het aantal herhaalde aanvragen. Dit is vooral handig voor gespecialiseerde FPGA-timers, wanneer de gehele kernfunctionaliteit in een paar functies van symmetrische cryptografie kan worden verpakt, terwijl de gehele TLS-stack naar een ander apparaat wordt overgebracht.

NTPSec

Wat is de bijzonderheid van NTP? Ondanks dat de auteur van het project, Dave Mills, zijn code zo goed mogelijk heeft gedocumenteerd, zal zelden een programmeur in staat zijn om de ingewikkeldheden van 35 jaar oude tijdsynchronisatie-algoritmen te doorgronden. Een deel van de code is geschreven vóór de POSIX-epoche en de Unix-API verschilde toen sterk van wat tegenwoordig wordt gebruikt. Bovendien zijn statistische kennis en vaardigheden nodig om het signaal van ruis te zuiveren op rumoerige lijnen.

NTS was niet de eerste poging om NTP te repareren. Nadat aanvallers het gebruik van NTP-kwetsbaarheden voor DDoS-aanvallen hadden geleerd, werd het duidelijk dat er radicale veranderingen nodig waren. En terwijl de concepten van NTS werden voorbereid en verfijnd, heeft de National Science Foundation van de VS eind 2014 snel een subsidie toegewezen voor de modernisering van NTP.

De werkgroep werd geleid door niemand minder dan Eric Steven Raymond — een van de oprichters en pijlers van de Open Source-gemeenschap en auteur van het boek The Cathedral and the Bazaar. Als eerste probeerde Eric met zijn collega's de NTP-code van het BitKeeper-platform naar git te migreren, maar dat lukte niet. De projectleider Harlan Stenn was tegen deze beslissing en de gesprekken kwamen tot stilstand. Toen werd besloten de code van het project te fork, wat resulteerde in de oprichting van NTPSec.

Met een solide ervaring, waaronder werk aan GPSD, een wiskundige achtergrond en de magische vaardigheid om oude code te lezen — Eric Raymond was precies de hacker die dit project kon omarmen. In het team was er een specialist op het gebied van code-migratie en binnen 10 weken was NTP gevestigdop GitLab. Het werk kwam op gang.

Het team van Eric Raymond ging te werk zoals Auguste Rodin met een blok steen. Door 175 KLOC oude code te verwijderen, slaagden ze erin de aanvalsvlak te verkleinen en veel beveiligingslekken te dichten.

Hier is een onvolledige lijst van de getroffen onderdelen:

Niet-gedocumenteerde, verouderde of gebroken refclock.
Ongebruikte ICS-bibliotheek.
libopts/autogen.
Oude code voor Windows.
ntpdc.
Autokey.
C-code van ntpq herschreven in Python.
C-code van sntp/ntpdig herschreven in Python.

Naast het opschonen van de code waren er ook andere taken voor het project. Hier is een onvolledige lijst van prestaties:

De beveiliging van de code tegen buffer overflow is aanzienlijk versterkt. Om buffer overflow te voorkomen, zijn alle onveilige stringfuncties (strcpy / strcat / strtok / sprintf / vsprintf / gets) vervangen door veilige versies die de grootte van de buffer beperken.
Ondersteuning voor NTS toegevoegd.
We hebben de precisie van de tijdstap met tienvoudig verhoogd door het gebruik van fysiek hardware. Dit komt omdat moderne computerklokken veel nauwkeuriger zijn dan die van het begin van NTP. Het meeste voordeel hebben GPSDO en gespecialiseerde tijdstations hiervan ondervonden.
Het aantal programmeertalen is teruggebracht tot twee. In plaats van Perl-, awk- en zelfs S-scripts, is het nu uitsluitend Python. Dit biedt meer mogelijkheden voor hergebruik van code.
In plaats van een wirwar van autotools-scripts is het project begonnen met het gebruik van een software-bouwsysteem. waf.
De documentatie van het project is bijgewerkt en heringericht. Van een tegenstrijdige en soms verouderde documentencollectie is een behoorlijk acceptabele documentatie gemaakt. Elke sleutel in de commandoregel en elke configuratie-eenheid heeft nu een uniforme waarheidsversie. Bovendien worden de handleidingen en webdocumentatie nu uit dezelfde basisbestanden gegenereerd.

NTPSec is beschikbaar voor verschillende Linux-distributies. Op dit moment is de laatste stabiele versie 1.1.8, voor Gentoo Linux is het de op één na laatste.

(1:696)$ sudo emerge -av ntpsec
Dit zijn de pakketten die samengevoegd zouden worden, in volgorde:
Afhankelijkheden berekenen... gedaan!
[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
Totaal: 1 pakket (1 herinstallatie), Grootte van downloads: 0 KiB
Wilt u deze pakketten samenvoegen? [Ja/Nee]

Chrony

Er was nog een poging om de oude NTP te vervangen door een veiligere variant. Chrony is, in tegenstelling tot NTPSec, vanaf de grond opgebouwd en ontworpen voor betrouwbare werking onder een breed scala aan omstandigheden, waaronder onbetrouwbare netwerkverbindingen, gedeeltelijke beschikbaarheid of netwerklast en temperatuurschommelingen. Bovendien heeft chrony nog andere voordelen:

chrony kan de systeemklokken sneller synchroniseren met een grotere nauwkeurigheid;
chrony gebruikt minder geheugen en benadert de processor alleen wanneer dat nodig is. Dit is een groot pluspunt voor het besparen van bronnen en energie;
chrony ondersteunt hardware-timestamps in Linux, wat een uiterst nauwkeurige synchronisatie in lokale netwerken garandeert.

Echter, chrony mist enkele functies van de oude NTP, zoals breedband- en multicastclient/server. Bovendien ondersteunt de klassieke NTP een groter aantal besturingssystemen en platforms.

Om de functionaliteit van de server en NTP-verzoeken naar het chronyd-proces uit te schakelen, hoef je alleen maar 'port 0' in het chrony.conf-bestand op te nemen. Dit wordt gedaan in gevallen waarbij het niet nodig is om tijd voor NTP-clients of peer-nodes te bedienen. Vanaf versie 2.0 is de NTP-serverpoort alleen geopend als toegang is toegestaan via de 'allow'-richtlijn of een bijbehorende opdracht, of als een NTP-peer-node is ingesteld, of de 'broadcast'-richtlijn wordt gebruikt.

Het programma bestaat uit twee modules.

chronyd is een service die op de achtergrond draait. Het ontvangt informatie over het verschil tussen de systeemklokken en een externe tijdserver en past de lokale tijd aan. Het implementeert ook het NTP-protocol en kan fungeren als een client of server.
chronyc is een opdrachtregelprogramma voor het monitoren en beheren van het programma. Het wordt gebruikt voor het fijn afstemmen van verschillende parameters van de service, bijvoorbeeld om NTP-servers toe te voegen of te verwijderen terwijl chronyd blijft draaien.

Vanaf versie 7 van RedHat Linux gebruikt is chrony een tijdsynchronisatieservice. Het pakket is ook beschikbaar voor andere Linux-distributies. De laatste stabiele versie is 3.5, versie 4.0 is in aantocht.

(1:712)$ sudo emerge -av chrony
Dit zijn de pakketten die in volgorde zullen worden samengevoegd:
Afhankelijkheden berekenen... gedaan!
[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
Totaal: 1 pakket (1 nieuw, 1 binair), downloadgrootte: 246 KiB
Wil je deze pakketten samenvoegen? [Ja/Nee]

Hoe je een eigen chrony-remote server op het internet instelt voor tijdsynchronisatie in je kantoor netwerk. Hieronder een voorbeeld van de configuratie op VPS.

Voorbeeld van het instellen van Chrony op RHEL / CentOS op VPS

Laten we nu wat oefenen en onze eigen NTP-server op VPS opzetten. Dat is heel eenvoudig, je hoeft alleen maar het juiste tarief op de website RuVDS te kiezen, een kant-en-klare server te krijgen en een tiental eenvoudige commando's in te voeren. Voor onze doeleinden is deze optie prima.

We gaan verder met het configureren van de service en de eerste stap is om het chrony-pakket te installeren.

[root@server ~]$ yum install chrony

RHEL 8 / CentOS 8 gebruiken een andere pakketbeheerder.

[root@server ~]$ dnf install chrony

Na de installatie van chrony moet je de service starten en activeren.

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

Als je wilt, kun je wijzigingen aanbrengen in /etc/chrony.conf door de NTP-servers te vervangen door de dichtstbijzijnde lokale om de responstijd te verkorten.

# 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

Vervolgens configureren we de synchronisatie van de NTP-server met de knooppunten uit de vermelde pool.

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

Je moet ook de NTP-poort openstellen, anders blokkeert de firewall binnenkomende verbindingen van de clientknopen.

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

Aan de clientzijde is het voldoende om de tijdzone correct in te stellen.

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

In het bestand /etc/chrony.conf geef je het IP of de hostnaam van onze VPS-server op waarop de NTP-server chrony draait.

server my.vps.server

En tot slot starten we de tijdsynchronisatie aan de clientzijde.

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

Volgende keer zal ik vertellen welke opties er zijn voor tijdsynchronisatie zonder internet.

Bron: habr.com