Como se fixo segura a sincronización horaria

Como asegurarse de que o tempo per se non mente se tes un millón de dispositivos grandes e pequenos que se comunican a través de TCP/IP? Despois de todo, cada un deles ten un reloxo, e a hora debe ser correcta para todos eles. Este problema non se pode evitar sen ntp.

Imaxinemos por un minuto que nun segmento da infraestrutura informática industrial hai dificultades para sincronizar servizos ao longo do tempo. Inmediatamente, a pila de clúster do software Enterprise comeza a fallar, os dominios desintegranse, os nodos mestres e en espera esfórzanse sen éxito por restaurar o status quo.

Tamén é posible que un atacante intente deliberadamente perturbar o tempo mediante un ataque MiTM ou DDOS. En tal situación, pode ocorrer calquera cousa:

• Os contrasinais das contas de usuario caducarán;
• Os certificados X.509 caducarán;
• A autenticación de dous factores TOTP deixará de funcionar;
• as copias de seguridade quedarán obsoletas e o sistema eliminaraas;
• DNSSec romperase.

Está claro que todos os departamentos de TI están interesados ​​no funcionamento fiable dos servizos de sincronización horaria, e sería bo que fosen fiables e seguros no funcionamento industrial.

Rompe NTP en 25 minutos

Os protocolos de rede: os millennials teñen unha peculiaridade, foron desactualizado e xa non serven para nada, pero substituílos non é tan sinxelo aínda que se acumule unha masa crítica de entusiastas e financiamento.

A principal queixa sobre o NTP clásico é a falta de mecanismos fiables para protexerse contra ataques de intrusos. Fixéronse varios intentos para resolver este problema. Para conseguilo, primeiro implementamos un mecanismo de chave precompartida (PSK) para intercambiar claves simétricas.

Desafortunadamente, este método non valeu por unha simple razón: non escala ben. A configuración manual é necesaria no lado do cliente dependendo do servidor. Isto significa que simplemente non pode engadir outro cliente así. Se algo cambia no servidor NTP, todos os clientes deben ser reconfigurados.

Despois ocorréuselles AutoKey, pero inmediatamente descubriron unha serie de graves vulnerabilidades no deseño do propio algoritmo e tiveron que abandonalo. O caso é que a semente contén só 32 bits, é demasiado pequena e non contén a complexidade computacional suficiente para un ataque frontal.

• ID de chave: chave simétrica de 32 bits;
• MAC (código de autenticación de mensaxes) - suma de verificación de paquetes NTP;

Autokey calcúlase do seguinte xeito.

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

Onde H() é unha función hash criptográfica.

A mesma función úsase para calcular a suma de verificación dos paquetes.

MAC=H(Autokey||NTP packet)

Resulta que toda a integridade das comprobacións de paquetes depende da autenticidade das cookies. Unha vez que os teñas, podes restaurar a tecla automática e despois falsificar o MAC. Non obstante, o servidor NTP usa unha semente ao xeralos. Aquí é onde está a trampa.

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

A función MSB_32 corta os 5 bits máis significativos do resultado do cálculo hash md32. A cookie do cliente non cambia mentres os parámetros do servidor permanecen inalterados. Entón, o atacante só pode restaurar o número inicial e poder xerar cookies de forma independente.

En primeiro lugar, cómpre conectarse ao servidor NTP como cliente e recibir cookies. Despois diso, usando un método de forza bruta, o atacante restaura o número inicial seguindo un algoritmo sinxelo.

Algoritmo para atacar o cálculo do número inicial mediante o método da forza 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 for

Os enderezos IP son coñecidos, polo que só queda crear 2^32 hash ata que a cookie creada coincida coa recibida do servidor NTP. Nunha estación doméstica normal con Intel Core i5, isto levará 25 minutos.

NTS: nova tecla automática

Era imposible soportar tales buratos de seguridade en Autokey, e en 2012 apareceu unha nova versión protocolo. Para comprometer o nome, decidiron cambiar de marca, polo que Autokey v.2 foi denominado Network Time Security.

