Ataque de Amplificación DNS

Cómo Funciona Ataque de Amplificación DNS

La amplificación DNS combina tres técnicas: falsificación de IP, reflexión y amplificación. El atacante envía consultas DNS a resolvers recursivos abiertos — servidores DNS públicamente accesibles que aceptan consultas de cualquier IP — con la IP de origen falsificada a la dirección de la víctima. La consulta se diseña para producir la respuesta más grande posible: una consulta ANY para un dominio con registros extensos (TXT, DNSSEC, MX, NS, SOA) puede devolver 2,000-4,000 bytes desde una consulta de 60 bytes. El resolver, comportándose normalmente, envía esta gran respuesta a lo que cree que es el solicitante — la víctima. Con más de 30,000 resolvers abiertos disponibles en internet, un atacante con 1 Gbps de capacidad de salida puede generar 28-54 Gbps dirigidos a la víctima. El tráfico reflejado se origina desde miles de servidores DNS legítimos en todo el mundo, haciendo que el filtrado basado en origen sea casi imposible sin bloquear también las respuestas DNS reales.

Ejemplos Reales

Impacto y Evaluación de Riesgo

Los ataques de amplificación DNS están entre las técnicas DDoS volumétricas más efectivas porque combinan altos ratios de amplificación (28-54x, hasta 70x+ con zonas diseñadas) con una infraestructura de reflectores virtualmente ilimitada — millones de resolvers abiertos existen en todo el mundo. El ataque no requiere una botnet para la amplificación en sí; un solo servidor con capacidad de falsificación puede generar cientos de gigabits de tráfico reflejado. El impacto se extiende más allá del objetivo inmediato: los enlaces de ISP upstream se saturan, afectando a todos los clientes que comparten el mismo segmento de red; se produce daño colateral a la infraestructura DNS ya que los resolvers luchan bajo la carga de consultas; y la reputación de IP de la víctima puede verse dañada ya que los resolvers comienzan a poner en lista negra la dirección de la víctima por generar tráfico 'excesivo' (las respuestas reflejadas). El impacto financiero incluye cargos por exceso de ancho de banda (los proveedores de nube facturan por el tráfico DDoS entrante en algunas configuraciones), costos de mitigación de emergencia, violaciones de SLA y pérdida de ingresos durante el tiempo de inactividad. Para organizaciones que dependen de servicios basados en UDP (VoIP, gaming, streaming), la amplificación DNS es particularmente devastadora porque el filtrado requiere una inspección cuidadosa consciente del protocolo para evitar descartar respuestas DNS legítimas.

Cómo Detectar Ataque de Amplificación DNS

Monitorear la proporción de respuestas DNS entrantes respecto a consultas DNS salientes — durante la operación normal esta proporción es aproximadamente 1:1, mientras que durante un ataque de amplificación la víctima recibe miles de respuestas DNS sin haber enviado las consultas correspondientes. Establecer alertas para respuestas DNS no solicitadas (puerto de origen 53, puerto de destino alto aleatorio) que llegan a tasas superiores a la línea base. Analizar los tamaños de respuesta DNS: las respuestas DNS legítimas promedian 100-500 bytes, mientras que el tráfico de ataque de amplificación contiene respuestas de 2,000-4,000+ bytes, desviando la distribución de tamaños dramáticamente. Rastrear las IPs de origen únicas del tráfico DNS entrante: un aumento repentino de docenas a miles de IPs de servidor DNS únicas indica reflexión. Desplegar análisis NetFlow o sFlow en el borde de la red para identificar patrones de tráfico pesados en DNS antes de que saturen el enlace — los datos de flujo pueden revelar firmas de amplificación (UDP puerto 53, altas proporciones de bytes por paquete, fuentes diversas) incluso cuando los flujos individuales parecen legítimos. Para operadores DNS: monitorear su propio resolver en busca de abuso rastreando las tasas de consulta por IP de origen, detectando consultas con IPs de origen fuera de su rango de clientes esperado, y alertando sobre picos repentinos en consultas ANY o de registros DNSSEC.

