Configuración Cloudflare para sitios web empresariales: velocidad y seguridad, paso a paso

Cloudflare se encuentra entre sus visitantes y su servidor. Los visitantes se conectan al centro de datos cercano de Cloudflare, que sirve archivos almacenados en caché directamente, filtra el tráfico hostil y reenvía el resto a su servidor. Para una empresa, eso significa páginas más rápidas para los clientes que se encuentran lejos de su ubicación de alojamiento, protección contra simples inundaciones por denegación de servicio y un lugar para hacer cumplir las reglas de seguridad sin cambiar el código de la aplicación. Muchos planes comienzan de forma gratuita y los planes pagos agregan funciones, así que verifique la comparación de planes actuales antes de decidirse.

No sustituye al software parcheado ni al código seguro. Nuestra lista de verificación de seguridad PHP aún se aplica. Piense en Cloudflare como una puerta de entrada resistente, no como un reemplazo para cerrar las habitaciones con llave.

Antes de empezar

• Haga un inventario de su DNS. Exporte o haga capturas de pantalla de todos los registros de su proveedor de DNS actual, incluido el correo (MX, SPF, DKIM, DMARC) y los registros de verificación. Un registro perdido es la forma clásica de romper el correo electrónico durante una migración.
• Sepa quién es el propietario de la cuenta del registrador de dominio y asegúrese de que sea una cuenta de empresa con autenticación multifactor. Cambiarás los servidores de nombres allí.
• Si puede, reduzca el TTL de sus registros clave con un día de anticipación, para que los cambios se propaguen más rápido.
• Elija un momento de tranquilidad y dígaselo al equipo. Planifique una reversión: los antiguos servidores de nombres, anotados.

Paso 1: agregue el sitio y revise DNS

Agregue su dominio en el panel de Cloudflare. Escanea registros existentes. Compáralos con tu inventario y soluciona los huecos. Para cada registro elija entre dos modos:

• Proxied (nube naranja): el tráfico pasa por Cloudflare. Úselo para los nombres de host de su sitio web y aplicaciones web.
• Solo DNS (nube gris): Cloudflare solo responde la consulta de DNS. Úselo para servidores de correo, nombres de host SSH o FTP y cualquier cosa que no sea tráfico HTTP o HTTPS.

Luego actualice los servidores de nombres en su registrador. Una vez que el sitio se muestre como activo, verifique su sitio y envíe un correo electrónico de prueba.

Paso 2: configure el cifrado correctamente

Esta es la configuración que rompe la mayoría de los sitios. Cloudflare tiene varios modos SSL/TLS:

• Flexible: cifra al visitante de Cloudflare pero envía el tráfico a su servidor sin cifrar. Parece que funciona, pero el segundo tramo está abierto y, a menudo, provoca bucles de redireccionamiento. Evítalo.
• Completo: cifra ambos tramos pero no verifica el certificado de su servidor.
• Completo (estricto): cifra ambos tramos y verifica el certificado en su servidor. Este es el que debes usar.

Primero instale un certificado válido en su servidor. Un certificado CA de origen Cloudflare o un certificado Let's Encrypt gratuito funcionan. Luego cambie a Completo (estricto), active Usar siempre HTTPS, establezca una versión TLS mínima de 1.2 y habilite HSTS solo después de que todo funcione a través de HTTPS, porque HSTS le dice a los navegadores que rechacen HTTP simple durante mucho tiempo.

Paso 3: haz que Cloudflare sea imposible de eludir

Si los atacantes conocen la dirección IP real de su servidor, pueden enviar tráfico directamente a él y omitir todas las protecciones que haya configurado. Solucione esto de dos maneras:

• Permita el tráfico web a su servidor solo desde los rangos de IP publicados de Cloudflare.
• Restaure la IP real del visitante en su servidor web, porque de lo contrario, cada solicitud en sus registros, límites de velocidad y análisis parece provenir de Cloudflare.

#!/usr/bin/env bash
# /opt/cf/update_cloudflare_ips.sh - run weekly from cron
set -euo pipefail
IPS="$(curl -fsS https://www.cloudflare.com/ips-v4) $(curl -fsS https://www.cloudflare.com/ips-v6)"

# 1) real visitor IP for Nginx
OUT=/etc/nginx/conf.d/cloudflare_real_ip.conf
{
  for r in $IPS; do echo "set_real_ip_from $r;"; done
  echo "real_ip_header CF-Connecting-IP;"
} > "$OUT.tmp" && mv "$OUT.tmp" "$OUT"
nginx -t && nginx -s reload

# 2) firewall: allow HTTPS only from Cloudflare (remove any generic "allow 443" rule first)
for r in $IPS; do ufw allow proto tcp from "$r" to any port 443 comment 'cloudflare'; done

Un detalle importante para los usuarios Docker: los puertos publicados por Docker omiten las reglas ufw. Vincule contenedores a localhost detrás de un proxy inverso o restrinja el acceso en la cadena de firewall DOCKER-USER de Docker. Para un aislamiento más fuerte, Cloudflare Tunnel permite que su servidor realice una conexión saliente únicamente, por lo que no necesita ningún puerto web entrante abierto. Para webhooks de pagos y otras integraciones de servidor a servidor, asegúrese de que las reglas de IP aún permitan el paso de esas solicitudes si no pasan por Cloudflare.

Paso 4: reglas de almacenamiento en caché

De forma predeterminada, Cloudflare almacena en caché archivos estáticos como imágenes, CSS y JavaScript, pero no HTML. Una política sensata para un sitio PHP típico:

• Activos estáticos: caché durante mucho tiempo (un mes o más). Utilice nombres de archivos versionados o una cadena de consulta como app.css?v=123 para que se realice una nueva implementación de inmediato.
• Páginas HTML públicas (páginas de marketing, blogs): se pueden almacenar en caché durante minutos u horas con una regla de caché. Pruebe con cuidado.
• Nunca almacene en caché: administrador, cuenta, carrito, pago, puntos finales API y cualquier página que dependa de una cookie de inicio de sesión. Cree una regla de omisión para estas rutas y para las solicitudes que lleven su cookie de sesión.

Purgue automáticamente después de cada implementación para que los clientes nunca vean archivos obsoletos. Cree un token de API solo con el permiso "Purga de caché" para esta zona y llámelo desde su script de implementación:

# purge selected files after a deployment
curl -sS -X POST "https://api.cloudflare.com/client/v4/zones/$CF_ZONE_ID/purge_cache" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"files":["https://example.com/css/app.css","https://example.com/js/app.js"]}'

Las páginas más rápidas también ayudan a la búsqueda y a las conversiones. Consulte nuestra guía Core Web Vitals para sitios PHP para saber qué corregir en el lado del servidor una vez que la CDN esté instalada.

Paso 5: firewall, bots y limitación de velocidad

• Active las reglas WAF administradas disponibles en su plan. Bloquean patrones de ataque comunes antes de que lleguen a su código.
• Habilite la protección contra bots adecuada a su plan y observe los análisis antes de ajustar algo.
• Puntos finales sensibles al límite de velocidad: inicio de sesión, restablecimiento de contraseña, registro y pago. Los ataques de fuerza bruta y de prueba de cartas tienen como objetivo exactamente estos.
• Tráfico de máquina confiable exento: los webhooks de los proveedores de pagos, los servicios de monitoreo y sus propias integraciones no deben verse afectados por los desafíos del navegador, ya que una página de desafío devuelta a un webhook parece un fracaso.

# Custom rule 1: block probes for secrets and repositories (action: Block)
(http.request.uri.path contains "/.env" or http.request.uri.path contains "/.git" or http.request.uri.path contains "wp-config")

# Custom rule 2: let payment webhooks through (action: Skip, security features)
(http.request.uri.path in {"/webhooks/stripe" "/webhooks/paypal"})

# Rate limiting rule: at most 10 login attempts per minute per IP
(http.request.uri.path eq "/login" and http.request.method eq "POST")  =>  10 requests / 1 minute / IP

La sintaxis de las reglas y los campos disponibles varían según el plan, así que trátelos como plantillas y pruébelos primero en modo "registro". Mantenga también las protecciones a nivel de aplicación: las comprobaciones de firmas de webhooks, como en nuestra guía de webhooks Stripe, nunca dependan únicamente de las reglas de la red.

Paso 6: verificar la configuración

# is traffic going through Cloudflare?
curl -sI https://example.com | grep -iE "^(server|cf-cache-status|cf-ray)"

# does the origin refuse direct access? (replace with your server IP; expect a timeout or refusal)
curl -sI --max-time 8 https://203.0.113.10 -H "Host: example.com" -k

# are the nameservers and mail records right?
dig NS example.com +short
dig MX example.com +short
dig TXT example.com +short

Verifique un archivo estático dos veces: la segunda respuesta debería mostrar cf-cache-status: HIT. Verifique los flujos de inicio de sesión, pago y administración con un navegador real, y envíe y reciba un correo electrónico de prueba.

Errores comunes

• SSL flexible y los bucles de redireccionamiento que siguen.
• Proxy el nombre de host de correo (debe ser solo DNS) u olvidar un registro de correo durante la mudanza.
• Almacenamiento en caché de páginas privadas, para que un cliente vea la página de la cuenta de otro. Evite siempre el caché para el tráfico conectado.
• Dejar el origen expuesto: la IP real es visible en registros DNS antiguos, encabezados de correo electrónico o registros de certificados. Restrinja el firewall y considere cambiar la IP si se ha filtrado.
• No restaurar la IP real, lo que infringe límites de tarifas, registros y controles de fraude.
• Webhooks y API desafiantes, que provocan fallas silenciosas en pagos e integraciones.
• Límites de tamaño de solicitud: las solicitudes representadas tienen un tamaño de cuerpo máximo según el plan. Verifique el límite actual si su aplicación acepta cargas grandes.
• Olvidar el seguimiento. Agregue alertas de vencimiento de certificados y dominios y mantenga controles de tiempo de actividad, como se describe en nuestra guía de respaldo y monitoreo.

Una lista de verificación de una página

1. Inventario de DNS exportado, cuenta de registrador asegurada.
2. Sitio agregado, registros revisados, proxy solo para nombres de host web.
3. Certificado de origen instalado, modo SSL completo (estricto), usar siempre HTTPS activado.
4. Firewall limitado a los rangos Cloudflare, se restableció la IP real del visitante.
5. Reglas de caché para activos estáticos, omisión de rutas privadas, purga en el script de implementación.
6. WAF administrado activado, límites de tarifas para inicio de sesión y pago, webhooks exentos.
7. Se ejecutan comandos de verificación, se configuran alertas y se documenta la reversión.

¿Cómo podemos ayudar?

Configuramos Cloudflare, hosting y canalizaciones de implementación para aplicaciones PHP y las conectamos a sistemas de pago, CRM y mensajería. Lea acerca de nuestro servicio de integraciones o reserve una breve llamada y revisaremos su configuración de DNS, SSL y almacenamiento en caché con esta lista de verificación.