🥇Hoe tijdsynchronisatie veilig werd

Hoe zorg je ervoor dat de tijd niet stagneert als je een miljoen grote en kleine apparaten via TCP/IP met elkaar laat communiceren? Ze hebben immers allemaal hun eigen klok en op alle klokken moet de tijd kloppen. Dit probleem kan niet worden omzeild zonder ntp.

Stel je voor dat één segment van de industriële IT-infrastructuur in de loop van de tijd moeite heeft met het synchroniseren van services. De clusterstack van de bedrijfssoftware begint onmiddellijk te falen, domeinen vallen uit elkaar en masters en standby-knooppunten proberen tevergeefs de status quo te herstellen.

Het is ook mogelijk dat een aanvaller opzettelijk de tijd probeert te resetten via een MiTM- of DDOS-aanval. In zo'n situatie kan er van alles gebeuren:

wachtwoorden van gebruikersaccounts verlopen;
X.509-certificaten verlopen;
TOTP-tweefactorauthenticatie werkt niet meer;
back-ups raken ‘verouderd’ en het systeem verwijdert ze;
DNSSec zal kapot gaan.

Het is duidelijk dat elke IT-afdeling belang heeft bij een betrouwbare werking van tijdsynchronisatieservices. Het zou dan ook mooi zijn als deze betrouwbaar en veilig zouden zijn in industriële toepassingen.

NTP in 25 minuten doorbreken

Netwerkprotocollen - millennials hebben één ding gemeen: ze zijn al lang verouderd en zijn nergens meer goed voor, maar ze vervangen is niet zo eenvoudig, zelfs niet als er een kritische massa aan enthousiastelingen en financiering is.

De voornaamste klacht over klassieke NTP is het gebrek aan betrouwbare mechanismen voor bescherming tegen kwaadaardige aanvallen. Er zijn verschillende pogingen gedaan om dit probleem op te lossen. Om dit te realiseren werd voor het eerst een PSK-mechanisme (Pre-Shared Key) geïntroduceerd om symmetrische sleutels uit te wisselen.

Helaas bleek deze methode niet te werken, om een eenvoudige reden: ze is niet goed schaalbaar. Afhankelijk van de server is handmatige configuratie aan de clientzijde vereist. Dit betekent dat je niet zomaar een nieuwe klant kunt toevoegen. Als er iets op de NTP-server verandert, moeten alle clients opnieuw worden geconfigureerd.

Vervolgens bedachten ze AutoKey, maar er werden direct een aantal ernstige kwetsbaarheden in het algoritmeontwerp ontdekt en het moest worden opgegeven. Het probleem is dat de seed slechts 32 bits groot is. Dat is te klein en bevat niet genoeg rekenkracht voor een brute-force-aanval.

Key ID is een symmetrische 32-bits sleutel;
MAC (Message Authentication Code) — controlegetal van NTP-pakket;

Autokey wordt als volgt berekend.

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

Waarbij H() een cryptografische hashfunctie is.

Dezelfde functie wordt gebruikt om de controlesom van het pakket te berekenen.

MAC=H(Autokey||NTP packet)

Het blijkt dat de volledige integriteit van pakketcontroles afhangt van de authenticiteit van de koekjes. Zodra u ze hebt, kunt u de autokey herstellen en vervolgens de MAC vervalsen. De NTP-server gebruikt echter een seed bij het genereren ervan. Hier zit hem het probleem.

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

De MSB_32-functie verwijdert de 5 meest significante bits uit het resultaat van de berekening van de md32-hash. De clientcookie verandert niet zolang de serverinstellingen ongewijzigd blijven. Het enige wat de aanvaller dan nog hoeft te doen, is het oorspronkelijke aantal herstellen en de mogelijkheid verkrijgen om zelfstandig cookies te genereren.

Eerst moet u als client verbinding maken met de NTP-server en de cookie ophalen. Hierna gebruikt de aanvaller brute force om het oorspronkelijke aantal te herstellen met behulp van een eenvoudig algoritme.

Een algoritme voor het aanvallen van het beginnummer met behulp van de brute-forcemethode.

   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 nog resteert is het aanmaken van 2^32 hashes totdat de gegenereerde cookie overeenkomt met de cookie die is ontvangen van de NTP-server. Op een typische thuiswerkplek met een Intel Core i5 duurt dit 25 minuten.

