¿Cómo asegurarse de que el tiempo per se no mienta si tiene un millón de dispositivos grandes y pequeños comunicándose a través de TCP/IP? Después de todo, cada uno tiene un reloj y la hora debe ser la correcta para todos. Este problema no se puede evitar sin ntp.
Imaginemos por un momento que en un segmento de la infraestructura de TI industrial hay dificultades para sincronizar los servicios a lo largo del tiempo. Inmediatamente, la pila del clúster de software empresarial comienza a fallar, los dominios se desintegran, los nodos maestros y en espera se esfuerzan sin éxito por restaurar el status quo.
También es posible que un atacante intente deliberadamente alterar el tiempo mediante un ataque MiTM o DDOS. En tal situación, puede pasar cualquier cosa:
- Las contraseñas de las cuentas de usuario caducarán;
- Los certificados X.509 caducarán;
- La autenticación de dos factores TOTP dejará de funcionar;
- las copias de seguridad quedarán obsoletas y el sistema las eliminará;
- DNSSec se romperá.
Está claro que todos los departamentos de TI están interesados en el funcionamiento fiable de los servicios de sincronización horaria, y sería bueno que fueran fiables y seguros en el funcionamiento industrial.
Romper NTP en 25 minutos
Protocolos de red: los millennials tienen una peculiaridad: han sido y ya no sirven para nada, pero sustituirlos no es tan fácil incluso cuando se acumula una masa crítica de entusiastas y financiación.
La principal queja del NTP clásico es la falta de mecanismos fiables de protección contra ataques de intrusos. Se han realizado varios intentos para resolver este problema. Para lograr esto, primero implementamos un mecanismo de clave precompartida (PSK) para intercambiar claves simétricas.
Desafortunadamente, este método no dio sus frutos por una sencilla razón: no escala bien. Se requiere configuración manual en el lado del cliente dependiendo del servidor. Esto significa que simplemente no puedes agregar otro cliente así. Si algo cambia en el servidor NTP, se deben reconfigurar todos los clientes.
Luego se les ocurrió AutoKey, pero inmediatamente descubrieron una serie de vulnerabilidades graves en el diseño del algoritmo y tuvieron que abandonarlo. El caso es que la semilla contiene sólo 32 bits, es demasiado pequeña y no contiene suficiente complejidad computacional para un ataque frontal.
- ID de clave: clave simétrica de 32 bits;
- MAC (código de autenticación de mensajes): suma de comprobación del paquete NTP;
La clave automática se calcula de la siguiente manera.
Autokey=H(Sender-IP||Receiver-IP||KeyID||Cookie)Donde H() es una función hash criptográfica.
La misma función se utiliza para calcular la suma de comprobación de los paquetes.
MAC=H(Autokey||NTP packet)Resulta que toda la integridad de las comprobaciones de paquetes depende de la autenticidad de las cookies. Una vez que los tenga, puede restaurar la clave automática y luego falsificar la MAC. Sin embargo, el servidor NTP utiliza una semilla al generarlos. Aquí es donde está el problema.
Cookie=MSB_32(H(Client IP||Server IP||0||Server Seed))La función MSB_32 corta los 5 bits más significativos del resultado del cálculo hash md32. La cookie del cliente no cambia mientras los parámetros del servidor permanezcan sin cambios. Entonces el atacante solo puede restaurar el número inicial y generar cookies de forma independiente.
Primero, debe conectarse al servidor NTP como cliente y recibir cookies. Después de esto, utilizando un método de fuerza bruta, el atacante restaura el número inicial siguiendo un algoritmo simple.
Algoritmo para atacar el cálculo del número inicial mediante el método de fuerza 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 forLas direcciones IP son conocidas, por lo que solo queda crear 2^32 hashes hasta que la cookie creada coincida con la recibida del servidor NTP. En una estación doméstica normal con Intel Core i5, esto tardará 25 minutos.
NTS - nueva clave automática
Era imposible soportar tales agujeros de seguridad en Autokey, y en 2012 apareció protocolo. Para comprometer el nombre, decidieron cambiar el nombre, por lo que Autokey v.2 se denominó Network Time Security.
El protocolo NTS es una extensión de la seguridad NTP y actualmente solo admite el modo de unidifusión. Proporciona una sólida protección criptográfica contra la manipulación de paquetes, evita el espionaje, se escala bien, es resistente a la pérdida de paquetes de red y produce la menor cantidad de pérdida de precisión incurrida durante la seguridad de la conexión.
Una conexión NTS consta de dos etapas que utilizan protocolos de capa inferior. En primero En esta etapa, el cliente y el servidor acuerdan varios parámetros de conexión e intercambian cookies que contienen claves con todo el conjunto de datos que las acompaña. En segundo En esta etapa, la sesión NTS protegida real tiene lugar entre el cliente y el servidor NTP.
NTS consta de dos protocolos de capa inferior: Network Time Security Key Exchange (NTS-KE), que inicia una conexión segura a través de TLS, y NTPv4, la última encarnación del protocolo NTP. Un poco más sobre esto a continuación.
Primera etapa - NTS KE
En esta etapa, el cliente NTP inicia una sesión TLS 1.2/1.3 a través de una conexión TCP separada con el servidor NTS KE. Durante esta sesión sucede lo siguiente.
- Las partes determinan los parámetros. Algoritmo para la segunda etapa.
- Las partes definen un segundo protocolo de capa inferior, pero por el momento sólo se admite NTPv4.
- Las partes determinan la dirección IP y el puerto del servidor NTP.
- El servidor NTS KE emite cookies bajo NTPv4.
- Las partes extraen un par de claves simétricas (C2S y S2C) del material de la cookie.
Este enfoque tiene la gran ventaja de que toda la carga de transmitir información secreta sobre los parámetros de conexión recae en el protocolo TLS, probado y fiable. Esto elimina la necesidad de reinventar su propia rueda para un protocolo de enlace NTP seguro.
Segunda etapa: NTP bajo protección NTS
En el segundo paso, el cliente sincroniza de forma segura la hora con el servidor NTP. Para ello transmite cuatro extensiones especiales (campos de extensión) en la estructura de paquetes NTPv4.
- La extensión de identificador único contiene un nonce aleatorio para evitar ataques de repetición.
- NTS Cookie Extension contiene una de las cookies NTP disponibles para el cliente. Dado que solo el cliente tiene las claves AAED simétricas C2S y S2C, el servidor NTP debe extraerlas del material de las cookies.
- La extensión de marcador de posición de cookies NTS es una forma para que un cliente solicite cookies adicionales del servidor. Esta extensión es necesaria para garantizar que la respuesta del servidor NTP no sea mucho más larga que la solicitud. Esto ayuda a prevenir ataques de amplificación.
- La extensión NTS Authenticator y Encrypted Extension Fields contiene el cifrado AAED con la clave C2S, el encabezado NTP, las marcas de tiempo y el EF anterior como datos adjuntos. Sin esta extensión es posible falsificar marcas de tiempo.
Al recibir una solicitud de un cliente, el servidor verifica la autenticidad del paquete NTP. Para ello, debe descifrar las cookies, extraer el algoritmo y las claves AAED. Después de verificar con éxito la validez del paquete NTP, el servidor responde al cliente en el siguiente formato.
- Unique Identifier Extension es una copia reflejada de la solicitud del cliente, una medida contra ataques de repetición.
- NTS Cookie Extension más cookies para continuar la sesión.
- La extensión NTS Authenticator y Encrypted Extension Fields contiene el cifrado AEAD con una clave S2C.
El segundo apretón de manos se puede repetir muchas veces, sin pasar por el primer paso, ya que cada solicitud y respuesta proporciona al cliente cookies adicionales. Esto tiene la ventaja de que las operaciones TLS de computación y transmisión de datos PKI que consumen relativamente muchos recursos se dividen por el número de solicitudes repetidas. Esto es especialmente conveniente para los cronometradores FPGA especializados, cuando toda la funcionalidad principal se puede empaquetar en varias funciones del campo de la criptografía simétrica, transfiriendo toda la pila TLS a otro dispositivo.
NTPsec
¿Qué tiene de especial NTP? A pesar de que el autor del proyecto, Dave Mills, intentó documentar su código lo mejor posible, son pocos los programadores que podrán comprender las complejidades de los algoritmos de sincronización de tiempo que tienen 35 años. Parte del código se escribió antes de la era POSIX, y la API de Unix era muy diferente de la que se usa hoy. Además, se necesitan conocimientos de estadística para limpiar la señal de interferencias en líneas ruidosas.
NTS no fue el primer intento de arreglar NTP. Una vez que los atacantes aprendieron a explotar las vulnerabilidades de NTP para amplificar los ataques DDoS, quedó claro que se necesitaban cambios radicales. Y mientras se preparaban y finalizaban los borradores de NTS, a finales de 2014 la Fundación Nacional de Ciencias de EE. UU. asignó urgentemente una subvención para la modernización de NTP.
El grupo de trabajo no estaba encabezado por cualquiera, sino - uno de los fundadores y pilares de la comunidad Open Source y autor del libro . Lo primero que Eric y sus amigos intentaron hacer fue mover el código NTP de la plataforma BitKeeper a git, pero no funcionó de esa manera. El jefe del proyecto, Harlan Stenn, se opuso a esta decisión y las negociaciones se estancaron. Luego se decidió bifurcar el código del proyecto y nació NTPSec.
Experiencia sólida, incluido el trabajo en GPSD, conocimientos matemáticos y la habilidad mágica de leer códigos antiguos: Eric Raymond era exactamente el hacker que podía llevar a cabo un proyecto de este tipo. El equipo encontró un especialista en migración de código y en solo 10 semanas NTP en GitLab. El trabajo estaba en pleno apogeo.
El equipo de Eric Raymond asumió la tarea del mismo modo que Auguste Rodin lo hizo con un bloque de piedra. Al eliminar 175 KLOC de código antiguo, pudieron reducir significativamente la superficie de ataque al cerrar muchos agujeros de seguridad.
Aquí hay una lista incompleta de los incluidos en la distribución:
- Refclock indocumentado, desactualizado, desactualizado o roto.
- Biblioteca ICS no utilizada.
- libopts/autogen.
- Código antiguo para Windows.
- ntpdc.
- Clave automática.
- El código ntpq C ha sido reescrito en Python.
- El código C sntp/ntpdig se ha reescrito en Python.
Además de limpiar el código, el proyecto tenía otras tareas. Aquí hay una lista parcial de logros:
- Se ha mejorado significativamente la protección del código contra el desbordamiento del búfer. Para evitar desbordamientos del búfer, todas las funciones de cadena inseguras (strcpy/strcat/strtok/sprintf/vsprintf/gets) se han reemplazado con versiones seguras que implementan límites de tamaño del búfer.
- Se agregó soporte NTS.
- Se mejoró diez veces la precisión del paso de tiempo al vincular el hardware físico. Esto se debe al hecho de que los relojes de las computadoras modernas se han vuelto mucho más precisos que aquellos cuando nació NTP. Los mayores beneficiarios de esto fueron GPSDO y las radios de tiempo dedicado.
- El número de lenguajes de programación se ha reducido a dos. En lugar de scripts Perl, awk e incluso S, ahora todo es Python. Debido a esto, existen más oportunidades para la reutilización del código.
- En lugar de fideos de scripts de herramientas automáticas, el proyecto comenzó a utilizar un sistema de compilación de software. .
- Documentación del proyecto actualizada y reorganizada. A partir de una colección de documentos contradictoria y a veces arcaica, crearon documentación bastante aceptable. Cada cambio de línea de comando y cada entidad de configuración ahora tiene una única versión de la verdad. Además, las páginas de manual y la documentación web ahora se crean a partir de los mismos archivos principales.
NTPSec está disponible para varias distribuciones de Linux. Por el momento la última versión estable es la 1.1.8, para Gentoo Linux es 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]
cronista
Hubo otro intento de sustituir el antiguo NTP por una alternativa más segura. Chrony, a diferencia de NTPSec, está escrito desde cero y está diseñado para funcionar de manera confiable en una amplia gama de condiciones, incluidas conexiones de red inestables, disponibilidad parcial de la red o congestión y cambios de temperatura. Además, chrony tiene otras ventajas:
- chrony puede sincronizar el reloj del sistema más rápido y con mayor precisión;
- chrony es más pequeño, consume menos memoria y accede a la CPU sólo cuando es necesario. Esta es una gran ventaja para ahorrar recursos y energía;
- chrony admite marcas de tiempo de hardware en Linux, lo que permite una sincronización extremadamente precisa en redes locales.
Sin embargo, chrony carece de algunas de las características del antiguo NTP, como cliente/servidor de transmisión y multidifusión. Además, el NTP clásico admite una mayor cantidad de sistemas operativos y plataformas.
Para deshabilitar la funcionalidad del servidor y las solicitudes NTP al proceso chronyd, simplemente escriba el puerto 0 en el archivo chrony.conf. Esto se hace en los casos en los que no es necesario mantener el tiempo para los clientes o pares NTP. Desde la versión 2.0, el puerto del servidor NTP está abierto solo cuando el acceso está permitido mediante una directiva de permiso o un comando apropiado, o se configura un par NTP o se utiliza una directiva de transmisión.
El programa consta de dos módulos.
- chronyd es un servicio que se ejecuta en segundo plano. Recibe información sobre la diferencia entre el reloj del sistema y el servidor de hora externo y ajusta la hora local. También implementa el protocolo NTP y puede actuar como cliente o servidor.
- chronyc es una utilidad de línea de comandos para monitoreo y control de programas. Se utiliza para ajustar varios parámetros del servicio, por ejemplo, permitiéndole agregar o eliminar servidores NTP mientras chronyd continúa ejecutándose.
Desde la versión 7 de RedHat Linux chrony como servicio de sincronización horaria. El paquete también está disponible para otras distribuciones de Linux. La última versión estable es la 3.5, preparándose para el lanzamiento 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]
Cómo configurar su propio servidor chrony remoto en Internet para sincronizar la hora en la red de una oficina. A continuación se muestra un ejemplo de configuración de un VPS.
Ejemplo de configuración de Chrony en RHEL/CentOS en VPS
Practiquemos ahora un poco y configuremos nuestro propio servidor NTP en un VPS. Es muy simple: simplemente elija la tarifa adecuada en el sitio web de RuVDS, obtenga un servidor listo para usar y escriba una docena de comandos simples. Para nuestros propósitos, esta opción es bastante adecuada.
Pasemos a configurar el servicio y primero instalemos el paquete chrony.
[root@server ~]$ yum install chronyRHEL 8/CentOS 8 utiliza un administrador de paquetes diferente.
[root@server ~]$ dnf install chronyDespués de instalar chrony, debe iniciar y activar el servicio.
[root@server ~]$ systemctl enable chrony --nowSi lo desea, puede realizar cambios en /etc/chrony.conf, reemplazando los servidores NPT por los locales más cercanos para reducir el tiempo de respuesta.
# 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 la sincronización del servidor NTP con los nodos del grupo especificado.
[root@server ~]$ timedatectl set-ntp true
[root@server ~]$ systemctl restart chronyd.service
También es necesario abrir el puerto NTP al exterior; de lo contrario, el firewall bloqueará las conexiones entrantes de los nodos cliente.
[root@server ~]$ firewall-cmd --add-service=ntp --permanent
[root@server ~]$ firewall-cmd --reload
Del lado del cliente, basta con configurar correctamente la zona horaria.
[root@client ~]$ timedatectl set-timezone Europe/MoscowEl archivo /etc/chrony.conf especifica la IP o el nombre de host de nuestro servidor VPS que ejecuta el servidor NTP chrony.
server my.vps.serverY finalmente, iniciar la sincronización horaria en el cliente.
[root@client ~]$ systemctl enable --now chronyd
[root@client ~]$ timedatectl set-ntp true
La próxima vez te contaré qué opciones hay para sincronizar la hora sin Internet.
Fuente: habr.com
