☰

DDOS usando servidor ntp

tag-icon • tag-icon security ddos ntp
DDOS usando servidor ntp

He oído hablar de un nuevo tipo de DDOS en el quentp se utiliza para la reflexión.

Mis preguntas son realmente simples:

  1. ¿Puede dar detalles sobre cómo funcionan y aclarar? Dado que ntp se ejecuta sobre UDP, supongo que debe haber algún tipo de paquete falsificado en alguna parte.

  2. ¿Cómo es posible comprobar exhaustivamente si algún servidor ntp es vulnerable (y no puede verse involucrado en ningún ataque)?

  3. Si alguna vez nos convertimos en el objetivo de tal ataque, ¿hay alguna manera de mitigarlo?

Como este tipo de ataque se utilizó ampliamente en 2014, aquí hay algunos detalles más:

  • Puedes encontrar más información sobre esto.cve.
  • "Ayer por la tarde, 30/01/2014, a partir de las 22:15 CET, la red Witbe en París se vio gravemente afectada por un ataque de denegación de servicio distribuido (DDOS) que utilizaba amplificación NTP".
  • Ay, 350Gpbs, eso duelehttp://www.itnews.com.au/News/372033,worlds-largest-ddos-strikes-us-europe.aspx
  • El comportamiento genérico sobre ddos ​​se puede encontrar aquí:Estoy bajo DDoS. ¿Qué puedo hacer?
  • La BBC habla sobre los ataques ntp:http://www.bbc.com/news/technology-26662051
  • Una pregunta más: si grabo correctamente, openntpd escucha de forma predeterminada en 127.0.0.1 y ntpd escucha en 0.0.0.0. No estoy muy seguro de si todos los servidores ntp involucrados en los ddos ​​de reflexión necesitaban cumplir condena públicamente. Simplemente, creo que algunos Los administradores de sistemas no cualificados instalaron ntp para sincronizar la hora localmente y dejaron los archivos de configuración predeterminados.

¿Una forma sencilla de prevenir y mitigar este tipo de problemas sería escuchar en 127.0.0.1 de forma predeterminada? ¿Supongo que esto es cierto para cualquier servicio (bind9, mysql, ...)?

Respuesta1

Estos ataques han existido durante años, pero se volvieron populares nuevamente en los últimos meses. Funcionan como cualquier ataque de amplificación normal: un host falsifica una consulta para que la dirección IP de origen parezca ser la del host objetivo. El servidor NTP envía su respuesta a la dirección falsificada. Dado que la respuesta para tipos de consultas específicos puede ser bastante grande y generalmente es UDP, esto puede convertirse rápidamente en un problema para el host objetivo: está siendo inundado con paquetes NTP.

Desafortunadamente, esto no es una vulnerabilidad en los servidores NTP, es simplemente una característica de la que se está abusando. Una cosa a considerar es si necesita ejecutar servidores NTP que se puedan consultar desde todo Internet. Si eso no es necesario, cree una lista de acceso o una política de firewall para bloquear consultas provenientes de fuentes que no sean de confianza. Luego, lo que puede hacer para comprobar si sus servidores NTP son vulnerables es realizar consultas NTP de fuentes no confiables y verificar si obtiene una respuesta. Pero desafortunadamente hay un buen número de servidores NTP que son públicos intencionalmente (por ejemplo, todos los servidores en pool.ntp.org). Si necesita ejecutar un servidor NTP público, puede considerar implementar una limitación de la tasa de consultas para reducir el impacto en el host de destino en caso de abuso.

Otra parte más genérica de la solución es que las redes necesitan implementarBCP38, que les indica que filtren el tráfico que sale de sus redes para que sea imposible enviar paquetes falsificados. Desafortunadamente, todavía hay una gran cantidad de redes que no implementan este tipo de filtrado, por lo que todos los ataques con paquetes fuente falsificados (usando cualquier protocolo como NTP, DNS o chargen) siguen siendo posibles.

Lo que puede hacer para mitigar dicho ataque depende un poco de su red y de las herramientas disponibles, pero una cosa que debe considerar es bloquear los paquetes NTP entrantes de fuentes no confiables (así que verifique qué servidores NTP está utilizando). Por supuesto, esto no ayuda si su enlace ascendente está congestionado. En ese caso, deberá pedirle a su ISP que le ayude a filtrar el tráfico.

Respuesta2

Mis respuestas:

  1. Los ataques utilizan comandos monlist (que se mostrarán como ntpv2 reservado en tcpdump). Estos comandos no están limitados por la velocidad normal. Monlist (y otros comandos de monitoreo) solo funcionarán desde IP a las que se les permite "consultar" su servidor, así que agregue "noquery" a sus valores predeterminados.
  2. Pruebe ntpdc -nc monlist yourip desde una IP externa para ver si su servidor responde.
  3. Limite su tráfico ntp entrante. No en el propio ntpd sino antes de que llegue al demonio. Cómo configurar esto en Linux se analiza en"mi configuración de limitación de velocidad" en la lista de correo del grupo ntp

Respuesta3

  1. ¿Puede dar detalles sobre cómo funcionan y aclarar? Dado que ntp se ejecuta sobre UDP, supongo que debe haber algún tipo de paquete falsificado en alguna parte.

El US-CERT tiene una excelente descripción de este ataque en "Alerta (TA14-017A) Ataques de amplificación basados ​​en UDP" y "Alerta (TA14-013A) Ataques de amplificación NTP utilizando CVE-2013-5211".

TA14-013A lo dice mejor:

Descripción

UDP, por diseño, es un protocolo sin conexión que no valida las direcciones IP de origen. A menos que el protocolo de capa de aplicación utilice contramedidas como el inicio de sesión, es muy fácil falsificar el datagrama del paquete IP para incluir una dirección IP de origen arbitraria [7]. Cuando muchos paquetes UDP tienen su dirección IP de origen falsificada en una sola dirección, el servidor responde a esa víctima, creando un ataque de denegación de servicio (DoS) reflejado.

Recientemente, se ha descubierto que ciertos protocolos UDP tienen respuestas particulares a ciertos comandos que son mucho más grandes que la solicitud inicial. Mientras que antes los atacantes estaban limitados linealmente por la cantidad de paquetes enviados directamente al objetivo para realizar un ataque DoS, ahora un solo paquete puede generar decenas o cientos de veces el ancho de banda en su respuesta. Esto se denomina ataque de amplificación y, cuando se combina con un ataque DoS reflectante a gran escala, hace que sea relativamente fácil realizar ataques DDoS.

El cuadro incluido sobre el "factor de amplificación de ancho de banda (BAF)" muestra que NTP muestra el peor comportamiento. Dado que NTP es un protocolo extremadamente común y muchos sistemas operativos Linux vienen con un servidor NTP activo, este problema es particularmente grave.

información relacionada