Reflexión UDP y amplificación DNS: cuando una consulta se convierte en una avalancha

Una infraestructura puede quedar indisponible sin que el atacante consiga ejecutar código en ella. En los ataques de reflexión y amplificación, se utilizan servicios accesibles desde la red como intermediarios para dirigir tráfico al objetivo. El DNS es uno de los ejemplos más conocidos de esta combinación.

Para el Red Team, entender este mecanismo ayuda a investigar dos exposiciones: la posibilidad de que la organización actúe como reflector y su capacidad para responder a un ataque volumétrico. Cada hipótesis exige evidencias diferentes y reglas de enfrentamiento propias.

Reflexión y amplificación son cosas distintas

La reflexión ocurre cuando la respuesta de un servicio se envía a un tercero cuya dirección se presentó como origen de la solicitud. La amplificación es el aumento de volumen entre la solicitud y las respuestas que provoca. Puede haber reflexión sin un aumento significativo de tamaño; juntas, ambas técnicas permiten dirigir más tráfico al objetivo del que envió originalmente el emisor.

El UDP, definido por la RFC 768, no establece una conexión con un handshake que confirme la alcanzabilidad del remitente antes de una respuesta. Sin controles adicionales, un servicio puede responder a la dirección de origen indicada en el paquete, aunque esté falsificada. La aplicación puede añadir mecanismos de validación, por lo que utilizar UDP, por sí solo, no convierte a todos los servicios en amplificadores. La CISA describe esta combinación en su alerta sobre ataques de amplificación basados en UDP.

Cómo entra el DNS en esta cadena

El flujo de reflexión DNS, analizado en la RFC 4732 sobre denegación de servicio, tiene tres participantes:

1. Emisor: envía una consulta DNS por UDP con la dirección de origen falsificada para que coincida con la dirección del objetivo.
2. Reflector: recibe la consulta y envía la respuesta a la dirección indicada como origen.
3. Objetivo: recibe respuestas que no solicitó; cuando el volumen supera su capacidad, la disponibilidad puede verse afectada.

El aumento de volumen depende del tamaño de las respuestas en relación con las consultas. Al distribuir el proceso entre varios reflectores, el tráfico converge desde múltiples orígenes. El objetivo no necesita operar un servidor DNS: basta con que reciba el tráfico destinado a su dirección. Cloudflare explica este funcionamiento en su análisis de amplificación DNS.

El servidor intermediario tampoco necesita estar comprometido. Un resolvedor recursivo abierto, que acepta solicitudes de clientes externos sin restricciones adecuadas, puede ser utilizado de forma abusiva mediante su funcionalidad normal. Los servidores autoritativos también pueden participar en la reflexión, aunque no ofrezcan recursión. Distinguir las funciones es esencial para elegir la corrección, como explica la RFC 5358.

El factor de amplificación no es un número fijo

La CISA define el factor de amplificación de ancho de banda a partir de los bytes de carga útil UDP enviados en las respuestas en relación con los bytes de carga útil de la solicitud:

Factor de amplificación = bytes de carga útil en las respuestas ÷ bytes de carga útil en la consulta.

En un ejemplo puramente didáctico, una consulta de 80 bytes que provoca una respuesta de 800 bytes tiene un factor 10 según esta métrica. Esto no representa una medición de un servidor real ni incluye los encabezados de las demás capas.

La tabla histórica de la alerta de la CISA no debe tratarse como una promesa de rendimiento actual. Los registros consultados, la implementación y la configuración influyen en las respuestas. Un informe técnico debe registrar qué midió, en qué contexto y qué límites impiden extrapolar el resultado.

Tres simplificaciones que dificultan el análisis

«Cualquier consulta ANY devuelve todos los registros». Esa expectativa es inadecuada. La RFC 8482 describe respuestas mínimas para consultas ANY, incluso con solo un subconjunto de los registros. Una explicación basada en respuestas siempre enormes puede no representar al servidor evaluado.

«Basta con cerrar la recursión». Restringir la recursión es una medida central para los resolvedores privados, pero un DNS autoritativo público necesita seguir respondiendo por sus zonas. La RFC 5358 ya reconoce que los servidores autoritativos pueden utilizarse como reflectores. Exigen controles apropiados para el servicio público que ofrecen.

«El firewall del objetivo lo resuelve solo». Si el enlace de entrada ya está saturado, descartar paquetes después de ese punto no recupera la capacidad perdida. La protección debe considerar al proveedor y los recorridos anteriores al cuello de botella. Cloudflare analiza esta limitación de las mitigaciones locales.

