🥇Hur tidssynkronisering blev säker

Hur ser man till att tiden i sig inte ljuger när man har en miljon stora och små enheter som kommunicerar via TCP/IP? Trots allt har var och en av dem en klocka, och tiden måste vara korrekt på dem alla. Detta problem kan inte kringgås utan ntp.

Låt oss föreställa oss en minut att ett segment av industriell IT-infrastruktur har svårt att synkronisera tjänster över tid. Klusterstacken för företagsprogramvara börjar omedelbart fallera, domäner faller isär, master- och standby-noder försöker utan framgång återställa status quo.

Det är också möjligt att en angripare avsiktligt försöker återställa tiden genom en MiTM- eller DDOS-attack. I en sådan situation kan vad som helst hända:

lösenord för användarkonton kommer att upphöra att gälla;
X.509-certifikat kommer att upphöra att gälla;
TOTP tvåfaktorsautentisering kommer att sluta fungera;
säkerhetskopior blir "föråldrade" och systemet tar bort dem;
DNSSec kommer att gå sönder.

Det är tydligt att varje IT-avdelning är intresserad av tillförlitlig drift av tidssynkroniseringstjänster, och det vore bra om de var tillförlitliga och säkra i industriell drift.

Bryt NTP på 25 minuter

Nätverksprotokoll – millennials har en sak gemensamt: de har länge varit föråldrad och är inte längre bra för någonting, men att ersätta dem är inte så lätt även när en kritisk massa av entusiaster och finansiering har vunnits.

Det huvudsakliga klagomålet mot klassisk NTP är bristen på tillförlitliga mekanismer för skydd mot skadliga attacker. Olika försök har gjorts för att lösa detta problem. För att uppnå detta introducerades först en mekanism för fördelad nyckel (PSK) för att utbyta symmetriska nycklar.

Tyvärr rättfärdigade sig inte denna metod av en enkel anledning - den skalar inte bra. Manuell konfiguration krävs på klientsidan beroende på servern. Det betyder att du inte bara kan lägga till en annan klient på det sättet. Om något ändras på NTP-servern måste alla klienter konfigureras om.

Sedan kom de på AutoKey, men omedelbart upptäcktes ett antal allvarliga sårbarheter i själva algoritmdesignen och den fick överges. Problemet är att fröet bara är 32 bitar, vilket är för litet och inte innehåller tillräckligt med beräkningskomplexitet för en brute force-attack.

Nyckel-ID är en symmetrisk 32-bitarsnyckel;
MAC (meddelandeautentiseringskod) — kontrollsumma för NTP-paket;

Autokey beräknas enligt följande.

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

Där H() är en kryptografisk hashfunktion.

Samma funktion används för att beräkna paketets kontrollsumma.

MAC=H(Autokey||NTP packet)

Det visar sig att hela integriteten hos paketkontroller vilar på cookies äkthet. När du väl har dem kan du återställa autonyckeln och sedan förfalska MAC-koden. NTP-servern använder dock ett frö (seed) när den genererar dem. Det är här haken ligger.

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

Funktionen MSB_32 tar bort 5 av de mest signifikanta bitarna från resultatet av beräkningen av md32-hashen. Klientkakan ändras inte så länge serverinställningarna förblir oförändrade. Allt som återstår för angriparen att göra är att återställa det ursprungliga numret och få möjligheten att generera cookies självständigt.

Först måste du ansluta till NTP-servern som klient och hämta cookien. Efter detta använder angriparen brute force för att återställa det ursprungliga numret enligt en enkel algoritm.

En algoritm för att attackera det initiala talet med hjälp av brute force-metoden.

   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

IP-adresserna är kända, så allt som återstår är att skapa 2^32 hashvärden tills den genererade cookien matchar den som tas emot från NTP-servern. På en typisk hemmaarbetsstation med en Intel Core i5 tar detta 25 minuter.

NTS — ny Autokey

