Hvordan tidssynkronisering ble sikker

Hvordan sikre at tiden i seg selv ikke lyver hvis du har en million store og små enheter som kommuniserer via TCP/IP? Tross alt har hver av dem en klokke, og tiden må være riktig for dem alle. Dette problemet kan ikke omgås uten ntp.

La oss forestille oss et øyeblikk at i ett segment av den industrielle IT-infrastrukturen er det vanskeligheter med å synkronisere tjenester over tid. Umiddelbart begynner klyngestakken med Enterprise-programvare å mislykkes, domener går i oppløsning, master- og standby-noder streber uten hell for å gjenopprette status quo.

Det er også mulig at en angriper bevisst prøver å forstyrre tiden gjennom et MiTM- eller DDOS-angrep. I en slik situasjon kan alt skje:

• Brukerkontopassord vil utløpe;
• X.509-sertifikater vil utløpe;
• TOTP to-faktor autentisering vil slutte å fungere;
• sikkerhetskopier vil bli utdaterte og systemet vil slette dem;
• DNSSec vil bryte.

Det er tydelig at hver IT-avdeling er interessert i pålitelig drift av tidssynkroniseringstjenester, og det ville vært fint om de var pålitelige og trygge i industriell drift.

Bryt NTP på 25 minutter

Nettverksprotokoller - millennials har en særegenhet, det har de vært utdatert og er ikke lenger gode for noe, men å erstatte dem er ikke så lett selv når en kritisk masse av entusiaster og finansiering er samlet.

Hovedklagen på klassisk NTP er mangelen på pålitelige mekanismer for å beskytte mot angrep fra inntrengere. Ulike forsøk er gjort for å løse dette problemet. For å oppnå dette implementerte vi først en PSK-mekanisme (pre-shared key) for utveksling av symmetriske nøkler.

Dessverre lønnet seg ikke denne metoden av en enkel grunn - den skalerer ikke godt. Manuell konfigurasjon er nødvendig på klientsiden avhengig av serveren. Dette betyr at du rett og slett ikke kan legge til en annen klient bare på den måten. Hvis noe endres på NTP-serveren, må alle klienter rekonfigureres.

Så kom de opp med AutoKey, men de oppdaget umiddelbart en rekke alvorlige sårbarheter i utformingen av selve algoritmen og de måtte forlate den. Saken er at frøet bare inneholder 32-biter, det er for lite og inneholder ikke nok beregningsmessig kompleksitet for et frontalangrep.

• Nøkkel-ID - symmetrisk 32-bits nøkkel;
• MAC (meldingsautentiseringskode) - NTP-pakkesjekksum;

Autokey beregnes som følger.

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

Hvor H() er en kryptografisk hash-funksjon.

Den samme funksjonen brukes til å beregne kontrollsummen av pakker.

MAC=H(Autokey||NTP packet)

Det viser seg at hele integriteten til pakkesjekkene hviler på ektheten til informasjonskapslene. Når du har dem, kan du gjenopprette autonøkkelen og deretter forfalske MAC-en. NTP-serveren bruker imidlertid et frø når de genererer dem. Det er her fangsten ligger.

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

MSB_32-funksjonen kutter av de 5 mest signifikante bitene fra md32-hash-beregningsresultatet. Klientinformasjonskapselen endres ikke så lenge serverparametrene forblir uendret. Da kan angriperen bare gjenopprette det opprinnelige nummeret og være i stand til å generere informasjonskapsler uavhengig.

Først må du koble til NTP-serveren som klient og motta informasjonskapsler. Etter dette, ved hjelp av en brute force-metode, gjenoppretter angriperen det opprinnelige tallet etter en enkel algoritme.

Algoritme for å angripe beregningen av det opprinnelige tallet ved hjelp 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-adressene er kjent, så det gjenstår bare å lage 2^32 hashes til den opprettede informasjonskapselen samsvarer med den mottatt fra NTP-serveren. På en vanlig hjemmestasjon med Intel Core i5 vil dette ta 25 minutter.

NTS - ny autonøkkel

