Un método habitual para mitigar los ataques de denegación de servicio distribuido basados en la
DNS, se sustenta en ignorar ciertos mensajes cuando se sospecha que son consultas destinadas a generar un ataque. Pero esta técnica destinada a mitigar los ataques
DDoS, pone en riesgo a los servidores que los utilizan, porque facilita a un atacante envenenar la caché de los servidores
DNS que la usan.
amplificación
Hasta hace relativamente poco, para
"tumbar" páginas web importantes bastaba con tener una
botnet lo suficientemente grande como para generar el tráfico necesario. Pero la
"globalización" de servicios y mejora de los sistemas
DDoS en general, hacen que cada vez sea más complejo para un atacante disponer de los
bots mínimos para causar daño. Así que necesitan "amplificar" ese tráfico que generan para poder atacar. Esto lo conseguían en los 90 con ataques tipo "
smurf", pero actualmente (el
ICMP era fácil de capar) se usa sobre todo el
DNS. Tanto ICMP como UDP permiten falsificar al emisor y sobre todo, generar respuestas "muy grandes" a consultas muy pequeñas.
Además de la
botnet y las peticiones falsificadas, los atacantes necesitan
"resolvedores" que se presten a este juego amplificando el tráfico. Los servidores configurados como
recursivos públicamente (se estima que existen sobre el millón accesibles en la red) son los nuevos servidores de correo que permitían
el "open relay" de los 90, y contra ellos se está luchando.
El ataque
El atacante, desde cualquier punto, envía una petición de resolución al servidor
DNS del que se va ayudar, y que dispone de un sistema anti-
DDoS.
Este servidor
DNS realiza la
recursión, preguntando al servidor autoritativo del dominio que corresponda, porque él no sabe la respuesta.
La botnet del atacante avisa
deliberamente al servidor autoritativo, diciéndole que ese servidor
DNS está siendo usado para amplificar, y que active sus mecanismos de protección que fundamentalmente consisten en que ignore a ese servidor
DNS que le pregunta: que no le responda o que lo haga más tarde.
Mientras el servidor espera, el atacante le envía ataques
Kaminsky al servidor (respuestas falsas que cacheará), porque tiene tiempo de sobra para hacerlo. El servidor cree que vienen del servidor autoritativo y las cacheará. El ataque de envenenamiento puede ser otro, pero ellos han usado
Kaminsky, por resultar un problema de diseño intrínseco al protocolo
DNS.
En resumen, aprovechar ese tiempo de
"baneo" para enviar
masivamente respuestas y aumentar las probabilidades de éxito en el envenenamiento de caché.
En realidad, es vulnerable cualquier dispositivo que, queriendo usar
DNS "Response
Rate Limiting" para precisamente evitar ataques, llegue a desestimar peticiones
DNS por considerarlas peligrosas. Incluso ciertos cortafuegos.