El uso indebido y abuso del servidor NTP cubre una serie de prácticas que causan daños o degradación a un servidor de Protocolo de tiempo de red (NTP), que van desde inundarlo con tráfico (efectivamente un ataque DDoS ) o violar la política de acceso del servidor o las reglas de participación de NTP . Un incidente fue marcado como vandalismo NTP en una carta abierta de Poul-Henning Kamp al fabricante de enrutadores D-Link en 2006. [1]Posteriormente, otros han ampliado este plazo para incluir de forma retroactiva otros incidentes. Sin embargo, no hay evidencia de que alguno de estos problemas sea vandalismo deliberado. Por lo general, son causados por configuraciones predeterminadas miopes o mal elegidas.
Una forma deliberada de abuso del servidor NTP se notó a fines de 2013, cuando los servidores NTP se utilizaron como parte de ataques de denegación de servicio de amplificación . Algunos servidores NTP responderían a un solo paquete de solicitud UDP "monlist", con paquetes que describen hasta 600 asociaciones. Al utilizar una solicitud con una dirección IP falsificada, los atacantes podrían dirigir un flujo amplificado de paquetes a una red. Esto resultó en uno de los ataques de denegación de servicio distribuidos más grandes conocidos en ese momento. [2]
Problemas comunes del cliente NTP
Los problemas más problemáticos han involucrado direcciones de servidor NTP codificadas en el firmware de los dispositivos de red de los consumidores. Dado que 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 de 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.
- Cuando se coloca detrás de cortafuegos agresivos que bloquean las respuestas del servidor, esta implementación conduce a un flujo interminable de solicitudes de clientes a los servidores NTP bloqueados de forma diversa.
- Estos clientes tan ansiosos (en particular los que realizan encuestas una vez por segundo) suelen representar más del 50% del tráfico de los servidores NTP públicos, a pesar de ser una fracción minúscula del total de clientes.
Si bien podría 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 velocidades logarítmicas o exponencialmente decrecientes para evitar la denegación de servicio .
Este retroceso en protocolo exponencial o logarítmico se aplica a cualquier protocolo sin conexión y, por extensión, a muchas partes de los protocolos basados en conexión. Se pueden encontrar ejemplos de este método de retroceso en la especificación de TCP para el establecimiento de conexión, sondeo de ventana cero y transmisiones de mantenimiento.
Casos notables
Tardis y Trinity College, Dublín
En octubre de 2002, uno de los primeros casos conocidos de mal uso del servidor de hora resultó en problemas para un servidor web en Trinity College, Dublín . En última instancia, el tráfico se remonta a copias que se comportan mal de un programa llamado Tardis [3] con miles de copias en todo el mundo que se contactan con el servidor web y obtienen 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 tiempo falso, lo que provocó que la mayoría de los clientes eligieran un servidor de tiempo diferente. [4] Posteriormente se lanzó una versión actualizada de Tardis para corregir este problema. [ cita requerida ]
Netgear y la Universidad de Wisconsin – Madison
El primer caso conocido de problemas del servidor NTP se inició en mayo de 2003, cuando Netgear 'productos de hardware s inundaron la Universidad de Wisconsin-Madison ' s servidor NTP con las solicitudes. [5] El personal de la universidad asumió inicialmente que se trataba de un ataque de denegación de servicio distribuido malicioso y tomó medidas para bloquear la inundación en la frontera de su red. En lugar de disminuir (como lo hacen la mayoría de los ataques DDOS), el flujo aumentó, llegando a 250.000 paquetes por segundo (150 megabits por segundo) en junio. La investigación posterior reveló que cuatro modelos de enrutadores Netgear eran la fuente del problema. Se encontró 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. En segundo lugar, 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 lanzado actualizaciones de firmware para los productos afectados (DG814, HR314, MR814 y RP614) que consultan los propios servidores de Netgear, sondean solo una vez cada diez minutos y se dan por vencidos después de cinco fallas. Si bien esta actualización corrige las fallas en el cliente SNTP original, no resuelve el problema mayor. La mayoría de los consumidores nunca actualizarán el firmware de su enrutador, especialmente si el dispositivo parece estar funcionando correctamente. El servidor NTP de la Universidad de Wisconsin – Madison continúa recibiendo altos niveles de tráfico de enrutadores Netgear, con inundaciones ocasionales de hasta 100,000 paquetes por segundo. [ cita requerida ] Netgear ha donado $ 375,000 a la División de Tecnología de la Información de la Universidad de Wisconsin-Madison por su ayuda en la identificación de la falla. [ cita requerida ]
SMC y CSIRO
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 Commonwealth de Australia ( CSIRO ) a cerrar al público. [6] Se demostró que el tráfico proviene de una mala implementación de NTP en algunos modelos de enrutadores SMC donde la dirección IP del servidor CSIRO estaba incrustada en el firmware. SMC ha publicado actualizaciones de firmware para los productos: se sabe que los modelos 7004VBR y 7004VWBR están afectados.
D-Link y Poul-Henning Kamp
En 2005, Poul-Henning Kamp , el administrador del único servidor NTP danés Stratum 1 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 de enrutador de D-Link. Los servidores NTP del estrato 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 ser utilizados por aplicaciones que requieran 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 al servidor de Kamp lo limitaba explícitamente a los servidores conectados directamente al intercambio de Internet danés (DIX). El uso directo de este y otros servidores Stratum 1 por los enrutadores de D-Link resultó en un gran aumento en el tráfico, aumentando 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 ofrece su servicio de tiempo " pro bono publico ". A cambio, DIX acordó 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 del tráfico causado por los enrutadores D-Link, DIX le pidió que pagara una tarifa de conexión anual de 54.000 DKK [ cita requerida ] (aproximadamente 9.920 dólares estadounidenses o 7.230 euros [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 D-Link. La empresa negó cualquier problema, lo acusó de extorsión y ofreció una indemnización que, según Kamp, 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 salir a bolsa, Kamp se dio cuenta de que los enrutadores D-Link consultaban 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]
Proveedores de TI y swisstime.ethz.ch
Durante más de 20 años, ETH Zurich ha proporcionado acceso abierto al servidor de hora swisstime.ethz.ch para la sincronización de la hora operativa. Debido al uso excesivo de ancho de banda, con un promedio de más de 20 GB / día, se ha hecho necesario dirigir el uso externo a grupos de servidores de tiempo público, como el ch. pool.ntp.org . El mal uso, causado principalmente por proveedores de TI que sincronizan las infraestructuras de sus clientes, ha generado demandas inusualmente altas en el tráfico de la red, lo que ha provocado que ETH tome medidas efectivas. A partir del otoño de 2012[actualizar], la disponibilidad de swisstime.ethz.ch se ha cambiado a acceso cerrado. Desde principios de julio de 2013[actualizar], el acceso al servidor está completamente bloqueado para el protocolo NTP.
Snapchat en iOS
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ó con 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 América del Sur. [dieciséis]
Como efecto secundario positivo, la biblioteca NTP utilizada es de código abierto, y la configuración predeterminada propensa a errores se mejoró [17] después de los comentarios de la comunidad NTP. [18] [19] [ cita completa necesaria ]
Pruebas de conectividad en extensores Wi-Fi TP-Link
El firmware para los extensores Wi-Fi TP-Link en 2016 y 2017 codificó cinco servidores NTP, incluida la Universidad de Fukuoka en Japón y los grupos de servidores NTP de Australia y Nueva Zelanda, y emitirí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 incorrectamente 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]
El problema fue reconocido por la sucursal de TP-Link en Japón, que presionó a la compañía para que rediseñara la prueba de conectividad y emitiera actualizaciones de firmware para abordar el problema de 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 alcance WiFi vendidos a nivel mundial. [20] [22]
Se informa que los servidores de la Universidad de Fukuoka se apagaron en algún momento entre febrero y abril de 2018, y deberían eliminarse de las listas de servidores de tiempo público NTP. [23]
Soluciones tecnicas
Después de estos incidentes, quedó claro que, además de establecer la política de acceso de un servidor, se necesitaba un medio técnico para hacer cumplir una política. Uno de esos mecanismos se proporcionó al extender la semántica de un campo Identificador de referencia en un paquete NTP cuando un campo Estrato es 0.
En enero de 2006, se publicó RFC 4330, que actualiza los detalles del protocolo SNTP , pero también aclara y amplía provisionalmente el protocolo NTP relacionado en algunas áreas. Las secciones 8 a 11 de RFC 4330 son de particular relevancia para este tema (El paquete del beso a la muerte, Sobre ser un buen ciudadano de la red, Mejores prácticas, Consideraciones de seguridad). La Sección 8 presenta los paquetes de 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 obtuvieron su nombre porque un uso temprano fue para decirle a los clientes que dejaran de enviar paquetes que violaban los controles de acceso al servidor.
Los nuevos requisitos del protocolo NTP no funcionan de forma retroactiva, y los clientes antiguos y las implementaciones de versiones anteriores del protocolo no reconocen KoD y actúan en consecuencia. Por el momento, no existen buenos medios técnicos para contrarrestar el mal uso de los servidores NTP.
En 2015, debido a posibles ataques al tiempo de protocolo de red, [24 ] se propuso una 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 la capa de transporte . El 21 de junio de 2019, Cloudflare inició un servicio de prueba en todo el mundo, [26] basado en un Borrador de Internet anterior. [27]
Referencias
- ↑ Kamp, Poul-Henning (8 de abril de 2006). "Carta abierta a D-Link sobre su vandalismo NTP" . FreeBSD . Archivado desde el original el 8 de abril de 2006 . Consultado el 8 de abril de 2006 .
- ^ Gallagher, Sean (11 de febrero de 2014). "El mayor DDoS jamás dirigido a la red de distribución de contenido de Cloudflare" . Ars Technica . Archivado desde el original el 7 de marzo de 2014 . Consultado el 8 de marzo de 2014 .
- ^ "Tardis 2000" . Archivado desde el original el 17 de agosto de 2019 . Consultado el 13 de junio de 2019 .
- ^ Malone, David (abril de 2006). "HTTP no deseado: ¿Quién tiene tiempo?" (PDF) . ; entrada: . Asociación USENIX . Archivado (PDF) desde el original el 28 de julio de 2013 . Consultado el 24 de julio de 2012 .
- ^ "Enrutadores defectuosos inundan el servidor de tiempo de Internet de la Universidad de Wisconsin, Netgear coopera con la Universidad en una resolución" . Universidad de Wisconsin – Madison . Archivado desde el original el 10 de abril de 2006 . Consultado el 6 de julio de 2020 .
- ^ "Los dispositivos de red casi derriban el reloj atómico" . Taborcommunications.com. 2003-07-11. Archivado desde el original el 4 de febrero de 2013 . Consultado el 21 de julio de 2009 .
- ^ Lester, Andy (19 de febrero de 2006). "Ayude a salvar los servidores de tiempo en peligro" . O'Reilly Net. Archivado desde el original el 18 de agosto de 2007 . Consultado el 7 de agosto de 2007 .
- ^ "Conversor de divisas - Google Finance" . Archivado desde el original el 31 de marzo de 2017 . Consultado el 11 de noviembre de 2016 .
- ^ "Conversor de divisas - Google Finance" . Archivado desde el original el 31 de marzo de 2017 . Consultado el 11 de noviembre de 2016 .
- ^ Kamp, Poul-Henning (27 de abril de 2006). "Carta abierta a D-Link sobre su vandalismo NTP: actualización del 27 de abril de 2006" . FreeBSD . Archivado desde el original el 27 de abril de 2006 . Consultado el 7 de agosto de 2007 .
- ^ Leyden, John (11 de mayo de 2006). "D-Link resuelve la disputa con 'time geek ' " . El registro . Archivado desde el original el 10 de mayo de 2019 . Consultado el 26 de mayo de 2020 .
- ^ "Aumento reciente del tráfico del grupo NTP: 20/12/2016" . Grupo NTP . 2016-12-10. Archivado desde el original el 21 de diciembre de 2016 . Consultado el 20 de diciembre de 2016 .
- ^ "Archivo de lista de correo NANOG: aumento reciente del tráfico del grupo NTP: 19/12/2016" . NANOG / opendac de shaw.ca. 2016-12-19. Archivado desde el original el 24 de septiembre de 2017 . Consultado el 20 de diciembre de 2016 .
- ^ "Archivo de lista de correo NANOG: aumento reciente del tráfico del grupo NTP: 20/12/2016 18:58:57" . NANOG / Jad Boutros de Snap inc. 2016-12-20. Archivado desde el original el 19 de abril de 2017 . Consultado el 19 de abril de 2017 .
- ^ "Archivo de lista de correo NANOG: aumento reciente del tráfico del grupo NTP: 20/12/2016 22:37:04" . NANOG / Jad Boutros de Snap inc. 2016-12-20. Archivado desde el original el 20 de abril de 2017 . Consultado el 20 de abril de 2017 .
- ^ "Archivo de lista de correo NANOG: aumento reciente del tráfico del grupo NTP: 21/12/2016 02:21:23" . NANOG / Jad Boutros de Snap inc. 2016-12-21. Archivado desde el original el 19 de abril de 2017 . Consultado el 19 de abril de 2017 .
- ^ "Biblioteca NTP de iOS: avance a v1.1.4; git commit en github.com" . GitHub . 2016-12-20. Archivado desde el original el 5 de julio de 2020 . Consultado el 19 de abril de 2017 .
- ^ "Biblioteca NTP de iOS: Problema # 47: Nombres de grupo NTP codificados; github.com" . GitHub . 2016-12-19. Archivado desde el original el 5 de julio de 2020 . Consultado el 19 de abril de 2017 .
- ^ "Registro de incidentes de grupo NTP: carga excesiva en servidores NTP" . Grupo NTP . 2016-12-30. Archivado desde el original el 19 de abril de 2017 . Consultado el 19 de abril de 2017 .
- ^ a b c Aleksandersen, Daniel (23 de noviembre de 2017). "El firmware del repetidor TP-Link derrocha 715 MB / mes" . Ctrl Blog . Archivado desde el original el 20 de diciembre de 2017 . Consultado el 21 de diciembre de 2017 .
- ^ "TP-Link 製 無線 LAN 中 継 器 に よ る NTP サ ー バ ー へ の ア ク セ ス に 関 し て" (en japonés). TP-Link . 2017-12-20. Archivado desde el original el 20 de diciembre de 2017 . Consultado el 21 de diciembre de 2017 .
- ^ a b Aleksandersen, Daniel (20 de noviembre de 2017). "TP-Link ofrece firmware desactualizado o sin firmware en el 30% de sus sitios web europeos" . Ctrl Blog . Archivado desde el original el 22 de diciembre de 2017 . Consultado el 21 de diciembre de 2017 .
- ^ "福岡 大学 に お け る 公開 用 NTP サ ー ビ ス の 現状 と 課題" (pdf) (en japonés). Universidad de Fukuoka . Archivado (PDF) desde el original el 29 de enero de 2018 . Consultado el 29 de enero de 2018 .
- ^ Malhotra, Aanchal; Cohen, Isaac E .; Brakke, Erik; Goldberg, Sharon (21 de octubre de 2015). "Atacando el protocolo de tiempo de la red" (pdf) . Universidad de Boston . Archivado (PDF) desde el original el 2 de mayo de 2019 . Consultado el 23 de junio de 2019 .
Exploramos el riesgo de que los atacantes de red puedan aprovechar el tráfico del Protocolo de tiempo de red (NTP) no autenticado para alterar el tiempo en los sistemas cliente
- ^ Franke, D .; Sibold, D .; Teichel, K .; Dansarie, M .; Sundblad, R. (30 de abril de 2019). Seguridad de tiempo de red para el protocolo de tiempo de red . IETF . ID borrador-ietf-ntp-using-nts-for-ntp-19. Archivado desde el original (html) el 13 de junio de 2019 . Consultado el 23 de junio de 2019 .
- ^ Malhotra, Aanchal (21 de junio de 2019). "Presentación de time.cloudflare.com" . Blog de Cloudflare . Archivado desde el original (html) el 21 de junio de 2019 . Consultado el 23 de junio de 2019 .
Usamos nuestra red global para brindar una ventaja en latencia y precisión. Nuestras 180 ubicaciones en todo el mundo utilizan Anycast para enrutar automáticamente sus paquetes a nuestro servidor más cercano. Todos nuestros servidores están sincronizados con proveedores de servicios de estrato 1 y luego ofrecen NTP al público en general, de manera similar a como funcionan otros proveedores públicos de NTP.
- ^ Franke, D .; Sibold, D .; Teichel, K .; Dansarie, M .; Sundblad, R. (17 de abril de 2019). Seguridad de tiempo de red para el protocolo de tiempo de red . IETF . ID borrador-ietf-ntp-using-nts-for-ntp-18. Archivado desde el original (html) el 15 de junio de 2019 . Consultado el 23 de junio de 2019 .
enlaces externos
- El incidente del Trinity College
- Incidente de SMC / CSIRO
- Carta abierta de Poul-Henning Kamp a D-Link (modificada el 27 de abril de 2006)
- Copia de la carta original de Poul-Henning Kamp a D-Link (desde el 23 de abril de 2006)
- ¡Cuando ataca el firmware! (DDoS por D-Link) por Richard Clayton
- Artículo de OSnews sobre "vandalismo NTP"
- Engadget sobre "vandalismo NTP"