¿Qué hacer ante un ataque DDoS en un sitio web?

Manuel Schulz · 31.10.2025 · Seguridad informática · 7 min

Hace poco fue Zerlo.net enfrentado a un ataque DDoS. Nos ha interesado: ¿Cómo manejamos eso, cómo reconocemos algo así, y cómo pudimos demostrarlo de manera inequívoca? En este artículo muestro nuestros pasos, qué hay detrás de DDoS y cómo Cloudflare funciona como capa de protección. Si tenéis problemas similares, encontráis herramientas prácticas en nuestra Zerlo-Toolseite y otros artículos en nuestro Zerlo-Blog .

Banner de características: ataque DDoS – imagen simbólica

Fuente: Representación propia

Explicación: ¿Qué es un DDoS?

Un Distributed-Denial-of-Service-Angriff (DDoS) es el intento de inutilizar un servicio en línea mediante solicitudes masivas y distribuidas. “Distributed” significa: el ataque proviene al mismo tiempo de muchos, a menudo fuentes automatizadas ( CISA-Leitfaden). ). Se distingue en gran medida entre ataques a nivel de red (p. ej., UDP/ICMP-Floods) y a nivel de aplicación (Capa 7), por ejemplo HTTP-Floods. . Una buena introducción práctica también la ofrece OWASP ( (Denial of Service)).

¿Cómo se detecta?

Un único valor medido rara vez basta. Patrones típicos: carga de origen en fuerte crecimiento, pero sesiones/conversiones reales sin cambios; de repente muchas solicitudes a endpoints “costosos” (Login, Búsqueda, /api, Formularios); agentes de usuario sospechosos o vacíos; picos inusuales de nuevos ASN; alta CPU/IO sin cambios en el código. Logs limpios son útiles, y podéis evaluarlos, por ejemplo, a través de Cloudflare Logpush/Log Explorer o en el servidor para analizarlas. Una lista de verificación compacta la encontraréis en el Zerlo-Blog ante incidentes similares.

Detección mediante Cloudflare

En Cloudflare se pueden desglosar estos patrones de forma clara:

Seguridad → Eventos/Analítica: Picos por ruta, país, ASN, método, User-Agent ( Security Analytics)).
Tráfico/Analítica: Muchas solicitudes de borde con una alta cuota de origen al mismo tiempo → Indicio de ataques L7 ( Traffic Analytics)).
WAF/Firewall: «Desafiado/Bloqueado» cuenta mitigaciones; ajustar reglas con cuidado ( Cloudflare WAF)).
HTTP-DDoS/Limitación de tasa: Identificar hotspots por IP/ruta ( Rate Limiting Rules, HTTP DDoS Managed Rules)).

Conclusión: para sitios web con muchos usuarios, una capa de protección previa como Cloudflare Application Services es prácticamente obligatoria – la telemetría y las herramientas ayudan a distinguir entre carga legítima y ataque y a responder rápidamente. Internamente remitimos a artículos de fundamentos al Zerlo-Blog y para herramientas al Zerlo-Tools.

Personal

Nosotros de Zerlo Tuvimos que el 31.10.2025 registrar una carga inusualmente alta: la página estuvo varias veces fuera de servicio. Al principio pensé que era un problema técnico. Luego revisé las cifras de visitas: casi idénticas al día anterior, lo cual era extraño, ya que nuestro contador solo mide interacciones humanas (JavaScript). Under-Attack-Mode (UAM) La prueba contraria clásica: iniciar todo localmente (localhost). Resultado: 0% de carga local, por lo que la carga externa debía ser artificial. En Cloudflare el incremento fue claramente visible. Activé temporalmente el

Cloudflare-Statistik: fuerte aumento de solicitudes entrantes

Fuente: Representación propia

En breve: fuimos geddost. Compartiremos más información continuamente en nuestro Zerlo-Blog.

Cloudflare

Si el hosting ya tiene una buena protección a nivel de red, suele ser suficiente para ataques volumétricos, especialmente si el proveedor mitiga. En Zerlo sin embargo, tenemos una red más grande con varios servicios y necesitamos interfaces centrales y situadas delante, que terminen y filtren el tráfico de forma inteligente antes de alcanzar nuestros orígenes. Exactamente aquí ayuda una red de borde global como Cloudflare: Anycast, Caching, WAF, Bot Fight Mode, Rate-Limiting y telemetría detallada.

Cloudflare es gratis en su versión básica y puede activarse temporalmente ante ataques. No detecta todos los escenarios automáticamente a la perfección: hay que observar patrones; luego, con las reglas adecuadas, es muy eficaz. Para configuraciones y benchmarks documentamos las mejores prácticas también en zerlo.net/de/tools.