O protocolo NTS é unha extensión da seguridade NTP e actualmente só admite o modo unicast. Proporciona unha forte protección criptográfica contra a manipulación de paquetes, evita o espionaje, escala ben, é resistente á perda de paquetes de rede e produce a menor cantidade de perdas de precisión durante a seguridade da conexión.

Unha conexión NTS consta de dúas etapas que usan protocolos de capa inferior. Activado o primeiro Nesta fase, o cliente e o servidor acordan varios parámetros de conexión e intercambian cookies que conteñen claves con todo o conxunto de datos que o acompaña. Activado segundo Nesta fase, a sesión NTS protexida real ten lugar entre o cliente e o servidor NTP.

NTS consta de dous protocolos de capa inferior: Network Time Security Key Exchange (NTS-KE), que inicia unha conexión segura a través de TLS, e NTPv4, a última encarnación do protocolo NTP. Un pouco máis sobre isto a continuación.

Primeira fase - NTS KE

Nesta fase, o cliente NTP inicia unha sesión TLS 1.2/1.3 a través dunha conexión TCP separada co servidor NTS KE. Durante esta sesión ocorre o seguinte.

• As partes determinan os parámetros AEAD algoritmo para a segunda etapa.
• As partes definen un segundo protocolo de capa inferior, pero polo momento só se admite NTPv4.
• As partes determinan o enderezo IP e o porto do servidor NTP.
• O servidor NTS KE emite cookies baixo NTPv4.
• As partes extraen un par de claves simétricas (C2S e S2C) do material de galletas.

Este enfoque ten a gran vantaxe de que toda a carga de transmitir información secreta sobre os parámetros de conexión recae no protocolo TLS comprobado e fiable. Isto elimina a necesidade de reinventar a túa propia roda para un apretón de mans NTP seguro.

Segunda etapa - NTP baixo protección NTS

No segundo paso, o cliente sincroniza de forma segura a hora co servidor NTP. Para este fin, transmite catro extensións especiais (campos de extensión) na estrutura de paquetes NTPv4.

• A extensión do identificador único contén un nonce aleatorio para evitar ataques de repetición.
• A extensión de cookies NTS contén unha das cookies NTP dispoñibles para o cliente. Dado que só o cliente ten as claves AAED simétricas C2S e S2C, o servidor NTP debe extraelas do material de cookies.
• NTS Cookie Placeholder Extension é unha forma de que un cliente solicite cookies adicionais ao servidor. Esta extensión é necesaria para garantir que a resposta do servidor NTP non sexa moito máis longa que a solicitude. Isto axuda a evitar ataques de amplificación.
• A extensión de campos de extensión cifrada e autenticador NTS contén o cifrado AAED coa clave C2S, a cabeceira NTP, as marcas de tempo e o EF anterior como datos que se acompañan. Sen esta extensión é posible falsificar marcas de tempo.

Ao recibir unha solicitude dun cliente, o servidor verifica a autenticidade do paquete NTP. Para iso, debe descifrar as cookies, extraer o algoritmo AAED e as claves. Despois de comprobar a validez do paquete NTP, o servidor responde ao cliente no seguinte formato.

• A extensión de identificador único é unha copia espellada da solicitude do cliente, unha medida contra os ataques de repetición.
• NTS Cookie Extension máis cookies para continuar a sesión.
• A extensión NTS Authenticator e Encrypted Extension Fields contén o cifrado AEAD cunha clave S2C.

O segundo apretón de mans pódese repetir moitas veces, evitando o primeiro paso, xa que cada petición e resposta dálle ao cliente cookies adicionais. Isto ten a vantaxe de que as operacións TLS relativamente intensivas en recursos de computación e transmisión de datos PKI divídense polo número de solicitudes repetidas. Isto é especialmente conveniente para cronometradores especializados de FPGA, cando toda a funcionalidade principal pódese empaquetar en varias funcións do campo da criptografía simétrica, transferindo toda a pila TLS a outro dispositivo.