Cómo Prevenir Ataque de Amplificación DNS

Para objetivos de ataques: desplegar mitigación DDoS upstream (servicios de scrubbing basados en la nube o desvío de tráfico basado en BGP) que puedan absorber los volúmenes de tráfico amplificado antes de que alcancen su red. Configurar los routers de borde para limitar la tasa de respuestas DNS entrantes si su red no aloja servicios DNS públicos — las respuestas DNS legítimas solo deben llegar en proporción a las consultas enviadas. Implementar BCP 38 (RFC 2827) validación de dirección de origen en el borde de su red para prevenir que su propia infraestructura sea usada como fuente de ataque. Para operadores DNS: deshabilitar la recursión abierta inmediatamente — configurar su resolver para que solo acepte consultas recursivas de redes de clientes autorizadas. Implementar Limitación de Tasa de Respuesta (RRL) para limitar las respuestas idénticas al mismo destino, lo que contrarresta directamente el abuso de amplificación. Descartar o restringir las consultas ANY (RFC 8482 recomienda devolver respuestas mínimas a ANY). Habilitar la validación DNSSEC pero tener en cuenta que las respuestas DNSSEC son más grandes y aumentan el potencial de amplificación — combinar con RRL. Para la comunidad de internet: la adopción generalizada de BCP 38 por los ISPs eliminaría la falsificación de IP y haría imposible la amplificación DNS, pero la adopción sigue siendo incompleta décadas después de que se publicó el estándar.

Ejemplos de Código

# /etc/named.conf — BIND 9 configuration to prevent resolver abuse

acl "trusted-clients" {
    192.168.0.0/16;
    10.0.0.0/8;
    172.16.0.0/12;
    # Add your legitimate client networks here
};

options {
    directory "/var/named";
    listen-on { any; };

    # CRITICAL: Only allow recursion for trusted clients
    # This single setting prevents your server from being an open resolver
    recursion yes;
    allow-recursion { trusted-clients; };
    allow-query-cache { trusted-clients; };

    # Allow anyone to query authoritative zones (if you host zones)
    # but deny recursive resolution to the world
    allow-query { any; };

    # Response Rate Limiting — throttle identical responses to same destination
    # Directly counters amplification by limiting how many times
    # the same answer is sent to the same IP per second
    rate-limit {
        responses-per-second 5;     # Max 5 identical responses/sec to same /24
        nxdomains-per-second 2;     # Limit NXDOMAIN responses
        referrals-per-second 5;     # Limit referral responses
        errors-per-second 2;        # Limit error responses
        window 5;                   # 5-second sliding window
        log-only no;                # Enforce, don't just log
    };

    # Minimize ANY responses (RFC 8482)
    # Modern BIND can return minimal responses to ANY queries
    minimal-any yes;

    # Disable zone transfers to unauthorized servers
    allow-transfer { none; };

    # DNSSEC validation (verify responses, don't just relay)
    dnssec-validation auto;
};

import subprocess
import time
import logging
from collections import defaultdict

logger = logging.getLogger('dns_amplification_monitor')

def get_dns_traffic_stats(interface='eth0', duration=10):
    """Capture DNS traffic and analyze for amplification indicators"""
    # Count inbound DNS responses (source port 53) vs outbound queries (dest port 53)
    result = subprocess.run(
        ['timeout', str(duration), 'tcpdump', '-i', interface, '-n',
         '-c', '50000', 'udp port 53', '-q', '--immediate-mode'],
        capture_output=True, text=True, timeout=duration + 5
    )

    inbound_responses = 0   # src port 53 → we're receiving DNS answers
    outbound_queries = 0    # dst port 53 → we're sending DNS queries
    response_sources = set()
    total_bytes = 0

    for line in result.stdout.strip().split('\n'):
        if not line.strip():
            continue
        # tcpdump output: "IP src.port > dst.port: UDP, length N"
        if '.53 >' in line and 'UDP' in line:
            inbound_responses += 1
            # Extract source IP
            parts = line.split()
            for p in parts:
                if '.53' in p and '>' not in p:
                    src_ip = p.rsplit('.', 1)[0]
                    response_sources.add(src_ip)
            # Extract packet length
            for p in parts:
                if p.isdigit() and int(p) > 0:
                    total_bytes += int(p)
                    break
        elif '> ' in line and '.53:' in line:
            outbound_queries += 1

    return {
        'inbound_responses': inbound_responses,
        'outbound_queries': outbound_queries,
        'unique_sources': len(response_sources),
        'total_bytes': total_bytes,
        'avg_response_size': total_bytes / max(inbound_responses, 1),
        'duration': duration
    }

