Prevención de ataques DDoS en su sitio web

Qué es un ataque DDoS

Un ataque de denegación de servicio distribuida (DDoS) intenta dejar una web o un servicio inaccesible saturándolo con tráfico o peticiones procedentes de muchas fuentes a la vez. A diferencia de una intrusión, el objetivo no suele ser robar datos, sino impedir que los usuarios legítimos lleguen a ti. Las fuentes suelen ser dispositivos comprometidos o infraestructura alquilada, por lo que bloquear una sola dirección IP rara vez sirve de algo.

Esta guía trata sobre la defensa: entender las principales categorías de ataque para elegir protecciones sensatas, configurar tu infraestructura y responder con calma si ocurre. Ninguna web puede hacerse totalmente inmune, pero una buena preparación reduce muchísimo la probabilidad de que un ataque se convierta en una caída prolongada.

Las principales categorías de ataques DDoS

Los ataques suelen agruparse según el recurso que intentan agotar. Conocer la categoría te indica dónde debe situarse la defensa.

La clave: los ataques volumétricos suelen superar con creces lo que un solo servidor o una conexión de hosting pequeña pueden absorber, así que filtrar en el propio servidor llega demasiado tarde. Los ataques de capa de aplicación, en cambio, pueden usar poco ancho de banda pero consumir mucha CPU, y ahí ajustar tu propia aplicación importa mucho.

Coloca una capa de protección delante de tu web

Para la mayoría de las webs, el paso más eficaz es enrutar el tráfico a través de un proveedor con una capacidad grande y distribuida: una CDN con protección DDoS, un servicio de mitigación dedicado o un balanceador de carga en la nube con filtrado integrado. Estas redes absorben las inundaciones volumétricas en muchas ubicaciones y filtran el tráfico malicioso antes de que te llegue.

Al comparar opciones, haz preguntas prácticas en lugar de fiarte de los mensajes comerciales:

• ¿Qué capas cubre (red, protocolo, aplicación) y alguna de ellas es un complemento de pago?
• ¿La mitigación está siempre activa o solo se activa tras detectar un ataque?
• ¿Hay límites de ancho de banda o de peticiones, y se factura el tráfico del ataque?
• ¿Cómo funciona el soporte durante una incidencia activa?
• ¿Puedes definir reglas personalizadas, límites de peticiones y desafíos para rutas concretas?

Los precios y límites cambian con frecuencia y varían entre planes, así que consulta la documentación actual de tu proveedor en lugar de dar por hecha la cobertura.

Oculta y blinda tu servidor de origen

Una capa de protección solo ayuda si los atacantes no pueden rodearla. Si se conoce la dirección IP de tu servidor de origen, un atacante puede enviar el tráfico directamente a ella y saltarse la CDN por completo.

1. Evita filtrar la IP de origen. Los registros DNS antiguos, los subdominios sin proteger como los de correo o FTP, las cabeceras de los correos y los datos DNS históricos pueden revelarla. Plantéate cambiar a una IP nueva después de activar la protección.
2. Permite tráfico web solo desde el proveedor. Configura el cortafuegos para que acepte los puertos 80 y 443 únicamente desde los rangos de IP publicados por tu CDN, o usa un túnel autenticado o un certificado de origen si tu proveedor lo admite.
3. Restringe el acceso administrativo. SSH, los paneles de control y los puertos de bases de datos no deben estar abiertos a todo internet; limítalos a VPN o a direcciones conocidas.

La consulta de hosting de TLDix es una forma rápida de ver qué puede saber cualquiera sobre adónde resuelve un nombre de host, algo útil al auditar subdominios en busca de filtraciones.

Refuerza la capa de aplicación

Las inundaciones de capa de aplicación imitan a visitantes reales, así que la defensa se centra en que cada petición sea barata y en limitar los patrones abusivos.

Usa la caché de forma intensiva

Las páginas servidas desde la caché de una CDN nunca llegan a tu origen. Guarda en caché los recursos estáticos durante periodos largos y plantéate una caché corta incluso para páginas dinámicas que no sean personales. Cada respuesta en caché es una que tu servidor no tiene que calcular.

Limita las peticiones con criterio

Limita las peticiones por cliente en los puntos costosos, como el inicio de sesión, la búsqueda, el pago y las API. Un ejemplo para Nginx:

http {
    limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
    limit_conn_zone $binary_remote_addr zone=connperip:10m;

    server {
        location /search {
            limit_req zone=perip burst=20 nodelay;
            limit_conn connperip 20;
        }

        client_body_timeout 10s;
        client_header_timeout 10s;
    }
}

Estas cifras son solo ejemplos. Basa los límites reales en tus propios registros de tráfico y recuerda que muchos usuarios pueden compartir una IP detrás de redes corporativas o móviles. Cuando el tráfico llega a través de una CDN, configura correctamente la cabecera con la IP real del cliente para no limitar a la propia CDN.

