Cómo mitigar un ataque DDoS paso a paso Guía completa

Cómo Mitigar un Ataque DDoS Paso a Paso: Guía Completa 2026

Deja un comentario / Ciberseguridad / Por

📘 Este artículo forma parte de nuestra Guía Completa de Ciberseguridad 2026 y de nuestra Guía Completa de Redes 2026. Si quieres entender qué es un DDoS y cómo prevenirlo, consulta Qué es un ataque DDoS y cómo proteger tu sitio web.

Introducción

Tu web está caída. Los usuarios no pueden acceder. El tráfico es 100 veces superior a lo normal. Estás bajo un ataque DDoS.

En ese momento, cada minuto cuenta. Cada minuto de caída son:

  • Pérdidas económicas (20.000-40.000 €/hora de media).
  • Daño reputacional (clientes frustrados).
  • Pérdida de confianza.
  • Posible extorsión (algunos atacantes piden rescate).

Saber qué hacer y en qué orden marca la diferencia entre una interrupción de minutos y una catástrofe de días.

En esta guía completa vas a aprender:

  • Los primeros 5 minutos de respuesta.
  • Cómo identificar el tipo de ataque.
  • Las 3 fases de mitigación.
  • Mitigación por capa (L3/L4 y L7).
  • Cómo configurar Cloudflare, AWS Shield, Nginx.
  • Mitigación con WAF, rate limiting, geo-blocking.
  • Contactar con tu ISP y CDN.
  • Qué hacer si el ataque persiste.
  • Análisis post-incidente.
  • Cómo prepararse para el próximo ataque.
  • FAQ con las preguntas más frecuentes.

Si todavía no tienes plan de prevención, empieza por Qué es un ataque DDoS y Cómo funciona un CDN.

Índice de contenidos

  1. Los primeros 5 minutos
  2. Identificar el tipo de ataque
  3. Las 3 fases de mitigación
  4. Mitigación capa 3-4 (volumétrico)
  5. Mitigación capa 7 (aplicación)
  6. Activación del modo «Under Attack»
  7. Configurar Nginx contra DDoS
  8. Configurar Cloudflare
  9. Configurar AWS Shield / CloudFront
  10. Rate limiting y WAF
  11. Contactar con tu ISP y CDN
  12. Si el ataque persiste
  13. Análisis post-incidente
  14. Cómo prepararse para el próximo ataque
  15. FAQ
  16. Conclusión

1. Los primeros 5 minutos

Cuando detectas que estás bajo un ataque DDoS, actúa rápido pero con orden.

Cómo mitigar un ataque DDoS paso a paso: Guía completa

1.1 Paso 1: Confirma que es un DDoS (30 segundos)

Señales claras:

  • Caída del servicio sin causa aparente.
  • Tráfico anormalmente alto.
  • Picos en CPU/RAM/ancho de banda.
  • Logs con miles de peticiones desde IPs distintas.
  • Alertas del CDN o monitorización.

Cómo confirmarlo:

# Ver peticiones por segundo en Nginx
tail -f /var/log/nginx/access.log | awk '{print $1}' | uniq -c | sort -rn | head

# Ver conexiones activas
ss -s
ss -tun | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head

# Tráfico de red en tiempo real
iftop -i eth0

Si ves 10.000+ conexiones desde 100 IPs distintas → es un DDoS.

1.2 Paso 2: Avisa al equipo (30 segundos)

  • Notifica al equipo de seguridad.
  • Activa el plan de respuesta a incidentes.
  • Designa un responsable de la mitigación.
  • Documenta todo desde el minuto 1.

1.3 Paso 3: Activa el modo «Under Attack» (1 minuto)

Si usas Cloudflare:

  • Dashboard → Security → Settings.
  • Activa «I’m Under Attack Mode».
  • Esto añade un challenge JavaScript a todos los visitantes.

Si usas AWS:

  • AWS Shield Advanced → activa mitigación automática.
  • CloudFront → activa «Attack Mode».

Si no tienes CDN:

  • Aplica rate limiting de emergencia (ver sección 10).

1.4 Paso 4: Identifica el vector (1 minuto)

  • ¿Tráfico volumétrico? (L3/L4).
  • ¿Tráfico aplicacional? (L7).
  • ¿Ataque específico? (DNS amplification, SYN flood, HTTP flood).
  • ¿IPs conocidas? (botnet, ataque dirigido).