def monitor_amplification(check_interval=30):
    """Continuous monitoring for DNS amplification indicators"""
    while True:
        stats = get_dns_traffic_stats()

        ratio = stats['inbound_responses'] / max(stats['outbound_queries'], 1)
        avg_size = stats['avg_response_size']
        sources = stats['unique_sources']

        # Indicator 1: Receiving far more DNS responses than queries sent
        if ratio > 10 and stats['inbound_responses'] > 100:
            logger.critical(
                f'DNS AMPLIFICATION LIKELY: response/query ratio={ratio:.0f}:1, '
                f'{stats["inbound_responses"]} responses from {sources} unique servers, '
                f'only {stats["outbound_queries"]} queries sent'
            )

        # Indicator 2: Abnormally large DNS responses
        if avg_size > 2000 and stats['inbound_responses'] > 50:
            logger.warning(
                f'Large DNS responses detected: avg {avg_size:.0f} bytes '
                f'(normal: 100-500 bytes), possible amplification payload'
            )

        # Indicator 3: Many unique DNS server sources
        if sources > 200:
            logger.warning(
                f'DNS responses from {sources} unique servers — '
                f'consistent with reflection attack pattern'
            )

        time.sleep(check_interval)

if __name__ == '__main__':
    logging.basicConfig(level=logging.INFO)
    monitor_amplification()

# Rate-limit inbound DNS responses (source port 53)
# Only useful if your server is NOT a public DNS resolver
# These rules limit the damage from amplification hitting your network

# Create a chain for DNS response filtering
iptables -N DNS_AMPLIFICATION

# Only process inbound UDP packets from source port 53 (DNS responses)
iptables -A INPUT -p udp --sport 53 -j DNS_AMPLIFICATION

# Allow DNS responses at a reasonable rate (legitimate traffic)
# A typical server sends ~10-50 DNS queries/sec
iptables -A DNS_AMPLIFICATION -m hashlimit \
  --hashlimit-above 100/sec \
  --hashlimit-burst 200 \
  --hashlimit-mode srcip \
  --hashlimit-name dns_response_limit \
  -j DROP

# Drop oversized DNS responses (amplification payloads > 1500 bytes)
# Legitimate DNS responses rarely exceed 512 bytes (without EDNS0)
# or 1232 bytes (with EDNS0 DNS Flag Day recommendation)
iptables -A DNS_AMPLIFICATION -p udp --sport 53 \
  -m length --length 1500:65535 -j DROP

# Log and drop DNS responses that exceed rate limits
iptables -A DNS_AMPLIFICATION -m limit --limit 5/min \
  -j LOG --log-prefix "DNS-AMP-BLOCKED: " --log-level 4

# Accept everything else (normal DNS responses)
iptables -A DNS_AMPLIFICATION -j ACCEPT

# Anti-spoofing: enable reverse path filtering
sysctl -w net.ipv4.conf.all.rp_filter=1
sysctl -w net.ipv4.conf.default.rp_filter=1

# Verify your resolver is not open (test from external network)
# dig @YOUR_SERVER_IP google.com ANY +short
# If it responds with full recursion, your server is an open resolver

Preguntas Frecuentes

Ataques Relacionados