Ciberataques DrDoS basados en el protocolo DNS

Tras el estudio preliminar de los ciberataques de denegación de servicio (DoS) junto con algunas de sus variantes expuestas en el artículo “DrDoS: características y funcionamiento”, en este nuevo artículo se va a abordar cómo el protocolo de DNS es utilizado como una herramienta para desarrollar un ciberataque DoS en su variante DrDoS.

DNS

El protocolo de resolución de nombres de dominio (DNS, Domain Name System), base del funcionamiento de Internet y cada vez más de la intranet, permite a los usuarios acceder a páginas web y aplicaciones mediante nombres más fáciles de interpretar sin necesidad de conocer la dirección IP de cada una de ellas.

Los servidores de DNS operan en un sistema jerárquico en el que un servidor, además de realizar consultas iterativas, puede realizar otras recursivas en la resolución de nombres para otros dominios y atender así, las consultas que le son dirigidas, aunque no sea para el dominio que gestiona directamente. Por otro lado, pese a que soporta el protocolo TCP en la capa de transporte, típicamente trabaja con UDP, por el puerto 53, al ser más rápido.

- Figura 1. Esquema de funcionamiento de DNS. -

Vector de ataque

El ataque se produce cuando una botnet realiza de forma masiva consultas de resolución de nombres a servidores DNS públicos. En estas consultas, se hace un spoofing de IP en el que la IP de origen es reemplazada por la IP de la máquina víctima. Esto es posible gracias a las características del protocolo de transporte UDP. De esta forma, los servidores DNS responden a peticiones legítimas, reflejando el ataque y saturando la capacidad de procesamiento del equipo víctima ante el excesivo número de paquetes de respuesta.

Por otro lado, a ese excesivo número de paquetes de respuesta se añade el posible incremento del tamaño de los mismos ante consultas específicas realizadas por los ciberatacantes, con las que se consigue el efecto “amplificador”, ya que el equipo víctima tiene que emplear más tiempo y recursos para procesar los paquetes recibidos. Algunas de las consultas específicas pueden ser:

• Consultas EDNS0 en las que se determina la extensión de tamaño. Se pasa del formato estándar RFC 2871 convencional al RFC 2673 o RFC 6891.
• Consultas con extensiones de seguridad de DNS (DNSSEC) según el estándar RFC 4033, en las que se añade cifrado al paquete aumentando su tamaño.
• Consultas de tipo “ANY” según el estándar RFC 2871, que provocan la resolución de todos los nombres registrados en una zona DNS en una única respuesta.

Estas consultas pueden combinarse entre sí para aumentar aún más el tamaño de los paquetes, por ejemplo, se puede realizar una petición de tipo ANY de acuerdo al estándar RFC 6891 para obtener una respuesta extendida de tamaño y, además, requerir que esta sea cifrada con DNSSEC. De esta forma, el paquete de datos puede llegar a ser entre 70 y 130 veces más grande que el paquete de origen DNS convencional.

- Figura 2. Esquema de ataque DrDoS DNS. -

Ante los ataques DrDoS, los servidores DNS también pueden verse afectados y colapsar debido al elevado número de consultas que pueden recibir desde la botnet.

Prevención

En primer lugar, para comprobar si un DNS es vulnerable a este tipo de ataques, se puede usar el comando dig en cualquier dispositivo Linux para hacer una petición de zona:

dig AXFR [zona solicitada] [servidor DNS al que se solicita]

Si la respuesta a esta petición es un listado con todos los dominios contenidos en la zona solicitada, el servidor estaría devolviendo una respuesta de un tamaño mucho mayor a la petición y por lo tanto sería vulnerable.

Aunque un servidor propio fuese vulnerable, es posible evitar que pueda ser utilizado para participar involuntariamente en un ataque DrDoS. Para ello, se enumeran las siguientes recomendaciones:

• Definir un protocolo de actuación ante incidentes de ataques DrDoS DNS. Hay que plantear y definir cómo se ha de actuar frente a un ataque DoS que afecte a los servidores DNS propios, adecuándolo a las características de la organización para dar una respuesta rápida y eficaz que minimice los efectos adversos en caso de producirse. Este procedimiento debe recoger cómo identificar estos ataques.
• Solicitar al proveedor de servicios de internet (ISP) filtros anti-spoofing. Estos proveedores pueden rechazar tráfico DNS con direcciones falsificadas, no accesibles a través de la ruta real del paquete. Esto evitará que el servidor DNS propio reciba y atienda consultas susceptibles de ser un ataque DrDoS.
• Desplegar los servidores DNS detrás de cortafuegos. El cortafuegos debe configurarse con reglas que detecten y filtren peticiones dirigidas por UDP al puerto 53 del servidor DNS y que tengan las direcciones IP de origen falseadas.
• Deshabilitar las peticiones recursivas a los servidores DNS globales. La configuración del servidor DNS, que depende de su software, permite desactivar las consultas recursivas. Por estándar, se puede deshabilitar esta función modificando el fichero de configuración “named.conf”, modificando o añadiendo la línea “recursion no;”. En servidores DNS basados en Microsoft Windows, se puede realizar desde la consola de gestión de DNS, accediendo a las “opciones avanzadas” de las propiedades del servidor.
• Eliminar los registros A y AAAA del fichero “db.root”. Esta modificación no afecta al funcionamiento del servidor DNS, puesto que dispone internamente de una lista de servidores DNS raíz. Lo que sí hace es impedir que el servidor actualice automáticamente su lista de servidores de nombres de referencia y las direcciones de los servidores DNS de raíz. También conviene eliminar las referencias a la zona root “.”, en el fichero “named.conf”.
• Limitar el número de respuestas del servidor DNS. A través del parámetro “rate response limit” del archivo “named.conf”, se puede limitar el número de respuestas que se pueden obtener por segundo del servidor DNS.
• Cambiar configuración de red en equipos cliente. En todos los equipos actuales, se puede establecer más de un servidor de resolución de nombres, por lo que se recomienda que se establezca el servidor DNS interno como principal y un servidor DNS público confiable como servidor secundario. Esta configuración se puede establecer de forma manual o automática por DHCP.
• Desplegar sistemas de detección y prevención de intrusiones (IDS/IPS). Para que monitoricen las conexiones y alerten de la detección de tráfico inusual en los protocolos asociados a DNS.
• Desplegar sistemas de monitorización de salud de equipos. Para monitorizar situaciones puntuales de uso intensivo de los recursos, red, procesador y memoria RAM, como indicios de sobrecarga producida por un ataque DoS.
• Implementar alta disponibilidad y balanceo de carga. Para reducir el impacto sobre los sistemas más expuestos, conviene duplicar el número de servidores DNS e implementar balanceadores que distribuyan el tráfico entre distintos servidores.

Detección y evidencias

Los indicios de que un servidor DNS propio está participando en un ataque de denegación de servicio amplificado, radican en su actividad. Una actividad intensiva e inusual relacionada con el tráfico UDP en el puerto 53 debe disparar todas las alertas en este sentido. El análisis del tráfico respecto a la dirección origen de las consultas que se reciben, en todos los paquetes la misma o con claros indicios de haber sido falsificada, confirman la participación en el ataque reflejado.

En el registro de actividad del servidor DNS, logs, también se podrán encontrar trazas del suceso en caso de que haya pasado desapercibido en el momento de producirse el ataque y haya sospechas de su ocurrencia. Los logs asociados al demonio de DNS, BIND, son accesibles por lo que debe consultar la documentación del fabricante para conocer exactamente cómo se almacenan estos registros de auditoría.

Respuesta y recomendaciones

En el caso de estar siendo víctima de un ataque de denegación de servicio distribuida por medio de una amplificación de servidor de nombres, o un servidor de nombres propio este indisponible debido a que se ha usado como medio de amplificación, se recomienda realizar las siguientes acciones:

• Revisar el origen de direcciones IP origen y destino de los paquetes, puertos de destino y direcciones URL de las consultas DNS. Reunir toda la información que se considere que pueda resultar de utilidad para comunicar al proveedor de servicios de Internet para que proceda a su bloqueo.
• Modificar la configuración de DNS para mantener la actividad de los usuarios. Si el servidor DNS afectado es utilizado para resoluciones internas, desconectar el servidor con la red desde donde se produce la inundación de consultas. De este modo, el servidor DNS seguirá atendiendo las peticiones de otras subredes para uso interno y sólo se verá afectado el segmento donde se origina el ataque. Cuando el servidor DNS afectado, haga la resolución de nombres para el exterior, Internet, modificar la configuración DNS de los equipos que lo utilizan como referencia para que utilicen un DNS secundario, que puede ser público, siempre asegurándose que sea confiable.
• Establecer contactos con el proveedor de Internet o hosting. Para comunicarle el suceso y transmitirle la información necesaria para que pueda aplicar las medidas de filtrado de tráfico necesarias para detener el ataque.
• Obtener asistencia técnica. Bien con los proveedores de servicios técnicos de TI que tuvieran contratados o a través de los centros de respuesta a incidentes de seguridad (CERT) de carácter público de referencia, como es INCIBE-CERT.

Igualmente, con independencia de la afectación e impacto que haya podido provocar el ataque, se recomienda informar a las autoridades y realizar un análisis sobre el mismo, para que pueda ser investigado y perseguido.