NTPSec

Que ten de especial NTP? A pesar de que o autor do proxecto, Dave Mills, intentou documentar o seu código o mellor posible, é un programador raro que será capaz de comprender as complejidades dos algoritmos de sincronización de tempo que teñen 35 anos. Parte do código foi escrito antes da era POSIX, e a API de Unix entón era moi diferente do que se usa hoxe. Ademais, é necesario o coñecemento das estatísticas para limpar o sinal de interferencias nas liñas ruidosas.

NTS non foi o primeiro intento de arranxar NTP. Unha vez que os atacantes aprenderon a explotar as vulnerabilidades NTP para amplificar os ataques DDoS, quedou claro que eran necesarios cambios radicais. E mentres se preparaban e finalizaban os borradores do NTS, a Fundación Nacional de Ciencia dos Estados Unidos a finais de 2014 destinou urxentemente unha subvención para a modernización do NTP.

O grupo de traballo non estaba encabezado por calquera, senón Eric Steven Raymond - un dos fundadores e piares da comunidade Open Source e autor do libro Catedral e Bazar. O primeiro que tentaron Eric e os seus amigos foi mover o código NTP da plataforma BitKeeper a git, pero non funcionou así. O líder do proxecto, Harlan Stenn, estaba en contra desta decisión e as negociacións paralizáronse. Entón decidiuse bifurcar o código do proxecto e naceu NTPSec.

Sólida experiencia, incluíndo traballos sobre GPSD, unha formación matemática e a habilidade máxica de ler códigos antigos: Eric Raymond foi exactamente o hacker que puido levar a cabo un proxecto deste tipo. O equipo atopou un especialista en migración de código e en só 10 semanas NTP asentadoen GitLab. O traballo estaba en pleno apoxeo.

O equipo de Eric Raymond asumiu a tarefa do mesmo xeito que o fixo Auguste Rodin cun bloque de pedra. Ao eliminar 175 KLOC do código antigo, puideron reducir significativamente a superficie de ataque pechando moitos buratos de seguridade.

Aquí tes unha lista incompleta dos incluídos na distribución:

• Refclock non documentado, desactualizado, desactualizado ou roto.
• Biblioteca ICS non utilizada.
• libopts/autogen.
• Código antigo para Windows.
• ntpdc.
• Tecla automática.
• O código C ntpq foi reescrito en Python.
• O código C sntp/ntpdig foi reescrito en Python.

Ademais de limpar o código, o proxecto tiña outras tarefas. Aquí tes unha lista parcial de logros:

• A protección do código contra o desbordamento do búfer mellorouse significativamente. Para evitar desbordamentos do búfer, todas as funcións de cadea non seguras (strcpy/strcat/strtok/sprintf/vsprintf/gets) substituíronse por versións seguras que implementan límites de tamaño do búfer.
• Engadido soporte NTS.
• A precisión do paso de tempo mellorou dez veces ao conectar hardware físico. Isto débese ao feito de que os reloxos dos ordenadores modernos fixéronse moito máis precisos que os de cando naceu NTP. Os maiores beneficiados disto foron GPSDO e radios de tempo dedicado.
• O número de linguaxes de programación reduciuse a dous. En lugar de scripts Perl, awk e incluso S, agora é todo Python. Debido a isto, hai máis oportunidades para a reutilización do código.
• No canto de fideos de scripts de autotools, o proxecto comezou a usar un sistema de compilación de software waf.
• Documentación do proxecto actualizada e reorganizada. A partir dunha colección de documentos contraditoria e ás veces arcaica, crearon documentación bastante transitable. Cada interruptor de liña de comandos e cada entidade de configuración ten agora unha única versión da verdade. Ademais, agora créanse páxinas man e documentación web a partir dos mesmos ficheiros principais.