Det var umulig å tåle slike sikkerhetshull i Autokey, og i 2012 dukket det opp en ny versjon protokoll. For å kompromittere navnet bestemte de seg for å rebrande, så Autokey v.2 ble kalt Network Time Security.

NTS-protokollen er en utvidelse av NTP-sikkerhet og støtter for øyeblikket bare unicast-modus. Den gir sterk kryptografisk beskyttelse mot pakkemanipulering, forhindrer snoking, skalerer godt, er motstandsdyktig mot nettverkspakketap og resulterer i minst mulig presisjonstap som oppstår under tilkoblingssikkerhet.

En NTS-tilkobling består av to trinn som bruker lavere lags protokoller. På den første På dette stadiet blir klienten og serveren enige om ulike tilkoblingsparametere og utveksler informasjonskapsler som inneholder nøkler med alle tilhørende datasett. På andre På dette stadiet finner den faktiske beskyttede NTS-sesjonen sted mellom klienten og NTP-serveren.

NTS består av to lavere lags protokoller: Network Time Security Key Exchange (NTS-KE), som initierer en sikker tilkobling over TLS, og NTPv4, den siste inkarnasjonen av NTP-protokollen. Litt mer om dette nedenfor.

Første etappe - NTS KE

På dette stadiet starter NTP-klienten en TLS 1.2/1.3-sesjon over en separat TCP-forbindelse med NTS KE-serveren. Under denne økten skjer følgende.

• Partene bestemmer parametrene FREM algoritme for andre trinn.
• Partene definerer en andre nedre lags protokoll, men for øyeblikket støttes kun NTPv4.
• Partene bestemmer IP-adressen og porten til NTP-serveren.
• NTS KE-server utsteder informasjonskapsler under NTPv4.
• Partene trekker ut et par symmetriske nøkler (C2S og S2C) fra informasjonskapselmaterialet.

Denne tilnærmingen har den store fordelen at hele byrden med å overføre hemmelig informasjon angående tilkoblingsparametere faller på den velprøvde og pålitelige TLS-protokollen. Dette eliminerer behovet for å finne opp ditt eget hjul på nytt for et sikkert NTP-håndtrykk.

Andre trinn - NTP under NTS-beskyttelse

I det andre trinnet synkroniserer klienten sikkert tiden med NTP-serveren. For dette formålet sender den fire spesielle utvidelser (utvidelsesfelt) i NTPv4-pakkestrukturen.

• Unique Identifier Extension inneholder en tilfeldig nonce for å forhindre replay-angrep.
• NTS Cookie Extension inneholder en av NTP-informasjonskapslene som er tilgjengelige for klienten. Siden bare klienten har de symmetriske AAED-nøklene C2S og S2C, må NTP-serveren trekke dem ut fra informasjonskapselmaterialet.
• NTS Cookie Placeholder Extension er en måte for en klient å be om ytterligere informasjonskapsler fra serveren. Denne utvidelsen er nødvendig for å sikre at NTP-serversvaret ikke er mye lengre enn forespørselen. Dette bidrar til å forhindre forsterkningsangrep.
• NTS Authenticator og Encrypted Extension Fields Extension inneholder AAED-chifferet med C2S-nøkkelen, NTP-overskriften, tidsstemplene og ovennevnte EF som tilhørende data. Uten denne utvidelsen er det mulig å forfalske tidsstempler.

Ved mottak av en forespørsel fra en klient, verifiserer serveren ektheten til NTP-pakken. For å gjøre dette må han dekryptere informasjonskapslene, trekke ut AAED-algoritmen og nøklene. Etter å ha kontrollert NTP-pakken for gyldighet, svarer serveren til klienten i følgende format.

• Unique Identifier Extension er en speilkopi av klientforespørselen, et tiltak mot replay-angrep.
• NTS Cookie Extension flere informasjonskapsler for å fortsette økten.
• NTS Authenticator og Encrypted Extension Fields Extension inneholder AEAD-chifferet med en S2C-nøkkel.