Qué evaluar en un ejercicio de Red Team

Una evaluación empieza con una pregunta verificable. Por ejemplo: «¿nuestro resolvedor privado acepta recursión desde una red que no debería tener acceso?» o «¿el equipo reconoce las respuestas DNS no solicitadas y contacta con el proveedor correcto?».

Las reglas de enfrentamiento deben identificar los activos permitidos, la ventana, los responsables, los límites de tráfico y los criterios de parada. Autorizar una evaluación de seguridad no implica autorizar pruebas de denegación de servicio; cualquier prueba de disponibilidad debe estar prevista expresamente.

Un itinerario de evaluación puede seguir esta secuencia:

1. Mapear las funciones de los servicios. Identificar resolvedores privados, servidores autoritativos, interfaces expuestas y controles de acceso previstos.
2. Revisar configuraciones y accesos. Verificar si clientes ajenos al conjunto autorizado pueden utilizar la recursión mediante comprobaciones puntuales de bajo volumen en los activos dentro del alcance.
3. Observar la asimetría en el laboratorio. Utilizar clientes, servidores y destinos propios, en una red aislada, para comparar tamaños de mensajes y capturar el flujo. Si el ejercicio incluye un origen falsificado, mantenerlo contenido en esa red y autorizado en el alcance.
4. Validar la visibilidad. Comprobar qué eventos llegan al monitoreo, si las alertas permiten distinguir las funciones de los activos y quién recibe el suceso.
5. Repetir después de la corrección. Comparar los mismos escenarios y confirmar que los clientes legítimos siguen resolviendo nombres.

El registro debe incluir la hipótesis, la topología, la configuración relevante, los horarios, las evidencias y el resultado esperado. Demostrar la exposición no exige saturar el servicio. Una demostración de bajo volumen tampoco demuestra resistencia a un ataque volumétrico; esa capacidad requiere una evaluación específica.

Qué señales ayudan a investigar

En el perímetro del objetivo, una hipótesis de reflexión DNS puede empezar por un aumento de respuestas UDP con puerto de origen 53, procedentes de múltiples servidores, sin que se observen las consultas correspondientes. En el posible reflector interesa comparar consultas recibidas, respuestas emitidas, destinos y crecimiento del volumen.

Estas señales son pistas para correlacionar, no pruebas aisladas. Una captura parcial, rutas asimétricas o pérdida de telemetría pueden ocultar consultas legítimas. La investigación debe relacionar flujos, contenido DNS cuando esté disponible, métricas del enlace y comportamiento de los servicios.

El ejercicio gana valor cuando registra el tiempo hasta la detección, la calidad del triaje y el tiempo hasta activar la mitigación. Son criterios propuestos para la evaluación: la organización debe definir los límites aceptables según sus servicios y su capacidad operativa.

Mitigación por capas

En el resolvedor privado: limitar la recursión a los clientes autorizados y revisar la exposición en todas las interfaces relevantes. La RFC 5358 recomienda que los servidores no ofrezcan recursión a redes externas por defecto.

En el DNS autoritativo: evaluar Response Rate Limiting (RRL) y políticas de respuesta compatibles con el servicio. La documentación de BIND 9 describe el control de respuestas UDP excesivas y similares. También advierte que su uso en resolvedores recursivos puede perjudicar a aplicaciones legítimas; restringir la recursión abierta sigue siendo la medida preferible en ese caso.

En la red de origen: aplicar validación de direcciones de origen para reducir la salida de paquetes falsificados. La BCP 38, publicada como RFC 2827, establece la práctica de filtrado que combate este tipo de spoofing.

En el camino hacia el objetivo: mantener un plan de mitigación con el proveedor o servicio de protección DDoS, incluidos los contactos y las condiciones de activación. Bloquear indiscriminadamente el tráfico DNS puede interrumpir la resolución legítima y el control debe realizarse donde aún exista capacidad para tratar el volumen.

Cada capa actúa en una parte de la cadena. El informe del Red Team debe mostrar qué exposición se confirmó, qué control se evaluó y qué sigue dependiendo de una validación. Ese vínculo entre mecanismo, evidencia y corrección convierte el estudio de la amplificación DNS en una mejora verificable de seguridad.

Como siguiente paso, elige un resolvedor bajo tu responsabilidad y documenta quién debería poder utilizarlo. Compara la configuración con esa expectativa y registra una comprobación autorizada de bajo volumen antes de considerar cualquier ejercicio de disponibilidad.