Hvordan tidssynkronisering blev sikker

Hvordan får man tid til at være korrekt, når man har en million store og små enheder, der interagerer via TCP/IP? For på hver enkelt er der ure, og tiden skal være korrekt på alle. Dette problem kan ikke undgås uden NTP.

Forestil dig et øjeblik, at der i et segment af virksomhedens IT-infrastruktur er problemer med synkroniseringen af tjenesterne. Klusterstakken af enterprise-software begynder straks at fejle, domæner opløses, og master- og standby-noder forsøger forgæves at genskabe status quo.

Det kan også være, at en angriber målrettet forsøger at forstyrre tiden gennem MiTM eller DDoS-angreb. I en sådan situation kan alt ske:

• brugernes konti kan miste deres adgangskoder;
• X.509-certifikaterne kan udløbe;
• to-faktor TOTP-godkendelse kan stoppe med at fungere;
• backups kan "forældes" og blive slettet af systemet;
• DNSSec kan fejle.

Det er klart, at enhver IT-afdeling er interesseret i, at tjenesterne til tidsynkronisering fungerer pålideligt og ideelt set skulle de være sikre og pålidelige i industriel brug.

At bryde NTP på 25 minutter

Netværksprotokoller — millennials har en særlig karakteristika, de er for længst er forældede. ubrugelige, men det er ikke så nemt at erstatte dem, selv når der samlet set er en kritisk masse af entusiaster og finansiering.

Den primære klage over klassisk NTP er fraværet af pålidelige beskyttelsesmekanismer mod angreb fra hackere. Forskellige forsøg er blevet gjort for at løse dette problem. For at gøre dette blev der først implementeret en mekanisme til forudbestemte nøgler (PSK) til udveksling af symmetriske nøgler.

Desværre har denne metode ikke været effektiv af den simple årsag, at den skalerer dårligt. Der kræves manuel opsætning på klientsiden afhængigt af serveren. Det betyder, at man ikke bare kan tilføje en klient. Hvis der sker ændringer på NTP-serveren, skal alle klienter konfigureres igen.

Så blev AutoKey opfundet, men der blev straks opdaget en række alvorlige sårbarheder i selve designet af algoritmen, og det måtte opgives. Problemet er, at det initiale nummer (seed) kun indeholder 32 bit, hvilket er for lidt og ikke indeholder tilstrækkelig beregningskompleksitet til en brute-force-angreb.

• Key ID — en symmetrisk 32-bit nøgle;
• MAC (message authentication code) — kontrolsum af NTP-pakken;

Autokey beregnes som følger.

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

Hvor H() er en kryptografisk hashfunktion.

For at beregne kontrolsummen anvendes den samme funktion til pakkerne.

MAC=H(Autokey||NTP pakke)

Det viser sig, at hele integritetskontrollen af pakker afhænger af autenticiteten af cookies. Hvis man får fat på dem, kan man genskabe autokey og dernæst forfalske MAC. Dog bruger NTP-serveren et startnummer (seed) ved deres generation. Her ligger knækket.

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

MSB_32-funktionen skærer de 32 mest betydningsfulde bits fra resultatet af md5 hashberegningen. Klientens cookie ændres ikke, så længe serverparametrene forbliver uændrede. Derefter er det blot op til angriberen at genskabe startnummeret for selv at kunne generere cookies.

Først skal man tilslutte sig NTP-serveren som klient og få cookies. Derefter kan angriberen genskabe startnummeret ved hjælp af en simpel algoritme.

Angrebsalgoritmen for genskabelse af startnummeret ved 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

IP-adresserne er kendte, så der er kun tilbage at skabe 2^32 hashes, indtil den genererede cookie stemmer overens med den, der er modtaget fra NTP-serveren. På en almindelig hjemmecomputer med Intel Core i5 vil dette tage 25 minutter.

NTS — ny Autokey

Det var umuligt at acceptere sådanne sikkerhedshuller i Autokey, og i 2012 blev en ny version protokollen præsenteret. I forbindelse med det beskyttede navn blev der gennemført et rebranding, så Autokey v.2 blev døbt Network Time Security.

