Ataques DDoS: las avalanchas digitales que tumban gigantes

Imagina una avenida principal —tu API o web— siendo invadida por miles de coches al mismo tiempo: nada se mueve, nadie entra, nadie sale. Eso es un DDoS, pero en bits. Desde bots en dispositivos domésticos hasta infraestructuras alquiladas por atacantes profesionales, los volúmenes y técnicas han evolucionado: protocolos explotados, ataques a la capa aplicación (HTTP floods), ataques a la capa de transporte (SYN/UDP floods), ataques de estado (reflections/amplification) y combinaciones inteligentes que buscan burlar defensas.

A continuación tienes un post extenso, técnico y narrativo —con ejemplos prácticos, señales de alerta (IoC), cómo mapearlo a MITRE, defensas en cada capa, recomendaciones concretas para equipos que usan Laravel y un playbook operativo para cuando la avalancha ya está en marcha.

Tipos principales de DDoS ¿qué esperar?

• Volumétricos (Capa 3/4): saturan el ancho de banda (UDP floods, amplification/reflection: DNS, NTP, CLDAP).

• De protocolo (Capa 3/4 estado): explotan límites del protocolo (SYN floods, fragmentación, TCP state exhaustion).

• A la aplicación (Capa 7): peticiones HTTP legítimas pero masivas que consumen CPU, memoria o conexiones (GET/POST floods, slowloris, resource-intensive endpoints).

• De amplificación/reflexión: el atacante falsifica la IP de la víctima y hace que servidores públicos respondan masivamente a la víctima.

• Ataques combinados / inteligentes: mezcla de capas (por ejemplo, UDP + HTTP) o “rastreo” que adapta patrones para evadir mitigación.

¿Por qué importan hoy más que nunca?

• Economía del ataque: servicios DDoS-for-hire permiten ataques a bajo costo.

• Extorsión: “pagas y paramos” — empresas presionadas a pagar o correr el riesgo de largas interrupciones.

• Ataques como distracción: mientras se ejecuta un DDoS, los atacantes aprovechan para realizar intrusión lateral o exfiltración.

• Complejidad: la migración a la nube y arquitecturas microservicios cambian el punto de impacto y complican la mitigación.

Señales de que podrías estar bajo DDoS (IoC)

• Tráfico entrante inusualmente alto (bps/pps) desde múltiples /24 o de muchas ASN distintas.

• Aumento repentino de conexiones TCP en estado SYN_RECEIVED (SYN backlog lleno).

• Picos sostenidos en requests por segundo a endpoints específicos (p. ej. /login, /search).

• Alto número de errores 503/504 en balanceadores o WAFs; timeouts en upstream.

• Latencia generalizada y cola de peticiones en workers (hilos ocupados).

• Logs de proxy/NAT mostrando mucha sesión corta desde mismas IPs o geo-distribución masiva.

• Aumento de tráfico UDP en puertos inusuales (posible reflection/amplification).

• Observación en netflow de patrones: muchos flujos pequeños pero masivos o muchos flujos incompletos.

Mapeo a MITRE ATT&CK

• T1499 — Endpoint Denial of Service (varias sub-técnicas relacionadas con DDoS y agotamiento de recursos).
  (Usar MITRE ayuda a integrar detección y priorizar controles de mitigación por técnica.)

Defensa en capas (la estrategia: defensa en profundidad)

1) Preparación: arquitectura resistente

• CDN / Anycast + scrubbing: colocar CDN y servicios Anycast delante de la app. Proveedores (CDN/Cloud + scrubbing) absorben y filtran en capa de borde.

• Autoscaling controlado: escalar no es suficiente por sí solo (puede aumentar la factura); combinar con políticas de mitigación que reduzcan tráfico malicioso antes de escalar.

• Segregación de endpoints críticos: separar endpoints pesados (búsquedas, reportes) y protegerlos con throttles / caches.

• Rate limits y quotas: implementar límites por IP, por token, por cuenta y por device.

• Edge caching y cache-control agresivo: reducir llamadas a la aplicación para contenidos cacheables.

• Circuit breakers y backpressure: colas y mecanismos que rechazan tráfico cuando el sistema está saturado en vez de colapsar.

• Escucha y observabilidad: netflow, sFlow, logs de LB, métricas de app y alertas por pps/bps y latencia.

2) Mitigación de red y transport (nivel infra)

• SYN cookies y tuning TCP stack: configurar kernel para manejar SYN floods (SYN cookies, aumentar backlog, reducir timeouts).

• Limitación por conexión concurrente: limitar conexiones por IP/rango.

• ACLs y listas negras dinámicas: bloquear IPs/ASNs atacantes detectados (con cuidado por falsos positivos).

• BGP Flowspec / Remotely Triggered Black Hole (RTBH): si el ataque es a nivel ISP, coordinar con upstream para filtrar tráfico masivo; preferir scrubbing antes que blackholing si deseas mantener servicio.

• Protección contra amplificación: bloquear tráfico de reply por puertos conocidos si no se usa (por ejemplo, NTP, DNS recursivo expuesto).

3) Mitigación a nivel aplicación (Capa 7)

• WAF + behavioral detection: reglas custom, challenge (CAPTCHA) para tráfico sospechoso, bloqueo por patrones anómalos.

• Progressive challenges: empezar con JavaScript challenges, luego CAPTCHA y negociación de tokens según riesgo.

• Throttling por cuenta/usuario/token: limitar peticiones por minuto y penalizar violaciones con backoff exponencial.

