NTP: el protocolo de sincronización para sistemas de TI

Los relojes de los sistemas informáticos suponen una valiosa ayuda a cualquiera que necesite saber qué hora es y no tenga ni un reloj de pulsera ni un smartphone a mano. Sin embargo, muy pocas personas saben que la hora que marca el sistema no solo es relevante para el usuario, sino también para los propios ordenadores. Durante un intercambio de información entre dos o más sistemas y, concretamente, para el correcto funcionamiento de procesos dependientes de la red, los sellos de tiempo desempeñan un papel central. Con el objetivo de prevenir complicaciones del sistema debido a la existencia de tiempos asíncronos, en 1985 se publicó el llamado Network Time Protocol (NTP).

El protocolo de tiempo de red o NTP es el resultado del trabajo de desarrollo realizado por David L. Mills, profesor de la Universidad de Delaware (Estados Unidos). La primera especificación oficial del protocolo, que forma parte de la familia de protocolos de Internet, se publicó en septiembre de 1985 en la RFC 985. El NTP se describe en este documento como un protocolo para sincronizar varios relojes de red usando un conjunto de clientes y servidores repartidos. Como predecesores, se hace mención al mensaje ICMP Timestamp y al Time Protocol, ya que sus funciones fueron incluidas en el Network Time Protocol. El NTP se basa en el protocolo de datagramas de usuario (User Datagram Protocol o UDP), que permite enviar datagramas sin que se haya establecido previamente una conexión. Es decir, utiliza UDP como capa de transporte usando el puerto 123.

El NTP proporciona los mecanismos de protocolo básicos necesarios para sincronizar los relojes de los diferentes sistemas con una precisión del orden de nanosegundos. Además, contiene indicaciones para especificar la precisión y las posibles fuentes de error del reloj del sistema local, así como las propiedades del reloj de referencia. No obstante, este protocolo se limita a especificar la arquitectura de la representación de datos y los formatos de mensaje, sin que por sí mismo lleve a cabo la sincronización y el algoritmo de filtrado.

Para sincronizar los relojes de los ordenadores con una precisión de nanosegundos, el Network Time Protocol utiliza el estándar Tiempo universal coordinado (UTC), que fija la hora universal válida y unitaria desde 1972. Esto se determina utilizando varios métodos, incluyendo sistemas de radio y satélite. Algunos servicios importantes como el Sistema de Posicionamiento Global (GPS) están equipados con receptores especiales para recibir las señales. Dado que no sería rentable ni factible equipar a cada uno de los ordenadores con estos receptores, existen también los denominados servidores de tiempo primarios (Primary Time Servers), que también están equipados con un receptor UTC. Utilizando protocolos como NTP, estos servidores sincronizan los relojes de los ordenadores de su red.

En este proceso de sincronización interviene un sistema estructurado de forma jerárquica conectado a la fuente UTC con diferentes niveles de distancia, también conocidos como estratos de reloj. Todos los dispositivos técnicos que obtienen la hora de un servidor de tiempo primario o de un sistema de navegación por satélite se clasifican en la categoría estrato 0. Como ejemplos podemos destacar los relojes atómicos o los relojes de radio. Un ordenador que obtiene el UTC de un reloj atómico o de un reloj de radio corresponderá al estrato 1 y así consecutivamente. Cada sistema es al mismo tiempo cliente del estrato precedente y servidor para los sistemas del estrato siguiente (al menos en potencia).

Las características principales del Network Time Protocol, que ya está disponible en su cuarta versión (NTPv4), pueden resumirse de la siguiente manera:

• NTP utiliza un reloj de referencia que actúa como punto fijo para todos los procesos de sincronización. Por lo tanto, todos los relojes están sincronizados respecto a ese reloj de referencia. Desde el principio se utilizó el estándar de Tiempo universal coordinado (UTC), por el cual el mundo regula los relojes y el tiempo.
• NTP es un protocolo tolerante a fallos que busca automáticamente las mejores fuentes de tiempo para realizar la sincronización. Para minimizar los fallos acumulados, es capaz de seleccionar y combinar varias fuentes. Cuando es posible, el protocolo de tiempo de red detecta e ignora las fuentes de tiempo que proporcionan valores desviados de manera temporal o permanente.
• Es un protocolo altamente escalable: en cada red de sincronización es posible encontrar varios relojes de referencia. Además, cada nodo de la red es capaz de transmitir información horaria en una estructura jerárquica bidireccional (punto a punto) o unidireccional (en una dirección).
• Es muy preciso. Gracias a que puede seleccionar la mejor fuente para realizar la sincronización, presenta una resolución teórica en un rango de nanosegundos de 2⁻³² segundos (es decir, 0,233 nanosegundos)
• Puede solucionar los problemas temporales de conexión de red. Para ello, el protocolo utiliza la información almacenada para determinar la hora actual o las desviaciones.