NTS — nieuwe Autokey

Het was onmogelijk om zulke beveiligingslekken in Autokey te tolereren, en in 2012, nieuwe versie protocol. Om de naam te compromitteren, besloten ze Autokey v.2 een nieuwe naam te geven: Network Time Security.

Het NTS-protocol is een beveiligingsuitbreiding van NTP en ondersteunt momenteel alleen de unicast-modus. Het biedt sterke cryptografische bescherming tegen pakketmanipulatie, voorkomt snooping, is goed schaalbaar, is bestand tegen netwerkpakketverlies en resulteert in het laagste nauwkeurigheidsverlies bij het beveiligen van een verbinding.

De NTS-verbinding bestaat uit twee fasen, waarbij gebruik wordt gemaakt van protocollen op lager niveau. Op de eerste In deze fase komen de client en de server overeen wat betreft diverse verbindingsparameters en wisselen ze cookies uit die sleutels bevatten met alle bijbehorende datasets. Op tweede In deze fase vindt de daadwerkelijke beveiligde NTS-sessie plaats tussen de client en de NTP-server.

NTS bestaat uit twee protocollen op de onderste laag: Network Time Security Key Exchange (NTS-KE), dat een beveiligde verbinding via TLS initialiseert, en NTPv4, de nieuwste versie van het NTP-protocol. Meer hierover hieronder.

Eerste fase - NTS KE

In deze fase start 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 AED algoritme voor de tweede fase.
De partijen zijn bezig een tweede protocol op lager niveau te definiëren, maar op dit moment wordt alleen NTPv4 ondersteund.
De partijen bepalen het IP-adres en de poort van de NTP-server.
De NTS KE-server geeft cookies uit onder NTPv4.
De partijen halen een paar symmetrische sleutels (C2S en S2C) uit het cookiemateriaal.

Deze aanpak heeft het grote voordeel dat de volledige last van het verzenden van geheime verbindingsparameterinformatie op het beproefde en betrouwbare TLS-protocol rust. Hierdoor is het niet nodig om het wiel opnieuw uit te vinden voor een veilige NTP-handshake.

Fase 2 - NTP onder NTS-bescherming

In de tweede fase synchroniseert de client de tijd op een veilige manier met de NTP-server. Hiervoor bevat het vier speciale extensievelden in de NTPv4-pakketstructuur.

De Unique Identifier Extension bevat een willekeurige nonce om replay-aanvallen te voorkomen.
NTS Cookie Extension bevat een van de cookies die beschikbaar zijn voor de NTP-client. Omdat alleen de client over de symmetrische AAED-sleutels C2S en S2C beschikt, moet de NTP-server deze uit het cookiemateriaal halen.
Met de NTS Cookie Placeholder Extension kan een client extra cookies van de server opvragen. Deze uitbreiding is nodig om ervoor te zorgen dat het NTP-serverantwoord niet veel langer is dan de aanvraag. Hiermee worden amplificatieaanvallen voorkomen.
NTS Authenticator en Encrypted Extension Fields Extension bevat de AAED-algoritmecodering met C2S-sleutel, NTP-header, tijdstempels en de hierboven genoemde EF als bijbehorende gegevens. Zonder deze extensie is het mogelijk om tijdstempels te vervalsen.

Nadat een verzoek van de client is ontvangen, controleert de server de authenticiteit van het NTP-pakket. Om dit te doen, moet hij de cookies decoderen en het AAED-algoritme en de sleutels extraheren. Nadat de geldigheid van het NTP-pakket succesvol is gecontroleerd, reageert de server op de client in de volgende vorm.

Unieke Identifier Extension is een spiegelkopie van het clientverzoek, een maatregel tegen replay-aanvallen.
NTS Cookie Extension: meer cookies om de sessie voort te zetten.
NTS Authenticator en Encrypted Extension Fields Extension bevatten een AEAD-cijfer met een S2C-sleutel.