Explicación del mecanismo de protección de Cloudflare

Tan simple como genial: antes de la carga real de la página, Cloudflare puede realizar una verificación basada en JavaScript ( Challenge) ) y evaluar señales del navegador. Para usuarios reales, ocurre de forma única y apenas perceptible; los bots y scripts fallan o deben usar muchos más recursos. Resultado: la carga en el backend cae de inmediato y vosotros ganáis tiempo para afinar ( WAF, Rate-Limits, Caching)).

❝ No se puede evitar un DDoS: se gestiona. El arte es hacer que los ataques sean invisibles para las personas, pero costosos para los bots. ❞

Manuel Schulz

Zerlo.net

Fuente: Breve visión general sobre botnets y DDoS.

¿Qué se puede hacer al respecto?

Nada.No puedes evitar un DDoS: cualquiera en la red puede enviarte paquetes. Pero puedes hacer que el efecto sea tan pequeño que la página permanezca disponible para usuarios reales. De eso se trata: atenuarlo de forma inteligente en lugar de esperar a que pase.

A corto plazo: Under-Attack-Mode (UAM) activar para mitigar de inmediato la carga de la capa 7.

A largo plazo: WAF-Regeln para POST/API/GETs costosas, Managed-Challenges para agentes de usuario sospechosos, Rate-Limiting por IP. Para páginas públicas, «Bypass on Cookie». Cache Everything“, Para inicios de sesión/Administradores, «Bypass on Cookie». Turnstile Formularios con seguridad.

Operación: Security Analytics observar, alertas establecer, Logs asegurar. Un pequeño script puede capturar UAM automáticamente si fallan los pings y avisarte. Ejemplos y fragmentos los documentamos en zerlo.net/de/blog.

Cloudflare: reglas razonables de WAF/Límite de tasa

(len(http.user_agent) = 0
 or lower(http.user_agent) contains "python"
 or lower(http.user_agent) contains "curl"
 or lower(http.user_agent) contains "bot"
 or lower(http.user_agent) contains "crawler")
=> Action: Managed Challenge

(http.request.method eq "POST"
 or starts_with(http.request.uri.path, "/api/")
 or http.request.uri.path contains "/sendMail.php")
=> Action: Managed Challenge

# Rate Limiting (Beispiel)
(http.request.method eq "POST" and starts_with(http.request.uri.path, "/api/"))
Threshold: 10 requests in 10 seconds per IP
Action: Challenge

# Doku:
# UAM: https://developers.cloudflare.com/fundamentals/reference/under-attack-mode/
# WAF: https://developers.cloudflare.com/waf/
# Rate Limiting: https://developers.cloudflare.com/waf/rate-limiting-rules/
# Challenges: https://developers.cloudflare.com/cloudflare-challenges/

cloudflare_uam_toggle.sh

#!/usr/bin/env bash
# Under-Attack-Mode per API setzen (Beispiel)
# Voraussetzung: CF_API_TOKEN mit Berechtigung 'Zone Settings Edit'
ZONE_ID="<ZONE_ID>"

# UAM EIN
curl -sX PATCH "https://api.cloudflare.com/client/v4/zones//settings/security_level" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"value":"under_attack"}'

# UAM AUS (z.B. wieder auf 'high' oder 'medium')
curl -sX PATCH "https://api.cloudflare.com/client/v4/zones//settings/security_level" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"value":"high"}'

# Mehr: https://developers.cloudflare.com/api/operations/zone-settings-change-security-level

nginx_rate_limit_example.conf

# Nginx: simples per-IP-Limit (Beispiel)
limit_req_zone $binary_remote_addr zone=perip:10m rate=30r/s;

server {
  location /api/ {
limit_req zone=perip burst=60 nodelay;
proxy_pass http://backend;
  }
}

# OWASP-DoS-Cheatsheet: https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html

Más recursos

Fundamentos y profundización: NIST-DoS, NIST-DDoS, CISA-DDoS, OWASP-DoS, Cloudflare Learning Center. Otros artículos prácticos y herramientas los encontraréis en zerlo.net y específicamente en zerlo.net/de/tools.

Conclusión

DDoS no es un estado de excepción, sino una condición operativa. Quien detecta anomalías rápido, las atenúa a corto plazo y luego endurece de forma dirigida, permanece online. Para sitios web en crecimiento es Cloudflare como capa de protección previa muy recomendable: visibilidad, medidas inmediatas y componentes para una operación duradera robusta. Para configuraciones individuales, listas de verificación y fragmentos, remitimos al Zerlo-Blog y el Zerlo-Tools.