1.5 Paso 5: Mitiga con la primera capa (2 minutos)

  • CDN absorbe tráfico (si está activa).
  • Firewall bloquea IPs sospechosas.
  • Rate limiting limita peticiones por IP.
  • CAPTCHA para tráfico sospechoso.

Regla de oro: no apagues el servidor. El atacante gana si lo haces.

1.6 Paso 6: Comunica (continuo)

  • Actualiza al equipo cada 15 min.
  • Publica un mensaje en el sitio (si es posible).
  • Comunica en redes sociales.
  • Prepara un comunicado para clientes.

2. Identificar el tipo de ataque

No todos los DDoS son iguales. La mitigación depende del tipo.

2.1 Por capa OSI

CapaTipoCaracterísticas
L3/L4VolumétricoSaturar ancho de banda
L4ProtocoloAgotar recursos del servidor
L7AplicaciónSaturar la aplicación

2.2 Ataques volumétricos (L3/L4)

Síntomas:

  • Ancho de banda saturado.
  • Tráfico de Gbps o Tbps.
  • Protocolos: UDP, ICMP, DNS.
  • Amplificación (DNS, NTP, Memcached).

Ejemplos:

  • UDP flood.
  • DNS amplification.
  • NTP amplification.
  • Memcached amplification (hasta 51.000x).

Mitigación: CDN + scrubbing centers.

2.3 Ataques de protocolo (L4)

Síntomas:

  • Servidor no responde.
  • Recursos del servidor agotados.
  • Conexiones incompletas.

Ejemplos:

  • SYN flood: conexiones TCP a medias.
  • ACK flood.
  • Ping of Death.

Mitigación: SYN cookies, firewall.

2.4 Ataques aplicacionales (L7)

Síntomas:

  • Servicio caído pero servidor OK.
  • Peticiones «legítimas» pero masivas.
  • Difícil de distinguir del tráfico normal.

Ejemplos:

  • HTTP flood.
  • Slowloris.
  • RUDY.
  • DNS query flood.
  • API abuse.

Mitigación: WAF, rate limiting, CAPTCHA.

2.5 Cómo identificar con logs

# Nginx: contar peticiones por IP
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# Contar peticiones por User-Agent
awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# Contar por URL
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# Peticiones por segundo
tail -f /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f3 | uniq -c

3. Las 3 fases de mitigación

3.1 Fase 1: Contención (minutos)

Objetivo: detener el daño inmediato.

  • Activar modo Under Attack.
  • Rate limiting de emergencia.
  • Bloquear IPs sospechosas.
  • Aumentar recursos si es posible (auto-scaling).

3.2 Fase 2: Mitigación (horas)

Objetivo: neutralizar el ataque.

  • Análisis del tipo de ataque.
  • Aplicar reglas específicas (WAF, firewall).
  • Coordinar con CDN/ISP.
  • Filtrar tráfico malicioso preservando el legítimo.

3.3 Fase 3: Recuperación (días)

Objetivo: volver a la normalidad.

  • Verificar que el servicio es estable.
  • Reducir las medidas temporales poco a poco.
  • Monitorizar durante 48-72 horas.
  • Documentar todo el incidente.
  • Análisis post-incidente.

Consulta Auditoría de ciberseguridad.

4. Mitigación capa 3-4 (volumétrico)

Los ataques volumétricos requieren infraestructura distribuida.

4.1 CDN con scrubbing

La mejor defensa. La CDN absorbe el tráfico antes de que llegue al origen.

Cloudflare:

  • DDoS ilimitado en todos los planes.
  • Absorbe Tbps de tráfico.
  • Sin intervención manual.

AWS Shield:

  • Standard: gratis, protección básica.
  • Advanced: 3.000 $/mes, protección avanzada.

Akamai Prolexic:

  • Enterprise.
  • Scrubbing centers globales.

Fastly:

  • Protección DDoS.
  • Red global.

4.2 Anycast

Distribuye el tráfico entre múltiples PoPs.

  • Cloudflare usa Anycast.
  • El tráfico se reparte por todo el mundo.
  • El ataque pierde efectividad.

4.3 Blackhole routing

Último recurso. Enviar todo el tráfico a un agujero negro.

  • Uso: cuando no puedes diferenciar legítimo de malicioso.
  • Coste: pierdes todo el tráfico.
  • Duración: minutos u horas.

