¿Cómo configurar Cloudflare para proteger un sitio de DDoS?

Question

IT Interview Practice · Accepted Answer

**Cloudflare protege mejor cuando las peticiones lo atraviesan y la aplicación soporta el tráfico restante.** Activar una opción no protege todas las rutas al servidor.

Imagina una tienda: atacantes saturan imágenes, repiten búsquedas caras o llaman directamente al servidor. Consumen recursos distintos y requieren varias capas.

## 1. Pon Cloudflare en la ruta

Activa proxied en los registros DNS compatibles. El visitante llega a Cloudflare antes del origin, el servidor real del sitio. DNS-only resuelve el nombre, pero no dirige HTTP por esta protección.

```text
Browser -> Cloudflare -> Origin -> Database
```

Es la base: solo puede filtrarse lo que llega a Cloudflare. Revisa todos los hostnames públicos, incluido el API, no únicamente el dominio principal.

## 2. Cierra el acceso directo al origin

Si sigue accesible, se puede saltar el filtro. Restringe entrada web pública a rangos IP de Cloudflare adecuados y actualizados. Otra opción es Cloudflare Tunnel, que conecta hacia fuera y puede evitar puertos web públicos entrantes.

Mantén administración en una ruta protegida separada y bases fuera de internet público. Prueba acceso normal y rechazo directo. Ocultar la IP no basta. Véase [protección del origin](https://developers.cloudflare.com/fundamentals/security/protect-your-origin-server/).

## 3. Filtra ataques conservando clientes reales

Revisa protección DDoS administrada y controles de tu plan. Añade WAF adecuado: examina patrones sospechosos en HTTP antes de reenviar. DDoS y WAF cubren problemas relacionados pero distintos; ninguno asegura que cada petición aceptada sea barata.

Empieza con reglas explicables, inspecciona tráfico afectado y ajusta específicamente falsos positivos. Muchos bloqueos no demuestran éxito. Cloudflare documenta [configuración y ajuste DDoS](https://developers.cloudflare.com/ddos-protection/get-started/).

## 4. Protege operaciones caras por separado

Una imagen cacheada suele costar menos al origin que buscar muchos registros. Limita frecuencia en endpoints caros según uso normal y capacidad posterior.

- En login u OTP combina límites de borde con límites por cuenta o destino en la aplicación. Una IP puede representar muchos usuarios.
- En búsqueda e informes limita trabajo por petición; contar peticiones no evita todas las muy costosas.
- En APIs autenticadas considera cliente o API key además de señales de red. Los atacantes distribuidos pueden usar muchas IP.

No hay umbral seguro universal. Observa picos legítimos, introduce límites cuidadosamente y mide alivio y rechazos válidos.

## 5. Usa caché donde compartir sea seguro

Cachea imágenes públicas y archivos estáticos para responder repeticiones sin origin. En la tienda reduce servir la misma imagen reiteradamente.

Carritos y cuentas personales necesitan otras reglas para no entregar datos ajenos. Revisa claves y bypass antes de cachear respuestas dinámicas. Caché reduce trabajo repetido, pero no hace seguros automáticamente login y checkout bajo carga.

## 6. Usa desafíos de emergencia con plan de retirada

Under Attack puede introducir un desafío de navegador durante un incidente. Evalúalo en rutas de navegador afectadas y retira la medida temporal cuando corresponda. Clientes automáticos y webhooks de pago podrían no superarlo: necesitan autenticación y controles específicos.

Confirma al final navegación y compras reales junto con latencia del origin, CPU, presión de base y errores. Si un ataque directo satura la conexión, coordina protección upstream con el proveedor. Se busca continuidad útil, no prometer invulnerabilidad ante cualquier ataque.

1. Pon Cloudflare en la ruta

2. Cierra el acceso directo al origin

3. Filtra ataques conservando clientes reales

4. Protege operaciones caras por separado

5. Usa caché donde compartir sea seguro

6. Usa desafíos de emergencia con plan de retirada

Preguntas relacionadas