El protocolo de tiempo de red ( NTP ) es un protocolo de red para la sincronización del reloj entre sistemas informáticos a través de redes de datos de latencia variable y conmutación de paquetes . En funcionamiento desde antes de 1985, NTP es uno de los protocolos de Internet más antiguos que se utilizan actualmente. NTP fue diseñado por David L. Mills de la Universidad de Delaware .
NTP está destinado a sincronizar todas las computadoras participantes dentro de unos pocos milisegundos del Tiempo Universal Coordinado (UTC). [1] : 3 Utiliza el algoritmo de intersección , una versión modificada del algoritmo de Marzullo , para seleccionar servidores de tiempo precisos y está diseñado para mitigar los efectos de la latencia variable de la red . Normalmente, NTP puede mantener el tiempo en decenas de milisegundos en la Internet pública y puede lograr una precisión superior a un milisegundo en redes de área local en condiciones ideales. Las rutas asimétricas y la congestión de la red pueden provocar errores de 100 ms o más. [2] [3]
El protocolo generalmente se describe en términos de un modelo cliente-servidor , pero también puede usarse fácilmente en relaciones entre pares donde ambos consideran al otro como una posible fuente de tiempo. [1] : 20 Las implementaciones envían y reciben marcas de tiempo utilizando el Protocolo de datagramas de usuario (UDP) en el puerto número 123. [4] [5] : 16 También pueden usar transmisión o multidifusión , donde los clientes escuchan pasivamente las actualizaciones de tiempo después de una ronda inicial. -cambio de calibración de viaje. [3] NTP proporciona una advertencia de cualquier ajuste de segundo intercalar inminente , pero no se transmite información sobre las zonas horarias locales o el horario de verano . [2] [3]
El protocolo actual es la versión 4 (NTPv4), [5] que es compatible con la versión 3. [6]
En 1979, la tecnología de sincronización horaria de la red se utilizó en lo que posiblemente fue la primera demostración pública de servicios de Internet funcionando a través de una red de satélites transatlántica, en la Conferencia Nacional de Computación en Nueva York. La tecnología se describió posteriormente en la Nota de ingeniería de Internet (IEN) 173 [18] de 1981 y a partir de ella se desarrolló un protocolo público que se documentó en RFC 778. La tecnología se implementó por primera vez en una red de área local como parte del protocolo de enrutamiento Hello. e implementado en el enrutador Fuzzball , un sistema operativo experimental utilizado en la creación de prototipos de redes, donde funcionó durante muchos años.
Otras herramientas de red relacionadas estaban disponibles entonces y ahora. Incluyen los protocolos Daytime y Time para registrar la hora de los eventos, así como los mensajes ICMP Timestamp y la opción IP Timestamp ( RFC 781). Los sistemas de sincronización más completos, aunque carecen de los algoritmos de análisis de datos y disciplinación del reloj de NTP, incluyen el demonio Unix timed , que utiliza un algoritmo de elección para designar un servidor para todos los clientes; [19] y el Servicio de sincronización de hora digital (DTSS), que utiliza una jerarquía de servidores similar al modelo de estrato NTP.
En 1985, se implementó la versión 0 de NTP (NTPv0) tanto en Fuzzball como en Unix, y el encabezado del paquete NTP y los cálculos de compensación y retraso de ida y vuelta , que han persistido en NTPv4, se documentaron en RFC 958. A pesar de las computadoras y redes relativamente lentas disponible en ese momento, generalmente se obtenía una precisión superior a 100 milisegundos en enlaces que abarcaban el Atlántico, con una precisión de decenas de milisegundos en redes Ethernet .
En 1988, se publicó en RFC 1059 una especificación mucho más completa del protocolo NTPv1, con algoritmos asociados. Se basó en los resultados experimentales y el algoritmo de filtro de reloj documentados en RFC 956 y fue la primera versión en describir la relación cliente-servidor y peer. modos -a igual . En 1991, la arquitectura, el protocolo y los algoritmos NTPv1 llamaron la atención de una comunidad de ingenieros más amplia con la publicación de un artículo de David L. Mills en IEEE Transactions on Communications . [20]
En 1989 se publicó el RFC 1119 definiendo NTPv2 mediante una máquina de estados , con pseudocódigo para describir su funcionamiento. Introdujo un protocolo de gestión y un esquema de autenticación criptográfica que han sobrevivido en NTPv4, junto con la mayor parte del algoritmo. Sin embargo, la comunidad DTSS criticó el diseño de NTPv2 por carecer de corrección formal , y el procedimiento de selección de reloj se modificó para incorporar el algoritmo de Marzullo para NTPv3 en adelante. [21]
En 1992, RFC 1305 definió NTPv3. El RFC incluyó un análisis de todas las fuentes de error, desde el reloj de referencia hasta el cliente final, lo que permitió calcular una métrica que ayuda a elegir el mejor servidor cuando varios candidatos parecen no estar de acuerdo. Se introdujo el modo de transmisión.
En los años siguientes, a medida que se agregaron nuevas funciones y se realizaron mejoras en los algoritmos, se hizo evidente que se necesitaba una nueva versión del protocolo. [22] En 2010, se publicó RFC 5905 que contiene una especificación propuesta para NTPv4. [23] Tras el retiro de Mills de la Universidad de Delaware , la implementación de referencia se mantiene actualmente como un proyecto de código abierto dirigido por Harlan Stenn. [24] [25] Por parte de la IANA, un grupo de trabajo ntp ( protocolos de tiempo de red ) está a cargo de revisar los borradores propuestos. [26]
El protocolo ha progresado significativamente desde NTPv4. [23] A partir de 2022 [update], se han publicado tres documentos RFC que describen actualizaciones del protocolo, [5] sin contar los numerosos estándares periféricos como NTS ( RFC 8915). [26] Mills había mencionado planes para un "NTPv5" en su página, pero uno nunca fue publicado. [23] En 2020 se inició un borrador no relacionado denominado "NTPv5" de M. Lichvar de chrony e incluye cambios de seguridad, precisión y escala. [27]
Como NTP reemplazó el uso del antiguo protocolo de tiempo , algunos casos de uso encontraron que el protocolo completo era demasiado complicado. En 1992, se definió el Protocolo simple de tiempo de red ( SNTP ) para llenar este nicho. El estándar SNTPv3 describe una forma de utilizar NTPv3, de modo que no sea necesario almacenar el estado durante largos períodos de tiempo. La topología es esencialmente la misma que con el protocolo de tiempo, ya que solo se utiliza un servidor. [10] En 1996, SNTP se actualizó a SNTPv4 [12] con algunas características del entonces en desarrollo NTPv4. La versión actual de SNTPv4 se fusionó con el estándar principal NTPv4 en 2010. [5] SNTP es totalmente interoperable con NTP ya que no define un nuevo protocolo. [28] : §14 Sin embargo, los algoritmos simples proporcionan tiempos de precisión reducida y, por lo tanto, no es aconsejable sincronizar el tiempo desde una fuente SNTP. [13]
NTP utiliza un sistema jerárquico de fuentes de tiempo semi-capas. Cada nivel de esta jerarquía se denomina estrato y se le asigna un número que comienza con cero para el reloj de referencia en la parte superior. Un servidor sincronizado con un servidor de estrato n se ejecuta en el estrato n + 1. El número representa la distancia desde el reloj de referencia y se utiliza para evitar dependencias cíclicas en la jerarquía. El estrato no siempre es una indicación de calidad o confiabilidad; Es común encontrar fuentes horarias de estrato 3 que son de mayor calidad que otras fuentes horarias de estrato 2. [a] A continuación se proporciona una breve descripción de los estratos 0, 1, 2 y 3.
El límite superior del estrato es 15; El estrato 16 se utiliza para indicar que un dispositivo no está sincronizado. Los algoritmos NTP en cada computadora interactúan para construir un árbol de expansión de ruta más corta de Bellman-Ford , para minimizar el retraso acumulado de ida y vuelta a los servidores del estrato 1 para todos los clientes. [1] : 20
Además del estrato, el protocolo es capaz de identificar la fuente de sincronización para cada servidor en términos de un identificador de referencia (refid).
Para servidores en el estrato 2 e inferiores, el refid es una forma codificada de la dirección IP del servidor de tiempo ascendente. Para IPv4, esta es simplemente la dirección de 32 bits; para IPv6, serían los primeros 32 bits del hash MD5 de la dirección de origen. Los refids sirven para detectar y prevenir bucles de sincronización en primer grado. [5]
El campo refid se llena con palabras de estado en el caso de paquetes de beso de muerte (KoD), que le dicen al cliente que deje de enviar solicitudes para que el servidor pueda descansar. [5] Algunos ejemplos son INIT (inicialización), STEP (cambio de tiempo de paso) y RATE (el cliente solicita demasiado rápido). [33] La salida del programa puede utilizar adicionalmente códigos no transmitidos en el paquete para indicar un error, como XFAC para indicar una desconexión de la red. [32]
La IANA mantiene un registro de nombres de fuentes refid y códigos KoD. Todavía pueden aparecer asignaciones informales. [34]
Las marcas de tiempo binarias de punto fijo de 64 bits utilizadas por NTP constan de una parte de 32 bits para segundos y una parte de 32 bits para fracciones de segundo, lo que proporciona una escala de tiempo que se actualiza cada 2,32 segundos (136 años) y una resolución teórica. de 2 −32 segundos (233 picosegundos). NTP utiliza una época del 1 de enero de 1900. Por lo tanto, la primera renovación se produce el 7 de febrero de 2036. [35] [36]
NTPv4 introduce un formato de fecha de 128 bits: 64 bits para el segundo y 64 bits para la fracción de segundo. Los 32 bits más importantes de este formato es el Número de Era , que resuelve la ambigüedad de la transferencia en la mayoría de los casos. [37] Según Mills, "El valor de 64 bits para la fracción es suficiente para resolver la cantidad de tiempo que tarda un fotón en pasar un electrón a la velocidad de la luz. El segundo valor de 64 bits es suficiente para proporcionar un tiempo inequívoco. representación hasta que el universo se oscurezca." [38] [b]
Un cliente NTP típico sondea periódicamente uno o más servidores NTP. El cliente debe calcular su compensación horaria y su retraso de ida y vuelta . El desplazamiento de tiempo θ es la diferencia positiva o negativa (hora del cliente > hora del servidor) en el tiempo absoluto entre los dos relojes. Se define por
Para derivar la expresión del desplazamiento, tenga en cuenta que para el paquete de solicitud,
Los valores de θ y δ se pasan a través de filtros y se someten a análisis estadístico ("mitigación"). Los valores atípicos se descartan y se deriva una estimación del tiempo de compensación a partir de los tres mejores candidatos restantes. Luego, la frecuencia del reloj se ajusta para reducir el desplazamiento gradualmente ("disciplina"), creando un bucle de retroalimentación . [1] : 20
Se logra una sincronización precisa cuando las rutas entrantes y salientes entre el cliente y el servidor tienen un retraso nominal simétrico. Si las rutas no tienen un retraso nominal común, existe un sesgo sistemático de la mitad de la diferencia entre los tiempos de viaje hacia adelante y hacia atrás. Se han propuesto varios enfoques para medir la asimetría, [39] pero entre las implementaciones prácticas sólo chrony parece tener uno incluido. [40] [41]
La implementación de referencia NTP , junto con el protocolo, se ha desarrollado continuamente durante más de 20 años. La compatibilidad con versiones anteriores se ha mantenido a medida que se han agregado nuevas funciones. Contiene varios algoritmos sensibles, especialmente para disciplinar el reloj, que pueden comportarse mal cuando se sincronizan con servidores que utilizan algoritmos diferentes. El software se ha adaptado a casi todas las plataformas informáticas, incluidas las computadoras personales. Se ejecuta como un demonio llamado ntpd en Unix o como un servicio en Windows. Se admiten relojes de referencia y sus compensaciones se filtran y analizan de la misma manera que los servidores remotos, aunque normalmente se sondean con mayor frecuencia. [1] : 15–19 Esta implementación fue auditada en 2017 y se encontraron 14 posibles problemas de seguridad. [42]
Todas las versiones de Microsoft Windows desde Windows 2000 incluyen el servicio de hora de Windows (W32Time), [43] que tiene la capacidad de sincronizar el reloj de la computadora con un servidor NTP.
W32Time se implementó originalmente para el protocolo de autenticación Kerberos versión 5, que requería que el tiempo estuviera dentro de los 5 minutos del valor correcto para evitar ataques de repetición . La versión de Windows 2000 y Windows XP sólo implementa SNTP y viola varios aspectos del estándar NTP versión 3. [44]
A partir de Windows Server 2003 y Windows Vista , W32Time se volvió compatible con un subconjunto importante de NTPv3. [45] Microsoft afirma que W32Time no puede mantener de forma fiable la sincronización horaria con una precisión de un segundo. [46] Si se desea una mayor precisión, Microsoft recomienda utilizar una versión más reciente de Windows o una implementación NTP diferente. [47]
A partir de Windows 10 versión 1607 y Windows Server 2016 , W32Time se puede configurar para alcanzar una precisión de tiempo de 1 s, 50 ms o 1 ms en determinadas condiciones operativas específicas. [48] [46] [49]
En 2004, Henning Brauer de OpenBSD presentó OpenNTPD , una implementación NTPv3/SNTPv4 [50] centrada en la seguridad y que abarca un diseño con privilegios separados. Si bien está dirigido más estrechamente a las necesidades genéricas más simples de los usuarios de OpenBSD, también incluye algunas mejoras de seguridad del protocolo y sigue siendo compatible con los servidores NTP existentes. La base de código más simple sacrifica la precisión, lo que se considera innecesario en este caso de uso. [51] Hay una versión portátil disponible en los repositorios de paquetes de Linux.
NTPsec es una bifurcación de la implementación de referencia cuya seguridad se ha reforzado sistemáticamente . El punto de bifurcación fue en junio de 2015 y fue en respuesta a una serie de compromisos en 2014. [52] La primera versión de producción se envió en octubre de 2017. [53] Entre la eliminación de características inseguras, la eliminación de soporte para hardware obsoleto y la eliminación de Con soporte para variantes obsoletas de Unix, NTPsec ha podido recortar el 75% del código base original, haciendo que el resto sea más fácil de auditar . [54] Una auditoría del código realizada en 2017 mostró ocho problemas de seguridad, incluidos dos que no estaban presentes en la implementación de referencia original, pero NTPsec no sufrió otros ocho problemas que permanecieron en la implementación de referencia. [55]
chrony es una implementación NTP independiente patrocinada principalmente por Red Hat , quien lo utiliza como programa de tiempo predeterminado en sus distribuciones. [56] Al estar escrito desde cero, chrony tiene una base de código más simple que permite una mejor seguridad [57] y un menor consumo de recursos. [58] Sin embargo, no compromete la precisión, sino que se sincroniza más rápido y mejor que el ntpd de referencia en muchas circunstancias. Es lo suficientemente versátil para computadoras comunes, que son inestables, entran en modo de suspensión o tienen una conexión intermitente a Internet. También está diseñado para máquinas virtuales, un entorno más inestable. [59]
Chrony ha sido evaluado como "digno de confianza", con sólo unos pocos incidentes. [60] Es capaz de lograr una precisión mejorada en las conexiones LAN, utilizando marcas de tiempo de hardware en el adaptador de red. [40] Se agregó compatibilidad con Network Time Security (NTS) en la versión 4.0. [61] chrony está disponible bajo la Licencia Pública General GNU versión 2 , fue creado por Richard Curnow en 1997 y actualmente es mantenido por Miroslav Lichvar. [58]
El día de un evento de segundo intercalar , ntpd recibe una notificación de un archivo de configuración , un reloj de referencia adjunto o un servidor remoto. Aunque el reloj NTP en realidad se detiene durante el evento, debido al requisito de que el tiempo debe parecer estrictamente creciente , cualquier proceso que consulte la hora del sistema hace que aumente en una pequeña cantidad, preservando el orden de los eventos. Si alguna vez fuera necesario un segundo intercalar negativo, se eliminaría con la secuencia 23:59:58, 00:00:00, omitiendo 23:59:59. [sesenta y cinco]
Una implementación alternativa, denominada jump smearing, consiste en introducir el segundo intercalar de forma incremental durante un período de 24 horas, desde el mediodía hasta el mediodía en horario UTC. Esta implementación es utilizada por Google (tanto internamente como en sus servidores NTP públicos), Amazon AWS, [66] y Facebook. [67] Chrony admite la difamación de salto en configuraciones de tiempo suave y modo de salto , pero dicho uso no debe combinarse con un grupo NTP público, ya que la difamación de salto no es estándar y alterará el cálculo del cliente en una combinación. [68]
Debido a que ajustar la hora del sistema es generalmente una operación privilegiada, parte o la totalidad del código NTP debe ejecutarse con algunos privilegios para admitir su funcionalidad principal. Sólo se han identificado algunos otros problemas de seguridad en la implementación de referencia del código base NTP, pero los que aparecieron en 2009 [ ¿cuáles? ] fueron motivo de gran preocupación. [69] [70] El protocolo ha sido objeto de revisión y revisión a lo largo de su historia. El código base para la implementación de referencia ha sido sometido a auditorías de seguridad de varias fuentes durante varios años. [71]
En 2014 se descubrió y parchó un exploit de desbordamiento del búfer de pila. [72] Apple estaba lo suficientemente preocupada por esta vulnerabilidad que utilizó su capacidad de actualización automática por primera vez. [73] En los sistemas que utilizan la implementación de referencia, que se ejecuta con la credencial del usuario root, esto podría permitir el acceso ilimitado. Algunas otras implementaciones, como OpenNTPD , tienen una base de código más pequeña y adoptaron otras medidas de mitigación como la separación de privilegios, no están sujetas a esta falla. [74]
Una auditoría de seguridad de 2017 de tres implementaciones de NTP, realizada en nombre de la Iniciativa de Infraestructura Central de la Fundación Linux, sugirió que tanto NTP [75] [76] como NTPsec [77] eran más problemáticos que Chrony [78] desde el punto de vista de la seguridad. [79]
Los servidores NTP pueden ser susceptibles a ataques de intermediario a menos que los paquetes estén firmados criptográficamente para su autenticación. [80] La sobrecarga computacional involucrada puede hacer que esto no sea práctico en servidores ocupados, particularmente durante ataques de denegación de servicio . [81] La suplantación de mensajes NTP a partir de un ataque de intermediario se puede utilizar para alterar los relojes de las computadoras cliente y permitir una serie de ataques basados en eludir la caducidad de la clave criptográfica. [82] Algunos de los servicios afectados por mensajes NTP falsos identificados son TLS , DNSSEC , varios esquemas de almacenamiento en caché (como el caché DNS), Border Gateway Protocol (BGP), Bitcoin [ cita requerida ] y una serie de esquemas de inicio de sesión persistentes. [83] [84]
NTP se ha utilizado en ataques distribuidos de denegación de servicio . [85] [86] Se envía una pequeña consulta a un servidor NTP con la dirección IP de retorno falsificada para ser la dirección de destino. De manera similar al ataque de amplificación de DNS , el servidor responde con una respuesta mucho mayor que permite al atacante aumentar sustancialmente la cantidad de datos que se envía al objetivo. Para evitar participar en un ataque, se puede actualizar el software del servidor NTP o se pueden configurar los servidores para ignorar consultas externas. [87]
El propio NTP incluye soporte para autenticar servidores ante clientes. NTPv3 admite un modo de clave simétrica , que no es útil contra MITM. El sistema de clave pública conocido como "autokey" en NTPv4 adaptado de IPSec ofrece autenticación útil, [80] pero no es práctico para un servidor ocupado. [81] Posteriormente también se descubrió que Autokey padecía varios defectos de diseño, [88] sin que se publicara ninguna corrección, salvo un cambio en el código de autenticación del mensaje . [dieciséis]
Network Time Security (NTS) es una versión segura de NTPv4 con TLS y AEAD . [89] La principal mejora con respecto a intentos anteriores es que un servidor separado de "establecimiento de claves" maneja la pesada criptografía asimétrica, que debe realizarse sólo una vez. Si el servidor falla, los usuarios anteriores aún podrían recuperar tiempo sin temor a MITM. [90] Actualmente, NTS es compatible con varios servidores de tiempo, [91] [92] incluido Cloudflare . Es compatible con NTPSec y chrony. [93]
Microsoft también tiene un enfoque para autenticar paquetes NTPv3/SNTPv4 utilizando una identidad de dominio de Windows , conocida como MS-SNTP. [94] Este sistema está implementado en la referencia ntpd y chrony, utilizando samba para la conexión del dominio. [95]
El procedimiento de selección de reloj se modificó para eliminar el primero de los dos pasos de clasificación/descarte y reemplazarlo con un algoritmo propuesto por primera vez por Marzullo y luego incorporado en el Servicio de Hora Digital. Estos cambios no afectan significativamente el funcionamiento normal ni la compatibilidad con varias versiones de NTP, pero proporcionan la base para declaraciones formales de corrección.
Los servidores primarios y los clientes que cumplen con un subconjunto de NTP, llamado Protocolo simple de tiempo de red (SNTPv4) [...], no necesitan implementar los algoritmos de mitigación [...] La implementación NTPv4 completamente desarrollada está destinada a [.. .] servidores con múltiples servidores ascendentes y múltiples servidores descendentes [...] Aparte de estas consideraciones, los servidores y clientes NTP y SNTP son completamente interoperables y pueden mezclarse [...]
Los programas del paquete linuxptp se pueden utilizar en combinación con un demonio NTP.
Un reloj PTP en una NIC se sincroniza mediante ptp4l y chronyd o ntpd lo utiliza como reloj de referencia para la sincronización del reloj del sistema.
Los códigos Refid se utilizan en paquetes de beso de muerte (KoD), el campo de identificador de referencia en pantallas publicitarias ntpq y ntpmon y mensajes de registro.
Esta directiva permite la marca de tiempo del hardware de los paquetes NTP enviados y recibidos desde la interfaz de red especificada.
Implementa el Protocolo de tiempo de red simple versión 4, como se describe en RFC 5905, y el Protocolo de tiempo de red versión 3, como se describe en RFC 1305.
A partir de Red Hat Enterprise Linux 7.0 (y ahora en Red Hat Enterprise Linux 6.8), también se proporciona una implementación NTP más versátil a través del paquete chrony.
En resumen, el software Chrony NTP se mantiene sólido y puede considerarse confiable
El software es compatible con Linux, FreeBSD, NetBSD, macOS y Solaris.
Soportar once días completos de pruebas remotas en agosto de 2017 significa que Chrony es robusto, fuerte y se desarrolló teniendo en cuenta la seguridad.
Entonces, en efecto, systemd-timesyncd se convirtió en el demonio NTP predeterminado en Debian en bookworm, lo cual me parece algo sorprendente.