Cómo solicitarlo a tu ISP:

Subject: Urgente - Solicitud de blackhole routing
To: soporte@isp.com

Estamos bajo un ataque DDoS volumétrico.
IP afectada: X.X.X.X
Tráfico: Y Gbps
Ataque: UDP flood / DNS amplification
Solicito blackhole routing temporal.
Contacto 24/7: [tu teléfono]

4.4 Rate limiting a nivel de red

En firewall (iptables/nftables):

# Limitar conexiones por IP
sudo iptables -A INPUT -p tcp --syn -m connlimit \
    --connlimit-above 20 -j DROP

# Limitar tasa de paquetes
sudo iptables -A INPUT -p tcp -m limit --limit 10/s \
    -j ACCEPT
sudo iptables -A INPUT -p tcp -j DROP

En nftables:

sudo nft add rule inet filter input tcp dport 80 \
    limit rate 10/second accept

Consulta Cómo configurar firewall en Linux.

4.5 SYN cookies

Protege contra SYN flood.

# Activar SYN cookies
echo 1 | sudo tee /proc/sys/net/ipv4/tcp_syncookies

Permanente:

echo "net.ipv4.tcp_syncookies = 1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

4.6 Aumentar backlog

echo "net.core.somaxconn = 65535" | sudo tee -a /etc/sysctl.conf
echo "net.ipv4.tcp_max_syn_backlog = 65535" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

5. Mitigación capa 7 (aplicación)

Los ataques aplicacionales se parecen al tráfico legítimo. Requieren análisis más fino.

5.1 WAF (Web Application Firewall)

Cloudflare WAF:

  • Reglas gestionadas (OWASP).
  • Rate limiting.
  • Challenge a bots.

ModSecurity:

  • Open source.
  • Reglas OWASP CRS.
sudo apt install libapache2-mod-security2
sudo a2enmod security2

AWS WAF:

  • Reglas gestionadas.
  • Rate limiting.
  • Geo-blocking.

Consulta Hardening de servidores web.

5.2 Rate limiting

Nginx:

# En http {}
limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
limit_conn_zone $binary_remote_addr zone=addr:10m;

# En server {}
limit_req zone=general burst=20 nodelay;
limit_conn addr 20;

location /login {
    limit_req zone=login burst=5 nodelay;
}

Cloudflare:

  • Rate Limiting en Security.
  • Configurable por URL.

5.3 CAPTCHA / Challenge

Cloudflare Challenge:

  • JavaScript challenge.
  • Turnstile (CAPTCHA invisible).
  • Challenge solo a tráfico sospechoso.

Configuración:

  • Security → WAF → Custom rules.
  • Managed Challenge para User-Agents sospechosos.

5.4 Bloqueo por User-Agent

Nginx:

# Bloquear User-Agents vacíos o maliciosos
if ($http_user_agent ~* (bot|crawler|spider|scraper)) {
    return 403;
}

if ($http_user_agent = "") {
    return 403;
}

5.5 Bloqueo por geolocalización

Si tu web es solo para un país, bloquea el resto.

Cloudflare:

  • Security → WAF → Country Block.

Nginx con GeoIP:

geoip_country /usr/share/GeoIP/GeoIP.dat;

map $geoip_country_code $allowed_country {
    default no;
    ES yes;
    MX yes;
}

if ($allowed_country = no) {
    return 403;
}

5.6 Cache agresivo

Nginx:

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g;

location / {
    proxy_cache my_cache;
    proxy_cache_valid 200 302 60m;
    proxy_cache_use_stale updating error timeout http_500 http_502 http_503 http_504;
    add_header X-Cache-Status $upstream_cache_status;
}

En Cloudflare:

  • Caching → Configuration → Cache Level: Aggressive.

Consulta Cómo funciona un caché de contenido.

5.7 Comprimir respuestas

gzip on;
gzip_types text/plain text/css application/json application/javascript;
gzip_min_length 1000;
gzip_comp_level 6;

5.8 Bloquear HTTP/1.0

if ($server_protocol ~* "HTTP/1.0") {
    return 444;
}

6. Activación del modo «Under Attack»

6.1 Cloudflare «I’m Under Attack Mode»

Qué hace:

  • Añade un challenge JavaScript a todos los visitantes.
  • Filtra bots simples.
  • Reduce carga del origen.