De tweede handdruk kan meerdere malen worden herhaald, waarbij de eerste fase wordt overgeslagen. Elk verzoek en elk antwoord levert de client namelijk extra cookies op. Dit heeft als voordeel dat de relatief resource-intensieve TLS-berekeningen en PKI-gegevensoverdrachtsbewerkingen worden verdeeld over een aantal herhaalde verzoeken. Dit is vooral handig voor gespecialiseerde FPGA-tijdwaarnemers, wanneer alle hoofdfunctionaliteit kan worden samengepakt in verschillende functies uit het veld van symmetrische cryptografie, waarbij de volledige TLS-stack naar een ander apparaat wordt overgebracht.

NTPSec

Wat is er speciaal aan NTP? Hoewel de auteur van het project, Dave Mills, zijn best heeft gedaan om zijn code zo goed mogelijk te documenteren, zal slechts een zeldzame programmeur in staat zijn om de complexiteit van de tijdsynchronisatiealgoritmes van 35 jaar geleden te begrijpen. Een deel van de code werd geschreven vóór het POSIX-tijdperk. De Unix API verschilde bovendien sterk van wat er tegenwoordig wordt gebruikt. Daarnaast is kennis van statistiek nodig om storingen op ruisige lijnen uit het signaal te verwijderen.

NTS was niet de eerste poging om NTP te repareren. Nadat aanvallers ontdekten hoe ze NTP-kwetsbaarheden konden misbruiken om DDoS-aanvallen te versterken, werd het duidelijk dat er radicale veranderingen nodig waren. Terwijl de concepten voor NTS werden voorbereid en afgerond, heeft de Amerikaanse National Science Foundation eind 2014 met spoed 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 de auteur van het boek Kathedraal en Bazaar. Het eerste wat Eric en zijn kameraden deden, was proberen de NTP-code van het BitKeeper-platform naar Git te verplaatsen, maar dat lukte niet. Projectleider Harlan Stenn was tegen dit besluit en de onderhandelingen liepen vast. Vervolgens werd besloten de projectcode te splitsen en zo ontstond NTPSec.

Met zijn solide achtergrond in onder meer GPSD, een achtergrond in wiskunde en het magische vermogen om eeuwenoude codes te lezen, was Eric Raymond de aangewezen hacker om een dergelijk project tot een goed einde te brengen. Het team vond een specialist in codemigratie en binnen slechts 10 weken was NTP klaar geregeldop GitLab. Het werk begon te koken.

Het team van Eric Raymond pakte de taak op dezelfde manier aan als Auguste Rodin een blok steen benaderde. Door 175 KLOC aan oude code te verwijderen, konden ze hun aanvalsoppervlak aanzienlijk verkleinen en veel beveiligingslekken dichten.

Hieronder vindt u een onvolledige lijst van de getroffenen:

Ongedocumenteerde, verouderde, achterhaalde of kapotte refclock.
Ongebruikte ICS-bibliotheek.
libopts/autogeen.
Oude code voor Windows.
ntpdc.
Automatische sleutel.
C-code ntpq herschreven in Python.
C-code sntp/ntpdig herschreven in Python.

Naast het opschonen van de code omvatte het project nog andere taken. Hier is een gedeeltelijke lijst van prestaties:

De codebeveiliging tegen bufferoverloop is aanzienlijk versterkt. Om bufferoverlopen te voorkomen, zijn alle onveilige tekenreeksfuncties (strcpy/strcat/strtok/sprintf/vsprintf/gets) vervangen door veilige versies die buffergroottebeperking implementeren.
NTS-ondersteuning toegevoegd.
Tien keer grotere nauwkeurigheid van tijdstappen door gebruik van fysieke hardwarebinding. Dit komt doordat moderne computerklokken tegenwoordig veel nauwkeuriger zijn dan de klokken die werden gebruikt toen NTP voor het eerst werd uitgevonden. De grootste begunstigden hiervan waren GPSDO en speciale radiotijdstations.
Het aantal programmeertalen is teruggebracht tot twee. In plaats van Perl, awk en zelfs S-scripts is het nu allemaal Python. Dit biedt meer mogelijkheden voor hergebruik van code.
In plaats van de noedels van autotools-scripts begon het project een softwarebouwsysteem te gebruiken waf.
De projectdocumentatie is bijgewerkt en gereorganiseerd. Uit een tegenstrijdige en hier en daar archaïsche verzameling documenten hebben ze een redelijk bruikbare documentatie samengesteld. Elke opdrachtregeloptie en elke configuratie-entiteit heeft nu één versie van de waarheid. Bovendien worden manpagina's en webdocumentatie nu gegenereerd vanuit dezelfde kernbestanden.

