Ataque reflejado amplificado en servidores DNS


11

El término Amplified reflected attackes nuevo para mí y tengo algunas preguntas al respecto.

He oído que sucede principalmente con servidores DNS, ¿es eso cierto?
¿Cómo te proteges contra eso?
¿Cómo saber si sus servidores pueden usarse en un ataque de este tipo? ¿Es un problema de configuración?

Respuestas:


22

Primero, este tipo de ataque no está (principalmente) dirigido al DNS en sí mismo como sugiere su título. Por supuesto, creará una carga adicional en los servidores DNS, pero el propósito principal es DDoS a otra persona. La mala configuración del servidor podría empeorarlo, pero al final este problema es inherente al diseño de DNS y UDP y, de hecho, a cualquier protocolo de comunicación sin estado.

Básicamente funciona así: un atacante envía consultas ordinarias (DNS) a un servidor (DNS). Esas consultas se falsifican para aparecer como si se originaran en el sistema de objetivos. El servidor DNS ahora responde la consulta, enviando la respuesta a su supuesto origen: la víctima. Por eso se llama ataque de reflexión .

Esto es posible porque puede verificar la fuente de comunicación sin estado (como DNS sobre UDP) tan bien como puede confiar en la dirección del remitente en una tarjeta postal. El servidor simplemente no tiene forma de decidir si una consulta es legítima o parte de dicho ataque. DNS es solo el protocolo más popular aquí porque hay muchos servidores para ello y no necesita mucha información técnica o equipo especial para (mal) usarlo.

Para empeorar las cosas (y en absoluto para atacar), mire la parte de amplificación . No sería un gran daño si el tráfico del atacante fuera igual en tamaño al tráfico resultante. El único beneficio para el atacante sería que su dirección se oculta detrás del servidor DNS. Podía falsificar la dirección del remitente directamente, no habría necesidad de cambiar de ruta por DNS. Pero las respuestas de DNS, y ese es otro punto por el cual DNS es tan popular aquí, puede ser mucho más grande que la pregunta. Puede encontrar números variables sobre esto dependiendo de las consultas exactas utilizadas, pero puede ir hasta 1:60 si el servidor es lo suficientemente amigable para realizar consultas recursivaspara ti. Por lo tanto, el atacante no necesita muchas máquinas bajo su control para producir mucho tráfico malicioso.

Como puede encontrar fácilmente cientos y miles de servidores DNS "abiertos" en Internet público, puede hacer los cálculos rápidos sobre el poco trabajo que tiene que hacer un atacante si cada servidor DNS abierto que conoce reflejará sus consultas amplificadas sesenta veces al objetivo. Como dije al principio, no hay una buena manera de contrarrestar esto. Naturalmente, muchos servidores DNS están abiertos a todos, mientras que no deberían estarlo, debido a una configuración incorrecta. Pero hay tantos servidores abiertos que tienen que estar abiertos, porque ese es exactamente su propósito.

Si bien no puede saber si una solicitud es parte de un ataque o no, su única opción es no ejecutar más el servidor. Puede jugar con la limitación de velocidad y otros juguetes, pero no puede deshacerse por completo de esto. Si proporciona DNS por diversión, puede incluir en la lista negra la IP de origen de las solicitudes. Pero si está en una escala mayor, esto dañaría aún más a la víctima. Recuerde, todo lo que puede ver en el servidor DNS es la dirección de la víctima. Imagine que su empresa está bajo ataque a través del DNS de su proveedor y su proveedor decide cortar el servicio de DNS para su empresa. El atacante podría calificar esto como un billón de puntos de bonificación en relación con la denegación de servicio .

De todos modos, esos ataques ocurren todo el día y toda la noche y se consideran "ruido de fondo" de Internet. Si configura un servidor DNS público (recursivo), no tardará mucho en participar en ataques aleatorios. Por supuesto, a veces las cosas se ponen realmente mal cuando las grandes infraestructuras (como incluso los servidores raíz dns) se usan incorrectamente para amplificar, pero en esos casos se toman contramedidas proactivas hasta que el ataque baja a niveles "normales".


Hasta ahora en la enseñanza. Para responder a su pregunta, por fin:

Usted sabe que su servidor es vulnerable si responde consultas sin restricciones. Período. Si está atendiendo consultas recursivas, su servidor puede generar la relación 1:60 mencionada para el atacante. Si solo sirve de forma no recursiva, no es tan malo, pero aún así ...

Entonces...

  • asegúrese de que realmente necesita ejecutar un servidor DNS público
  • si es necesario, eche un vistazo a BIND allow-recursiony allow-querydirectivas
  • Si su servidor DNS tendrá autoridad para su propia zona , no hay necesidad de recurrencia, establezca allow-recursion"ninguno";
  • si desea ejecutar un solucionador para otros dominios , restrinja los usuarios permitidos para consultas y consultas recursivas. Puede definir direcciones IP, redes o listas de acceso en las directivas mencionadas
  • piense en limitar el tráfico DNS no solo en BIND sino también en el nivel del sistema. Como un ejemplo muy simple, estas reglas de iptables no permitirán más de 10 consultas por minuto desde cada dirección IP:

.

iptables -A INPUT -p udp --dport 53 --set --name dnslimit
iptables -A INPUT -p udp --dport 53 -m recent --update --seconds 60 --hitcount 11 --name dnslimit -j DROP

Ahora, con estos puntos en mente, debería estar listo. Todavía puede haber tráfico malicioso en su servidor de vez en cuando, pero no en cantidades que le quiten el sueño.


3
Esta es una muy buena respuesta. Gracias por tomarte el tiempo de escribirlo.
jamieb

1
@mikejanson serverfault.com/questions/450099 - eche un vistazo a esta pregunta para ver qué otras opciones podría tener (especialmente el parche BIND de Vixie & Schryver )
the-wabbit

RRL ahora es una característica estándar de bind y otros servidores de nombres: kb.isc.org/article/AA-01000/189/…
Patrick Mevzek

En general, es un error tener el mismo servidor autorizado y recursivo. Las mejores prácticas aconsejan dividir eso en dos procesos separados.
Patrick Mevzek
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.