Cómo activarlo:

  1. Cloudflare Dashboard.
  2. Selecciona tu dominio.
  3. Security → Settings.
  4. Security Level: I’m Under Attack.
  5. Guardar.

Consideraciones:

  • Puede afectar a algunos usuarios legítimos.
  • No detiene ataques volumétricos (para eso está su red).
  • Úsalo temporalmente.

6.2 AWS Shield Advanced

Activación:

  1. AWS Console → Shield.
  2. Activar Advanced.
  3. Asociar recursos (CloudFront, ELB).
  4. Configurar proactive engagement.

Coste: 3.000 $/mes + coste de datos.

6.3 Otras CDNs

Akamai:

  • Prolexic.
  • Kona Site Defender.

Fastly:

  • DDoS Mitigation.
  • Rate Limiting.

Bunny:

  • DDoS protection.

6.4 Sin CDN

Si no tienes CDN:

  • Rate limiting agresivo.
  • Firewall con reglas.
  • Blackhole routing (con ISP).
  • Contactar con el ISP para scrubbing.

7. Configurar Nginx contra DDoS

Configuración completa de Nginx endurecido contra DDoS.

7.1 Rate limiting básico

# En http {}
limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=login:10m rate=3r/m;
limit_conn_zone $binary_remote_addr zone=addr:10m;

# En server {}
server {
    listen 80;
    server_name tudominio.com;

    # Aplicar rate limiting
    limit_req zone=general burst=20 nodelay;
    limit_conn addr 20;

    # Timeouts
    client_body_timeout 10s;
    client_header_timeout 10s;
    keepalive_timeout 15s;
    send_timeout 10s;

    # Tamaño máximo
    client_max_body_size 10M;
    client_body_buffer_size 128k;
    client_header_buffer_size 1k;
    large_client_header_buffers 4 8k;
}

7.2 Bloqueo de peticiones sospechosas

# Bloquear User-Agents vacíos
if ($http_user_agent = "") {
    return 403;
}

# Bloquear HTTP/1.0
if ($server_protocol ~* "HTTP/1.0") {
    return 444;
}

# Bloquear métodos no usados
if ($request_method !~ ^(GET|HEAD|POST|PUT|DELETE|OPTIONS)$) {
    return 405;
}

# Bloquear peticiones a archivos sensibles
location ~ /\.(env|git|htaccess) {
    deny all;
    return 404;
}

7.3 Cache agresivo

# En http {}
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=ddos_cache:20m max_size=2g inactive=1h use_temp_path=off;

# En server {}
location / {
    proxy_cache ddos_cache;
    proxy_cache_valid 200 302 10m;
    proxy_cache_valid 404 1m;
    proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
    proxy_cache_background_update on;
    proxy_cache_lock on;
    add_header X-Cache-Status $upstream_cache_status;
    proxy_pass http://backend;
}

7.4 Timeouts ajustados

# En http {}
client_body_timeout 10s;
client_header_timeout 10s;
send_timeout 10s;
keepalive_timeout 15s;

# En server {}
sendfile on;
tcp_nopush on;
tcp_nodelay on;

7.5 Buffer limits

# En http {}
client_body_buffer_size 128k;
client_header_buffer_size 1k;
large_client_header_buffers 4 8k;

7.6 Fail2ban para Nginx

sudo apt install fail2ban

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Añadir a jail.local:

[nginx-limit-req]
enabled = true
filter = nginx-limit-req
port = http,https
logpath = /var/log/nginx/error.log
maxretry = 10
findtime = 60
bantime = 86400

Consulta Cómo configurar Fail2ban.

7.7 Verificar configuración

sudo nginx -t
sudo systemctl reload nginx

8. Configurar Cloudflare

Cloudflare es la mejor defensa para la mayoría de sitios.

8.1 Configuración base

  1. DNS → Proxy activado (nube naranja) en todos los registros.
  2. SSL/TLS → Full (Strict).
  3. Security → WAF activado.
  4. Speed → Optimization con Brotli, HTTP/3.

8.2 Configuración anti-DDoS

Security Level:

  • Normal.
  • High.
  • I’m Under Attack (temporal).

Challenge Passage:

  • 30 minutos.

Browser Integrity Check:

  • Activo.

Privacy Pass:

  • Activo.