NTS-protokollen er en udvidelse af sikkerheden i NTP og understøtter i øjeblikket kun unicast-tilstand. Den giver pålidelig kryptografisk beskyttelse mod manipulation af pakker, forhindrer overvågning, skalerer godt, er robust over for tab af netværkspakker og resulterer i minimale tab af præcision, der opstår under beskyttelsen af forbindelsen.

NTS-forbindelsen består af to faser, der bruger lavere protokoller. I den første fase aftaler klient og server forskellige forbindelsesparametre og udveksler cookies, der indeholder nøgler med alt tilhørende datamængde. I den anden fase finder den sikre NTS-session sted mellem klienten og NTP-serveren.

NTS består af to lavnivåprotokoller: Network Time Security Key Exchange (NTS-KE), som initierer en sikker forbindelse oven på TLS, og NTPv4 — den seneste inkarnation af NTP-protokollen. Mere om dette nedenfor.

Fase et — NTS KE

I denne fase initierer NTP-klienten en TLS 1.2/1.3 session via en separat TCP-forbindelse med NTS KE-serveren. I løbet af denne session sker følgende.

• Parterne definerer parametrene AEAD for algoritmen til fase to.
• Parterne bestemmer den anden lavnivåprotokol, men i øjeblikket understøttes kun NTPv4.
• Parterne angiver IP-adressen og porten for NTP-serveren.
• NTS KE-serveren udsteder cookies til NTPv4.
• Parterne udtrækker fra materiale cookies et par symmetrisk nøgler (C2S og S2C).

Denne tilgang har den store fordel, at al belastning for overførsel af fortrolige forbindelsesparametre påhviler en pålidelig og sikker TLS-protokol. Dermed er der ikke behov for at opfinde cyklen igen for en sikker NTP-håndtryk.

Fase to — NTP beskyttet af NTS

I fase to synkroniserer klienten sikkert tiden med NTP-serveren. Til dette formål sender den fire specielle udvidelser (extension field) i strukturen af NTPv4-pakken.

• Unique Identifier Extension indeholder en tilfældig nonce for at forhindre angreb ved gentagelse.
• NTS Cookie Extension indeholder en af de tilgængelige NTP-cookies hos klienten. Da kun klienten har de symmetrisk AAED-nøgler C2S og S2C, skal NTP-serveren udtrække dem fra cookie-materialet.
• NTS Cookie Placeholder Extension er en måde for klienten at anmode om yderligere cookies fra serveren. Denne udvidelse er nødvendig for, at NTP-serverens svar ikke bliver meget længere end anmodningen. Dette forhindrer forstærkningsangreb.
• NTS Authenticator and Encrypted Extension Fields Extension indeholder krypteringsalgoritmen AAED med C2S-nøglen, NTP-headeren, tidsstempler og de ovennævnte EF som ledsagedata. Uden denne udvidelse er det muligt at forfalske tidsstempler.

Når serveren modtager en anmodning fra klienten, verificerer den autenticiteten af NTP-pakken. For dette skal den dekryptere cookies, udtrække AAED-algoritmen og nøglerne. Efter en succesfuld validering af NTP-pakken svarer serveren klienten i følgende format.

• Unique Identifier Extension er et spejl af klientens anmodning, som en foranstaltning mod angreb ved gentagelse.
• NTS Cookie Extension flere cookies til at fortsætte sessionen.
• NTS Authenticator og Krypterede Udvidelsesfelter indeholder en AEAD-kryptering med en S2C nøgle.

Det andet håndtryk kan gentages mange gange, idet man springer det første trin over, da hver anmodning og svar giver klienten ekstra cookies. Dette giver den fordel, at de relativt ressourcekrævende TLS operationer til beregning og transmission af PKI-data opdeles på antallet af gentagne anmodninger. Dette er især praktisk for specialiserede FPGA-urværker, når hele den primære funktionalitet kan pakkes ind i et par funktioner fra området for symmetrisk kryptografi og hele TLS-stakken overføres til en anden enhed.

NTPSec