NTPSec está dispoñible para varias distribucións de Linux. Polo momento, a última versión estable é a 1.1.8, para Gentoo Linux é a 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]

Cronía

Houbo outro intento de substituír o antigo NTP por unha alternativa máis segura. Chrony, a diferenza de NTPSec, está escrito desde cero e está deseñado para funcionar de forma fiable baixo unha ampla gama de condicións, incluíndo conexións de rede inestables, dispoñibilidade ou conxestión parcial da rede e cambios de temperatura. Ademais, a crónica ten outras vantaxes:

• chrony pode sincronizar o reloxo do sistema máis rápido con maior precisión;
• chrony é máis pequeno, consume menos memoria e accede á CPU só cando é necesario. Esta é unha gran vantaxe para aforrar recursos e enerxía;
• chrony admite marcas de tempo de hardware en Linux, o que permite unha sincronización extremadamente precisa nas redes locais.

Non obstante, Chrony carece dalgunhas das características do antigo NTP, como o cliente/servidor de transmisión e multidifusión. Ademais, o NTP clásico admite un maior número de sistemas operativos e plataformas.

Para desactivar a funcionalidade do servidor e as solicitudes NTP ao proceso chronyd, só tes que escribir o porto 0 no ficheiro chrony.conf. Isto faise nos casos nos que non hai necesidade de manter o tempo para os clientes NTP ou os pares. Desde a versión 2.0, o porto do servidor NTP só está aberto cando se permite o acceso mediante unha directiva allow ou un comando apropiado, ou se configura un par NTP ou se utiliza unha directiva de difusión.

O programa consta de dous módulos.

• chronyd é un servizo que se executa en segundo plano. Recibe información sobre a diferenza entre o reloxo do sistema e o servidor de tempo externo e axusta a hora local. Tamén implementa o protocolo NTP e pode actuar como cliente ou servidor.
• chronyc é unha utilidade de liña de comandos para o seguimento e control de programas. Utilízase para afinar varios parámetros do servizo, por exemplo, permíteche engadir ou eliminar servidores NTP mentres chronyd continúa a funcionar.

Desde a versión 7 de RedHat Linux usos chrony como servizo de sincronización horaria. O paquete tamén está dispoñible para outras distribucións de Linux. A última versión estable é a 3.5, que se prepara para o lanzamento da 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]

Como configurar o seu propio servidor de chrony remoto en Internet para sincronizar o tempo nunha rede de oficina. A continuación móstrase un exemplo de configuración dun VPS.

Exemplo de configuración de Chrony en RHEL / CentOS en VPS

Agora practiquemos un pouco e configuremos o noso propio servidor NTP nun VPS. É moi sinxelo, só tes que escoller a tarifa adecuada no sitio web de RuVDS, conseguir un servidor preparado e escribir unha ducia de comandos sinxelos. Para os nosos propósitos, esta opción é bastante adecuada.

Pasemos á configuración do servizo e instalemos primeiro o paquete chrony.

[root@server ~]$ yum install chrony

RHEL 8 / CentOS 8 usa un xestor de paquetes diferente.

[root@server ~]$ dnf install chrony

Despois de instalar chrony, cómpre iniciar e activar o servizo.

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

Se o desexa, pode facer cambios en /etc/chrony.conf, substituíndo os servidores NPT polos locais máis próximos para reducir o tempo 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ón, configuramos a sincronización do servidor NTP con nós do grupo especificado.

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

Tamén é necesario abrir o porto NTP ao exterior, se non, o firewall bloqueará as conexións entrantes dos nodos do cliente.

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

No lado do cliente, abonda con establecer correctamente a zona horaria.

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

O ficheiro /etc/chrony.conf especifica a IP ou o nome de host do noso servidor VPS que executa o servidor NTP chrony.

server my.vps.server

E, finalmente, comezando a sincronización horaria no cliente.

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

A próxima vez contarei que opcións hai para sincronizar o tempo sen Internet.

Fonte: www.habr.com