Qué es un ataque DDoS y cómo proteger un sitio web
Aprende qué es un ataque DDoS, por qué daña los sitios web y qué métodos de protección como CDN, WAF, limitación de tasa y monitoreo funcionan mejor.
¿Qué es un ataque DDoS y por qué es peligroso para un sitio web?
Un ataque DDoS es una inundación masiva de solicitudes que abruma un sitio web, servidor o conexión de red. Un visitante no causará ningún problema. 10,000 solicitudes por segundo es una historia muy diferente.
La idea es simple: el atacante no “hackea” el sitio de frente, sino que lo sobrecarga hasta que no puede hacer frente, y a veces el objetivo es la página de inicio, a veces la API, a veces el formulario de inicio de sesión. También sucede que se ataca a un servicio específico y todo el sitio se cae porque comparte una base de datos o un solo servidor sin separación de carga.
Las consecuencias aparecen rápidamente. Las páginas cargan lentamente, el carrito de compras deja de funcionar, el panel de usuario muestra errores, el bot de búsqueda recibe respuestas 5xx, y los usuarios se van a un competidor. El daño reputacional a menudo dura más que el ataque en sí, especialmente si el sitio estuvo fuera de servicio durante 20-30 minutos durante el horario laboral.
Un ataque DDoS es peligroso no solo por el tiempo de inactividad, sino que también incrementa los costos de infraestructura, desencadena alertas analíticas falsas y hace que el soporte pierda solicitudes reales de clientes. Si el sitio vende servicios, cada hora de inactividad perjudica los leads y las consultas, y si es un medio o SaaS, el consumo regular de contenido y la confianza en el producto se ven afectados.
Protección DDoS para un sitio web: qué métodos realmente funcionan
No hay un solo botón para la protección DDoS. Una configuración efectiva casi siempre combina varias capas: CDN, WAF, limitación de tasa, filtrado de tráfico, Anycast y restricciones del lado del hosting. Si estás interesado en la protección práctica del sitio web contra ataques DDoS, también vale la pena mirar el material sobre seguridad del sitio web, porque DDoS casi siempre va acompañado de otros ataques.
Un CDN ayuda a distribuir solicitudes entre nodos y a aliviar parte de la carga del origen. Esto es especialmente notable para páginas estáticas y medios: en lugar de un solo servidor, el tráfico se encuentra con una red de puntos de presencia, y Anycast funciona de manera similar, pero se enfoca en el enrutamiento: la solicitud va al nodo más cercano. Para un proyecto grande, esto no es un lujo, sino una forma de evitar caídas por un pico local.
Un WAF filtra patrones de solicitudes sospechosas. No protege contra todo, pero hace un buen trabajo al eliminar parte del tráfico basura y bots. La limitación de tasa restringe con qué frecuencia pueden llegar solicitudes desde una IP, subred o sesión. Cuando un ataque llega como miles de solicitudes idénticas a un formulario, los límites comienzan a ayudar rápidamente.
El filtrado de tráfico del lado del proveedor o del host es importante cuando la línea de conexión está saturada antes de que la solicitud llegue a tu servidor. Aquí es donde vale la pena preguntar de antemano qué mecanismos tiene la plataforma: un centro de limpieza, enrutamiento de agujero negro, redirección temporal y soporte sin un plan de incidente listo a menudo responde demasiado lento durante un ataque.
La protección a nivel de hosting y proveedor es necesaria no como una opción de respaldo, sino como la primera capa de respuesta, y un servidor puede ser reforzado, pero si el proveedor en sí no puede cortar el tráfico no deseado, el recurso seguirá cayendo. En un proyecto real, la configuración habitual es una combinación: CDN al frente, WAF en la entrada, límites de solicitudes y hosting que mantenga la infraestructura operativa.
Cómo proteger un sitio web de DDoS antes de que comience un ataque
La preparación comienza con la arquitectura. Si el sitio vive en un solo servidor, sin caché y sin separación de roles, es más fácil derribarlo. Es mejor separar la capa web, la base de datos y las tareas pesadas de fondo de inmediato, y restringir el área de administración por IP o VPN. Para proyectos con mayor riesgo, es útil observar enfoques del estudio de caso S4M — infraestructura de red privada: VPN y proxies.
El primer paso es eliminar puntos de entrada innecesarios, y un panel de administración abierto, SSH sin protección, subdominios de prueba adicionales y métodos de API antiguos solo amplían la superficie de ataque. Si el formulario de búsqueda y el formulario de inicio de sesión están disponibles sin restricciones, esas son las primeras cosas que atacarán los atacantes.
El segundo paso es planificar un escenario de respaldo. Necesitas un plan para cuando el servidor principal se vuelva inaccesible: un marcador estático, DNS de respaldo, el contacto del proveedor y la persona responsable de la transición. Tal plan no ocupa mucho espacio en la documentación, pero ahorra horas una vez que el tráfico comienza a llegar en oleadas.
El tercer paso es la monitorización. Necesitas métricas para RPS, CPU, RAM, tiempo de respuesta, el número de errores 5xx y anomalías por país o IP, y si el sitio de repente recibe 5,000 solicitudes a la página de inicio de sesión en 3 minutos, eso es inmediatamente visible. Sin monitorización, un ataque a menudo solo parece que “algo está lento.”
El cuarto paso es fortalecer el servidor. Un CPU y memoria adicionales no detendrán un DDoS, pero comprarán tiempo para activar la protección y evitar la pérdida de datos. Es una buena idea verificar los límites de PHP-FPM, los tamaños de las colas, la configuración del proxy inverso y los tiempos de espera de conexión con anticipación. Un tiempo de espera incorrecto puede convertir un pico corto en una larga interrupción.
El quinto paso es la caché. Las páginas que se pueden servir sin acceder a la base de datos deben ser almacenadas en caché, y esto reduce el número de operaciones costosas y ayuda a soportar cargas similares a ataques de bots. La caché no soluciona el problema, pero suaviza el impacto.
Señales de un ataque DDoS y cómo detectarlo a tiempo
La primera señal es un aumento repentino del tráfico sin una razón clara. Si, a las 2 a.m., el tráfico salta de 30 países a la vez y no hay una campaña publicitaria en el sitio, eso es una señal de advertencia. Es especialmente sospechoso si el aumento se concentra en una página o un método de API.
La segunda señal es la carga lenta. El sitio puede seguir abriéndose, pero con un retraso de 8 a 15 segundos, y a veces incluso más. Los usuarios no esperarán. Cerrarán la pestaña.
La tercera señal son los errores 5xx. Estos pueden ser 500, 502, 503 y 504. El servidor está sobrecargado, el proxy no responde, la aplicación no puede seguir el ritmo de las solicitudes, y si tales errores aumentan junto con el tráfico, en lugar de después de un lanzamiento, vale la pena investigar un ataque DDoS.
La cuarta señal son los problemas con la autenticación y el panel de administración. El sitio puede seguir siendo visible desde el exterior, pero iniciar sesión en la cuenta de usuario, área de administración o módulo de pago comienza a fallar. Para las empresas, esto es especialmente desagradable: el cliente ve “el sitio está funcionando”, pero no puede completar la acción.
La quinta señal son patrones inusuales en los registros, y agentes de usuario repetidos, URLs idénticas, muchas solicitudes sin un referente, rangos de IP extraños. Si un registro de 10 minutos parece un copiar y pegar, es hora de verificar la protección en lugar de esperar a que “pase por sí solo.”
Qué hacer durante un ataque DDoS en un sitio web
La primera acción es activar todos los mecanismos de protección preparados. Habilitar el perfil WAF, límites de solicitudes, modo de desafío si está disponible, y almacenamiento en caché al máximo nivel sin arriesgar la lógica del negocio. Si del sitio web contra ataques DDoSse configuró con anticipación, esto es cuestión de minutos. Si no, la situación es mucho peor.
La segunda acción es contactar al proveedor de hosting o al proveedor de infraestructura de inmediato. No solo envíes un mensaje de chat: proporciona detalles específicos: la hora de inicio del ataque, las URL afectadas, el patrón de tráfico, capturas de pantalla de gráficos y direcciones IP de los registros. Cuanto más precisa sea la descripción, más rápido podrá el soporte habilitar el filtro adecuado.
La tercera acción es restringir temporalmente los puntos de entrada vulnerables. Puedes bloquear el área de administración por IP, deshabilitar formularios pesados, cambiar parte del sitio a modo de solo lectura, reducir la funcionalidad de la API o eliminar temporalmente integraciones innecesarias. Sí, eso es inconveniente. Pero una funcionalidad reducida es mejor que un sitio completamente caído.
La cuarta acción es analizar las fuentes de tráfico, y necesitas registros, geografía, patrones de solicitud, encabezados idénticos y frecuencia de solicitudes, no suposiciones. Si el ataque proviene de un único punto de entrada, puedes aislarlo, y si el ataque es distribuido, el enfoque se desplaza hacia el proveedor y el filtrado a nivel de red.
La quinta acción es mantener una línea de tiempo corta. Quién habilitó la protección, cuándo se contactó al soporte, qué se cambió y qué efecto se vio después de 5, 15 y 30 minutos. Después del ataque, este registro te ayuda a entender qué funcionó y qué hizo que el sitio se rompiera aún más que el propio ataque.
Cómo elegir un servicio o alojamiento para la protección DDoS
La elección comienza con el filtrado de tráfico. Pregunta qué niveles de protección están disponibles: en la capa de enlace, la capa de red y la capa de aplicación, y si el proveedor solo puede 'bloquear por IP', eso no es suficiente para ataques complejos. Necesitas mecanismos que vean no solo la dirección, sino también el comportamiento de la solicitud.
Revisa el SLA. El contrato debería detallar los tiempos de respuesta, la disponibilidad del servicio y los procedimientos de escalación. Sin esas líneas, solo descubrirás sobre el “soporte 24/7” después del primer ataque, cuando la respuesta llegue 40 minutos después.
La geografía de los nodos también importa. Si tu base de usuarios está en 3 regiones, pero el filtrado está disponible solo en un centro de datos, la latencia y la pérdida de paquetes aumentarán. Para un sitio internacional, es mejor elegir una infraestructura distribuida en múltiples puntos de presencia.
La compatibilidad con el CMS y la pila del proyecto debe verificarse de antemano. WordPress, Laravel, Bitrix, Node.js, arquitectura sin cabeza: cada opción tiene sus propias limitaciones en torno a la caché, los proxies y los encabezados, y un buen servicio de protección aún puede no ser adecuado para un sitio específico si interrumpe la autenticación o el carrito de compras.
El soporte debería ser capaz no solo de responder, sino de actuar. Durante un ataque, es importante que un ingeniero pueda aplicar rápidamente una regla en lugar de pasar el ticket entre departamentos. Para un sitio web corporativo, también es útil leer sobre estructura del sitio web corporativo, porque la protección también depende de cómo están organizadas las páginas de inicio de sesión, los formularios de consulta y las cuentas de usuario.
Errores que debilitan la protección DDoS del sitio web
El primer error es no monitorear. Si no se configuran gráficos, el ataque se nota demasiado tarde. El sitio ya está cayendo, y el equipo apenas comienza a buscar la causa en el código, la caché o la actualización del plugin.
El segundo error son las contraseñas débiles y los paneles de administración abiertos, y el dDoS a menudo va acompañado de intentos de adivinar el acceso o distraer al equipo. Un panel de control sin restricciones de IP es una mala idea incluso para un proyecto pequeño.
El tercer error son las configuraciones incorrectas de la caché, y a veces después de habilitar la caché, el sitio se vuelve rápido, pero el carrito, la autenticación o la cuenta de usuario se rompen. Eso crea una falsa sensación de seguridad, y bajo ataque el problema regresa, en un momento más inconveniente.
El cuarto error es confiar en solo una herramienta. Un CDN sin un WAF, un WAF sin límites, un host sin soporte — todos estos son más débiles que una combinación de varias capas. Un ataque DDoS rara vez se ve igual dos veces.
El quinto error es ignorar las pruebas de carga. Si el sitio nunca ha sido revisado bajo un pico, nadie sabe dónde fallará primero, y una prueba con 1,000 solicitudes no es lo mismo que un ataque, pero proporciona un punto de referencia útil y revela puntos débiles.
El sexto error es mantener todos los servicios críticos en un solo lugar. Cuando el sitio, la base de datos, el correo y la analítica están en un solo nodo, un problema arrastra a los demás también. Aquí vale la pena mirar con anticipación el material sobre soporte del sitio web después del lanzamiento, porque la protección y el soporte post-lanzamiento están estrechamente conectados.
En resumen: un plan básico para la protección del sitio web contra ataques DDoS
Comienza con 3 pasos: habilita la monitorización, cierra los puntos de entrada innecesarios y acuerda con tu proveedor de hosting el proceso de respuesta en caso de un ataque, y si el sitio ya está bajo carga, añade un CDN, WAF y límites de solicitudes. Si el proyecto es crítico para las ventas, mantén un escenario de respaldo y los datos de contacto de tu proveedor a mano.
Luego revisa los registros, los tiempos de espera, la caché y las áreas de administración, y la protección configurada una vez no te salva para siempre, pero sí te da tiempo cuando un ataque ya ha comenzado. Y ese tiempo a menudo importa más que toda la infraestructura que lo rodea.
Si el proyecto está creciendo, la protección del sitio web debe revisarse después de cada lanzamiento importante y después de cada cambio en el tráfico, y un nuevo módulo, un formulario, un método API puede abrir una carga extra, y un ataque DDoS encontrará rápidamente ese punto débil.