Reduce el trabajo costoso

• Optimiza las consultas lentas a la base de datos y añade índices para las búsquedas habituales.
• Traslada las tareas pesadas, como la generación de informes o el procesamiento de imágenes, a colas en segundo plano.
• Usa desafíos o CAPTCHA de forma selectiva en los formularios sensibles, no en todas partes.
• Define tiempos de espera para que las conexiones lentas no puedan mantener recursos ocupados indefinidamente.

Planifica la capacidad y la degradación controlada

La resiliencia no consiste solo en filtrar. Piensa en qué debe hacer tu web cuando está bajo presión. ¿Pueden servirse la página de inicio y las principales páginas de destino como archivos estáticos desde la CDN si la aplicación cae? ¿Pueden desactivarse con un indicador de funciones las funciones no esenciales, como recomendaciones, búsqueda en directo o widgets pesados, para ahorrar recursos? El autoescalado en entornos cloud puede absorber picos moderados en la capa de aplicación, pero define límites de gasto y alertas, porque escalar para atender tráfico de ataque puede encarecerse rápidamente.

Separar componentes también ayuda. Alojar la API, el área de administración y la web pública en nombres de host o servicios distintos significa que una inundación contra uno no derriba automáticamente a los demás, y te permite aplicar reglas más estrictas donde más importan.

No olvides el DNS ni el propio dominio

Si tu DNS autoritativo cae, tu web es inaccesible aunque los servidores web funcionen bien. Usa un proveedor de DNS con infraestructura anycast y redundancia; consulta cómo funciona el DNS anycast para más contexto. Algunas organizaciones usan dos proveedores de DNS independientes para ganar resiliencia, lo que exige mantener las zonas sincronizadas.

Protege también el propio registro. Durante una incidencia puede que necesites cambiar rápidamente los servidores de nombres, así que asegúrate de que el acceso al registrador es seguro y de que el dominio no está a punto de caducar. Controla las fechas de renovación en la monitorización de dominios de TLDix para que un registro vencido nunca agrave un ataque.

Monitorización y alerta temprana

Cuanto antes detectes un ataque, antes podrás responder. Algunas señales útiles:

• Comprobaciones de disponibilidad desde varias ubicaciones externas.
• Picos repentinos de peticiones por segundo, ancho de banda o tasas de error (sobre todo respuestas 5xx).
• Concentración inusual del tráfico en una URL, un agente de usuario o una región.
• Aumento de CPU, memoria, número de conexiones o carga de la base de datos sin un motivo de negocio que lo explique.

Mantén la monitorización independiente de la infraestructura que vigila; un servicio de alertas alojado en el mismo servidor se quedará callado justo cuando lo necesites.

Establece una referencia del tráfico normal para que las anomalías salten a la vista. Las alertas deben llegar a una persona capaz de actuar, no a un buzón que nadie revisa.

Lista de respuesta ante incidentes

Escribe tu plan antes de necesitarlo. Una versión sencilla:

1. Confirma que se trata de un ataque y no de un aumento legítimo del tráfico, un despliegue fallido o una caída de un proveedor.
2. Contacta con tu proveedor de hosting y de protección siguiendo la vía de escalado que preparaste con antelación.
3. Activa modos más estrictos: niveles de seguridad más altos, desafíos en las rutas atacadas y reglas temporales geográficas o de límite de peticiones cuando esté justificado.
4. Sirve una versión en caché o estática de las páginas clave si la aplicación tiene dificultades.
5. Comunícate con los usuarios mediante una página de estado o un canal social alojado fuera de la web principal.
6. Después, revisa los registros, ajusta las reglas y actualiza el plan.

Prepara a las personas, no solo a los sistemas

Durante una incidencia se pierde tiempo buscando credenciales y números de teléfono. Mantén actualizada una hoja de contactos con los canales de soporte de los proveedores, los identificadores de cuenta y quién está autorizado a cambiar el DNS o la configuración de protección. Guárdala en un lugar accesible aunque tu web principal y tu correo estén afectados. Hacer un breve simulacro una o dos veces al año, repasando la lista anterior, revela problemas como credenciales caducadas o responsabilidades poco claras mucho antes de que lo haga un ataque real.

Si un ataque va acompañado de una exigencia de extorsión, implica a tu proveedor y denúncialo ante las autoridades competentes. Esto no constituye asesoramiento legal; consulta los requisitos locales.

Revisa la configuración con regularidad

Las defensas se degradan con el tiempo: se añaden subdominios nuevos sin pasar por la CDN, cambian los rangos de IP del proveedor o se relajan reglas durante una campaña y nadie las vuelve a ajustar. Programa una revisión trimestral de los registros DNS, las reglas del cortafuegos de origen y los límites de peticiones para confirmar que siguen reflejando tu infraestructura actual.