Hvad er det særlige ved NTP? Selvom projektets forfatter Dave Mills har forsøgt at dokumentere sin kode så godt som muligt, vil sjældne programmører være i stand til at finde ud af kompleksiteterne i tidsynchroniseringsalgoritmerne fra for 35 år siden. En del af koden er skrevet før POSIX-æraen, og Unix API var dengang meget forskelligt fra det, der bruges i dag. Derudover kræves viden om statistik for at rense signalet for støj på støjfyldte linjer.

NTS var ikke det første forsøg på at reparere NTP. Efter at angribere lærte at udnytte NTP's sårbarheder til at forstærke DDoS-angreb, blev det klart, at der var behov for radikale ændringer. Og mens udkastene til NTS blev forberedt og finpudset, bevilgede National Science Foundation i USA i slutningen af 2014 hastigt et grant til modernisering af NTP.

Arbejdgruppen blev ledet af ikke hvem som helst, men Eric Steven Raymond — en af grundlæggerne og staldene af Open Source-samfundet og forfatteren til bogen Katedral og Basar. Først forsøgte Eric og hans kolleger at flytte NTP-koden fra BitKeeper-platformen til git, men det gik ikke. Projektleder Harlan Stenn var imod denne beslutning, og forhandlingerne stødte på en afgrund. Derefter blev det besluttet at forke projektets kode, således blev NTPSec til.

Solid erfaring, inklusive arbejde med GPSD, matematisk baggrund og en magisk evne til at læse gammel kode — Eric Raymond var netop den hacker, der kunne trække et sådant projekt igennem. I teamet fandtes en specialist i kodeoverførsel, og på bare 10 uger blev NTP etableretpå GitLab. Arbejdet gik i gang.

Eric Raymonds team tog fat på arbejdet, som Auguste Rodin gjorde med en stor klump sten. Ved at fjerne 175 KLOC gammel kode lykkedes det dem signifikant at reducere angrebsoverfladen ved at lukke mange sikkerhedshuller.

Her er en ufuldstændig liste over dem, der blev ramt:

• Dokumenterede, forældede, forældede eller defekte refclock.
• Ubrugt ICS-bibliotek.
• libopts/autogen.
• Gammel kode til Windows.
• ntpdc.
• Autokey.
• C-koden fra ntpq er gen skrevet i Python.
• C-koden fra sntp/ntpdig er gen skrevet i Python.

Udover oprydning af koden var der også andre opgaver for projektet. Her er en ufuldstændig liste over præstationer:

• Sikkerheden i koden mod buffer overflow er betydeligt forbedret. For at forhindre buffer overflow er alle usikre strenge funktioner (strcpy / strcat / strtok / sprintf / vsprintf / gets) blevet erstattet med sikre versioner, der implementerer størrelsesbegrænsninger.
• Tilføjet understøttelse af NTS.
• Ti gange forbedret tidspræcision ved binding af fysisk udstyr. Dette skyldes, at moderne computere er blevet meget mere præcise end dem, der fandtes ved starten af NTP. GPSDO og dedikerede tidsradiostationer har haft den største fordel.
• Antallet af programmeringssprog er blevet reduceret til to. I stedet for Perl-, awk- og endda S-scripts er der nu kun Python. Dette giver større mulighed for genbrug af kode.
• I stedet for rodet af scripts er autotools-projektet blevet ændret til at bruge et softwarebygge-system. waf.
• Dokumentationen til projektet er blevet opdateret og omorganiseret. Fra en modstridende og til tider forældet dokumentationssamling er der nu blevet lavet en rimelig dokumentation. Hver kommando linje og hver konfigurationsenhed har nu en eneste sandheds version. Desuden genereres manualer og webdokumentation nu fra de samme grundlæggende filer.

NTPSec er tilgængelig for en række Linux-distributioner. I øjeblikket er den seneste stabile version 1.1.8, for Gentoo Linux er det næstsidste.

