Se necesita considerar la seguridad DNS de manera distinta
Según la Encuesta de IDC 2014 sobre la seguridad DNS: “las soluciones de seguridad tradicionales no constituyen la respuesta adecuada para proteger la infraestructura DNS crítica de los ataques”, afirmó un analista de IDC (el 68% de los encuestados aún utilizan firewalls). “Se trata de un caso claro de respuesta incorrecta a un problema real”.
Durante un ataque, el hacker intenta destruir el servidor DNS de tal manera que las consultas legítimas no puedan ser respondidas o bien intenta corromper la caché DNS para que devuelva información incorrecta. Actualmente, existen varios métodos para protegerse contra ataques sobre el DNS. Uno de ellos consiste en filtrar las consultas DNS para eliminar las consultas ilegítimas y soportar el tráfico legítimo. Pero las soluciones de hoy en día no tienen potencia suficiente como para recibir y analizar cuidadosamente todas las peticiones que se le envíen, pudiendo incluso producir efectos colaterales peligrosos que afecten al servicio DNS.
-Cabe la posibilidad de poner en la lista negra a la persona equivocada
-Los métodos de análisis actuales no pueden gestionar los ataques volumétricos
-Los ataques “lentos”, “insidiosos” o distribuidos no se detectan
-La solución de filtrado puede ayudar a los hackers a envenenar la caché DNS
-El mantenimiento de las reglas resulta complicado
¿Por qué el filtrado no siempre constituye el método adecuado para proteger los servidores DNS?
1. Falsos positivos: cabe la posibilidad de poner en la lista negra a la persona equivocada
Las soluciones de filtrado existentes definen umbrales (tiempo y volumen) y aseguran el análisis del tráfico DNS para identificar comportamientos anormales basándose en dichos umbrales. La eficacia de dichas soluciones des- cansa marcadamente en la agudeza de sus métodos de análisis, que fundamentalmente utilizan la dirección IP fuente como criterio de discriminación. El problema es que fácilmente pueden producir falsos positivos.
El protocolo DNS está basado en UDP, un protocolo de intercambio de datos sin conexión. Cualquier hacker puede engañar fácilmente a una dirección IP legítima para gene- rar ataques que afecten a servicios DNS. Se engaña al sistema de detección y se bloquean las peticiones procedentes de esta dirección IP para proteger la disponibilidad del servicio DNS.
Esta dirección IP puede ser la dirección de un cliente, un partner, la suya propia… Digamos que una de las reglas de filtrado es bloquear las direcciones IP que generan muchos NXDOMAIN. Un hacker genera un montón de resoluciones inexistentes a través de malware instalado en varios ordenadores. En este ejemplo, se envía un gran número de correos electrónicos a un servidor SMTP, y cada correo electrónico contiene una gran cantidad de direcciones de correo electrónico con nombres de dominio inexistentes. El servidor SMTP intentará resolver todos los dominios y saturará los servidores recursivos. Esto activará el sistema de filtrado que bloqueará todas las consultas DNS desde el servidor SMTP, lo que implicará que el servicio de correo electrónico no esté disponible para la empresa
2. Los métodos de análisis actuales no pueden gestionar los ataques volumétricos
Detectar un ataque volumétrico es bastante simple. Pero para detectar ataques de volumen bajo el sistema de filtrado debe efectuar un análisis transaccional minucioso del contenido de los mensajes DNS (consultas, respuestas perentorias, fragmentos, recursiones) para reconstruir las resoluciones extremo a extremo requeridas por los clientes. El sistema necesita almacenar, indexar y analizar grandes cantidades de datos mientras responde simultáneamente al tráfico legítimo sin generar latencia adicional.
El análisis en profundidad realmente está haciendo que las soluciones de filtrado actuales sean más vulnerables a los ataques DDoS. Suelen utilizar herramientas SIEM para analizar el tráfico. Un registro de consultas DNS genera una media de 120 bytes. La mayor parte de los ataques volumétricos generan aproximadamente 1 millón de consultas por segundo, lo que representa aproximadamente 400GB de registros para almacenar, indexar y finalmente analizar por hora. Las soluciones SIEM resultan inoperativas para semejante carga de trabajo y simplemente se detendrán provocando un impacto en todo el sistema operativo. Se trata de una reacción en cadena que provoca la indisponibilidad de varios servicios.
3. Los ataques “lentos”, “insidiosos” o distribuidos no se detectan
Las soluciones de filtrado obsoletas no permiten detectar fácilmente ataques lentos como puede ser el caso de la “tortura china” que no se basan en el volumen sino en consultas incorrectas. Dichos ataques están diseñados para persistir bajo umbrales definidos.
Por ejemplo, un bot envía 10 consultas DNS por segundo para subdominios que pertenezcan a un servidor DNS que no esté respondiendo. En este caso, debido a los reintentos y al intervalo, la respuesta tardará más tiempo en llegar al cliente, ya que los SERVFAIL no están siendo cacheados por la DNS. Para 1.000 clientes infectados, se envían 10.000 consultas únicas por segundo. Se trata de un pequeño volumen procedente de distintas direcciones IP: en su mayor parte no se detectará. Pero para cada una de estas consultas, la resolución tardará mucho tiempo en producirse, los servidores rápidamente recursivos se saturarán y el servicio no estará disponible.
Se produce el mismo problema si, en lugar de utilizar un servidor defectuoso, el botnet genera consultas sobre dominios no existentes y creados aleatoriamente. Debido al tiempo de resolución extendido, la función recursiva de la DNS se saturará rápidamente.
Finalmente: ataques DNS por pulso. Se envían grandes volúmenes de datos en un periodo de tiempo muy corto y el proceso se repite con una frecuencia muy superior a la duración del ataque. El ataque permanece indetectado por la solución de filtrado porque el volumen de consultas (en promedio durante un determinado periodo de tiempo) no se alcanza o bien dispara los mecanismos de filtrado que permanecerán activados durante cierto tiempo, incluso si el ataque ha concluido.
4. La solución de filtrado puede ayudar a los hackers a envenenar la caché DNS
Los hackers que llevan a cabo sus ataques pueden explotar mecanismos de filtrado simples. Ya no constituyen un obstáculo para ellos: se trata de una herramienta.
La mayor parte de las soluciones de filtrado existentes que no implementan RRL pueden hacer que los servidores DNS recursivos resulten vulnerables al envenenamiento de la caché. Bloquear todas las respuestas basadas en la fuente IP atacante es una puerta abierta de par en par para que el hacker envenene una caché DNS.
Cuando una solución de filtrado actuando en un servidor autoritativo detecta un comportamiento sospechoso, se lanzan paquetes y se intenta dar servicio a las consultas legítimas. El problema es que lanzar paquetes deja consultas sin responder y el tiempo durante el cual la DNS recursiva está esperando una respuesta constituye una ventana de oportunidad para que los hackers envenenen la caché. Como consecuencia de ello, un objetivo del hacker será disparar la herramienta de filtrado con un falso positivo para aprovechar estas oportunidades.
Para evitar esto, la mejor solución es DNSSEC. Un recursivo nunca puede saber si la dirección IP ha sido “engaña- da” en la DNS autoritativa. Con DNSSEC, la autenticidad de las respuestas enviadas al servidor recursivo está garantizada. Pero, puesto que el despliegue y el mantenimiento de DNSSEC resulta difícil, la implementación RRL, que protege los sistemas de resolución DNS y la red contra DDoS y limita el riesgo de que se produzca un envenenamiento de la caché, constituye una buena solución intermedia.
5. El mantenimiento de las reglas se convierte en una pesadilla
Los hackers son muy creativos y cada día encuentran nuevas formas de atacar la infraestructura DNS, al tiempo que el estudio de recientes ataques muestra un cambio constante de su perfil y complejidad. El problema con las reglas actuales es que no pueden adaptarse a las amenazas persistentes avanzadas. Si los umbrales son muy bajos, cualquier aumento del tráfico disparará la solución de filtrado con falsos positivos y, a menudo, el tráfico quedará bloqueado. Si los umbrales son demasiado altos, una importante cantidad de pequeños ataques no se detectarán ni se bloquearán. Y siempre se trata de una reacción “posteriori”, siendo muy difícil ser proactivo.
Además, algunas de las soluciones actuales proponen más de 100 reglas que deben configurarse y la combinación de dichas reglas es simplemente una pesadilla. Asimismo, esto implica que cualquier cambio en la configuración induce un riesgo operativo en lo que respecta a la disponibilidad y el rendimiento del servicio.
Conclusión
Si bien las soluciones de seguridad de filtrado de DNS ofrecen un primer nivel de protección contra ataques DNS, no siempre son suficientemente eficaces y, si se utilizan de forma inadecuada, incluso pueden resultar peligrosas. Pueden bloquear el tráfico legítimo (véanse los recientes informes de ataque Rackspace y DNSimple) y son difíciles de mantener. El filtrado o bloqueo de peticiones resulta válido para la mayor parte de los servicios pero no siempre es relevante para el protocolo DNS sin conexión. Ha llegado el momento de buscar nuevas formas de mitigar los ataques DNS.
EfficientIP ofrece un nuevo enfoque en lo que respecta a la seguridad DNS con la aplicación DNS SOLIDserver, garantizando la disponibilidad del servicio DNS incluso cuando se está experimentando un ataque y asegurando la integridad de los datos.
Incluye varias innovaciones clave para detectar, proteger y corregir ataques DNS:
-En primer lugar, el rendimiento. DNS Blast de EfficientIP es la única aplicación DNS disponible en la actualidad que puede absorber hasta 17 millones (17M) de consultas por segundo (QPS). Se trata de una cantidad de ancho de banda superior a la que puede gestionar la red; por tanto, la caché nunca puede saturarse ni corromperse.
-En segundo lugar, una innovación en la arquitectura que separa las funciones DNS caché y recursiva para reforzar y mejorar espectacularmente el marco de seguridad. Cuando una función es objeto de un ataque, cada función se protege individualmente evitando efectos colaterales y continuando con el suministro de servicio.
-En tercer lugar, análisis en tiempo real de las transacciones caché DNS-recursiva permitiendo que los clientes detecten firmas de ataque DNS específicas, protegiendo el servicio aplicando las contramedidas apropiadas y corrigiendo el ataque mediante la identificación de su fuente.
-Finalmente, la contramedida modo de rescate para mitigar los ataques volumétricos, lentos e insidiosos sobre funciones recursivas y caché. Esta innovación garantiza un 100 % de disponibilidad del servicio de caché incluso bajo el ataque DoS más insidioso sobre la función recursiva.