• Protección de endpoints costosos: poner autenticación previa o anti-abuse en endpoints que consumen CPU/DB.

• Connection timeouts cortos y keepalive tuning: reducir impacto de conexiones idle (ej: slowloris).

• Offload heavy work: mover procesamiento intensivo a jobs asíncronos con colas controladas.

Técnicas y ejemplos prácticos — defensas aplicables hoy

A. En el firewall / kernel (Linux tuning ejemplos — conceptual)

• Habilitar SYN cookies:

sysctl -w net.ipv4.tcp_syncookies=1

• Aumentar backlog y reducir timeouts:

sysctl -w net.ipv4.tcp_max_syn_backlog=4096
sysctl -w net.core.somaxconn=1024

(Ajustes deben probarse en entorno; dependen de la carga y del proveedor cloud.)

B. En el balanceador / reverse proxy (NGINX ejemplo conceptual)

• Timeouts ajustados:

keepalive_timeout  10s;
client_body_timeout 10s;
client_header_timeout 10s;

• Limitar conexiones por IP (ngx_http_limit_conn_module) y rate (limit_req):

limit_conn_zone $binary_remote_addr zone=addr:10m;
limit_conn addr 10;

limit_req_zone $binary_remote_addr zone=req_zone:10m rate=10r/s;
limit_req zone=req_zone burst=20 nodelay;

C. En la aplicación (Laravel — medidas concretas)

• Rate limiting con RateLimiter (Laravel 8+):

  use Illuminate\Cache\RateLimiter;
use Illuminate\Support\Facades\RateLimiter as Limiter;
use Illuminate\Http\Request;

  // routes/web.php
Route::middleware(['throttle:global'])->group(function () {
    Route::get('/search', 'SearchController@index');
});

  // App\Providers\RouteServiceProvider::boot()
use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Support\Facades\RateLimiter;

  RateLimiter::for('global', function (Request $request) {
    return Limit::perMinute(60)->by($request->ip());
})

   

Token-based quotas: implementar per-api-key quotas y rechazar cuando se exceda.Queueing y backpressure: mover tareas intensas a colas (Redis, SQS) y aplicar worker autoscale con límites.Cache primero: para endpoints de lectura, cachear respuestas (Redis / Varnish) y servir desde allí.Health endpoints y graceful degradation: devolver 503 con Retry-After cuando el sistema está en modo degradado en vez de colapsar.

Playbook operativo — si te cae un DDoS ahora mismo

Preparación ya debe existir: runbook, contactos de ISP/CDN, métricas baselines.

1) Detectar y confirmar

• Correlaciona netflow, LB logs, WAF alerts y métricas de app (RPS, errores, latencia).

• Identifica tipo del ataque (volumétrico vs aplicación vs combinado).

2) Triage y clasificación

• ¿Es volumétrico en capa 3/4? → coordina scrubbing/ISP/peer.

• ¿Es capa 7 dirigida a endpoints específicos? → aplicar WAF rules, challenges y throttles por endpoint.

3) Mitigación inmediata

• Activar rules de CDN/Cloud (enable DDoS protection / scrubbing).

• Aplicar rate limits globales y por IP/token; habilitar challenge (JS/CAPTCHA) en capa edge.

• Bloquear ASN/IPs claramente maliciosos (temporal).

• Para volumétrico extremo, coordinar con ISP BGP Flowspec o RTBH (con precaución).

4) Contención interna

• Ajustar timeouts y backlog en proxies; priorizar tráfico crítico (API health endpoints).

• Habilitar cache y servir contenido estático desde CDN/backups.

5) Comunicación

• Notificar equipos (SRE, Dev, Legal, Comms). Preparar mensajes públicos y status page.

• Mantén transparencia: decir “trabajando en mitigación; servicio degradado” evita ruido.

6) Recuperación

• Monitorear reducción del tráfico; retirar gradualmente reglas agresivas y verificar normalidad.

• Revisar logs de acceso para detectar actividades paralelas (intrusión que aprovechó el DDoS).

7) Post-mortem

• Analizar origen, vectores, reglas aplicadas y efectividad. Actualiza runbooks, thresholds y playbooks.

Checklist rápido (acciones priorizadas)

• Tener CDN / proveedor de mitigación DDoS configurado (contacto de emergencia).

• Definir y probar reglas de rate-limiting en edge (CDN/NLB) y en app (Laravel RateLimiter).

• Instrumentar observabilidad: netflow, LB logs, métricas RPS/latencia, alertas.

• Preparar playbook y contactos (ISP, CDN, scrubbing) con runbook y SLAs.

• Implementar circuit breakers y colas para trabajo pesado.

• Configurar WAF con reglas para capa 7 y progressive challenges.

• Tuning del kernel (SYN cookies, backlog) y límites de conexión por IP.

• Plan de comunicación (status page + mensaje para clientes).

Reflexión final — cuando la resiliencia importa más que la perfección

Ninguna defensa es infalible, pero la combinación correcta (borde + red + aplicación + procesos) convierte una avalancha en una molestia manejable en lugar de una catástrofe. Para equipos que construyen en Laravel: piensa en caches, límites y degradación controlada como primeras líneas de defensa. Para arquitectos: coloca mitigación en el edge, automatiza respuesta y prueba tus playbooks con ejercicios.

Aquì la siguiente pregunta:  Si mañana tus usuarios no pueden acceder a tu servicio por horas,

¿tu equipo tiene el playbook, los contactos y la estructura para recuperarlo antes de que el daño sea irreversible?