# 7 señales de que tu web sufre un ataque DDoS (y qué hacer en los primeros 10 minutos)

> La mayoría de los equipos pierden los primeros veinte minutos de un ataque discutiendo si es un ataque siquiera. Aquí tienes las señales que separan un pico de tráfico de una inundación, y el orden de acciones que de verdad acorta un incidente.

- Category: Buenas prácticas
- Author: Equipo Akarguard, Ingeniería de Seguridad
- Published: Apr 2, 2025
- Canonical: https://akarguard.net/es/blog/senales-de-ataque-ddos

---

Un ataque DDoS rara vez se anuncia. Lo primero que ves es una web lenta, una alerta de paging o una queja de un cliente — los mismos síntomas que un despliegue fallido, un bloqueo de base de datos o una publicación viral. Los equipos que se recuperan más rápido son los que pueden clasificar el evento en minutos en vez de discutirlo durante una hora.

## Las siete señales

- La tasa de peticiones salta muy por encima de tu pico normal, pero las conversiones y los registros se mantienen planos — la demanda real mueve ambos números juntos.
- El tráfico se concentra en una ruta. Una inundación suele machacar una sola URL, a menudo la home, un endpoint de búsqueda o un formulario de login.
- El servidor de origen está ocupado pero la base de datos está ociosa: las conexiones se apilan en la capa web mientras las consultas por segundo apenas se mueven.
- Los tiempos de respuesta suben mientras la CPU del servidor de aplicación está baja — el cuello de botella son las conexiones y los sockets, no el cálculo.
- Las direcciones de origen son geográfica o topológicamente improbables: un negocio regional servido de repente desde decenas de redes desconocidas.
- Los user agents son uniformes, ausentes o raramente anticuados. Las poblaciones de navegadores reales son caóticas; las botnets son monótonas.
- El patrón es demasiado regular. El tráfico humano respira con la jornada laboral; las inundaciones son líneas planas u ondas cuadradas.

> **Prueba rápida** — Compara las peticiones por segundo con los pedidos, registros o logins por minuto en la misma ventana. Si el volumen de peticiones se multiplica y los eventos de negocio no, estás viendo automatización, no clientes.

## Qué NO hacer primero

Las respuestas instintivas suelen ser las equivocadas. Reiniciar el servidor web vacía la cola unos segundos y luego se vuelve a llenar. Escalar el origen compra capacidad que el atacante puede consumir más rápido de lo que tu factura puede absorber. Bloquear a mano un puñado de direcciones ruidosas es satisfactorio y casi nunca relevante, porque el conjunto de fuentes suele ser mucho mayor que las direcciones que llegaron al final de tu log.

## Los primeros diez minutos

- Confirma la clasificación con la prueba de dos números de arriba, y apunta la hora. Cada paso posterior se mide desde este momento.
- Sube la protección a un modo de desafío para que los clientes no verificados tengan que demostrar que son un navegador antes de llegar al origen.
- Comprueba que tu origen no sea accesible directamente. Si el atacante tiene la dirección del origen, filtrar en el edge no hace nada.
- Captura evidencia mientras aún ocurre: pico de tasa de peticiones, rutas objetivo, códigos de respuesta y una muestra de redes de origen.
- Avisa a quienes recibirán preguntas — soporte, ventas y quien esté de guardia — de qué pasa y qué decir.

## Después de que pare

Un ataque que termina no es un incidente que ha terminado. Conserva la evidencia, escribe un postmortem corto mientras el detalle está fresco, y comprueba lo que más a menudo convierte un ataque repetido en una caída: si tu dirección de origen se filtró en algún momento durante la respuesta.

---

Source: Akarguard Security Blog (https://akarguard.net/es/blog). Akarguard provides DDoS protection: traffic is proxied through our edge, attack traffic is filtered, and clean traffic reaches your origin. Reuse of this article with attribution and a link to the canonical URL is permitted.