Protección DDoS para webs: lo que funciona de verdad

Una buena protección DDoS para una web no es un único producto, sino varias capas que frenan cada una un tipo de ataque distinto: filtrado de red para las inundaciones de tráfico en bruto, un proxy inverso delante de la web, reglas contra los ataques a la capa de aplicación y un servidor de origen que solo habla con ese proxy. Lo que más importa es el momento, porque la protección que ya está activa funciona desde la primera petición, mientras que la que se añade en mitad de un ataque te cuesta horas. Si tu web está sufriendo un ataque ahora mismo, ve a la página para webs bajo ataque o a nuestra guía sobre qué hacer si tu web sufre un ataque DDoS.

Por qué la protección va delante del servidor

Un servidor ocupado respondiendo peticiones basura no puede decidir a la vez cuáles son basura. Cuando una regla de firewall o un plugin de seguridad de tu servidor revisa una petición, el ancho de banda ya se ha consumido y PHP muchas veces ya se ha puesto en marcha. Una protección eficaz filtra lo más lejos posible del origen.

Para la prevención, la pregunta útil es qué capa frena qué tipo de ataque:

Ninguna capa lo cubre todo: un proxy sin blindaje del origen se puede esquivar, y un origen blindado sin proxy se enfrenta solo a cada inundación HTTP.

Las cuatro capas en detalle

1. Nivel de red: inundaciones volumétricas y de protocolo

Los ataques volumétricos llenan la conexión de tu servidor con más tráfico del que puede transportar. Nada de lo que configures en el servidor sirve, porque el enlace está saturado antes de que tu firewall vea un solo paquete. Esta capa se gestiona aguas arriba, en la red de tu hosting o en un servicio de scrubbing especializado. Tu tarea es saber qué hace tu hosting aquí y ocultar la IP de tu origen detrás de un proxy, para que los atacantes tengan que inundar la red del proxy en lugar de la conexión de tu servidor.

2. Un proxy inverso delante de toda la web

Un proxy inverso de sitio completo recibe todas las peticiones de tu dominio, responde lo que puede desde su caché y reenvía el resto a tu origen. Importan dos efectos:

• Las páginas en caché salen baratas. Una inundación contra tu portada es inofensiva si la portada se sirve desde el edge y nunca llega a tu servidor.
• El filtrado ocurre antes del origen. Las reglas, los límites de peticiones y los desafíos se ejecutan en el edge, así que las peticiones bloqueadas no le cuestan nada a tu servidor.

Asegúrate de que el proxy cubre tu HTML. Un CDN de recursos que solo sirve imágenes y scripts desde otro host acelera la web, pero las peticiones de páginas siguen llegando directamente a tu servidor, y los ataques también. La guía sobre qué es un CDN explica la diferencia.

3. WAF, límites de peticiones y reglas contra bots para la capa 7

Las inundaciones en la capa de aplicación son los ataques más habituales contra webs pequeñas y medianas y los más difíciles de detectar, porque cada petición parece legítima. Apuntan a las URL que más hacen trabajar a tu servidor, así que planifica tus reglas en torno a ellas:

Un firewall de aplicaciones web (WAF) con conjuntos de reglas gestionados también bloquea intentos de explotación como la inyección SQL y el cross-site scripting, y las reglas contra bots mantienen fuera a los scrapers. Las reglas por país ayudan si solo vendes en unos pocos mercados, pero mejor un desafío que un bloqueo total, para que los clientes que usan una VPN puedan seguir entrando.

4. Blindaje del origen

Un proxy solo te protege si los atacantes no pueden rodearlo. En cuanto tu web esté detrás de uno, cierra el origen:

