El uso indebido de un servidor NTP ( Network Time Protocol ) puede ir desde inundarlo de tráfico (un ataque DDoS ) hasta violar la política de acceso del servidor o las reglas de interacción del NTP. En una carta abierta de Poul-Henning Kamp al fabricante de enrutadores D-Link en 2006, se denominó vandalismo NTP . [1] Este término se amplió posteriormente para incluir otros incidentes de forma retroactiva. Sin embargo, no hay pruebas de que alguno de estos problemas sea vandalismo deliberado. Suelen estar causados por configuraciones predeterminadas poco previsoras o mal elegidas.
A finales de 2013 se observó una forma deliberada de abuso de servidores NTP, cuando se utilizaron como parte de ataques de denegación de servicio por amplificación . Algunos servidores NTP respondían a un único paquete de solicitud UDP "monlist", con paquetes que describían hasta 600 asociaciones. Al utilizar una solicitud con una dirección IP falsificada , los atacantes podían dirigir un flujo amplificado de paquetes a una red. Esto dio lugar a uno de los mayores ataques de denegación de servicio distribuidos conocidos en ese momento. [2]
Los problemas más problemáticos han estado relacionados con las direcciones de servidor NTP codificadas en el firmware de los dispositivos de red de consumo. Como los principales fabricantes y OEM han producido cientos de miles de dispositivos que utilizan NTP y los clientes casi nunca actualizan el firmware de estos dispositivos, los problemas de tormentas de consultas NTP persistirán mientras los dispositivos estén en servicio.
Un error de software NTP particularmente común es generar paquetes de consulta en intervalos cortos (menos de cinco segundos) hasta que se recibe una respuesta.
Si bien puede ser técnicamente razonable enviar algunos paquetes iniciales a intervalos cortos, es esencial para la salud de cualquier red que los reintentos de conexión del cliente se generen a tasas que disminuyen de forma logarítmica o exponencial para evitar la denegación de servicio .
Este método de reducción exponencial o logarítmica del protocolo se aplica a cualquier protocolo sin conexión y, por extensión, a muchas partes de los protocolos con conexión. Se pueden encontrar ejemplos de este método de reducción en la especificación TCP para el establecimiento de conexión, el sondeo de ventana cero y las transmisiones de mantenimiento de conexión.
En octubre de 2002, uno de los primeros casos conocidos de uso indebido de un servidor horario provocó problemas en un servidor web del Trinity College de Dublín . El tráfico se atribuyó en última instancia a copias defectuosas de un programa llamado Tardis [3], con miles de copias en todo el mundo que se pusieron en contacto con el servidor web y obtuvieron una marca de tiempo a través de HTTP. En última instancia, la solución fue modificar la configuración del servidor web para ofrecer una versión personalizada de la página de inicio (de tamaño muy reducido) y devolver un valor de hora falso, lo que provocó que la mayoría de los clientes eligieran un servidor horario diferente. [4]
El primer caso ampliamente conocido de problemas con el servidor NTP comenzó en mayo de 2003, cuando los productos de hardware de Netgear inundaron el servidor NTP de la Universidad de Wisconsin-Madison con solicitudes. [5] El personal de la universidad asumió inicialmente que se trataba de un ataque malicioso de denegación de servicio distribuido y tomó medidas para bloquear la inundación en el borde de su red. En lugar de disminuir (como lo hacen la mayoría de los ataques DDOS), el flujo aumentó, alcanzando 250.000 paquetes por segundo (150 megabits por segundo) en junio. Una investigación posterior reveló que cuatro modelos de enrutadores Netgear eran la fuente del problema. Se descubrió que el cliente SNTP (Simple NTP) en los enrutadores tiene dos fallas graves. Primero, se basa en un solo servidor NTP (en la Universidad de Wisconsin-Madison) cuya dirección IP estaba codificada en el firmware. Segundo, sondea el servidor a intervalos de un segundo hasta que recibe una respuesta. Se produjeron un total de 707.147 productos con el cliente defectuoso.
Netgear ha publicado actualizaciones de firmware para los productos afectados (DG814, HR314, MR814 y RP614) que consultan los servidores propios de Netgear, sondean solo una vez cada diez minutos y dejan de funcionar después de cinco fallos. Si bien esta actualización corrige los fallos del cliente SNTP original, no resuelve el problema más grave. La mayoría de los consumidores nunca actualizarán el firmware de su enrutador, en particular si el dispositivo parece funcionar correctamente.
También en 2003, otro caso obligó a los servidores NTP del Laboratorio Nacional de Medición de la Organización de Investigación Científica e Industrial de la Mancomunidad de Australia ( CSIRO ) a cerrar al público. [6] Se demostró que el tráfico provenía de una mala implementación de NTP en algunos modelos de enrutadores SMC donde la dirección IP del servidor CSIRO estaba incorporada en el firmware. SMC ha publicado actualizaciones de firmware para los productos: se sabe que los modelos 7004VBR y 7004VWBR están afectados.
En 2005, Poul-Henning Kamp , el administrador del único servidor NTP Stratum 1 danés disponible para el público en general, observó un enorme aumento en el tráfico y descubrió que entre el 75 y el 90% se originaba con los productos enrutadores de D-Link. Los servidores NTP Stratum 1 reciben su señal horaria de una fuente externa precisa, como un receptor GPS, un reloj de radio o un reloj atómico calibrado. Por convención, los servidores de tiempo Stratum 1 solo deben usarse en aplicaciones que requieren mediciones de tiempo extremadamente precisas, como aplicaciones científicas o servidores Stratum 2 con una gran cantidad de clientes. [7] Un enrutador de red doméstica no cumple ninguno de estos criterios. Además, la política de acceso del servidor de Kamp lo limitó explícitamente a los servidores conectados directamente al Danish Internet Exchange (DIX). El uso directo de este y otros servidores Stratum 1 por parte de los enrutadores de D-Link resultó en un enorme aumento del tráfico, lo que aumentó los costos de ancho de banda y la carga del servidor.
En muchos países, los servicios oficiales de cronometraje son proporcionados por una agencia gubernamental (como el NIST en los EE. UU.). Dado que no existe un equivalente danés, Kamp proporciona su servicio de cronometraje " pro bono público ". A cambio, DIX aceptó proporcionar una conexión gratuita para su servidor de tiempo bajo el supuesto de que el ancho de banda involucrado sería relativamente bajo, dado el número limitado de servidores y clientes potenciales. Con el aumento de tráfico causado por los enrutadores D-Link, DIX le solicitó el pago de una tarifa de conexión anual de 54.000 coronas danesas [ cita requerida ] (aproximadamente US$9.920 o €7.230 [8] [9] ).
Kamp se puso en contacto con D-Link en noviembre de 2005, con la esperanza de que solucionaran el problema y lo compensaran por el tiempo y el dinero que gastó en rastrear el problema y los cargos por ancho de banda causados por los productos de D-Link. La empresa negó cualquier problema, lo acusó de extorsión y le ofreció una cantidad en compensación que Kamp afirmó que no cubría sus gastos. El 7 de abril de 2006, Kamp publicó la historia en su sitio web. [10] La historia fue recogida por Slashdot , Reddit y otros sitios de noticias. Después de hacerse pública, Kamp se dio cuenta de que los enrutadores de D-Link estaban consultando directamente a otros servidores de tiempo Stratum 1, violando las políticas de acceso de al menos 43 de ellos en el proceso. El 27 de abril de 2006, D-Link y Kamp anunciaron que habían "resuelto amistosamente" su disputa. [11]
Desde hace más de 20 años, la ETH de Zúrich ofrece acceso abierto al servidor horario swisstime.ethz.ch para la sincronización horaria operativa. Debido al uso excesivo del ancho de banda, que supera los 20 GB/día de media, se ha hecho necesario dirigir el uso externo a grupos de servidores horarios públicos, como ch.pool.ntp.org . El uso indebido, causado principalmente por los proveedores de TI que sincronizan sus infraestructuras de clientes, ha generado demandas inusualmente altas en el tráfico de red, lo que ha obligado a la ETH a tomar medidas efectivas. A partir del otoño de 2012 [actualizar], la disponibilidad de swisstime.ethz.ch se ha modificado a acceso cerrado. Desde principios de julio de 2013 [actualizar], el acceso al servidor está bloqueado por completo para el protocolo NTP.
En diciembre de 2016, la comunidad de operadores NTPPool.org notó un aumento significativo en el tráfico NTP, a partir del 13 de diciembre. [12]
La investigación mostró que la aplicación Snapchat que se ejecuta en iOS era propensa a consultar todos los servidores NTP que estaban codificados en una biblioteca NTP de iOS de terceros, y que una solicitud a un dominio propiedad de Snapchat siguió a la inundación de solicitudes NTP. [13] Después de que se contactó a Snap Inc., [14] sus desarrolladores resolvieron el problema dentro de las 24 horas posteriores a la notificación con una actualización de su aplicación. [15] Como disculpa y para ayudar a lidiar con la carga que generaron, Snap también contribuyó con servidores de tiempo a los grupos NTP de Australia y Sudamérica. [16]
Las configuraciones predeterminadas propensas a errores se mejoraron [17] después de los comentarios de la comunidad NTP. [18] [19] [ cita completa necesaria ]
El firmware de los extensores de Wi-Fi de TP-Link en 2016 y 2017 codificaba cinco servidores NTP, incluidos los de la Universidad de Fukuoka en Japón y los grupos de servidores NTP de Australia y Nueva Zelanda, y emitía repetidamente una solicitud NTP y cinco solicitudes DNS cada cinco segundos, consumiendo 0,72 GB por mes por dispositivo. [20] Las solicitudes excesivas se utilizaron indebidamente para impulsar una verificación de conectividad a Internet que mostraba el estado de conectividad del dispositivo en su interfaz de administración web. [20]
La sucursal de TP-Link en Japón reconoció el problema y presionó a la compañía para que rediseñara la prueba de conectividad y emitiera actualizaciones de firmware que solucionaran el problema para los dispositivos afectados. [21] Es poco probable que los dispositivos afectados instalen el nuevo firmware, ya que los extensores WiFi de TP-Link no instalan actualizaciones de firmware automáticamente ni notifican al propietario sobre la disponibilidad de actualizaciones de firmware. [22] La disponibilidad de actualizaciones de firmware de TP-Link también varía según el país, aunque el problema afecta a todos los extensores de rango WiFi vendidos a nivel mundial. [20] [22]
Se informa que los servidores de la Universidad de Fukuoka se cerrarán en algún momento entre febrero y abril de 2018, y deberían eliminarse de las listas de servidores de tiempo públicos de NTP. [23]
Después de estos incidentes, quedó claro que, además de indicar la política de acceso de un servidor, se necesitaba un medio técnico para hacerla cumplir. Uno de esos mecanismos se proporcionó ampliando la semántica de un campo de identificador de referencia en un paquete NTP cuando un campo de estrato es 0.
En enero de 2006 se publicó la RFC 4330, que actualizaba los detalles del protocolo SNTP , pero también aclaraba y ampliaba provisionalmente el protocolo NTP relacionado en algunas áreas. Las secciones 8 a 11 de la RFC 4330 son de particular relevancia para este tema (El paquete Kiss-o'-Death, Cómo ser un buen ciudadano de la red, Mejores prácticas, Consideraciones de seguridad). La sección 8 presenta los paquetes Kiss-o'-Death:
En NTPv4 y SNTPv4, los paquetes de este tipo se denominan paquetes Kiss-o'-Death (KoD) y los mensajes ASCII que transmiten se denominan códigos Kiss. Los paquetes KoD recibieron su nombre porque uno de sus primeros usos era indicar a los clientes que dejaran de enviar paquetes que violaran los controles de acceso del servidor.
Los nuevos requisitos del protocolo NTP no tienen efecto retroactivo y los antiguos clientes y las implementaciones de versiones anteriores del protocolo no reconocen KoD ni actúan en consecuencia. Por el momento, no existen medios técnicos adecuados para contrarrestar el uso indebido de los servidores NTP.
En 2015, debido a posibles ataques al Protocolo de Tiempo de Red, [24] se propuso un Proyecto de Seguridad de Tiempo de Red para NTP ( Borrador de Internet draft-ietf-ntp-using-nts-for-ntp-19 ) [25] utilizando una implementación de Seguridad de Capa de Transporte . El 21 de junio de 2019, Cloudflare inició un servicio de prueba en todo el mundo, [26] basado en un Proyecto de Internet anterior. [27]
Exploramos el riesgo de que los atacantes de red puedan explotar el tráfico no autenticado del Protocolo de tiempo de red (NTP) para alterar la hora en los sistemas cliente
Usamos nuestra red global para brindar una ventaja en latencia y precisión. Nuestras 180 ubicaciones en todo el mundo usan anycast para enrutar automáticamente sus paquetes a nuestro servidor más cercano. Todos nuestros servidores están sincronizados con proveedores de servicios de tiempo de estrato 1 y luego ofrecen NTP al público en general, de manera similar a cómo funcionan otros proveedores de NTP públicos.