Seguridad
¿Tu web sufre un ataque DDoS? Qué hacer ahora
Cómo reconocer un ataque, qué hacer en la primera hora y cómo proteger tu web para que el próximo haga menos daño.
Si tu web va de repente lentísima o se ha caído y tu servidor recibe muchas más peticiones de lo normal, es posible que estés sufriendo un ataque DDoS. Lo más eficaz que puedes hacer ahora mismo es poner un filtro por delante de tu servidor, porque un servidor que ya está desbordado no puede defenderse solo. Esta guía te explica cómo reconocer un ataque, qué hacer en la primera hora y qué configuración hace que el próximo ataque duela mucho menos.
Cómo saber si es un ataque DDoS
Un ataque distribuido de denegación de servicio (DDoS) inunda tu web con tráfico desde muchas fuentes a la vez, de modo que los visitantes reales no consiguen entrar. Pero no todo pico de tráfico es un ataque. Una newsletter, una mención en la tele o unas rebajas pueden parecer lo mismo a primera vista. Fíjate en estos patrones:
- El pico no tiene ninguna explicación de negocio. No hay campaña, prensa ni lanzamiento, y aun así las peticiones se disparan.
- Las peticiones van a las mismas pocas URLs. A menudo la portada, una página de búsqueda, una página de login o una URL con parámetros aleatorios (
/?x=83729) pensados para esquivar la caché. - Orígenes de tráfico extraños. Muchas peticiones desde países donde no tienes clientes, desde rangos de IP de proveedores de hosting o con user agents idénticos o vacíos.
- Ninguna conversión. El tráfico sube, pero las ventas, los registros y el tiempo en la página no se mueven.
- Tu servidor está al límite. La CPU, los workers de PHP o las conexiones a la base de datos están al máximo, y el log de errores se llena de timeouts y errores 502/503/504.
Revisa tu log de accesos
Si tienes acceso por shell, un vistazo rápido al log de accesos te dice mucho. Estos comandos muestran las IPs con más peticiones y las rutas más solicitadas (ajusta la ruta del log a tu servidor):
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
Si un puñado de IPs envía miles de peticiones, se trata de un ataque pequeño que puedes bloquear directamente. Si son miles de IPs y cada una envía una cantidad moderada, lo más probable es una botnet, y eso es mucho más difícil de frenar desde el propio servidor.
Tipos de ataque a los que te puedes enfrentar
Conocer más o menos el tipo te ayuda a elegir la respuesta adecuada.
| Tipo | A qué apunta | Señal típica |
|---|---|---|
| Volumétrico (capa 3/4) | Tu conexión de red | El hosting informa de ancho de banda saturado; el servidor puede quedar totalmente inaccesible |
| De protocolo (capa 4) | La gestión de conexiones, firewalls, balanceadores de carga | Muchas conexiones medio abiertas, el equipo de red no da abasto |
| De capa de aplicación (capa 7) | Tu propia aplicación web | Peticiones HTTP de aspecto normal, pero la CPU y la base de datos están sobrecargadas |
La mayoría de ataques contra webs de pequeñas y medianas empresas son HTTP floods de capa 7. No necesitan un ancho de banda enorme, porque cada petición obliga a tu servidor a hacer un trabajo costoso: generar una página, ejecutar una búsqueda, consultar la base de datos. Unos cientos de peticiones por segundo sin caché pueden bastar para tumbar una tienda o un CMS típicos.
Qué hacer en la primera hora
Mantén la calma y sigue estos pasos en orden. Apunta qué haces y cuándo, porque lo necesitarás más adelante.
1. Confírmalo y avisa
Asegúrate de que no se trata de un despliegue roto, un plugin que falla o un pico legítimo. Después avisa a quien tenga que saberlo: tu equipo, tu agencia y tu proveedor de hosting. Los proveedores suelen ver el ataque en su monitorización de red y puede que ya estén filtrando o, en algunos casos, enviando tu IP a una null route para proteger al resto de clientes.
2. Contacta con tu hosting
Pregunta directamente a tu proveedor: qué ven, qué protección tienen y si pueden filtrar a nivel de red. Algunos incluyen una protección DDoS básica y otros no. Si tu servidor está en una null route, necesitas una capa de filtrado delante antes de que vuelva a estar en línea.
3. Bloquea lo que puedas identificar
Si el ataque viene de un número pequeño de IPs o rangos, bloquéalos en tu firewall o en la configuración del servidor web. Si apunta a una URL costosa, como un endpoint de búsqueda, limita su frecuencia o desactívala temporalmente. Si llega sobre todo desde países en los que no vendes, un bloqueo geográfico temporal o un desafío pueden darte margen. Son parches, no una estrategia.
4. Pon una capa de filtrado delante de tu servidor
La solución de verdad es frenar el tráfico malicioso antes de que llegue a tu origen. Un proxy inverso o un CDN con protección DDoS absorbe y filtra las peticiones en el edge, y tu servidor solo ve lo que pasa el filtro. Darse de alta suele implicar cambiar los servidores de nombres de tu dominio, algo que surte efecto a medida que caducan las cachés DNS. Si lo haces en pleno ataque, sigue una checklist para no perder el correo ni otros registros. Nuestra guía para cambiar los servidores de nombres sin caídas trata justo eso.
5. Reduce el trabajo que provoca cada petición
Mientras dure el ataque, haz que cada petición salga más barata. Sirve páginas en caché siempre que puedas, desactiva funciones pesadas de las que puedas prescindir un día (búsqueda en vivo, widgets de productos relacionados, llamadas a APIs externas) y asegúrate de que los parámetros aleatorios en la URL no se saltan tu caché.
Errores que debes evitar durante un ataque
- No te limites a ampliar el servidor. Más CPU ayuda un rato, pero los atacantes suelen poder escalar más rápido que tu presupuesto de hosting. Además, no frena las inundaciones de ancho de banda.
- No pagues un rescate. Algunos ataques llegan acompañados de una exigencia de pago. Pagar no garantiza nada y te señala como un objetivo dispuesto a pagar. Denuncia la extorsión a la policía.
- No bloquees de forma demasiado amplia. Bloquear países enteros o todos los bots puede dejar fuera a clientes y a los rastreadores de los buscadores. Si tienes dudas, usa desafíos en lugar de bloqueos duros y retira las reglas temporales cuando termine el ataque.
- No te olvides de otras vías de ataque. A veces un DDoS es una maniobra de distracción. Revisa después los inicios de sesión, las cuentas de administración y los cambios recientes. El resumen de CISA sobre los ataques de denegación de servicio (en inglés) también lo menciona.
Después del ataque: refuerza tu configuración
Cuando todo esté tranquilo, aprovecha lo aprendido. El objetivo es que el próximo ataque choque contra un filtro y no contra tu servidor.
Deja un proxy delante de forma permanente
El filtrado en el edge funciona mejor cuando ya está en marcha. Añadirlo en pleno ataque te cuesta tiempo mientras se propagan los cambios de DNS. Si no tienes claro qué aporta un CDN aparte de velocidad, lee qué es un CDN y si tu web lo necesita.
Cachea todo lo que puedas de forma segura
Cada página servida desde una caché es una petición que tu servidor no llega a ver. Las páginas públicas como la portada, las categorías, las fichas de producto y los artículos del blog deberían estar en caché. Las páginas personales como el carrito, el checkout y la cuenta tienen que seguir siendo dinámicas. Una tasa alta de aciertos de caché también deja a tu servidor más margen para los visitantes reales, y un origen rápido ayuda igualmente: consulta cómo reducir el TTFB.
Blinda el origen
Permite el tráfico HTTP y HTTPS hacia tu servidor solo desde los rangos de IP de tu proxy. Mantén la IP del origen fuera de los registros DNS públicos, de las cabeceras de los correos y de subdominios antiguos, porque son las vías habituales por las que los atacantes la encuentran.
Configura límites de frecuencia y alertas
Los límites de frecuencia en el login, la búsqueda y las APIs frenan tanto las inundaciones como los ataques de fuerza bruta. Las alertas sobre picos de tráfico y tasas de error hacen que te enteres del próximo ataque por una notificación y no por un cliente.
Escribe un pequeño plan de actuación
Basta con una página: a quién llamar en tu hosting, quién tiene acceso al DNS y al panel del proxy, qué reglas activar y cómo informar a los clientes. En pleno ataque nadie quiere ponerse a buscar contraseñas.
Cómo te ayuda fast.site
fast.site se coloca delante de tu hosting actual. Mantienes tu proveedor y apuntas los servidores de nombres de tu dominio a fast.site. A partir de ese momento, el tráfico llega primero a la red edge y se filtra allí antes de que nada pase a tu origen.
La detección de DDoS de capa 7 funciona automáticamente en todos los dominios, sin necesidad de configuración. Además, puedes bloquear IPs y rangos CIDR, bloquear países enteros o someterlos a un desafío CAPTCHA, crear tus propias reglas de desafío y fijar límites de frecuencia por IP. Los conjuntos de reglas gestionados protegen contra la inyección SQL, el XSS y los bots maliciosos. Tienes los detalles en la documentación de seguridad.
La caché reduce aún más la carga. Las páginas públicas servidas desde el edge muestran fs-cache: HIT y nunca tocan tu servidor, mientras que los carritos, el checkout y las sesiones iniciadas muestran BYPASS y van a tu origen como siempre. La analítica muestra las peticiones, las tasas de error y el ancho de banda del origen, y las alertas de anomalías te avisan de los picos de tráfico.
Si estás sufriendo un ataque ahora mismo, ve a la página de ataque en curso, que es el camino más rápido. Si no, puedes configurar la protección con calma y comprobar el resultado en tu propia web. Puedes empezar con una prueba gratuita de 7 días, sin tarjeta de crédito. Los planes y el tráfico incluido están en la página de precios.
Preguntas frecuentes
¿Cuánto dura un ataque DDoS?
Varía mucho. Algunos ataques duran minutos y otros llegan en oleadas a lo largo de varios días. Las ráfagas cortas son habituales, a menudo como prueba antes de un ataque mayor o junto a una exigencia de rescate. Por eso resulta más útil una protección siempre activa que algo que enciendes en pleno ataque.
¿Un ataque DDoS puede perjudicar mi SEO?
Una caída corta no suele tener efectos duraderos. Si tu web sigue inaccesible o devolviendo errores durante más tiempo, los buscadores pueden rastrearla menos y retirar páginas temporalmente. Volver a poner la web en marcha rápido y devolver códigos de estado correctos limita el daño.
¿Un ataque DDoS es ilegal?
Sí, en la mayoría de países lanzar un ataque DDoS es un delito. Guarda los logs, las marcas de tiempo y cualquier mensaje de rescate, y denuncia el ataque a la policía o a la unidad de delitos informáticos de tu país. Es especialmente importante cuando te piden dinero.
¿Un plugin de seguridad de WordPress puede frenar un ataque DDoS?
En realidad no. Un plugin se ejecuta dentro de WordPress, así que cada petición sigue llegando a tu servidor, arranca PHP y a menudo consulta la base de datos antes de que el plugin pueda bloquearla. Esa es precisamente la carga de la que vive un DDoS. Los plugins son útiles contra ataques al login y contra el malware, pero el filtrado DDoS tiene que hacerse por delante del servidor.
¿Por qué mi web va lenta si el tráfico parece normal?
Entonces probablemente no sea un DDoS. Las causas habituales son un hosting lento, plugins pesados, páginas sin caché o imágenes grandes. El artículo de soporte sobre una web lenta es un buen punto de partida.
Prueba fast.site con tu propia web
fast.site añade caché en el edge, optimización de imágenes y protección DDoS a tu hosting actual. Conecta tu dominio y mide la diferencia en tus propias páginas.
Dale 7 días a tu web. Que decidan los resultados.
Empieza con tu dominio, tu tráfico y una idea clara de lo que ocurre después.