Det var omöjligt att åtgärda sådana säkerhetshål i Autokey, och år 2012, en ny version protokoll. För att kompromissa med namnet bestämde de sig för att byta namn, så Autokey v.2 fick namnet Network Time Security.

NTS-protokollet är en säkerhetsutökning av NTP och stöder för närvarande endast unicast-läge. Den ger starkt kryptografiskt skydd mot paketmanipulation, förhindrar snokning, skalar bra, är motståndskraftig mot nätverkspaketförlust och resulterar i den lägsta noggrannhetsförlusten i processen att säkra en anslutning.

NTS-anslutningen består av två steg, där protokoll på lägre nivå används. På den första I detta skede kommer klienten och servern överens om olika anslutningsparametrar och utbyter cookies som innehåller nycklar med all tillhörande datamängd. På andra I detta skede sker den faktiska säkra NTS-sessionen mellan klienten och NTP-servern.

NTS består av två protokoll på lägre nivåer: Network Time Security Key Exchange (NTS-KE), som initierar en säker anslutning via TLS, och NTPv4, den senaste versionen av NTP-protokollet. Mer om detta nedan.

Första etappen - NTS KE

I detta skede initierar NTP-klienten en TLS 1.2/1.3-session över en separat TCP-anslutning till NTS KE-servern. Under denna session händer följande.

Parterna bestämmer parametrarna BORT algoritm för det andra steget.
Parterna definierar ett andra protokoll på lägre nivå, men för närvarande stöds endast NTPv4.
Parterna bestämmer IP-adressen och porten för NTP-servern.
NTS KE-servern utfärdar cookies under NTPv4.
Parterna extraherar ett par symmetriska nycklar (C2S och S2C) från cookiematerialet.

Denna metod har en stor fördel i det att hela bördan av att överföra information om hemliga anslutningsparametrar faller på det beprövade och pålitliga TLS-protokollet. Detta eliminerar behovet av att uppfinna hjulet på nytt för en säker NTP-handskakning.

Steg 2 - NTP under NTS-skydd

I det andra steget synkroniserar klienten tiden säkert med NTP-servern. För detta ändamål bär den fyra speciella tilläggsfält i NTPv4-paketstrukturen.

Unique Identifier Extension innehåller en slumpmässig nonce för att förhindra replay-attacker.
NTS Cookie Extension innehåller en av de cookies som är tillgängliga för NTP-klienten. Eftersom endast klienten har de symmetriska AAED-nycklarna C2S och S2C, måste NTP-servern extrahera dem från cookiematerialet.
NTS Cookie Placeholder Extension är ett sätt för en klient att begära ytterligare cookies från servern. Denna tillägg är nödvändig för att säkerställa att NTP-serverns svar inte är mycket längre än begäran. Detta hjälper till att förhindra förstärkningsattacker.
NTS Authenticator och Encrypted Extension Fields Extension innehåller AAED-algoritmchiffern med C2S-nyckel, NTP-rubrik, tidsstämplar och ovan nämnda EF som medföljande data. Utan detta tillägg är det möjligt att förfalska tidsstämplar.

Efter att ha mottagit en begäran från klienten kontrollerar servern äktheten hos NTP-paketet. För att göra detta måste han dekryptera cookies, extrahera AAED-algoritmen och nycklarna. Efter att NTP-paketet har kontrollerats för giltighet svarar servern klienten i följande format.

Unique Identifier Extension är en spegelkopia av klientbegäran, en åtgärd mot replay-attacker.
NTS Cookie Extension fler cookies för att fortsätta sessionen.
NTS Authenticator och Encrypted Extension Fields Extension innehåller en AEAD-chiffer med en S2C-nyckel.

Det andra handskakningssteget kan upprepas många gånger, och kringgå det första steget, eftersom varje begäran och svar ger klienten ytterligare cookies. Detta har fördelen att de relativt resurskrävande TLS-beräkningarna och PKI-dataöverföringsoperationerna är uppdelade i ett antal upprepade förfrågningar. Detta är särskilt bekvämt för specialiserade FPGA-tidshållare, när all huvudfunktionalitet kan packas i flera funktioner från området symmetrisk kryptografi, vilket överför hela TLS-stacken till en annan enhet.