Det andre håndtrykket kan gjentas mange ganger, og omgå det første trinnet, siden hver forespørsel og svar gir klienten ytterligere informasjonskapsler. Dette har fordelen at de relativt ressurskrevende TLS-operasjonene med å beregne og overføre PKI-data er delt på antall gjentatte forespørsler. Dette er spesielt praktisk for spesialiserte FPGA-tidtakere, når all hovedfunksjonaliteten kan pakkes inn i flere funksjoner fra feltet symmetrisk kryptografi, og overføre hele TLS-stakken til en annen enhet.

NTPSec

Hva er spesielt med NTP? Til tross for at forfatteren av prosjektet, Dave Mills, prøvde å dokumentere koden sin best mulig, er det en sjelden programmerer som vil kunne forstå forviklingene med tidssynkroniseringsalgoritmer som er 35 år gamle. Noe av koden ble skrevet før POSIX-æraen, og Unix API da var veldig forskjellig fra det som brukes i dag. I tillegg trengs kunnskap om statistikk for å fjerne signalet fra forstyrrelser på støyende linjer.

NTS var ikke det første forsøket på å fikse NTP. Så snart angripere lærte å utnytte NTP-sårbarheter for å forsterke DDoS-angrep, ble det klart at radikale endringer var nødvendig. Og mens utkastene til NTS ble utarbeidet og ferdigstilt, bevilget US National Science Foundation på slutten av 2014 et presserende tilskudd til modernisering av NTP.

Arbeidsgruppen ble ledet ikke av hvem som helst, men Eric Steven Raymond - en av grunnleggerne og pilarene i Open Source-fellesskapet og forfatter av boken katedral og basar. Det første Eric og vennene hans prøvde å gjøre var å flytte NTP-koden fra BitKeeper-plattformen til git, men det fungerte ikke slik. Prosjektleder Harlan Stenn var imot dette vedtaket og forhandlingene strandet. Så ble det besluttet å gafle prosjektkoden, og NTPSec ble født.

Solid erfaring, inkludert arbeid med GPSD, en matematisk bakgrunn og den magiske ferdigheten med å lese gammel kode - Eric Raymond var akkurat den hackeren som kunne gjennomføre et slikt prosjekt. Teamet fant en kodemigreringsspesialist og på bare 10 uker NTP bosatte segpå GitLab. Arbeidet var i full gang.

Teamet til Eric Raymond tok på seg oppgaven på samme måte som Auguste Rodin gjorde med en steinblokk. Ved å fjerne 175 KLOC med gammel kode, klarte de å redusere angrepsoverflaten betydelig ved å tette mange sikkerhetshull.

Her er en ufullstendig liste over de som er inkludert i distribusjonen:

• Udokumentert, utdatert, utdatert eller ødelagt refclock.
• Ubrukt ICS-bibliotek.
• libopts/autogen.
• Gammel kode for Windows.
• ntpdc.
• Autotast.
• ntpq C-koden er skrevet om i Python.
• sntp/ntpdig C-koden er skrevet om i Python.

I tillegg til å rydde opp i koden, hadde prosjektet andre oppgaver. Her er en delvis liste over prestasjoner:

• Kodebeskyttelsen mot bufferoverløp er betydelig forbedret. For å forhindre bufferoverløp har alle usikre strengfunksjoner (strcpy/strcat/strtok/sprintf/vsprintf/gets) blitt erstattet med sikre versjoner som implementerer bufferstørrelsesgrenser.
• Lagt til NTS-støtte.
• Forbedret tidstrinns nøyaktighet tidoblet ved å koble fysisk maskinvare. Dette skyldes det faktum at moderne dataklokker har blitt mye mer nøyaktige enn de da NTP ble født. De største fordelene med dette var GPSDO og dedikerte tidsradioer.
• Antall programmeringsspråk er redusert til to. I stedet for Perl, awk og til og med S-skript, er det nå Python. På grunn av dette er det flere muligheter for gjenbruk av kode.
• I stedet for nudler av autotools-skript, begynte prosjektet å bruke et programvarebyggesystem WAF.
• Oppdatert og omorganisert prosjektdokumentasjon. Fra en selvmotsigende og noen ganger arkaisk dokumentsamling skapte de ganske farbar dokumentasjon. Hver kommandolinjebryter og hver konfigurasjonsenhet har nå en enkelt versjon av sannheten. I tillegg opprettes man-sider og nettdokumentasjon fra de samme kjernefilene.

