Un ataque DDoS intenta que un servicio deje de responder al coordinar tráfico desde muchas fuentes. El efecto no depende únicamente de que el servidor tenga mucha o poca CPU: también puede agotarse el enlace de red, la tabla de conexiones, la capacidad de un proxy o una ruta concreta de la aplicación.
La respuesta útil comienza por identificar qué recurso se agota y en qué punto del recorrido ocurre. Una web puede conservar memoria disponible y, aun así, resultar inaccesible porque la conexión con el proveedor está saturada.
Volumen, protocolo y aplicación
Los ataques volumétricos buscan consumir capacidad de tránsito con grandes cantidades de tráfico. Otros explotan costes de protocolos o conexiones, y los de capa de aplicación envían peticiones que parecen normales pero fuerzan operaciones caras. No todos se observan igual en los gráficos del servidor.
Una petición a una página estática puede atenderse desde caché, mientras que una consulta que accede a base de datos consume más recursos. Por eso contar solicitudes sin distinguir rutas, tamaños y códigos de respuesta puede ocultar el cuello de botella real.
Qué ocurre antes de llegar al servidor
Si el tráfico ya ha llenado el enlace ascendente, un firewall local solo recibirá una parte de los paquetes o tendrá que procesarlos cuando el recurso crítico ya está comprometido. La capacidad de mitigación debe existir suficientemente arriba en la red, en un proveedor o servicio que pueda absorber y filtrar el volumen.
Un proxy inverso o una CDN pueden terminar conexiones, servir contenido almacenado y distribuir solicitudes, aunque su utilidad depende de qué tráfico pueda cachearse y de cómo se protejan las rutas dinámicas. No sustituyen el diseño de la aplicación ni garantizan que todo ataque desaparezca.
Medidas según el recurso agotado
Para el ancho de banda se necesita capacidad de tránsito y filtrado aguas arriba. Para conexiones y sesiones pueden ayudar límites, tiempos de espera y una configuración que no mantenga recursos indefinidamente. Para una ruta costosa conviene reducir trabajo por petición, cachear lo que sea seguro y exigir autenticación cuando corresponda.
El rate limiting debe considerar identidad, ruta y contexto. Un límite por dirección IP puede afectar a usuarios detrás de una misma red y no detiene un tráfico distribuido por sí solo. Las reglas deben probarse con tráfico legítimo antes de activarlas de forma estricta.
Monitorización que permita decidir
Registra volumen por origen y ruta, ancho de banda, conexiones activas, latencia, errores, uso de CPU y memoria, tiempo de base de datos y estado del proveedor. Compara esos datos con una línea base normal. Una subida de tráfico no demuestra por sí sola un ataque; puede coincidir con una campaña o un cambio de contenido.
Define quién puede activar una regla, qué evidencia necesita y cómo se retira cuando el incidente termina. Conserva los registros sin almacenar más datos personales de los necesarios y sincroniza los relojes para reconstruir la secuencia.
Plan de continuidad y límites
Una estrategia debe contemplar comunicación, rutas alternativas, priorización de servicios y recuperación después del pico. Si el sitio principal depende de una API externa o una base de datos compartida, esa dependencia puede seguir siendo el punto débil aunque el tráfico web esté filtrado.
Un DDoS no se resuelve prometiendo disponibilidad absoluta. La mitigación tiene capacidad finita, puede introducir latencia o bloquear falsos positivos y debe adaptarse al tipo de tráfico. El firewall del servidor sigue siendo útil para reducir exposición de puertos, pero no reemplaza la coordinación con la red cuando el enlace ya está saturado.
Qué medir antes de elegir una estrategia de mitigación
Documenta capacidad normal, rutas críticas, dependencias, límites del proveedor y tiempo aceptable de recuperación. Prueba una respuesta controlada y revisa qué métricas permiten distinguir saturación de red, agotamiento de conexiones y sobrecarga de aplicación. Esa información permite escoger controles proporcionados sin convertir una regla local en una supuesta protección total.
Distinguir incidente y pico legítimo
Una campaña comercial, una publicación popular o una tarea de indexación también pueden elevar el tráfico. Compara rutas, agentes, códigos de respuesta, distribución geográfica y patrón temporal antes de activar bloqueos amplios. Un ataque puede coincidir con tráfico legítimo, por lo que una regla basada únicamente en volumen puede afectar a clientes reales.
Los registros de aplicación deben combinarse con métricas del enlace y del proveedor. Si la aplicación deja de recibir tráfico porque el upstream filtra antes, el servidor puede parecer normal mientras el servicio sigue inaccesible desde fuera.
Dependencias que suelen quedar ocultas
La página principal puede estar protegida por caché y, sin embargo, el inicio de sesión, el carrito o una API seguir accediendo a la base de datos en cada petición. Identifica esas rutas y decide cuáles pueden degradarse temporalmente. Mantener información estática disponible puede ser preferible a intentar servir todas las funciones durante una saturación.
La capacidad de un proveedor externo también forma parte del límite. Documenta contactos, procedimientos de escalado y señales para pedir ayuda, pero no confundas la existencia de un proxy con una garantía de absorción ilimitada.
Preparar la respuesta por fases
Define una fase de detección, otra de contención y otra de recuperación. Durante la detección, conserva una línea base y confirma si el incremento afecta a todas las rutas o solo a una. Durante la contención, prioriza servicios esenciales y evita bloquear indiscriminadamente redes compartidas. Después, revisa qué regla funcionó y qué coste tuvo.
El objetivo no es mantener todas las funciones a cualquier precio. Un modo degradado que sirve contenido informativo puede proteger una operación crítica mejor que dejar abiertas consultas costosas sin límites.