NTPSec is beschikbaar voor een aantal Linux-distributies. Op dit moment is de laatste stabiele versie 1.1.8, voor Gentoo Linux is dit de voorlaatste.

(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]

chronisch

Er werd nog een poging gedaan om de oude NTP te vervangen door een veiliger analoog apparaat. Chrony is, in tegenstelling tot NTPSec, vanaf nul geschreven en ontworpen om betrouwbaar te werken onder uiteenlopende omstandigheden, waaronder onstabiele netwerkverbindingen, gedeeltelijke of overbelaste netwerkbeschikbaarheid en temperatuurschommelingen. Daarnaast heeft chrony nog andere voordelen:

chrony kan de systeemklok sneller en nauwkeuriger synchroniseren;
chrony is kleiner, gebruikt minder geheugen en benadert de processor alleen als dat nodig is. Dit is een groot pluspunt voor het besparen van grondstoffen en energie;
chrony ondersteunt hardwaretijdstempels in Linux, waardoor uiterst nauwkeurige synchronisatie via lokale netwerken mogelijk is.

Chrony mist echter enkele oude NTP-functies, zoals broadcast en multicast client/server. Bovendien ondersteunt de klassieke NTP een breder scala aan besturingssystemen en platforms.

Om de serverfunctionaliteit en NTP-verzoeken naar het chronyd-proces uit te schakelen, voert u eenvoudigweg poort 0 in het bestand chrony.conf in. Dit wordt gedaan in gevallen waarbij er geen noodzaak is om de tijd voor NTP-clients of -peers bij te houden. Sinds versie 2.0 is de NTP-serverpoort alleen open wanneer toegang is toegestaan via de allow-richtlijn of de overeenkomstige opdracht, of wanneer er een NTP-peer is geconfigureerd, of wanneer 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 systeemklok en een externe tijdserver en past de lokale tijd hierop aan. Het implementeert ook het NTP-protocol en kan als client of server fungeren.
chronyc is een opdrachtregelhulpprogramma voor het bewaken en besturen van een programma. Wordt gebruikt om verschillende serviceparameters nauwkeurig af te stemmen, zoals het toevoegen of verwijderen van NTP-servers terwijl chronyd actief blijft.

Sinds RedHat Linux versie 7 toepassingen chrony als een tijdsynchronisatieservice. Het pakket is ook beschikbaar voor andere Linux-distributies. De laatste stabiele versie is 3.5, v4.0 wordt voorbereid voor release.

(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]

Hoe u uw eigen externe chronoy-server op internet instelt om de tijd in een kantoornetwerk te synchroniseren. Hieronder ziet u een voorbeeld van een installatie op een VPS.

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

Laten we nu een beetje oefenen en onze eigen NTP-server op een VPS instellen. Het is heel eenvoudig: selecteer een geschikt tarief op de RuVDS-website, selecteer een kant-en-klare server en voer een tiental eenvoudige opdrachten in. Deze optie is prima geschikt voor onze doeleinden.

Laten we verder gaan met het instellen van de service en eerst het chrony-pakket installeren.

[root@server ~]$ yum install chrony

RHEL 8 / CentOS 8 gebruikt een andere pakketbeheerder.

[root@server ~]$ dnf install chrony

Nadat u chrony hebt geïnstalleerd, moet u de service starten en activeren.

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

Indien gewenst, kunt u /etc/chrony.conf bewerken om NPT-servers te vervangen door de dichtstbijzijnde lokale servers om zo 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 knooppunten uit de opgegeven pool.

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

Het is ook nodig om de NTP-poort naar buiten te openen, anders blokkeert de firewall inkomende verbindingen van clientknooppunten.

[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

Geef in het bestand /etc/chrony.conf het IP-adres of de hostnaam op van onze VPS-server waarop de NTP-server chrony draait.

server my.vps.server

En tot slot start u de tijdsynchronisatie op de client.

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

De volgende keer vertel ik je welke mogelijkheden er zijn om de tijd te synchroniseren zonder internet.

Bron: www.habr.com

Hoe tijdsynchronisatie veilig werd