Guía de puertos NTP: sincronización horaria en UDP 123

Un cliente NTP envía periódicamente una solicitud a uno o más servidores de tiempo a través de UDP 123. El servidor devuelve marcas de tiempo que permiten al cliente estimar el desplazamiento, el retraso y la fluctuación, luego el cliente ajusta su reloj local sin realizar saltos disruptivos a menos que la deriva sea demasiado grande.

Las implementaciones de NTP a menudo se organizan en estratos. Stratum 0 es un reloj de referencia como un GPS o una fuente atómica. Los servidores del estrato 1 se conectan directamente a esas referencias y los servidores del estrato inferior distribuyen más el tiempo en la red. La mayoría de las organizaciones deberían utilizar fuentes ascendentes confiables y proporcionar NTP interno a sus propios sistemas.

Un cliente NTP necesita acceso saliente a UDP 123 hacia sus fuentes horarias configuradas. Un servidor NTP necesita UDP 123 entrante de los clientes a los que debe servir. Esas son preguntas diferentes sobre el firewall y mezclarlas es una fuente común de interrupción de la sincronización horaria.

Las estaciones de trabajo y los servidores de aplicaciones normalmente actúan sólo como clientes. Los controladores de dominio, los dispositivos de tiempo de red, la infraestructura de monitoreo y los centros de tiempo internos pueden actuar como servidores para el resto de la flota.

Permitir UDP 123 saliente desde sistemas que necesitan sincronizarse con fuentes horarias externas o internas confiables. Permita UDP 123 entrante solo en servidores que proporcionen intencionalmente NTP a clientes conocidos.

No exponga un servidor NTP ampliamente a Internet a menos que sea operado intencionalmente como un servicio de tiempo público con capacidad, limitación de velocidad, monitoreo y controles de abuso. Se puede abusar del NTP público mal configurado para ataques de reflexión y amplificación.

Antes de permitir UDP 123, decida qué sistemas son clientes, qué sistemas son servidores y qué fuentes de tiempo ascendentes son confiables. Confirme si su entorno utiliza chrony, systemd-timesyncd, ntpd, servicio de hora de Windows, una jerarquía de dominio o un dispositivo dedicado.

Un verificador de puertos puede ayudar con la accesibilidad, pero la sincronización de la hora también debe verificarse a nivel de protocolo y reloj. Utilice chronyc, ntpq, w32tm, timedatectl o datos de monitoreo para confirmar la compensación, el estrato, la selección de fuente y la deriva.

En dominios de Windows, el servicio de hora de Windows generalmente sincroniza los miembros del dominio a través de la jerarquía del dominio, con el emulador de PDC configurado con fuentes ascendentes confiables. Los servidores independientes de Windows se pueden configurar con w32tm y reglas de firewall para UDP 123 cuando cumplen su horario.

En Linux, chrony es común en las distribuciones modernas, mientras que ntpd y systemd-timesyncd también aparecen. Configure grupos de confianza o servidores internos, permita UDP 123 solo cuando el host proporcione tiempo y supervise el desplazamiento y el estado de la fuente.

En dispositivos de red, apunte conmutadores, enrutadores, firewalls y dispositivos a fuentes NTP internas cuando sea posible. La hora exacta del dispositivo hace que los registros, los certificados, las VPN y las investigaciones de incidentes sean mucho más confiables.

Comience comprobando si se puede acceder a UDP 123 entre el cliente y el servidor de hora previsto. Luego verifique la sincronización real con el seguimiento de chronyc, las fuentes de chronyc, ntpq -p, timedatectl timesync-status o w32tm /query /status según la plataforma.

Si opera un servidor NTP, pruebe desde una red de cliente conocida y confirme que las redes no autorizadas no puedan consultarlo. Para los servicios conectados a Internet, observe el volumen de solicitudes y los patrones de respuesta porque la accesibilidad por sí sola no demuestra una configuración segura.

Si NTP no se sincroniza, es posible que el cliente esté bloqueado desde UDP 123, que utilice el servidor incorrecto, que rechace una fuente debido a un desplazamiento alto o que no pueda resolver el nombre de host del servidor de hora. Las máquinas virtuales también pueden desviarse si el tiempo del host, las herramientas invitadas y NTP luchan entre sí.

Si se puede acceder a un servidor pero los clientes aún se desvían, inspeccione el estrato, el estado del salto, la selección de fuente, el estado del firewall, el comportamiento de NAT y si hay varios sistemas de tiempo configurados a la vez. Para dominios de Windows, verifique la jerarquía de tiempo del dominio antes de cambiar cada host individualmente.

Restrinja quién puede consultar sus servidores NTP, deshabilite los comandos obsoletos de alta amplificación, mantenga el software NTP parcheado y supervise los picos de tráfico inusuales. Prefiera la distribución de tiempo interna a permitir que cada host consulte servidores públicos aleatorios.

Para entornos importantes, utilice múltiples fuentes de tiempo confiables, alerte sobre compensación excesiva, documente la ruta de tiempo autorizada e incluya sincronización de tiempo en las verificaciones de respuesta a incidentes. Un mal momento puede dañar los certificados, la autenticación, la correlación de registros y los trabajos programados.