Kiel certigi, ke la tempo mem ne mensogas, se vi havas milionon da grandaj kaj malgrandaj aparatoj interagantaj per TCP/IP? Fine, ĉiu el ili havas horloĝon, kaj la tempo devas esti ĝusta sur ĉiuj. Ĉi tiu problemo ne povas esti evitata sen ntp.
Ni imagu por minuto, ke en unu segmento de industria IT-infrastrukturo estas malfacilaĵoj kun sinkronigado de servoj laŭ tempo. La stako de entreprena programaro tuj komencas panei, domajnoj disfalas, mastroj kaj rezervaj nodoj malsukcese provas restarigi la status quo-on.
Eblas ankaŭ, ke atakanto intence provas malaltigi la tempon per MiTM aŭ DDOS-atako. En tia situacio, ĉio povas okazi:
- pasvortoj de uzantkontoj eksvalidiĝos;
- X.509-atestiloj eksvalidiĝos;
- TOTP du-faktora aŭtentigo ĉesos funkcii;
- sekurkopioj fariĝos "malaktualaj" kaj la sistemo forigos ilin;
- DNSSec paneos.
Estas klare, ke ĉiu unua IT-fako interesiĝas pri fidinda funkciigo de temposinkronigaj servoj, kaj estus bone se ili estus fidindaj kaj sekuraj en industria funkciigo.
Rompu NTP-on en 25 minutoj
Retaj protokoloj - miljaruloj havas unu komunan aferon: ili delonge estis kaj jam ne taŭgas por io ajn, sed anstataŭigi ilin ne estas tiel facile eĉ kiam oni akiras kritikan mason da entuziasmuloj kaj financado.
La ĉefa plendo pri klasika NTP estas la manko de fidindaj mekanismoj por protekto kontraŭ malicaj atakoj. Diversaj provoj estis faritaj por solvi ĉi tiun problemon. Por fari tion, la antaŭestablita ŝlosila (PSK) mekanismo unue estis enkondukita por la interŝanĝo de simetriaj ŝlosiloj.
Bedaŭrinde, ĉi tiu metodo ne pravigis sin pro simpla kialo - ĝi ne bone skaliĝas. Mana agordo estas necesa ĉe la klienta flanko depende de la servilo. Tio signifas, ke vi ne povas simple aldoni alian klienton. Se io ŝanĝiĝas ĉe la NTP-servilo, vi devas reagordi ĉiujn klientojn.
Poste ili elpensis AutoKey, sed tuj kelkaj gravaj vundeblecoj estis trovitaj en la algoritma dezajno mem kaj ĝi devis esti forlasita. La tuta afero estas, ke la komenca nombro (semo) enhavas nur 32 bitojn, ĝi estas tro malgranda kaj ne enhavas sufiĉe da komputila komplekseco por krudforta atako.
- Ŝlosila ID estas simetria 32-bita ŝlosilo;
- MAC (mesaĝa aŭtentika kodo) — kontrolsumo de NTP-pakaĵo;
Aŭtoŝlosilo estas kalkulata jene.
Autokey=H(Sender-IP||Receiver-IP||KeyID||Cookie)Kie H() estas kriptografia haŝfunkcio.
La sama funkcio estas uzata por kalkuli la kontrolsumon de la pakaĵeto.
MAC=H(Autokey||NTP packet)Montriĝas, ke la tuta integreco de pakaĵkontroloj dependas de la aŭtentikeco de kuketoj. Kaptinte ilin, oni povas restarigi la aŭtoŝlosilon kaj poste falsi la MAC-adreson. Tamen, la NTP-servilo uzas la komencan numeron (semon) dum ilia generado. Jen kie kuŝas la kaptilo.
Cookie=MSB_32(H(Client IP||Server IP||0||Server Seed))La funkcio MSB_32 fortranĉas 5 pli altrangajn bitojn el la rezulto de la md32-haŝa kalkulo. La klienta kuketo ne ŝanĝiĝas dum la servilaj parametroj restas senŝanĝaj. Tiam la atakanto nur bezonas restarigi la komencan nombron kaj akiri la kapablon generi kuketojn sendepende.
Unue, konektu al la NTP-servilo kiel kliento kaj ricevu la kuketon. Post tio, la atakanto reakiras la komencan nombron uzante simplan algoritmon.
Algoritmo por ataki la komencan nombron uzante la krudfortan metodon.
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-adresoj estas konataj, do restas nur krei 2^32 haŝojn ĝis la kreita kuketo kongruas kun tiu ricevita de la NTP-servilo. Ĉe tipa hejma stacio kun Intel Core i5, tio daŭros 25 minutojn.
NTS — nova Aŭtoŝlosilo
Estis neeble toleri tiajn sekurecajn truojn en Autokey, kaj en 2012, protokolo. Por kompromiti la nomon, ili decidis renomigi ĝin, do Autokey v.2 estis nomita Network Time Security.
La protokolo NTS estas sekureca etendaĵo de NTP kaj nuntempe subtenas nur unicast-reĝimon. Ĝi provizas fortan kriptografian protekton kontraŭ pakaĵmanipulado, malhelpas spionadon, bone skaliĝas, estas rezistema al retpakaĵperdo, kaj rezultas en la plej malalta precizecperdo en la procezo de sekurigado de la konekto.
NTS-konekto konsistas el du etapoj, en kiuj oni uzas malaltnivelajn protokolojn. la unua En ĉi tiu etapo, la kliento kaj servilo konsentas pri diversaj konektaj parametroj kaj interŝanĝas kuketojn enhavantajn ŝlosilojn kun ĉiuj akompanantaj datumoj. dua En ĉi tiu stadio, la efektiva sekura NTS-sesio okazas inter la kliento kaj la NTP-servilo.
NTS konsistas el du pli malalttavolaj protokoloj: Network Time Security Key Exchange (NTS-KE), kiu inicialigas sekuran konekton per TLS, kaj NTPv4, la plej nova enkarniĝo de la NTP-protokolo. Pli pri tio sube.
Unua etapo - NTS KE
En ĉi tiu etapo, la NTP-kliento komencas TLS 1.2/1.3-sesion per aparta TCP-konekto al la NTS KE-servilo. Dum ĉi tiu sesio, okazas la sekvanta.
- La partioj difinas la parametrojn algoritmo por la dua etapo.
- La partioj difinas duan pli malaltnivelan protokolon, sed nuntempe nur NTPv4 estas subtenata.
- La partioj difinas la IP-adreson kaj pordon de la NTP-servilo.
- La servilo NTS KE eldonas kuketojn sub NTPv4.
- La partioj eltiras paron da simetriaj ŝlosiloj (C2S kaj S2C) el la kuketomaterialo.
Ĉi tiu aliro havas grandan avantaĝon, ke la tuta ŝarĝo de transdono de sekretaj informoj pri konektoparametroj falas sur la pruvitan kaj fidindan TLS-protokolon. Tial, ne necesas reinventi la radon por sekura NTP-manpremo.
Ŝtupo 2 - NTP sub NTS-protekto
En la dua etapo, la kliento sekure sinkronigas la tempon kun la NTP-servilo. Por tiu celo, ĝi sendas kvar specialajn etendajn kampojn en la pakaĵstrukturo de NTPv4.
- Unika Identigilo-Etendaĵo enhavas hazardan ne-funkcion por malhelpi ripetatakojn.
- La NTS-kuketa etendaĵo enhavas unu el la NTP-kuketoj tenataj de la kliento. Ĉar nur la kliento havas la simetriajn AAED-ŝlosilojn C2S kaj S2C, la NTP-servilo devas ĉerpi ilin el la kuketa materialo.
- La etendaĵo por provizoraj kuketoj de NTS estas maniero por kliento peti pliajn kuketojn de la servilo. Ĉi tiu etendaĵo estas necesa por certigi, ke la respondo de la NTP-servilo ne estas multe pli longa ol la peto. Tio helpas malhelpi plifortigajn atakojn.
- La etendaĵo NTS Authenticator kaj Encrypted Extension Fields enhavas la AAED-algoritman ĉifron kun la C2S-ŝlosilo, NTP-kaplinio, tempstampoj kaj la supre menciita EF kiel subtenaj datumoj. Sen ĉi tiu etendaĵo, eblas falsi tempstampojn.
Post ricevo de peto de la kliento, la servilo kontrolas la aŭtentecon de la NTP-pakaĵo. Por fari tion, ĝi devas malĉifri la kuketojn, eltiri la AAED-algoritmon kaj ŝlosilojn. Post sukcesa kontrolo de la valideco de la NTP-pakaĵo, la servilo respondas al la kliento en la sekva formato.
- Unika Identigilo-Etendo spegula kopio de la klienta peto, rimedo kontraŭ ripetatakoj.
- NTS-Kuketa Etendaĵo pli da kuketoj por daŭrigi la sesion.
- NTS Authenticator kaj Encrypted Extension Fields Extension enhavas AEAD-ĉifron kun S2C-ŝlosilo.
La dua manpremo povas esti ripetata multfoje, preterirante la unuan etapon, ĉar ĉiu peto kaj respondo donas al la kliento pliajn kuketojn. Tio havas la avantaĝon, ke la relative rimedo-intensaj TLS-operacioj de komputado kaj transdono de PKI-datumoj estas dividitaj per la nombro de ripetaj petoj. Tio estas aparte oportuna por specialigitaj FPGA-horloĝoj, kiam ĉiuj bazaj funkcioj povas esti pakitaj en plurajn funkciojn el la kampo de simetria kriptografio, transdonante la tutan TLS-stakon al alia aparato.
NTPSec
Kio specialas pri NTP? Malgraŭ la fakto, ke la aŭtoro de la projekto, Dave Mills, provis dokumenti sian kodon kiel eble plej bone, malofta programisto povos kompreni la komplikaĵojn de temposinkronigaj algoritmoj de antaŭ 35 jaroj. Iuj partoj de la kodo estis skribitaj antaŭ la POSIX-epoko, kaj la Uniksa API estis tre malsama ol tio, kio estas uzata hodiaŭ. Krome, scio pri statistiko estas necesa por purigi la signalon de interfero sur bruaj linioj.
NTS ne estis la unua provo ripari NTP. Post kiam atakantoj lernis ekspluati NTP-vundeblecojn por plifortigi DDoS-atakojn, fariĝis klare, ke radikalaj ŝanĝoj estis necesaj. Kaj dum la skizoj de NTS estis preparataj kaj finpretigataj, la Usona Nacia Scienca Fonduso urĝe asignis stipendion por NTP-modernigo fine de 2014.
La laborgrupon estris neniu alia ol — unu el la fondintoj kaj kolonoj de la Malfermitkoda komunumo kaj la aŭtoro de la libro La unua afero, kiun Eriko kaj liaj kamaradoj provis fari, estis translokigi la NTP-kodon de la platformo BitKeeper al git, sed tio ne funkciis tiel. Projektestro Harlan Stenn kontraŭis ĉi tiun decidon kaj la intertraktadoj atingis sakstraton. Poste oni decidis disbranĉigi la projektan kodon, kaj tiel NTPSec ekestis.
Kun solida fono inkluzive de GPSD, matematika fono kaj magia kapablo legi antikvan kodon, Eric Raymond estis la hakisto kiu sukcesis pri tia projekto. La teamo trovis specialiston pri kodmigrado kaj post nur 10 semajnoj NTP... sur GitLab. La laboro komencis boli.
La teamo de Eric Raymond traktis la problemon kiel Auguste Rodin pritraktus rokblokon. Forigante 175 KLOC-ojn da malnova kodo, ili sukcesis signife redukti sian ataksurfacon, fermante multajn sekurectruojn.
Jen nekompleta listo de la koncernatoj:
- Nedokumentita, malnoviĝinta, malmoderna aŭ rompita refhorloĝo.
- Neuzita ICS-biblioteko.
- libopts/aŭtogen.
- Malnova kodo por Vindozo.
- ntpdc.
- Aŭtoŝlosilo.
- C-kodo ntpq reskribita en Python.
- C-kodo sntp/ntpdig reskribita en Python.
Aldone al kodpurigado, la projekto havis aliajn taskojn. Jen nekompleta listo de atingoj:
- La protekto de la kodo kontraŭ bufrosuperfluoj estis signife plifortigita. Por malhelpi bufrosuperfluojn, ĉiuj nesekuraj tekstfunkcioj (strcpy / strcat / strtok / sprintf / vsprintf / gets) estis anstataŭigitaj per sekuraj versioj, kiuj efektivigas limigon de bufrograndeco.
- Aldonita NTS-subteno.
- La precizeco de tempopaŝoj dekobliĝis per fizika aparatara ligado. Tio estas ĉar modernaj komputilaj horloĝoj fariĝis multe pli precizaj ol tiuj, kiuj ekzistis kiam NTP unue estis enkondukita. La plej grandaj profitantoj de tio estas GPSDO kaj dediĉitaj radiostacioj.
- La nombro de programlingvoj reduktiĝis al du. Anstataŭ Perl, awk kaj eĉ S-skriptoj, nun estas nur Python. Tio permesas pli da ŝancoj por reuzo de kodo.
- Anstataŭ la aro da aŭtomataj iloj-skriptoj, la projekto komencis uzi programaran konstrusistemon. .
- Ĝisdatigis kaj reorganizis la projektan dokumentaron. El malkonsekvenca kaj foje arkaika kolekto de dokumentoj, ni kreis sufiĉe akcepteblan dokumentaron. Ĉiu komandlinia ŝaltilo kaj ĉiu agorda ento nun havas ununuran version de la vero. Krome, la manlibro-paĝoj kaj TTT-dokumentaro nun estas generitaj el la samaj kernaj dosieroj.
NTPSec estas havebla por kelkaj Linuksaj distribuaĵoj. La plej nova stabila versio estas nuntempe 1.1.8, por Gentoo Linukso ĝi estas la antaŭlasta.
(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]
Kroniko
Estis alia provo anstataŭigi la malnovan NTP per pli sekura analogo. Chrony, male al NTPSec, estas skribita de nulo kaj estas desegnita por funkcii fidinde en vasta gamo de kondiĉoj, inkluzive de malstabilaj retkonektoj, parta havebleco aŭ troŝarĝo de la reto, kaj temperaturŝanĝoj. Krome, chrony havas aliajn avantaĝojn:
- chrony povas sinkronigi la sistemhorloĝon pli rapide kaj kun pli granda precizeco;
- chrony estas pli malgranda, uzas malpli da memoro kaj nur aliras la procesoron kiam necese. Tio estas granda avantaĝo por ŝpari rimedojn kaj energion;
- chrony subtenas aparatarajn tempstampojn en Linukso, permesante ekstreme precizan sinkronigadon tra lokaj retoj.
Tamen, al chrony mankas kelkaj funkcioj de la malnova NTP, kiel ekzemple elsendo kaj plurdissendo kliento/servilo. Krome, klasika NTP subtenas pli grandan nombron da operaciumoj kaj platformoj.
Por malŝalti la servilan funkcion kaj NTP-petojn al la procezo chronyd, simple specifu pordon 0 en la dosiero chrony.conf. Ĉi tio estas farata en kazoj kie ne necesas konservi la tempon por NTP-klientoj aŭ samtavolanoj. Ekde versio 2.0, la pordo de la NTP-servilo estas malfermita nur kiam aliro estas permesita per la direktivo "permesi" aŭ la responda komando, aŭ NTP-samtavolano estas agordita, aŭ la direktivo "elsendo" estas uzata.
La programo konsistas el du moduloj.
- chronyd estas fona servo kiu ricevas informojn pri la diferenco inter la sistema horloĝo kaj ekstera temposervilo kaj ĝustigas la lokan tempon. Ĝi ankaŭ efektivigas la NTP-protokolon kaj povas funkcii kiel kliento aŭ servilo.
- chronyc estas komandlinia ilo por monitori kaj kontroli la programon. Ĝi estas uzata por fajnagordi diversajn servparametrojn, ekzemple, ĝi permesas al vi aldoni aŭ forigi NTP-servilojn dum chronyd daŭre funkcias.
Ekde RedHat Linukso versio 7 chrony kiel temposinkroniga servo. La pakaĵo ankaŭ haveblas por aliaj Linuksaj distribuaĵoj. La plej nova stabila versio estas 3.5, kun v4.0 en preparo.
(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]
Kiel starigi vian propran malproksiman kronikan servilon en la Interreto por sinkronigi tempon en oficeja reto. Jen ekzemplo de agordo sur VPS.
Ekzemplo de agordo de Chrony sur RHEL / CentOS sur VPS
Ni nun praktiku iom kaj starigu nian propran NTP-servilon sur VPS. Estas tre simple, nur elektu taŭgan tarifon en la retejo de RuVDS, akiru pretan servilon kaj tajpu dekduon da simplaj komandoj. Por niaj celoj, ĉi tiu opcio estas tute taŭga.
Ni daŭrigu al la agordo de la servo kaj unue instalu la pakaĵon chrony.
[root@server ~]$ yum install chronyRHEL 8 / CentOS 8 uzas malsaman pakaĵadministrilon.
[root@server ~]$ dnf install chronyPost instalado de chrony, vi devas lanĉi kaj aktivigi la servon.
[root@server ~]$ systemctl enable chrony --nowSe vi deziras, vi povas redakti /etc/chrony.conf por anstataŭigi NPT-servilojn per la plej proksimaj lokaj por redukti la respondotempon.
# 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
Poste, ni agordas sinkronigadon de la NTP-servilo kun nodoj el la specifita naĝejo.
[root@server ~]$ timedatectl set-ntp true
[root@server ~]$ systemctl restart chronyd.service
Ankaŭ necesas malfermi la NTP-pordon al la ekstero, alie la fajromuro blokos alvenantajn konektojn de klientaj nodoj.
[root@server ~]$ firewall-cmd --add-service=ntp --permanent
[root@server ~]$ firewall-cmd --reload
Ĉe la kliento, sufiĉas ĝuste agordi la horzonon.
[root@client ~]$ timedatectl set-timezone Europe/MoscowEn la dosiero /etc/chrony.conf, specifu la IP-adreson aŭ gastigan nomon de nia VPS-servilo, sur kiu la NTP-servilo chrony funkcias.
server my.vps.serverKaj fine, komencu temposinkronigadon ĉe la kliento.
[root@client ~]$ systemctl enable --now chronyd
[root@client ~]$ timedatectl set-ntp true
Venontfoje mi diros al vi, kiaj ebloj ekzistas por sinkronigi tempon sen la Interreto.
fonto: www.habr.com