NTPSec er tilgjengelig for en rekke Linux-distribusjoner. For øyeblikket er den siste stabile versjonen 1.1.8, for Gentoo Linux er det den nest siste.

(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 var et nytt forsøk på å erstatte den gamle NTP med et sikrere alternativ. Chrony, i motsetning til NTPSec, er skrevet fra grunnen av og er designet for å fungere pålitelig under en lang rekke forhold, inkludert ustabile nettverkstilkoblinger, delvis nettverkstilgjengelighet eller overbelastning, og temperaturendringer. I tillegg har chrony andre fordeler:

• chrony kan synkronisere systemklokken raskere med større nøyaktighet;
• chrony er mindre, bruker mindre minne og får tilgang til CPU-en bare når det er nødvendig. Dette er et stort pluss for å spare ressurser og energi;
• chrony støtter maskinvaretidsstempler på Linux, noe som tillater ekstremt nøyaktig synkronisering på lokale nettverk.

Chrony mangler imidlertid noen av funksjonene til den gamle NTP-en, for eksempel kringkasting og multicast-klient/server. I tillegg støtter klassisk NTP et større antall operativsystemer og plattformer.

For å deaktivere funksjonaliteten til serveren og NTP-forespørsler til chronyd-prosessen, skriv bare port 0 i chrony.conf-filen. Dette gjøres i tilfeller der det ikke er behov for å opprettholde tid for NTP-klienter eller likemenn. Siden versjon 2.0 er NTP-serverporten bare åpen når tilgang tillates av et tillat-direktiv eller passende kommando, eller en NTP-peer er konfigurert, eller et kringkastingsdirektiv brukes.

Programmet består av to moduler.

• chronyd er en tjeneste som kjører i bakgrunnen. Den mottar informasjon om forskjellen mellom systemklokken og den eksterne tidsserveren og justerer den lokale tiden. Den implementerer også NTP-protokollen og kan fungere som en klient eller server.
• chronyc er et kommandolinjeverktøy for programovervåking og kontroll. Brukes til å finjustere ulike tjenesteparametere, for eksempel slik at du kan legge til eller fjerne NTP-servere mens chronyd fortsetter å kjøre.

Siden versjon 7 av RedHat Linux bruker chrony som en tidssynkroniseringstjeneste. Pakken er også tilgjengelig for andre Linux-distribusjoner. Den siste stabile versjonen er 3.5, som forbereder utgivelsen av v4.0.

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

Hvordan sette opp din egen eksterne chrony-server på Internett for å synkronisere tid på et kontornettverk. Nedenfor er et eksempel på å sette opp en VPS.

Eksempel på oppsett av Chrony på RHEL / CentOS på VPS

La oss nå øve litt og sette opp vår egen NTP-server på en VPS. Det er veldig enkelt, bare velg passende tariff på RuVDS-nettstedet, skaff deg en ferdig server og skriv inn et dusin enkle kommandoer. For våre formål er dette alternativet ganske egnet.

La oss gå videre til å sette opp tjenesten og først installere chrony-pakken.

[root@server ~]$ yum install chrony

RHEL 8 / CentOS 8 bruker en annen pakkebehandling.

[root@server ~]$ dnf install chrony

Etter å ha installert chrony, må du starte og aktivere tjenesten.

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

Om ønskelig kan du gjøre endringer i /etc/chrony.conf, og erstatte NPT-servere med de nærmeste lokale for å redusere 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

Deretter setter vi opp synkronisering av NTP-serveren med noder fra det angitte bassenget.

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

Det er også nødvendig å åpne NTP-porten til utsiden, ellers vil brannmuren blokkere innkommende tilkoblinger fra klientnoder.

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

På klientsiden er det nok å stille inn tidssonen riktig.

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

/etc/chrony.conf-filen spesifiserer IP- eller vertsnavnet til vår VPS-server som kjører NTP-server chrony.

server my.vps.server

Og til slutt, starttidssynkronisering på klienten.

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

Neste gang skal jeg fortelle deg hvilke alternativer det er for å synkronisere tid uten Internett.

Kilde: www.habr.com