Soy un desarrollador y estoy tratando de obtener una idea de lo que podría hacer para permitir que mi aplicación resista los ataques de amplificación de DNS. ¿Ayudarían estos métodos de prevención contra ataques de tipo DOS también? ¿Cuáles son las mejores prácticas de la industria, las pautas para la detección, la prevención y el desgaste de dichos ataques? ¿Hay errores comunes?
El objetivo de un ataque de DNS reflejado es enviar grandes volúmenes de tráfico de red a un host para provocar la caída del tráfico legítimo. Se elige cuando el atacante no controla el ancho de banda suficiente por sí mismo para exceder el ancho de banda del objetivo. En gran medida, es irrelevante si el destino está ejecutando un servidor DNS o no, ya que el daño generalmente ya está hecho cuando los paquetes llegan al servidor.
El primer síntoma que verá es que su servidor no responde a través de la red. Si tiene una conexión fuera de banda (como estar físicamente sentado frente al teclado o usando un iLOM, ALOM, iDrac, lo que sea), el servidor probablemente tendrá una carga baja.
Si sospecha un ataque de DNS reflejado, puede usar tcpdump para buscar una gran cantidad de respuestas de DNS que no solicitó. Hacer un seguimiento de las solicitudes y las respuestas puede ser difícil, pero si no realiza ninguna solicitud de ninguna , todas las respuestas son parte del ataque.
tcpdump -A -n dst port 53 and not host <local IP address>
La opción -n es importante aquí porque le dice a tcpdump que no haga búsquedas de DNS, que en este tipo de ataque expirará. El <local IP address> obviamente debe reemplazarse con su dirección IP de salida.
Si realmente está ejecutando un servidor de nombres, la asignación aleatoria del puerto de origen puede ayudar a reducir la carga que causan estas respuestas falsas. Dan Kaminsky encabezó una colaboración hace unos años que hizo de esto una parte estándar de todo lo moderno. servidor de nombres.
Algunos firewalls con estado pueden rastrear "sesiones" UDP. La configuración de su firewall para eliminar cualquier entrada entrante en el puerto 53 que no sea parte de una sesión establecida podría impedir que las respuestas falsas lleguen a un servicio válido en su máquina, lo que significa que los paquetes no tendrían que procesarse. Una regla DROP es mejor que una regla REJECT porque una regla% co_de en realidad envía una respuesta ICMP al servidor de nombres que le envía la respuesta DNS falsa (que usa más ancho de banda), mientras que la regla% co_de simplemente se detiene todo allí y no desperdicia ancho de banda adicional.
Aún suponiendo que está ejecutando un servidor de nombres, asegúrese de que el almacenamiento en caché esté activado y funcionando. (En realidad, haz esto ahora de todos modos. Los servidores de nivel superior te lo agradecerán).
Lamentablemente, estas tres cosas son prácticamente una gota en el océano si se ha agotado el ancho de banda de su proveedor de alojamiento, lo que suele ser el caso.
Las dos estrategias más exitosas para sobrevivir a un DoS basado en el ancho de banda son
Si el cuello de botella se encuentra dentro de la red de su proveedor de alojamiento, es posible que puedan filtrar el tráfico más lejos siempre que pueda darles algo concreto y preciso, como "eliminar todos los paquetes UDP entrantes con el puerto de destino 53".
Si está fuera o al borde de su red o si simplemente no pueden filtrar tanto tráfico, el siguiente paso es una compañía que se especialice en mitigar los ataques DoS. Hay muchas opciones en estos días y realmente no puedo recomendar ninguna de ellas sin experiencia personal. Hay una lista rápida en ServerFault . El consenso general es que son caros, pero a menudo menos que el tiempo de inactividad o la solicitud de extorsión que sigue inmediatamente al ataque.
También hay que tener cuidado con los ataques. He escuchado informes de que a veces el DoS es simplemente una desviación antes / después / mientras los atacantes entran y roban los datos.
Tómate un poco de tiempo y visita este sitio: enlace
Esta herramienta fue desarrollada para descartar ataques de DNS a su nombre (BIND). Más información se puede obtener en la página de arriba. No se necesitan reglas de firewall.
(revelación: estoy afiliado a bindguard)
Lea otras preguntas en las etiquetas denial-of-service dns attack-prevention ddos incident-response