8.3 Rate Limiting

  1. Security → WAF → Rate limiting rules.
  2. Crear reglas:
    • URL: /* → 100 req/min.
    • URL: /login → 5 req/min.
    • URL: /api/* → 60 req/min.
  3. Action: Block / Challenge / Managed Challenge.

8.4 Custom Rules (WAF)

Ejemplos:

# Bloquear países
(ip.geoip.country in {"CN" "RU" "KP"}) → Block

# Bloquear User-Agents maliciosos
(http.user_agent contains "curl") or 
(http.user_agent contains "python") → Challenge

# Bloquear peticiones a admin
(http.request.uri.path contains "/wp-admin") and 
(not ip.src in {IPs autorizadas}) → Block

8.5 Under Attack Mode (temporal)

Security → Settings → Security Level: I’m Under Attack.

Duración: solo hasta que pase el ataque.

8.6 Analytics

  • Security → Events.
  • Analytics → Traffic.
  • Ver ataques en tiempo real.

8.7 Coste

  • Free: protección básica.
  • Pro: 20 €/mes, WAF avanzado.
  • Business: 200 €/mes, más protección.
  • Enterprise: desde ~2.000 €/mes, custom.

Consulta Beneficios del uso de CDN.

9. Configurar AWS Shield / CloudFront

9.1 AWS Shield Standard (gratis)

Incluido automáticamente con:

  • CloudFront.
  • Elastic Load Balancer.
  • Route 53.
  • Elastic IP.

Protege contra:

  • L3/L4 volumétrico.
  • SYN flood.
  • UDP flood.

9.2 AWS Shield Advanced (pago)

3.000 $/mes + coste de datos.

Añade:

  • Protección L7.
  • Respuesta proactiva (AWS DRT).
  • Reembolso de costes por escalado.
  • Integración con WAF.

Cómo activar:

  1. AWS Shield → Activate Advanced.
  2. Seleccionar recursos.
  3. Configurar DRT (DDoS Response Team).

9.3 AWS WAF

Configuración:

{
    "Name": "RateLimitRule",
    "Priority": 1,
    "Statement": {
        "RateBasedStatement": {
            "Limit": 2000,
            "AggregateKeyType": "IP"
        }
    },
    "Action": {
        "Block": {}
    }
}

9.4 CloudFront

  • Cache agresivo.
  • Origin Shield para reducir carga del origen.
  • Lambda@Edge para lógica personalizada.

9.5 Coste

  • Shield Standard: gratis.
  • Shield Advanced: 3.000 $/mes.
  • WAF: 5 /mesporwebACL+1/mesporwebACL+1/millón de peticiones.
  • CloudFront: variable.

10. Rate limiting y WAF

10.1 Rate limiting en Cloudflare

Rate limiting rules:

  • Security → WAF → Rate limiting rules.

Ejemplo:

Rule: Login protection
URL: /login
Rate: 5 requests per minute
Action: Block
Duration: 1 hour

Coste: incluido en plan Pro.

10.2 Rate limiting en Nginx

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

server {
    location / {
        limit_req zone=mylimit burst=20 nodelay;
        limit_req_status 429;
    }
}

10.3 Rate limiting en HAProxy

frontend http_front
    bind *:80
    stick-table type ip size 100k expire 30s store http_req_rate(10s)
    http-request track-sc0 src
    http-request deny if { sc_http_req_rate(0) gt 100 }
    default_backend http_back

10.4 WAF reglas

ModSecurity con OWASP CRS:

sudo apt install libapache2-mod-security2
sudo a2enmod security2
sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf
sudo nano /etc/modsecurity/modsecurity.conf
# Cambiar: SecRuleEngine On
sudo systemctl restart apache2

Cloudflare WAF:

  • Reglas gestionadas (OWASP).
  • Reglas personalizadas.
  • Managed Challenge.

10.5 CAPTCHA

Cloudflare Turnstile:

  • CAPTCHA invisible.
  • Sin fricción.
  • Buena UX.

Google reCAPTCHA:

  • v2 (visible).
  • v3 (invisible).

hCaptcha:

  • Alternativa privacy-focused.

11. Contactar con tu ISP y CDN

11.1 Cuándo contactar

  • Ataque volumétrico (L3/L4).
  • Ancho de banda saturado.
  • Servicio completamente caído.
  • Ataque prolongado (+1 hora).

11.2 Qué información dar

Plantilla:

Subject: URGENTE - Ataque DDoS en curso

Estimado equipo de soporte,

Estamos bajo un ataque DDoS activo.

Detalles:
- IP afectada: X.X.X.X
- Dominio: tudominio.com
- Tráfico actual: Y Gbps
- Tipo de ataque: UDP flood / DNS amplification / HTTP flood
- Inicio: [hora]
- Duración: [minutos/horas]

Impacto:
- Servicio: caído / degradado
- Usuarios afectados: [número aproximado]
- Impacto económico: [estimado]

Solicitamos:
1. Verificación del ataque.
2. Activar mitigación en vuestra red.
3. Considerar blackhole routing temporal (si es necesario).

Contacto 24/7:
- Nombre: [tu nombre]
- Email: [tu email]
- Teléfono: [tu teléfono]

Gracias.

11.3 A quién contactar

ISP:

  • Nivel 1: soporte técnico.
  • Nivel 2: ingeniería de red.
  • Nivel 3: abuso.

CDN:

  • Cloudflare: soporte técnico.
  • AWS: Support Center.
  • Fastly: ticket urgente.

11.4 Qué esperar

  • Verificación del ataque.
  • Mitigación en su red.
  • Análisis del tráfico.
  • Tiempo de respuesta: horas.

En caso de emergencia: escalado al NOC (Network Operations Center).

12. Si el ataque persiste

12.1 Opciones avanzadas

1. Blackhole routing:

  • Contacta con el ISP.
  • Todo el tráfico se descarta.
  • Consecuencia: servicio completamente caído.

2. Cambio de IP:

  • Mueve el servicio a otra IP.
  • Actualiza DNS.
  • Consecuencia: propagación DNS (24-48h).

3. Scrubbing centers:

  • Redirige tráfico a un centro de limpieza.
  • Solo el tráfico limpio llega al origen.
  • Proveedores: Akamai Prolexic, Cloudflare Magic Transit.

4. Upstream filtering:

  • ISP filtra en su red.
  • Requiere colaboración.

12.2 Si el atacante pide rescate

Nunca pagues.

  • Financia el crimen.
  • No garantiza que paren.
  • Te marca como objetivo.
  • Puede ser ilegal.

Alternativas:

  • Documentar todo.
  • Contactar con INCIBE-CERT.
  • Contactar con la policía.
  • Mantener mitigación técnica.

12.3 Cuándo parar los servicios

Último recurso:

  • Ataque extremadamente grande.
  • Costes insostenibles.
  • Sin opciones técnicas.

Recomendación: no pares. El atacante gana.

13. Análisis post-incidente

13.1 Documentar

  • Timeline del ataque.
  • Tipo de ataque.
  • Origen (IPs, países).
  • Impacto (económico, reputacional).
  • Mitigación aplicada.
  • Lecciones aprendidas.

13.2 Analizar

  • ¿Cómo se detectó?
  • ¿Cuánto tardó?
  • ¿Qué funcionó?
  • ¿Qué falló?
  • ¿Qué mejorar?

13.3 Mejorar

  • Actualizar el plan de respuesta.
  • Añadir capas de defensa.
  • Formar al equipo.
  • Simulacros periódicos.
  • Monitorización mejorada.

Consulta Auditoría de ciberseguridad.

13.4 Métricas

  • MTTD (tiempo de detección).
  • MTTR (tiempo de respuesta).
  • Duración del ataque.
  • Coste total.
  • Impacto en usuarios.

14. Cómo prepararse para el próximo ataque

14.1 Plan de respuesta

Documento con:

  • Contactos de emergencia.
  • Procedimientos por tipo de ataque.
  • Roles y responsabilidades.
  • Plantillas de comunicación.
  • Checklist de activación.

14.2 Infraestructura

  • CDN con protección DDoS.
  • Auto-scaling en cloud.
  • Redundancia geográfica.
  • Anycast.
  • Firewall preparado.

14.3 Monitorización

  • Alertas tempranas.
  • Análisis de tráfico continuo.
  • Dashboards en tiempo real.
  • NetFlow / sFlow.

Consulta La importancia de la monitorización de redes.

14.4 Simulacros

  • Ejercicios de respuesta.
  • Simulaciones de ataque (autorizadas).
  • Formación continua.
  • Mejora del plan.

14.5 Contratos

  • SLA con CDN.
  • SLA con ISP.
  • Seguro ciber.
  • Servicios de emergencia.

14.6 Documentación

  • Runbooks por escenario.
  • Diagramas de infraestructura.
  • Contactos actualizados.
  • Herramientas documentadas.

15. FAQ

¿Qué es un ataque DDoS?

Un ataque DDoS (Distributed Denial of Service) satura un servicio con tráfico masivo desde múltiples fuentes, haciéndolo inaccesible.

Objetivo: tumbar el servicio.

Consulta Qué es un ataque DDoS.

¿Cómo sé si estoy bajo un ataque DDoS?

Señales:

  • Caída del servicio sin causa.
  • Tráfico anormalmente alto.
  • CPU/RAM al 100%.
  • Miles de peticiones desde IPs distintas.
  • Alertas de CDN o monitorización.

Diagnóstico:

tail -f /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

¿Cuáles son los primeros pasos?

  1. Confirma el ataque.
  2. Avisa al equipo.
  3. Activa modo Under Attack.
  4. Aplica rate limiting.
  5. Contacta con CDN/ISP.
  6. Documenta.

¿Debo apagar el servidor?

NO. El atacante gana si lo haces.

Alternativas:

  • Blackhole routing.
  • Mantener mitigación.
  • Cambiar de IP.

¿Cuánto cuesta mitigar un DDoS?

Varía:

  • Cloudflare Free: gratis.
  • Cloudflare Pro: 20 €/mes.
  • AWS Shield Advanced: 3.000 $/mes.
  • Akamai Prolexic: decenas de miles $/mes.

Coste de NO mitigar: 20.000-40.000 €/hora de caída.

¿Cloudflare es suficiente?

Para la mayoría de casos, sí.

  • DDoS ilimitado en todos los planes.
  • WAF gratuito.
  • SSL gratuito.
  • Buena red global.

Para ataques muy grandes:

  • Cloudflare Enterprise.
  • Akamai Prolexic.
  • AWS Shield Advanced.

¿Qué es el modo «Under Attack»?

Modo de Cloudflare que añade un challenge JavaScript a todos los visitantes.

Efecto: filtra bots simples, reduce carga.

Duración: temporal, solo durante el ataque.

¿Qué es el rate limiting?

Limitar el número de peticiones por IP.

Ejemplo: 100 peticiones por minuto por IP.

Configuración: Cloudflare, Nginx, WAF.

¿Qué es blackhole routing?

Enviar todo el tráfico a un agujero negro (descartarlo).

Uso: último recurso contra ataques volumétricos.

Consecuencia: servicio completamente caído.

Solicitud: a través del ISP.

¿Debo pagar el rescate?

NO, nunca.

  • Financia el crimen.
  • No garantiza que paren.
  • Te marca como objetivo.
  • Puede ser ilegal.

Alternativas: mitigación técnica, denuncia.

¿Puedo mitigar un DDoS sin CDN?

Sí, pero es más difícil.

  • Rate limiting agresivo.
  • Firewall con reglas.
  • Blackhole routing.
  • Contactar con ISP.

Recomendación: usa al menos Cloudflare Free.

¿Qué diferencia hay entre DDoS L3/L4 y L7?

  • L3/L4 (volumétrico): satura ancho de banda. Tráfico masivo.
  • L7 (aplicación): satura la aplicación. Peticiones «legítimas».

Mitigación:

  • L3/L4: CDN con scrubbing.
  • L7: WAF, rate limiting, CAPTCHA.

¿Cómo protejo mi API contra DDoS?

Medidas:

  • Rate limiting por API key.
  • Autenticación fuerte.
  • Cloudflare delante.
  • AWS API Gateway con throttle.
  • Circuit breaker.

Consulta Guía para asegurar APIs.

¿Los DDoS son legales?

No. Son delito en España (Código Penal, arts. 264, 264 bis).

Penalización: prisión de 6 meses a 3 años.

¿Cómo se originan los ataques DDoS?

  • Botnets de dispositivos infectados.
  • IoT vulnerable.
  • Servidores comprometidos.
  • Ransomware-as-a-Service.
  • DDoS-as-a-Service (desde 10 $/hora).

¿Qué es DDoS-as-a-Service?

Servicio en la dark web que permite alquilar ataques DDoS.

Precio: desde 10 $/hora.

Consecuencia: cualquiera puede atacar.

¿Cómo evito ser parte de una botnet?

  • Actualiza dispositivos.
  • Contraseñas robustas.
  • Antivirus/EDR.
  • Firewall.
  • No expongas servicios innecesarios.

¿Qué es un scrubbing center?

Centro especializado que filtra tráfico malicioso.

Cómo funciona:

  1. Todo el tráfico pasa por el scrubbing center.
  2. Se filtra el malicioso.
  3. Solo el tráfico limpio llega al origen.

Proveedores: Akamai Prolexic, Cloudflare Magic Transit.

¿Cuánto dura un ataque DDoS?

Varía:

  • Ataques cortos: minutos.
  • Ataques medios: horas.
  • Ataques sostenidos: días o semanas.
  • Ataques extorsivos: hasta que pagues (no lo hagas).

¿Puedo recuperarme de un DDoS?

Sí, con preparación:

  • Backups regulares.
  • Redundancia.
  • Plan de respuesta.
  • CDN.
  • Auto-scaling.

¿Qué es un ataque de amplificación?

Amplificación: usar servicios legítimos para multiplicar el ataque.

Ejemplos:

  • DNS amplification: ×50.
  • NTP amplification: ×500.
  • Memcached amplification: ×51.000.

Mitigación: CDN con scrubbing.

¿Qué herramientas de monitorización uso?

  • Netdata (tiempo real).
  • Wireshark (análisis).
  • Cloudflare Analytics.
  • Zabbix, Prometheus.

Consulta Las mejores herramientas de monitorización.

¿Cómo sé si el ataque ha terminado?

Señales:

  • Tráfico vuelve a la normalidad.
  • Servicio responde.
  • CPU/RAM normales.
  • Logs sin peticiones anómalas.

Recomendación: monitoriza 48-72 horas.

¿Debo notificar a las autoridades?

Sí, si es grave.

  • INCIBE-CERT (España).
  • Policía Nacional (delitos informáticos).
  • Guardia Civil (GDT).
  • AEPD (si hay datos personales).

¿Cuánto cuesta un ataque DDoS para el atacante?

  • DDoS-as-a-Service: 10-100 $/hora.
  • Botnet propia: coste de desarrollo.
  • Ataques patrocinados: millones.

ROI para el atacante: altísimo.

¿Qué hago si mi ISP no colabora?

Escalado:

  1. Nivel 2 (ingeniería de red).
  2. Nivel 3 (abuso).
  3. Dirección del ISP.
  4. Cambio de ISP.
  5. Denuncia en Consumo.

¿Puedo prevenir un DDoS?

No completamente, pero puedes mitigarlo:

  • CDN con protección DDoS.
  • WAF.
  • Rate limiting.
  • Auto-scaling.
  • Plan de respuesta.

Regla: asume que serás atacado, prepárate para resistir.

¿Qué es la ciberresiliencia?

Capacidad de anticipar, resistir, recuperarse y adaptarse a incidentes.

Diferencia con prevención:

  • Prevención: evitar el ataque.
  • Resiliencia: resistir y recuperarse.

Consulta La importancia de la ciberresiliencia.

16. Conclusión

Los ataques DDoS son una amenaza constante, creciente y muy peligrosa. Cualquiera puede lanzar uno desde 10 $/hora, y los ataques son cada vez más grandes y sofisticados.

La clave está en la preparación. Con un plan de respuesta claro, CDN con protección DDoS, y rate limiting configurado, puedes mitigar la mayoría de ataques en minutos.

Puntos clave:

  1. Los primeros 5 minutos marcan la diferencia.
  2. Identifica el tipo de ataque.
  3. Activa modo Under Attack inmediatamente.
  4. Aplica rate limiting de emergencia.
  5. Contacta con CDN/ISP.
  6. Documenta todo el incidente.
  7. Nunca apagues el servidor.
  8. Nunca pagues rescates.
  9. Análisis post-incidente para mejorar.
  10. Prepárate para el próximo ataque.

Recomendación:

  1. Configura Cloudflare (gratis).
  2. Activa rate limiting en Nginx.
  3. Documenta un plan de respuesta.
  4. Monitoriza continuamente.
  5. Simula ataques (autorizados).

Si quieres profundizar:

Te puede interesar

Deja un comentario