Com assegurar-se que el temps per se no menteix si teniu un milió de dispositius grans i petits que es comuniquen mitjançant TCP/IP? Al cap i a la fi, cadascun d'ells té un rellotge, i l'hora ha de ser correcta per a tots. Aquest problema no es pot evitar sense ntp.
Imaginem per un minut que en un segment de la infraestructura informàtica industrial hi ha dificultats per sincronitzar els serveis al llarg del temps. Immediatament, la pila de clúster de programari empresarial comença a fallar, els dominis es desintegren, els nodes mestres i en espera s'esforcen sense èxit per restaurar l'estat quo.
També és possible que un atacant intenti deliberadament interrompre el temps mitjançant un atac MiTM o DDOS. En aquesta situació, pot passar qualsevol cosa:
- Les contrasenyes del compte d'usuari caducaran;
- Els certificats X.509 caducaran;
- L'autenticació de dos factors TOTP deixarà de funcionar;
- les còpies de seguretat quedaran obsoletes i el sistema les suprimirà;
- DNSSec es trencarà.
És evident que tots els departaments informàtics estan interessats en el funcionament fiable dels serveis de sincronització horària, i estaria bé que fossin fiables i segurs en el funcionament industrial.
Trenqueu NTP en 25 minuts
Els protocols de xarxa: els millennials tenen una peculiaritat, ho han estat i ja no serveixen per a res, però substituir-los no és tan fàcil fins i tot quan s'acumula una massa crítica d'entusiastes i finançament.
La principal queixa sobre NTP clàssic és la manca de mecanismes fiables per protegir-se dels atacs d'intrusos. S'han fet diferents intents per resoldre aquest problema. Per aconseguir-ho, primer hem implementat un mecanisme de clau prèviament compartida (PSK) per intercanviar claus simètriques.
Malauradament, aquest mètode no va donar els seus fruits per una raó senzilla: no escala bé. La configuració manual és necessària al costat del client en funció del servidor. Això vol dir que simplement no podeu afegir un altre client així. Si canvia alguna cosa al servidor NTP, s'han de reconfigurar tots els clients.
Llavors van sortir amb AutoKey, però immediatament van descobrir una sèrie de vulnerabilitats greus en el disseny del propi algorisme i van haver d'abandonar-lo. El cas és que la llavor només conté 32 bits, és massa petita i no conté prou complexitat computacional per a un atac frontal.
- ID de clau: clau simètrica de 32 bits;
- MAC (codi d'autenticació de missatges) - suma de comprovació de paquets NTP;
Autokey es calcula de la següent manera.
Autokey=H(Sender-IP||Receiver-IP||KeyID||Cookie)On H() és una funció hash criptogràfica.
La mateixa funció s'utilitza per calcular la suma de control dels paquets.
MAC=H(Autokey||NTP packet)Resulta que tota la integritat de les comprovacions de paquets es basa en l'autenticitat de les galetes. Un cop els tingueu, podeu restaurar la clau automàtica i, a continuació, falsificar el MAC. Tanmateix, el servidor NTP utilitza una llavor quan els genera. Aquí és on rau la trampa.
Cookie=MSB_32(H(Client IP||Server IP||0||Server Seed))La funció MSB_32 talla els 5 bits més significatius del resultat del càlcul hash md32. La galeta del client no canvia mentre els paràmetres del servidor es mantinguin sense canvis. Aleshores, l'atacant només pot restaurar el número inicial i ser capaç de generar cookies de manera independent.
En primer lloc, cal connectar-se al servidor NTP com a client i rebre galetes. Després d'això, utilitzant un mètode de força bruta, l'atacant restaura el número inicial seguint un algorisme senzill.
Algorisme per atacar el càlcul del nombre inicial mitjançant el mètode de força bruta.
for i=0:2^32 − 1 do
Ci=H(Server-IP||Client-IP||0||i)
if Ci=Cookie then
return i
end if
end forLes adreces IP es coneixen, de manera que només queda crear 2^32 hash fins que la galeta creada coincideixi amb la rebuda del servidor NTP. En una estació domèstica normal amb Intel Core i5, això trigarà 25 minuts.
NTS - nou Autokey
Era impossible suportar aquests forats de seguretat a Autokey, i el 2012 va aparèixer protocol. Per tal de comprometre el nom, van decidir canviar de marca, de manera que Autokey v.2 es va anomenar Network Time Security.
El protocol NTS és una extensió de la seguretat NTP i actualment només admet el mode unicast. Proporciona una forta protecció criptogràfica contra la manipulació de paquets, impedeix el rastreig, s'escala bé, és resistent a la pèrdua de paquets de xarxa i provoca la menor quantitat de pèrdua de precisió durant la seguretat de la connexió.
Una connexió NTS consta de dues etapes que utilitzen protocols de capa inferior. Encès el primer En aquesta fase, el client i el servidor acorden diversos paràmetres de connexió i intercanvien galetes que contenen claus amb tot el conjunt de dades que l'acompanyen. Encès segon En aquesta etapa, la sessió NTS protegida real té lloc entre el client i el servidor NTP.
NTS consta de dos protocols de capa inferior: Network Time Security Key Exchange (NTS-KE), que inicia una connexió segura a través de TLS, i NTPv4, l'última encarnació del protocol NTP. Una mica més sobre això a continuació.
Primera etapa - NTS KE
En aquesta etapa, el client NTP inicia una sessió TLS 1.2/1.3 mitjançant una connexió TCP independent amb el servidor NTS KE. Durant aquesta sessió succeeix el següent.
- Les parts determinen els paràmetres algorisme per a la segona etapa.
- Les parts defineixen un segon protocol de capa inferior, però de moment només és compatible amb NTPv4.
- Les parts determinen l'adreça IP i el port del servidor NTP.
- El servidor NTS KE emet galetes sota NTPv4.
- Les parts extreuen un parell de claus simètriques (C2S i S2C) del material de galetes.
Aquest enfocament té el gran avantatge que tota la càrrega de transmetre informació secreta sobre els paràmetres de connexió recau en el protocol TLS provat i fiable. Això elimina la necessitat de reinventar la vostra pròpia roda per a una encaixada de mans NTP segura.
Segona etapa - NTP sota protecció NTS
En el segon pas, el client sincronitza de manera segura l'hora amb el servidor NTP. Amb aquesta finalitat, transmet quatre extensions especials (camps d'extensió) a l'estructura de paquets NTPv4.
- L'extensió d'identificador únic conté un nonce aleatori per evitar atacs de reproducció.
- L'extensió de galetes NTS conté una de les galetes NTP disponibles per al client. Com que només el client té les claus simètriques AAED C2S i S2C, el servidor NTP ha d'extreure-les del material de galetes.
- NTS Cookie Placeholder Extension és una manera perquè un client sol·liciti galetes addicionals al servidor. Aquesta extensió és necessària per garantir que la resposta del servidor NTP no sigui molt més llarga que la sol·licitud. Això ajuda a prevenir atacs d'amplificació.
- L'extensió de camps d'extensió xifrada i autenticador NTS conté el xifratge AAED amb la clau C2S, la capçalera NTP, les marques de temps i l'EF anterior com a dades acompanyades. Sense aquesta extensió és possible falsificar les marques de temps.
En rebre una sol·licitud d'un client, el servidor verifica l'autenticitat del paquet NTP. Per fer-ho, ha de desxifrar les cookies, extreure l'algoritme AAED i les claus. Després de comprovar correctament la validesa del paquet NTP, el servidor respon al client amb el format següent.
- L'extensió d'identificador únic és una còpia mirall de la sol·licitud del client, una mesura contra els atacs de reproducció.
- Extensió de galetes NTS més galetes per continuar la sessió.
- L'extensió de camps d'extensió xifrada i autenticador NTS conté el xifratge AEAD amb una clau S2C.
La segona encaixada de mans es pot repetir moltes vegades, obviant el primer pas, ja que cada sol·licitud i resposta ofereix al client cookies addicionals. Això té l'avantatge que les operacions TLS relativament intensives en recursos de la computació i la transmissió de dades PKI es divideixen pel nombre de sol·licituds repetides. Això és especialment convenient per als cronometradors especialitzats de FPGA, quan tota la funcionalitat principal es pot empaquetar en diverses funcions del camp de la criptografia simètrica, transferint tota la pila TLS a un altre dispositiu.
NTPSec
Què té d'especial NTP? Malgrat que l'autor del projecte, Dave Mills, va intentar documentar el seu codi de la millor manera possible, és un programador rar que serà capaç d'entendre les complexitats dels algorismes de sincronització de temps que tenen 35 anys. Part del codi es va escriure abans de l'era POSIX, i l'API d'Unix aleshores era molt diferent de la que s'utilitza actualment. A més, es necessita coneixements estadístics per netejar el senyal de les interferències en línies sorolloses.
NTS no va ser el primer intent d'arreglar NTP. Una vegada que els atacants van aprendre a explotar les vulnerabilitats NTP per amplificar els atacs DDoS, va quedar clar que es necessitaven canvis radicals. I mentre s'estaven preparant i finalitzant els esborranys de NTS, la Fundació Nacional de Ciència dels EUA a finals de 2014 va destinar urgentment una subvenció per a la modernització de la NTP.
El grup de treball no estava encapçalat per qualsevol, sinó - un dels fundadors i pilars de la comunitat Open Source i autor del llibre . El primer que van intentar fer l'Eric i els seus amics va ser moure el codi NTP de la plataforma BitKeeper a git, però no va funcionar així. El líder del projecte, Harlan Stenn, estava en contra d'aquesta decisió i les negociacions es van estancar. Aleshores es va decidir bifurcar el codi del projecte i va néixer NTPSec.
Una sòlida experiència, que inclou treballs en GPSD, un bagatge matemàtic i l'habilitat màgica de llegir codi antic: Eric Raymond va ser exactament el pirata informàtic que podria tirar endavant un projecte d'aquest tipus. L'equip va trobar un especialista en migració de codi i en només 10 setmanes NTP a GitLab. La feina estava en ple apogeu.
L'equip d'Eric Raymond va assumir la tasca de la mateixa manera que Auguste Rodin ho va fer amb un bloc de pedra. En eliminar 175 KLOC de codi antic, van poder reduir significativament la superfície d'atac tancant molts forats de seguretat.
Aquí teniu una llista incompleta dels inclosos en la distribució:
- Refclock no documentat, obsolet, obsolet o trencat.
- Biblioteca ICS no utilitzada.
- libopts/autogen.
- Codi antic per a Windows.
- ntpdc.
- Tecla automàtica.
- El codi C ntpq s'ha reescrit en Python.
- El codi C sntp/ntpdig s'ha reescrit en Python.
A més de netejar el codi, el projecte tenia altres tasques. Aquí teniu una llista parcial d'assoliments:
- La protecció del codi contra el desbordament de la memòria intermèdia s'ha millorat significativament. Per evitar desbordaments de memòria intermèdia, totes les funcions de cadena no segures (strcpy/strcat/strtok/sprintf/vsprintf/gets) s'han substituït per versions segures que implementen límits de mida de memòria intermèdia.
- S'ha afegit suport NTS.
- S'ha millorat la precisió del pas de temps deu vegades mitjançant l'enllaç de maquinari físic. Això es deu al fet que els rellotges d'ordinador moderns s'han tornat molt més precisos que els de quan va néixer NTP. Els majors beneficiaris d'això van ser GPSDO i les ràdios de temps dedicats.
- El nombre de llenguatges de programació s'ha reduït a dos. En lloc dels scripts Perl, awk i fins i tot S, ara és tot Python. A causa d'això, hi ha més oportunitats per a la reutilització del codi.
- En lloc de fideus d'scripts d'autotools, el projecte va començar a utilitzar un sistema de creació de programari .
- Actualització i reorganització de la documentació del projecte. A partir d'una col·lecció de documents contradictòria i de vegades arcaica, van crear una documentació força transitable. Cada commutador de línia d'ordres i cada entitat de configuració ara té una única versió de la veritat. A més, ara les pàgines man i la documentació web es creen a partir dels mateixos fitxers bàsics.
NTPSec està disponible per a diverses distribucions de Linux. De moment, la darrera versió estable és la 1.1.8, per a Gentoo Linux és la penúltima.
(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]
Crònica
Hi va haver un altre intent de substituir l'antiga NTP per una alternativa més segura. Chrony, a diferència de NTPSec, està escrit des de la base i està dissenyat per funcionar de manera fiable en una àmplia gamma de condicions, com ara connexions de xarxa inestables, disponibilitat o congestió parcial de la xarxa i canvis de temperatura. A més, la crònica té altres avantatges:
- chrony pot sincronitzar el rellotge del sistema més ràpidament amb una major precisió;
- chrony és més petit, consumeix menys memòria i accedeix a la CPU només quan és necessari. Això és un gran avantatge per estalviar recursos i energia;
- chrony admet segells de temps de maquinari a Linux, permetent una sincronització extremadament precisa a les xarxes locals.
Tanmateix, Chrony no té algunes de les característiques de l'antiga NTP, com ara el client/servidor de broadcast i multicast. A més, l'NTP clàssic admet un nombre més gran de sistemes operatius i plataformes.
Per desactivar la funcionalitat del servidor i les sol·licituds NTP al procés chronyd, només cal que escriviu el port 0 al fitxer chrony.conf. Això es fa en els casos en què no cal mantenir el temps per als clients o companys NTP. Des de la versió 2.0, el port del servidor NTP està obert només quan l'accés està permès per una directiva allow o una ordre adequada, o quan es configura un peer NTP o s'utilitza una directiva de difusió.
El programa consta de dos mòduls.
- chronyd és un servei que s'executa en segon pla. Rep informació sobre la diferència entre el rellotge del sistema i el servidor horari extern i ajusta l'hora local. També implementa el protocol NTP i pot actuar com a client o servidor.
- chronyc és una utilitat de línia d'ordres per al seguiment i control de programes. S'utilitza per ajustar diversos paràmetres de servei, per exemple, per afegir o eliminar servidors NTP mentre chronyd continua funcionant.
Des de la versió 7 de RedHat Linux chrony com a servei de sincronització horària. El paquet també està disponible per a altres distribucions de Linux. L'última versió estable és la 3.5, que es prepara per al llançament de la 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]
Com configurar el vostre propi servidor chrony remot a Internet per sincronitzar l'hora en una xarxa d'oficina. A continuació es mostra un exemple de configuració d'un VPS.
Exemple de configuració de Chrony a RHEL / CentOS a VPS
Ara practiquem una mica i configurem el nostre propi servidor NTP en un VPS. És molt senzill, només heu de triar la tarifa adequada al lloc web de RuVDS, obtenir un servidor preparat i escriure una dotzena d'ordres senzilles. Per als nostres propòsits, aquesta opció és molt adequada.
Passem a configurar el servei i primer instal·lem el paquet chrony.
[root@server ~]$ yum install chronyRHEL 8 / CentOS 8 utilitzen un gestor de paquets diferent.
[root@server ~]$ dnf install chronyDesprés d'instal·lar chrony, heu d'iniciar i activar el servei.
[root@server ~]$ systemctl enable chrony --nowSi ho desitja, podeu fer canvis a /etc/chrony.conf, substituint els servidors NPT pels locals més propers per reduir el temps de resposta.
# 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
A continuació, configurem la sincronització del servidor NTP amb nodes del grup especificat.
[root@server ~]$ timedatectl set-ntp true
[root@server ~]$ systemctl restart chronyd.service
També cal obrir el port NTP a l'exterior, en cas contrari, el tallafoc bloquejarà les connexions entrants dels nodes del client.
[root@server ~]$ firewall-cmd --add-service=ntp --permanent
[root@server ~]$ firewall-cmd --reload
Per part del client, n'hi ha prou amb configurar correctament la zona horària.
[root@client ~]$ timedatectl set-timezone Europe/MoscowEl fitxer /etc/chrony.conf especifica la IP o el nom d'amfitrió del nostre servidor VPS que executa el servidor NTP chrony.
server my.vps.serverI finalment, començar la sincronització horària al client.
[root@client ~]$ systemctl enable --now chronyd
[root@client ~]$ timedatectl set-ntp true
La propera vegada us explicaré quines opcions hi ha per sincronitzar l'hora sense Internet.
Font: www.habr.com