NTPSec

Vad är speciellt med NTP? Trots att projektets författare Dave Mills försökte dokumentera sin kod så bra som möjligt, kommer en sällsynt programmerare att kunna förstå invecklingen i tidssynkroniseringsalgoritmerna för 35 år sedan. En del av koden skrevs före POSIX-eran, och Unix API var väldigt annorlunda än vad som används idag. Dessutom krävs kunskap om statistik för att rensa signalen från störningar på brusiga linjer.

NTS var inte det första försöket att fixa NTP. Efter att angripare lärt sig att utnyttja NTP-sårbarheter för att förstärka DDoS-attacker, blev det tydligt att radikala förändringar behövdes. Och medan utkasten till NTS förbereddes och slutfördes, beviljade den amerikanska National Science Foundation snarast ett bidrag för modernisering av NTP i slutet av 2014.

Arbetsgruppen leddes av ingen mindre än Eric Steven Raymond — en av grundarna och stöttepelarna i öppen källkodsgemenskapen och författaren till boken Katedral och basar. Det första Eric och hans kamrater gjorde var att försöka flytta NTP-koden från BitKeeper-plattformen till git, men det fungerade inte så. Projektledaren Harlan Stenn var emot detta beslut och förhandlingarna hamnade i en återvändsgränd. Man beslutade sedan att forka projektkoden, och det var så NTPSec uppstod.

Med en gedigen bakgrund inom bland annat GPSD, matematik och en magisk förmåga att läsa uråldrig kod var Eric Raymond precis rätt hackare för att genomföra ett sådant projekt. Teamet hittade en specialist på kodmigrering och på bara 10 veckor NTP fastpå GitLab. Arbetet började koka.

Eric Raymonds team närmade sig uppgiften på samma sätt som Auguste Rodin skulle ha närmat sig ett stenblock. Genom att ta bort 175 KLOC gammal kod kunde de avsevärt minska attackytan och stänga många säkerhetshål.

Här är en ofullständig lista över de drabbade:

Odokumenterad, föråldrad, utdaterad eller trasig refclock.
Oanvänt ICS-bibliotek.
libopts/autogen.
Gammal kod för Windows.
ntpdc.
Autonyckel.
C-kod ntpq omskriven i Python.
C-kod sntp/ntpdig omskriven i Python.

Förutom kodrensning hade projektet andra uppgifter. Här är en ofullständig lista över prestationer:

Avsevärt förstärkt kodskydd mot buffertöverflöde. För att förhindra buffertöversvämningar har alla osäkra strängfunktioner (strcpy/strcat/strtok/sprintf/vsprintf/gets) ersatts med säkra versioner som implementerar begränsning av buffertstorlek.
Lade till NTS-stöd.
Ökad tidsstegsnoggrannhet tiofaldigt genom att använda fysisk hårdvarubindning. Detta beror på att moderna datorklockor har blivit mycket mer exakta än de som fanns på plats när NTP först uppfanns. De som gynnades mest av detta var GPSDO och dedikerade radiotidsstationer.
Antalet programmeringsspråk har minskats till två. Istället för Perl, awk och till och med S-skript är det nu allt Python. Detta möjliggör större möjligheter för återanvändning av kod.
Istället för allt från Autotools-skript började projektet använda ett system för mjukvarubyggande. WAF.
Uppdaterade och omorganiserade projektdokumentationen. Från en motsägelsefull och bitvis arkaisk samling av dokument skapade de ganska godkänd dokumentation. Varje kommandoradsväxel och varje konfigurationsenhet har nu en enda version av sanningen. Dessutom genereras nu manualsidor och webbdokumentation från samma kärnfiler.

