¿Qué pasa si tu sitio recibe un ataque DDoS y cómo protegerlo?

Un ataque de denegación de servicio distribuido (DDoS) no explota una vulnerabilidad de código: satura tu sitio con tráfico hasta que deja de responder. Para una pyme o una consultoría con presencia web, la pregunta no es «¿puede pasarme?» sino «¿qué tan preparado estoy si pasa?».

Qué es en realidad un DDoS

DDoS (Distributed Denial of Service) es el envío coordinado de tráfico desde miles de equipos —normalmente comprometidos sin que sus dueños lo sepan— hacia un mismo destino, con el único objetivo de agotar sus recursos: ancho de banda, procesos del servidor, o ambos. No roba datos ni compromete el sistema directamente; su daño es la indisponibilidad, que en la práctica significa clientes que no pueden contactarte, formularios que no funcionan y, en algunos sectores, reportes que exigir explicar la caída.

Dos tipos de ataque muy distintos

No todos los DDoS se ven ni se combaten igual. Conviene separar dos capas:

• Volumétricos (capa 3/4 — red y transporte): el atacante intenta saturar tu ancho de banda con paquetes masivos. Es el clásico ataque «de fuerza bruta» de tráfico. Se combate con infraestructura de red a gran escala: es prácticamente imposible mitigarlo desde tu propio servidor.
• De aplicación (capa 7 — HTTP): el atacante envía peticiones que parecen tráfico normal —cargar la página de inicio, enviar el formulario de contacto, buscar en el sitio— pero a un volumen que agota la CPU o los procesos disponibles del servidor. Es más difícil de distinguir del tráfico real, y es el que más golpea a sitios en hosting compartido.

Un ataque volumétrico se combate con infraestructura de red. Uno de capa de aplicación se combate entendiendo el comportamiento normal de tus usuarios y filtrando lo que se sale de ese patrón.

Qué protección te da el hosting por defecto

La mayoría de proveedores de hosting compartido —como el que usa SystemVal— ya colocan tu sitio detrás de una capa de red propia (CDN/edge del proveedor) antes de llegar al servidor. Eso absorbe parte del tráfico volumétrico de forma automática, sin que el cliente tenga que configurar nada.

Lo que esa capa no resuelve bien es un ataque de capa 7 sostenido: si miles de peticiones HTTP «legítimas» llegan por segundo contra tu sitio, el hosting compartido tiene límites de CPU y procesos por cuenta, y el proveedor prioriza proteger su infraestructura general, no mantener arriba un sitio individual bajo ataque. En ese escenario, tu sitio puede caerse o volverse muy lento aunque el resto de la plataforma siga funcionando con normalidad.

El vector que casi nadie protege: los formularios

Cuando se piensa en DDoS, se imagina tráfico genérico contra la página de inicio. Pero un vector igual de común —y más barato de ejecutar para un atacante— es un formulario de contacto sin límites: basta un script simple enviando cientos de solicitudes por minuto para saturar el buzón de correo, disparar costos de envío o, en el peor caso, tumbar el proceso PHP que lo atiende.

La defensa aquí no requiere infraestructura cara. Es rate limiting: limitar cuántos envíos acepta el sistema desde el mismo origen en una ventana de tiempo, y un tope diario global que protege el buzón sin importar de cuántas IPs venga el abuso. El propio formulario de contacto de systemval.com funciona así:

• Máximo 3 envíos por dirección IP cada 10 minutos.
• Máximo 50 envíos totales por día, sin importar el origen.
• Un campo oculto invisible para personas (honeypot) que descarta automáticamente los envíos de bots simples.
• Registro de los intentos bloqueados —sin guardar la IP en texto plano— para poder revisar patrones de abuso después.

La capa que sí marca la diferencia: una CDN

Para cubrir lo que el rate limiting y el hosting no alcanzan —sobre todo ataques volumétricos grandes y de capa de aplicación más sofisticados— la práctica estándar es poner una CDN con protección DDoS delante del dominio, como Cloudflare (tiene un plan gratuito suficiente para un sitio de este tamaño). Sus beneficios concretos:

• Absorción de tráfico a escala global antes de que llegue al servidor de origen, que además queda oculto detrás de la CDN.
• WAF (Web Application Firewall) básico que filtra patrones de ataque conocidos.
• Modo «bajo ataque», activable manualmente, que agrega una verificación adicional antes de servir la página cuando se detecta un pico anómalo.
• Cacheo de contenido estático, que reduce la carga del servidor de origen incluso en tráfico normal.

Checklist de protección realista

Ni el pánico ni la sobreingeniería. Para un sitio corporativo del tamaño de una pyme, esto es proporcional:

• Rate limiting en cualquier formulario o endpoint que procese datos (no solo el de contacto).
• Cabeceras de seguridad activas (CSP, HSTS, X-Frame-Options) — no detienen un DDoS, pero cierran otras puertas de abuso.
• Una CDN con protección DDoS delante del dominio, incluso en su plan gratuito.
• Un registro de intentos bloqueados que alguien revise periódicamente, no solo un sistema que bloquea en silencio.
• Un plan claro de a quién contactar (hosting, registrador del dominio) si el ataque supera estas capas.