(1:696)$ sudo emerge -av ntpsec
Disse er de pakker, der vil blive flettet i rækkefølge:
Beregn afhængigheder... færdig!
[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 pakke (1 geninstallation), Størrelse af downloads: 0 KiB
Vil du gerne flette disse pakker? [Ja/Nej]

Chrony

Der var endnu et forsøg på at erstatte den gamle NTP med en mere sikker version. Chrony er, i modsætning til NTPSec, skrevet fra bunden og er designet til at fungere pålideligt under et bredt spektrum af forhold, herunder ustabile netværksforbindelser, delvis tilgængelighed eller netværksoverbelastninger og temperaturændringer. Derudover har chrony også andre fordele:

• chrony kan hurtigere synkronisere systemklokker med større præcision;
• chrony er mindre, bruger mindre hukommelse og tilgår kun CPU'en, når det er nødvendigt. Dette er en stor fordel for at spare ressourcer og energi;
• chrony understøtter tidsstempler på hardware-niveau i Linux, hvilket sikrer ekstremt præcis synkronisering i lokale netværk.

Dog mangler chrony visse funktioner fra den gamle NTP, såsom broadcast- og multicast-klient/server. Derudover understøtter klassisk NTP et større antal operativsystemer og platforme.

For at deaktivere serverfunktionalitet og NTP-anmodninger til chronyd-processen er det tilstrækkeligt at angive port 0 i chrony.conf-filen. Dette gøres i de tilfælde, hvor der ikke er behov for at tilbyde tid til NTP-klienter eller peer-noder. Fra version 2.0 er NTP-serverens port kun åben, når adgangen er tilladt af direktivet allow eller den relevante kommando, eller når der er konfigureret en peer-NTP-node, eller når broadcast-direktivet anvendes.

Programmet består af to moduler.

• chronyd er en tjeneste, der kører i baggrunden. Den modtager information om forskellen mellem systemklokkerne og en ekstern tidsserver og justerer den lokale tid. Den implementerer også NTP-protokollen og kan fungere som klient eller server.
• chronyc er et kommandolinjeværktøj til overvågning og kontrol af programmet. Det bruges til at finjustere forskellige parametre for tjenesten, for eksempel til at tilføje eller fjerne NTP-servere, mens chronyd fortsætter med at køre.

Fra version 7 af RedHat Linux bruger chrony som en tidsynkroniseringstjeneste. Pakken er også tilgængelig for andre Linux-distributioner. Den seneste stabile version 3.5 er ved at blive forberedt til version 4.0.

(1:712)$ sudo emerge -av chrony
Disse er de pakker, der ville blive samlet, i rækkefølge:
Beregnende afhængigheder... færdig!
[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
I alt: 1 pakke (1 ny, 1 binær), Størrelse på downloads: 246 KiB
Vil du gerne samle disse pakker? [Ja/Nej]

Sådan konfigurerer du din egen fjernserver chrony på internettet til tidsynkronisering i dit kontornetværk. Her er et eksempel på opsætning på VPS.

Eksempel på opsætning af Chrony på RHEL / CentOS på VPS

Lad os nu træne lidt og oprette vores egen NTP-server på VPS. Det er meget simpelt, det er nok at vælge en passende plan på RuVDS's hjemmeside, få serveren klar og indtaste en ti ikke særlig komplicerede kommandoer. Til vores formål vil en sådan løsning være tilstrækkelig.

Vi går videre til opsætningen af tjenesten, og først installerer vi pakken chrony.

[root@server ~]$ yum install chrony

RHEL 8 / CentOS 8 bruger en anden pakkehåndtering.

[root@server ~]$ dnf install chrony

Efter installationen af chrony skal tjenesten startes og aktiveres.

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

Hvis ønskes, kan der foretages ændringer i /etc/chrony.conf ved at erstatte NPT-serverne med de nærmeste lokale for at forkorte responstiden.

# 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

Herefter konfigurerer vi NTP-serverens synkronisering med noderne fra den angivne pulje.

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

Det er også nødvendigt at åbne NTP-porten, ellers vil firewall blokere for indgående forbindelser fra klientnoder.

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

På klientsiden er det nok at indstille tidszonen korrekt.

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

I filen /etc/chrony.conf angiver du IP-adressen eller værtsnavnet på vores VPS-server, hvor NTP-serveren chrony kører.

server my.vps.server

Og endelig, start tidsynkroniseringen på klienten.

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

Næste gang vil jeg fortælle om mulighederne for tidsynkronisering uden internet.

Kilde: habr.com