NTPSec är tillgängligt för ett antal Linuxdistributioner. För närvarande är den senaste stabila versionen 1.1.8, för Gentoo Linux är det den näst sista.

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

Chrony

Det gjordes ytterligare ett försök att ersätta den gamla NTP:n med en säkrare analog. Till skillnad från NTPSec är Chrony skrivet från grunden och utformat för att fungera tillförlitligt under en mängd olika förhållanden, inklusive instabila nätverksanslutningar, partiell eller överbelastad nätverkstillgänglighet och temperaturförändringar. Dessutom har chrony andra fördelar:

chrony kan synkronisera systemklockan snabbare och med större noggrannhet;
chrony är mindre, använder mindre minne och använder bara processorn när det behövs. Detta är ett stort plus för att spara resurser och energi;
chrony stöder hårdvarutidsstämplar i Linux, vilket möjliggör extremt noggrann synkronisering över lokala nätverk.

Chrony saknar dock några av de gamla NTP-funktionerna som broadcast och multicast-klient/server. Dessutom stöder klassisk NTP ett bredare utbud av operativsystem och plattformar.

För att inaktivera serverfunktionen och NTP-förfrågningar till chronyd-processen, ange helt enkelt port 0 i chrony.conf-filen. Detta görs i fall där det inte finns något behov av att hålla tid för NTP-klienter eller kollegor. Sedan version 2.0 är NTP-serverporten endast öppen när åtkomst tillåts av allow-direktivet eller motsvarande kommando, eller när en NTP-peer är konfigurerad, eller när broadcast-direktivet används.

Programmet består av två moduler.

chronyd är en tjänst som körs i bakgrunden. Den tar emot information om skillnaden mellan systemklockan och en extern tidsserver och justerar den lokala tiden. Den implementerar också NTP-protokollet och kan fungera som en klient eller server.
chronyc är ett kommandoradsverktyg för att övervaka och styra ett program. Används för att finjustera olika tjänsteparametrar, till exempel att låta dig lägga till eller ta bort NTP-servrar medan chronyd fortsätter att köras.

Sedan RedHat Linux version 7 användningsområden chrony som en tidssynkroniseringstjänst. Paketet är även tillgängligt för andra Linuxdistributioner. Den senaste stabila versionen är 3.5, v4.0 förbereds för 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]

Hur man konfigurerar sin egen fjärranslutna Chrony-server på internet för att synkronisera tid i ett kontorsnätverk. Nedan följer ett exempel på installation på en VPS.

Exempel på att konfigurera Chrony på RHEL / CentOS på VPS

Låt oss nu öva lite och sätta upp vår egen NTP-server på en VPS. Det är väldigt enkelt, välj bara en lämplig tariff på RuVDS webbplats, skaffa en färdig server och ange ett dussin enkla kommandon. Det här alternativet är ganska lämpligt för våra ändamål.

Låt oss gå vidare till att konfigurera tjänsten och först och främst installera chrony-paketet.

[root@server ~]$ yum install chrony

RHEL 8 / CentOS 8 använder en annan pakethanterare.

[root@server ~]$ dnf install chrony

Efter att du har installerat chrony måste du starta och aktivera tjänsten.

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

Om så önskas kan du redigera /etc/chrony.conf för att ersätta NPT-servrar med de närmaste lokala servrarna för att minska svarstiden.

# 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

Därefter konfigurerar vi synkronisering av NTP-servern med noder från den angivna poolen.

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

Det är också nödvändigt att öppna NTP-porten utåt, annars blockerar brandväggen inkommande anslutningar från klientnoder.

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

På klientsidan räcker det att ställa in tidszonen korrekt.

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

I filen /etc/chrony.conf anger du IP-adressen eller värdnamnet för vår VPS-server där NTP-servern chrony körs.

server my.vps.server

Och slutligen, starta tidssynkronisering på klienten.

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

Nästa gång ska jag berätta vilka alternativ det finns för att synkronisera tid utan internet.

Källa: will.com

Hur tidssynkronisering blev säker