En su origen, el protocolo de tiempo de red fue desarrollado concretamente para sistemas UNIX en los que el protocolo, hasta día de hoy, está implementado en forma de proceso que se ejecuta en segundo plano (daemons) ntpd. Es posible utilizarlo como cliente para sincronizar el sistema local y como servidor NTP para sincronizar otros sistemas. Durante mucho tiempo, se mantuvo como la solución más extendida a la hora de implementar NTP en distribuciones Linux. Las versiones más actuales se decantan cada vez más a menudo por la aplicación cliente timesyncd, que forma parte del sistema de gestión systemd, para la sincronización de los relojes. También los sistemas operativos macOS y Windows utilizan actualmente el Network time protocol para obtener el UTC mediante procesos de sistema simples que funcionan vía internet y no necesitan software adicional.

Aunque el protocolo NTP es considerado en todo el mundo como el estándar de sincronización horaria, eso no significa que sea infalible, especialmente si hablamos de seguridad. Dado que se basa en el protocolo sin conexión UDP, podría permitir a un atacante enviar paquetes a un servidor NTP con una dirección de remitente falsa mediante IP spoofing. La dirección del remitente es la dirección del sistema que hay que atacar. El servidor envía su respuesta, que es mucho más larga que la petición enviada por el atacante, de vuelta al supuesto remitente, que es el sistema víctima. Imagina que el atacante comenzara a enviar a gran escala un gran número de esas peticiones manipuladas. En ese caso, podría sobrecargar el sistema de destino –no te pierdas nuestro artículo DoS y DDoS: resumen rápido de patrones de ataque.

En consecuencia, existen varios proyectos consagrados al desarrollo de soluciones alternativas y más seguras que puedan utilizarse como sustitutas de las soluciones habituales de cliente y servidor NTP:

• tlsdate: tlsdate fue desarrollado en 2012 por Jacob Appelbaum y publicado en GitHub. En lugar de UDP, tlsdate utiliza el protocolo TCP para el transporte de datos. El servicio cifra la configuración de la conexión mediante TLS para evitar la manipulación de los paquetes de datos. Además, tlsdate utiliza las funciones TLS “ServerHello” y “ClientHello” para sincronizar los relojes. Sin embargo, esta alternativa a NTP solo funciona con TLS 1.1 y 1.2.
• Ntimed: Ntimed es una implementación de NTP que se centra específicamente en la seguridad y el rendimiento. Para ello, el código del programa de ntpd, en el que se basa Ntimed, fue “purificado” y optimizado. Este paquete de software, que consta de cliente, servidor y archivo maestro, está disponible gratuitamente en el directorio oficial de Ntimed-GitHub.
• NTPsec: NPTsec es también una variante del servicio clásico de ntpd. Sin embargo, ahorra más de 175 000 líneas de código en comparación con el original. Además, el equipo de desarrollo ha sustituido una serie de funciones string que no eran seguras como “strcpy”, “sprintf” o “gets” por sustitutos seguros. Es posible consultar detalladamente estas y otras diferencias en la página web oficial del proyecto Open Source.

Además de las alternativas basadas en software, existe también el protocolo Precision Time Protocol (PTP). A diferencia del Network Time Protocol, este protocolo de red para sistemas Linux se centra explícitamente en una precisión de sincronización especialmente alta. En el protocolo PTP estamos hablando de una precisión de microsegundos, es decir, mayor aún que en el protocolo NTP. Además, el protocolo funciona con un rendimiento del procesador y del ancho de banda mínimo, por lo que es una opción perfecta para dispositivos sencillos de bajo precio.

El proyecto pool.ntp.org, iniciado por Adrian von Bider y mantenido y desarrollado por Ask Bjørn Hansen desde julio de 2005, es un enorme clúster virtual con más de 4000 servidores de tiempo NTP. La mayoría de los servidores distribuidos por todo el mundo y utilizados por varios millones de sistemas se encuentran en Europa. El repositorio NTP Pool ha crecido a lo largo del tiempo de forma constante gracias a la comunidad de este exitoso proyecto: cualquier persona que disponga de un servidor con dirección IP estática que esté permanentemente conectado a Internet puede ser incluido en el clúster. A pesar de la creciente demanda, el servicio puede utilizarse gratuitamente y sin restricciones.

Si quieres utilizar el NTP Server Pool para sincronizar la hora del sistema de tus dispositivos, puedes hacerlo desde UNIX o Linux utilizando el servicio ntpd. Lo único que tienes que hacer es implementar la siguiente configuración en el NTP drift file:

La condición previa es que la hora del sistema esté fijada al menos de forma aproximada. Para verificar el estado del servicio ntpd, introduce, pasados unos minutos, el siguiente comando de consulta:

El cliente NTP presenta una lista con las direcciones IP de los servidores de tiempo del Pool utilizados aleatoriamente. Si alguno de esos servidores está marcado con un asterisco (*), la hora del sistema podrá sincronizarse como queramos.