• Acepta tráfico web solo del proxy. Configura el firewall del servidor o del hosting para que los puertos 80 y 443 solo acepten conexiones de los rangos de IP publicados por tu proveedor de proxy.
• Da por hecho que los registros DNS antiguos se conocen. Si tu dominio apuntaba antes directamente a tu servidor, los servicios que archivan el historial de DNS hacen que esa IP sea fácil de encontrar. Pregunta a tu hosting si puedes obtener una IP nueva tras el cambio.
• Revisa los subdominios. Registros como staging, dev, ftp, cpanel o mail suelen apuntar directamente al mismo servidor y delatan el origen.
• Separa el correo del servidor web. Si tu registro MX apunta al servidor web, o el servidor envía él mismo los correos del formulario de contacto, su IP aparece en el DNS y en las cabeceras Received de cada correo. Revisa también tu registro SPF en busca de entradas ip4: que delaten el servidor.

Una comprobación rápida muestra qué registros resuelven a la IP de tu origen:

dig +short example.com A
dig +short mail.example.com A
dig +short example.com MX
dig +short example.com TXT

Cualquier respuesta que contenga la IP de tu servidor es un camino para rodear tu proxy.

Qué cubre tu hosting y qué no

Muchos hostings filtran los grandes ataques volumétricos en el borde de su red. Eso protege su infraestructura y a todos los clientes alojados en ella, que no es lo mismo que proteger tu web. Lagunas típicas:

• Las inundaciones de capa 7 pasan. Unos cientos de peticiones HTTP por segundo son muy poco para la red de un centro de datos, pero bastan para sobrecargar un CMS o una tienda típicos.
• El null routing te deja fuera de línea. Si un ataque amenaza la red, algunos hostings dejan de enrutar tráfico a la IP atacada. Los demás clientes están a salvo, tu web está caída.
• Los límites de recursos aprietan. En planes compartidos o gestionados, un ataque puede llevar tu cuenta a sus límites de CPU o de procesos, y tu web queda ralentizada.
• Sin reglas propias por web. Normalmente no puedes definir tus propios límites de peticiones ni desafíos a nivel de red del hosting.

Hazle estas preguntas a tu hosting y guarda las respuestas:

1. ¿Qué tipos de ataque filtráis y el filtrado de inundaciones HTTP (capa 7) forma parte de mi plan?
2. ¿Qué le pasa a mi web durante un ataque grande: limitación, null routing, suspensión?
3. ¿Puedo restringir mi servidor para que solo acepte tráfico web de los rangos de IP de un proxy?
4. ¿Cómo contacto con soporte durante un ataque?

Cómo elegir un servicio de protección

Si tu hosting cubre el nivel de red pero no tu aplicación, un servicio basado en proxy cubre ese hueco. Compara por criterios, no por etiquetas de marketing:

• Cobertura de toda la web. Hace de proxy para tu HTML, no solo para los recursos estáticos.
• Siempre activo. El filtrado permanente no necesita ningún cambio durante un ataque. En los servicios bajo demanda, el tiempo de conmutación es justo el problema.
• Herramientas de capa 7 que controlas tú. Detección automática más tus propios bloqueos de IP, reglas por país, desafíos y límites de peticiones.
• Caché segura y visibilidad. Respeta tus cabeceras Cache-Control, nunca cachea carritos ni páginas con sesión iniciada, y muestra peticiones y errores con alertas.
• Los bots buenos siguen funcionando. Los rastreadores de los buscadores y las notificaciones de las pasarelas de pago siguen pasando cuando endureces las reglas.
• DNS completo. Tanto si cambias los servidores de nombres como un solo registro, los registros MX, TXT y SRV tienen que seguir funcionando. Nuestra checklist para cambiar los servidores de nombres sin caídas lo explica.
• Facturación durante los ataques. Pregunta cómo cuenta el tráfico del ataque en el tráfico incluido.
• Soporte. Cómo hablas con una persona durante un ataque.

La guía sobre denegación de servicio (en inglés) del National Cyber Security Centre del Reino Unido es una buena lectura neutral para la planificación.

Checklist de preparación

Repasa esta lista una vez y revísala cada pocos meses:

• Contactos. El soporte del hosting con tu número de cliente, tu agencia o desarrollador, tu proveedor de protección y quién decide si se desactivan funciones o se informa a los clientes.
• Accesos. Al menos dos personas pueden entrar en el registrador, el DNS y el panel del proxy, cada una con su propia cuenta y autenticación en dos pasos.
• DNS. Guarda una exportación actualizada de tu zona y ten claro qué registros deben seguir accesibles.
• Monitorización. Una comprobación externa de disponibilidad, alertas por picos de tráfico y por aumento de errores 5xx, y una vista de la CPU de tu origen.
• Plan de actuación. Una página con las reglas más estrictas que vas a activar, las funciones costosas que puedes apagar durante un día (búsqueda en vivo, widgets de recomendaciones, llamadas a APIs externas) y una nota breve para los clientes.
• Prueba del origen. Comprueba que tu origen rechaza el tráfico directo usando la IP de tu servidor:

curl -sI --max-time 10 --resolve www.example.com:443:203.0.113.10 https://www.example.com/

Si esto devuelve una respuesta en lugar de agotar el tiempo o ser rechazado, tu origen sigue aceptando tráfico que se salta el proxy.

Cómo te ayuda fast.site

fast.site es un proxy inverso de sitio completo que se coloca delante de tu hosting actual. Mantienes tu proveedor y cambias los servidores de nombres de tu dominio a fast.site. A partir de ahí, cada petición llega primero a la red edge y se filtra allí antes de que nada pase a tu origen. fast.site gestiona tu zona DNS, incluidos los registros MX, TXT y SRV, como se describe en la documentación de DNS.

La detección de DDoS en capa 7 funciona automáticamente en todos los dominios, sin configuración. También puedes bloquear IP y rangos CIDR, bloquear países o enviarlos a un desafío CAPTCHA, crear tus propias reglas de desafío y fijar límites de peticiones por IP. Los conjuntos de reglas gestionados filtran la inyección SQL, el XSS y los bots maliciosos. La documentación de seguridad recoge todas las opciones.

La caché también quita carga a tu servidor: las páginas públicas muestran fs-cache: HIT y se sirven desde el edge, mientras que los carritos, los checkouts y las sesiones iniciadas muestran BYPASS. Las analíticas muestran peticiones, tasas de error y ancho de banda del origen, y las alertas de anomalías avisan de los picos de tráfico. La protección a nivel de red de la conexión de tu origen sigue siendo cosa de tu hosting, así que limita tu origen al proxy.

Configúralo con calma y mide el resultado en tu propia web. Puedes probarlo con una prueba gratuita de 7 días, sin tarjeta de crédito. Los planes están en la página de precios.

Preguntas frecuentes

¿Las webs pequeñas necesitan protección DDoS?

El tamaño no te protege. Las webs pequeñas caen ante una inundación HTTP modesta, y en un hosting compartido un ataque contra una web vecina también puede afectar a la tuya. Si una caída te cuesta pedidos, contactos o reputación, merece la pena montar protección delante de la web.

¿Mi hosting incluye protección DDoS?

A menudo en parte. Muchos hostings filtran las grandes inundaciones de red para proteger su infraestructura, pero las inundaciones en la capa de aplicación contra tu web suelen pasar, y algunos hostings aplican null routing a la IP atacada. Pregunta exactamente qué tipos de ataque cubren.

¿Un CDN protege contra ataques DDoS?

Solo si hace de proxy para toda tu web y filtra el tráfico antes de que llegue a tu servidor. Un CDN de recursos en otro host no protege tus páginas, porque las peticiones de HTML siguen yendo directamente a tu origen.

¿La protección DDoS ralentiza mi web?

Un proxy añade una parada entre el visitante y el servidor, pero las páginas en caché desde un edge cercano a menudo llegan más rápido. Depende de tu web y de tus visitantes, así que haz una comparación de antes y después como se describe en nuestra guía para medir la velocidad de una web.