Hvordan sikrer man sig, at tiden i sig selv ikke lyver, når man har en million store og små enheder, der kommunikerer via TCP/IP? De har trods alt hver især et ur, og tiden skal være korrekt på dem alle. Dette problem kan ikke omgås uden ntp.
Lad os et øjeblik forestille os, at et segment af den industrielle IT-infrastruktur har problemer med at synkronisere tjenester over tid. Virksomhedssoftwareklyngestakken begynder straks at fejle, domæner falder fra hinanden, og mastere og standby-noder forsøger uden held at genoprette status quo.
Det er også muligt, at en angriber bevidst forsøger at nulstille tiden via et MiTM- eller DDOS-angreb. I en sådan situation kan alt ske:
- brugerkontoadgangskoder udløber;
- X.509-certifikater udløber;
- TOTP tofaktorgodkendelse vil stoppe med at virke;
- sikkerhedskopier vil blive "forældede", og systemet vil slette dem;
- DNSSec vil bryde sammen.
Det er tydeligt, at alle IT-afdelinger er interesserede i pålidelig drift af tidssynkroniseringstjenester, og det ville være godt, hvis de var pålidelige og sikre i industriel drift.
Bryd NTP på 25 minutter
Netværksprotokoller - millennials har én ting til fælles: de har længe været og er ikke længere gode til noget, men det er ikke så nemt at erstatte dem, selv når der er opnået en kritisk masse af entusiaster og finansiering.
Den primære klage over klassisk NTP er manglen på pålidelige mekanismer til beskyttelse mod ondsindede angreb. Der er gjort forskellige forsøg på at løse dette problem. For at opnå dette blev en PSK-mekanisme (pre-shared key) først introduceret til at udveksle symmetriske nøgler.
Desværre retfærdiggjorde denne metode sig ikke af en simpel grund - den skalerer ikke godt. Manuel konfiguration er påkrævet på klientsiden afhængigt af serveren. Det betyder, at du ikke bare kan tilføje en anden klient på den måde. Hvis noget ændrer sig på NTP-serveren, skal alle klienter omkonfigureres.
Så kom de op med AutoKey, men straks blev der opdaget en række alvorlige sårbarheder i selve algoritmedesignet, og det måtte opgives. Problemet er, at seed'et kun er 32 bit, hvilket er for lille og ikke indeholder nok beregningsmæssig kompleksitet til et brute-force-angreb.
- Nøgle-ID er en symmetrisk 32-bit nøgle;
- MAC (message authentication code) — checksum for NTP-pakke;
Autokey beregnes som følger.
Autokey=H(Sender-IP||Receiver-IP||KeyID||Cookie)Hvor H() er en kryptografisk hashfunktion.
Den samme funktion bruges til at beregne pakkens checksum.
MAC=H(Autokey||NTP packet)Det viser sig, at hele integriteten af pakkekontroller hviler på cookies' ægthed. Når du har dem, kan du gendanne autokey'en og derefter forfalske MAC-koden. NTP-serveren bruger dog et seed (frø), når den genererer dem. Det er her, hagen ligger.
Cookie=MSB_32(H(Client IP||Server IP||0||Server Seed))Funktionen MSB_32 fjerner 5 af de mest betydende bits fra resultatet af beregningen af md32-hashen. Klientcookien ændres ikke, så længe serverindstillingerne forbliver uændrede. Alt, hvad angriberen skal gøre, er at gendanne det oprindelige antal og få muligheden for at generere cookies uafhængigt.
Først skal du oprette forbindelse til NTP-serveren som klient og hente cookien. Derefter bruger angriberen brute force til at gendanne det oprindelige tal efter en simpel algoritme.
En algoritme til at angribe det oprindelige tal ved hjælp af 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 forIP-adresserne er kendte, så alt, der er tilbage, er at oprette 2^32 hashes, indtil den genererede cookie matcher den, der modtages fra NTP-serveren. På en typisk hjemmearbejdsstation med en Intel Core i5 vil dette tage 25 minutter.
NTS — ny Autonøgle
Det var umuligt at håndtere sådanne sikkerhedshuller i Autokey, og i 2012, protokol. For at gå på kompromis med navnet besluttede de at omdøbe det, så Autokey v.2 blev døbt Network Time Security.
NTS-protokollen er en sikkerhedsudvidelse af NTP og understøtter i øjeblikket kun unicast-tilstand. Den giver stærk kryptografisk beskyttelse mod pakkemanipulation, forhindrer snooping, skalerer godt, er modstandsdygtig over for pakketab i netværket og resulterer i det laveste nøjagtighedstab i processen med at sikre en forbindelse.
NTS-forbindelsen består af to faser, hvor der anvendes protokoller på lavere niveau. På den første På dette stadie bliver klienten og serveren enige om forskellige forbindelsesparametre og udveksler cookies, der indeholder nøgler med alle de tilhørende datasæt. På sekund På dette stadie finder den faktiske sikre NTS-session sted mellem klienten og NTP-serveren.
NTS består af to protokoller på det lavere niveau: Network Time Security Key Exchange (NTS-KE), som initialiserer en sikker forbindelse via TLS, og NTPv4, den seneste inkarnation af NTP-protokollen. Mere om dette nedenfor.
Første fase - NTS KE
På dette stadie starter NTP-klienten en TLS 1.2/1.3-session over en separat TCP-forbindelse til NTS KE-serveren. Under denne session sker følgende.
- Parterne fastlægger parametrene algoritme for anden fase.
- Parterne definerer en anden protokol på lavere niveau, men i øjeblikket understøttes kun NTPv4.
- Parterne bestemmer IP-adressen og porten på NTP-serveren.
- NTS KE-serveren udsteder cookies under NTPv4.
- Parterne udtrækker et par symmetriske nøgler (C2S og S2C) fra cookiematerialet.
Denne tilgang har en stor fordel, idet hele byrden med at transmittere hemmelige forbindelsesparameteroplysninger falder på den dokumenterede og pålidelige TLS-protokol. Dette eliminerer behovet for at genopfinde hjulet for et sikkert NTP-handshake.
Fase 2 - NTP under NTS-beskyttelse
I anden fase synkroniserer klienten sikkert tiden med NTP-serveren. Til dette formål bærer den fire specielle udvidelsesfelter i NTPv4-pakkestrukturen.
- Unique Identifier Extension indeholder en tilfældig nonce for at forhindre replay-angreb.
- NTS Cookie Extension indeholder en af de cookies, der er tilgængelige for NTP-klienten. Da kun klienten har de symmetriske AAED-nøgler C2S og S2C, skal NTP-serveren udtrække dem fra cookiematerialet.
- NTS Cookie Placeholder Extension er en måde, hvorpå en klient kan anmode om yderligere cookies fra serveren. Denne udvidelse er nødvendig for at sikre, at NTP-serverens svar ikke er meget længere end anmodningen. Dette hjælper med at forhindre forstærkningsangreb.
- NTS Authenticator og Encrypted Extension Fields Extension indeholder AAED-algoritmekrypteringen med C2S-nøgle, NTP-header, tidsstempler og ovennævnte EF som ledsagende data. Uden denne udvidelse er det muligt at forfalske tidsstempler.
Efter at have modtaget en anmodning fra klienten, kontrollerer serveren ægtheden af NTP-pakken. For at gøre dette skal han dekryptere cookies, udtrække AAED-algoritmen og nøglerne. Efter at have kontrolleret NTP-pakken for gyldighed, svarer serveren klienten i følgende format.
- Unique Identifier Extension er en spejlkopi af klientanmodningen, en foranstaltning mod replay-angreb.
- NTS Cookie Extension flere cookies for at fortsætte sessionen.
- NTS Authenticator og Encrypted Extension Fields-udvidelsen indeholder en AEAD-chiffer med en S2C-nøgle.
Det andet handshake kan gentages mange gange, hvorved det første trin omgås, da hver anmodning og hvert svar giver klienten yderligere cookies. Dette har den fordel, at den relativt ressourcekrævende TLS-beregning og PKI-dataoverførsel er opdelt i et antal gentagne anmodninger. Dette er især praktisk for specialiserede FPGA-tidstagere, når al hovedfunktionaliteten kan pakkes ind i flere funktioner fra symmetrisk kryptografi, hvorved hele TLS-stakken overføres til en anden enhed.
NTPSec
Hvad er det særlige ved NTP? Selvom projektets forfatter Dave Mills forsøgte at dokumentere sin kode så godt som muligt, vil en sjælden programmør være i stand til at forstå detaljerne i tidssynkroniseringsalgoritmerne for 35 år siden. Noget af koden blev skrevet før POSIX-æraen, og Unix API'en var meget anderledes end det, der bruges i dag. Derudover kræves kendskab til statistik for at rense signalet for interferens på støjende linjer.
NTS var ikke det første forsøg på at fikse NTP. Efter at angribere lærte at udnytte NTP-sårbarheder til at forstærke DDoS-angreb, blev det klart, at der var behov for radikale ændringer. Og mens udkastene til NTS blev udarbejdet og færdiggjort, bevilgede den amerikanske National Science Foundation hastigt en bevilling til modernisering af NTP i slutningen af 2014.
Arbejdsgruppen blev ledet af ingen ringere end — en af grundlæggerne og grundpillerne i Open Source-fællesskabet og forfatter til bogen . Det første Eric og hans kammerater gjorde var at forsøge at flytte NTP-koden fra BitKeeper-platformen til git, men det fungerede ikke sådan. Projektleder Harlan Stenn var imod denne beslutning, og forhandlingerne endte i en blindgyde. Det blev derefter besluttet at forke projektkoden, og sådan opstod NTPSec.
Med en solid baggrund, herunder arbejde med GPSD, en baggrund i matematik og en magisk evne til at læse gammel kode, var Eric Raymond den perfekte hacker til at gennemføre et sådant projekt. Teamet fandt en specialist i kodemigrering, og på bare 10 uger NTP på GitLab. Arbejdet begyndte at koge.
Eric Raymonds hold greb opgaven an på samme måde, som Auguste Rodin ville have grebet en stenblok an. Ved at fjerne 175 KLOC gammel kode var de i stand til at reducere angrebsfladen betydeligt og lukke mange sikkerhedshuller.
Her er en ufuldstændig liste over de berørte:
- Udokumenteret, forældet, uddateret eller defekt ref-ur.
- Ubrugt ICS-bibliotek.
- libopts/autogen.
- Gammel kode til Windows.
- ntpdc.
- Autonøgle.
- C-kode ntpq omskrevet i Python.
- C-kode sntp/ntpdig omskrevet i Python.
Udover kodeoprydning havde projektet andre opgaver. Her er en delvis liste over præstationer:
- Markant forbedret kodebeskyttelse mod bufferoverløb. For at forhindre bufferoverløb er alle usikre strengfunktioner (strcpy/strcat/strtok/sprintf/vsprintf/gets) blevet erstattet med sikre versioner, der implementerer begrænsning af bufferstørrelse.
- Tilføjet NTS-understøttelse.
- Øget nøjagtighed af tidstrin ti gange ved at bruge fysisk hardwarebinding. Dette skyldes, at moderne computerure er blevet meget mere præcise end dem, der var på plads, da NTP først blev opfundet. De største modtagere af dette var GPSDO og dedikerede radiotidsstationer.
- Antallet af programmeringssprog er blevet reduceret til to. I stedet for Perl, awk og endda S-scripts er det nu alt sammen Python. Dette giver større muligheder for genbrug af kode.
- I stedet for alle de nødvendige Autotools-scripts begyndte projektet at bruge et softwarebyggesystem. .
- Opdateret og reorganiseret projektdokumentationen. Ud fra en modstridende og til tider arkaisk samling af dokumenter skabte de en ret tålelig dokumentation. Hver kommandolinjeparameter og hver konfigurationsenhed har nu en enkelt version af sandheden. Derudover genereres man-sider og webdokumentation nu fra de samme kernefiler.
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 den næstsidste.
(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
Der var endnu et forsøg på at erstatte den gamle NTP med en mere sikker analog. I modsætning til NTPSec er Chrony skrevet fra bunden og designet til at fungere pålideligt under en bred vifte af forhold, herunder ustabile netværksforbindelser, delvis eller overbelastet netværkstilgængelighed og temperaturændringer. Derudover har chrony andre fordele:
- chrony kan synkronisere systemuret hurtigere og med større nøjagtighed;
- chrony er mindre, bruger mindre hukommelse og tilgår kun processoren, når det er nødvendigt. Dette er et stort plus for at spare ressourcer og energi;
- chrony understøtter hardwaretidsstempler i Linux, hvilket muliggør ekstremt præcis synkronisering over lokale netværk.
Chrony mangler dog nogle af de gamle NTP-funktioner såsom broadcast og multicast-klient/server. Derudover understøtter klassisk NTP en bredere vifte af operativsystemer og platforme.
For at deaktivere serverfunktionaliteten og NTP-anmodninger til chronyd-processen skal du blot indtaste port 0 i chrony.conf-filen. Dette gøres i tilfælde, hvor der ikke er behov for at opretholde tid for NTP-klienter eller peers. Siden version 2.0 er NTP-serverporten kun åben, når adgang er tilladt af allow-direktivet eller den tilsvarende kommando, eller når en NTP-peer er konfigureret, eller når broadcast-direktivet bruges.
Programmet består af to moduler.
- chronyd er en tjeneste, der kører i baggrunden. Den modtager information om forskellen mellem systemuret og en ekstern tidsserver og justerer den lokale tid. Den implementerer også NTP-protokollen og kan fungere som en klient eller server.
- chronyc er et kommandolinjeværktøj til overvågning og styring af et program. Bruges til at finjustere forskellige serviceparametre, f.eks. at give dig mulighed for at tilføje eller fjerne NTP-servere, mens chronyd fortsætter med at køre.
Siden RedHat Linux version 7 chrony som en tidssynkroniseringstjeneste. Pakken er også tilgængelig til andre Linux-distributioner. Den seneste stabile version er 3.5, v4.0 er under forberedelse til udgivelse.
(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]
Sådan konfigurerer du din egen eksterne Chrony-server på internettet for at synkronisere tid i et kontornetværk. Nedenfor er et eksempel på opsætning på en VPS.
Eksempel på opsætning af Chrony på RHEL / CentOS på VPS
Lad os nu øve os lidt og sætte vores egen NTP-server op på en VPS. Det er meget simpelt, bare vælg en passende takst på RuVDS' hjemmeside, få en færdiglavet server og indtast et dusin simple kommandoer. Denne mulighed er ret velegnet til vores formål.
Lad os gå videre til opsætningen af tjenesten og først og fremmest installere chrony-pakken.
[root@server ~]$ yum install chronyRHEL 8 / CentOS 8 bruger en anden pakkehåndtering.
[root@server ~]$ dnf install chronyEfter installation af chrony skal du starte og aktivere tjenesten.
[root@server ~]$ systemctl enable chrony --nowHvis det ønskes, kan du redigere /etc/chrony.conf for at erstatte NPT-servere med de nærmeste lokale servere for at reducere svartid.
# 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
Dernæst konfigurerer vi synkronisering af NTP-serveren med noder fra den angivne pool.
[root@server ~]$ timedatectl set-ntp true
[root@server ~]$ systemctl restart chronyd.service
Det er også nødvendigt at åbne NTP-porten udad, ellers vil firewallen blokere 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/MoscowI filen /etc/chrony.conf skal du angive IP-adressen eller værtsnavnet på vores VPS-server, som NTP-serveren chrony kører på.
server my.vps.serverOg til sidst, start tidssynkronisering på klienten.
[root@client ~]$ systemctl enable --now chronyd
[root@client ~]$ timedatectl set-ntp true
Næste gang vil jeg fortælle dig, hvilke muligheder der er for at synkronisere tid uden internettet.
Kilde: www.habr.com
