¿Sigues recibiendo ataques con Cloudflare? 7 vías ocultas de filtración de IP de origen y guía de protección

Un blog quedó offline bajo ataque con ~20 GB de tráfico en un día—suspendido por impago—pese a usar Cloudflare. Los logs mostraban tráfico que no pasaba por Cloudflare: todo directo a la IP del servidor de origen. Los atacantes saltaron el CDN y golpearon el servidor real. Eso es la filtración de IP de origen.

Es muy habitual. Muchos creen que con Cloudflare ya está todo resuelto, pero la IP de origen lleva tiempo expuesta por historial DNS, cabeceras de correo y escaneo de subdominios. Este artículo cubre las vías habituales de filtración, cómo detectarlas y un plan de protección completo.

Por qué filtra la IP de origen

Qué es la filtración de IP de origen y sus riesgos

Cuando usas un CDN como Cloudflare, los usuarios acceden a los nodos de Cloudflare y este reenvía las solicitudes a tu servidor real (origen). Los atacantes solo ven la IP de Cloudflare, no la de tu servidor.

Pero si obtienen tu IP de origen por alguna vía, el CDN pierde sentido. Pueden atacar directamente tu servidor y saltarse toda la protección de Cloudflare.

Los daños son graves:

• Servidor caído: un DDoS directo al origen puede tumbar el servidor
• Factura de tráfico disparada: muchos proveedores cobran por tráfico; un ataque puede dejarte una factura enorme
• Riesgo de robo de datos: si hay vulnerabilidades, el atacante salta el WAF del CDN y el riesgo aumenta

Según el informe de Cloudflare del cuarto trimestre de 2024, observaron el mayor ataque DDoS de la historia: 5,6 Tbps.

Aunque un sitio normal difícilmente lo sufra, incluso unos pocos G pueden tumbar un servidor pequeño.

[Imagen: diagrama del funcionamiento del CDN]
Prompt: server behind CDN shield, user traffic flow through cloudflare nodes, simplified diagram, tech blue color scheme, professional illustration

Las 7 vías habituales de filtración de IP de origen

Estas son las 7 vías más comunes, de mayor a menor riesgo.

Vía 1: Historial DNS (riesgo: alto)

La más común y la que más se pasa por alto.

El problema: muchos apuntan el dominio a la IP real un tiempo y luego recuerdan poner Cloudflare. Pero los registros DNS ya fueron rastreados y guardados de forma permanente por servicios como SecurityTrails o DNSdumpster.

Yo cometí ese error. Al lanzar el sitio usé la IP real y tardé medio año en configurar Cloudflare. Al consultar SecurityTrails, los registros DNS de hace meses seguían ahí.

Vía 2: Cabeceras del servidor de correo (riesgo: alto)

Muy oculta; muchos no lo imaginan.

Los sitios envían correos: confirmación de registro, recuperación de contraseña, notificaciones RSS… Las cabeceras (Email Header) incluyen la IP del servidor emisor. Si usas servidor de correo propio o el sitio envía correo directamente desde el servidor, la IP de origen queda expuesta.

¿Cómo lo explotan? Registran una cuenta, reciben el correo de confirmación, ven el correo en bruto y buscan el campo Received: ahí está la IP real.

La primera vez que lo descubrí me sorprendió: no imaginaba que el correo pudiera filtrar la IP.

Vía 3: Escaneo de subdominios (riesgo: medio-alto)

También muy habitual.

Puede que example.com tenga Cloudflare, ¿y los subdominios? mail.example.com, admin.example.com, dev.example.com pueden apuntar directo a la IP del origen sin CDN.

Con herramientas como sublist3r u OneForAll listan subdominios y hacen ping; si uno devuelve la IP real, el origen queda localizado.

Aunque el dominio principal y los subdominios no estén en el mismo servidor, si comparten el mismo segmento C (por ejemplo 192.168.1.x), el atacante puede acotar el rango de IP.

Vía 4: Filtración en el código fuente (riesgo: medio)

Páginas de prueba o depuración pueden filtrar la IP.

Casos habituales:

• Página phpinfo() sin borrar, muestra IP y configuración
• Directorio .git accesible con IP en configuración
• Modo debug en logs de error con rutas e IP del servidor
• API hardcodeada con IP en lugar de dominio

He visto info.php de prueba olvidado en el servidor, indexado por buscadores, mostrando toda la información del servidor. No es tan raro.

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

Vía 5: Consulta de certificados SSL (riesgo: medio)

Los certificados SSL también pueden filtrar.

Certificate Transparency registra todos los certificados emitidos. Con crt.sh o Censys puedes ver el historial de certificados de un dominio y las IP vinculadas.

Si antes de Cloudflare el certificado SSL estaba vinculado directamente a la IP del origen, ese registro queda guardado. No siempre se obtiene la IP por certificados, pero es una vía viable.

Vía 6: Diferencias de resolución DNS en el extranjero (riesgo: medio-bajo)

Algunos CDN solo tienen nodos en un país.

Desde servidores DNS extranjeros la consulta puede devolver la IP de origen en lugar de la del CDN. Cloudflare es global, así que el riesgo es bajo; con CDN de proveedores pequeños conviene vigilarlo.

Compruébalo con DNS de Google (8.8.8.8) o de Cloudflare (1.1.1.1) y mira si la IP devuelta es del CDN.

Vía 7: Escaneo de segmento C y sitios en el mismo servidor (riesgo: bajo)

Si en el mismo servidor hay varios sitios y uno sin protección, los demás pueden localizarse.

Los atacantes usan la sintaxis ip:xxx.xxx.xxx.xxx en Bing o Google para ver qué sitios hay en una IP, o escanean el segmento C completo.

El riesgo es relativamente bajo, pero si alojas muchos sitios en un servidor, conviene tenerlo en cuenta.

[Imagen: infografía de las 7 vías de filtración de IP]
Prompt: 7 ways of IP leak infographic, DNS history, email headers, subdomain scan, source code leak, SSL certificate, colorful icons, flat design

Cómo detectar si la IP de origen filtró

Tras ver las vías de filtración, ¿cómo comprobar si tu sitio está afectado? Esta lista de autocomprobación suele bastar.

Tabla resumen de herramientas de detección

Pasos detallados de detección

Comprobación 1: Historial DNS

Abre estos sitios e introduce tu dominio:

• SecurityTrails (securitytrails.com) — historial de resolución DNS
• DNSdumpster (dnsdumpster.com) — enumeración DNS, subdominios e historial
• Netcraft (sitereport.netcraft.com) — también registra IP históricas

Si aparece la IP real de antes de Cloudflare, casi seguro que filtró.

Comprobación 2: Cabeceras de correo

Método muy práctico:

1. Si tu sitio tiene registro, crea una cuenta de prueba y dispara el correo de confirmación
2. O usa recuperación de contraseña y envíate un correo de restablecimiento
3. Abre el correo original (el nombre varía según el cliente)
4. Busca los campos Received o X-Originating-IP
5. Comprueba si la IP es la de tu origen

Si el correo sale de un tercero (SendGrid, Amazon SES), verás la IP del proveedor; no hay problema.

Comprobación 3: Escaneo de subdominios

Revisa manualmente la resolución DNS de cada subdominio:

# Consultar subdominios con dig
dig mail.yourdomain.com
dig admin.yourdomain.com
dig api.yourdomain.com

O usa herramientas en línea:

• Sublist3r — herramienta Python que encuentra muchos subdominios
• OneForAll — recopilador de subdominios muy completo

Haz ping a cada subdominio y comprueba si devuelve IP de Cloudflare o la tuya.

Comprobación 4: Ping global

Desde varias regiones, haz ping a tu dominio y comprueba si la IP es consistente:

• ping.pe — ping simultáneo desde nodos globales
• 17ce.com — prueba multiubicación (China)

Si las IP difieren entre países, puede haber problema. Con Cloudflare como CDN global, el ping debería devolver el nodo CF más cercano.

Comprobación 5: Certificados SSL

Busca tu dominio en crt.sh:

https://crt.sh/?q=yourdomain.com

Comprueba si algún certificado vinculó tu IP de origen. Si es así, la IP queda en cierto modo pública.

Comprobación 6: Motores de búsqueda en ciberespacio

Método avanzado pero efectivo. Usa Shodan o Censys:

• Shodan (shodan.io) — buscador de dispositivos en Internet
• Censys (censys.io) — escaneo de ciberespacio
• Fofa (fofa.so) — mapeo de ciberespacio

Si tu origen tiene servicios expuestos (puerto 80 abierto), puede quedar indexado y filtrar la IP.

Comprobación 7: Logs del servidor

El método más directo:

# Logs de Nginx suelen estar en
tail -f /var/log/nginx/access.log
# Logs de Apache
tail -f /var/log/apache2/access.log

Si hay accesos directos a la IP de origen que no vienen de rangos de Cloudflare, alguien ya conoce tu IP e intenta conectar directamente.

Los rangos de Cloudflare están en la documentación oficial; en condiciones normales, todas las solicitudes deberían venir de esos rangos.

Plan de protección completo

Preparación antes de configurar

Si aún no usas Cloudflare o descubriste que la IP filtró y vas a reconfigurar, estos pasos previos ahorran problemas.

Preparación 1: Cambiar la IP del servidor o usar uno nuevo

La solución más drástica. Si la IP ya filtró, lo mejor es empezar con una IP nueva.

Opciones en la nube:

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

• Comprar un servidor nuevo: migra los datos y destruye el viejo
• Cambiar la IP pública: algunos proveedores (Alibaba Cloud, Tencent Cloud) permiten cambiar la IP elástica, a menudo gratis o con poca tarifa
• Dominio nuevo: si dominio e IP están muy ligados, podrías cambiar de dominio (coste alto; solo en casos extremos)

Si el sitio está empezando, un servidor nuevo suele ser lo más simple. Con pocos datos, la migración lleva minutos.

Preparación 2: Limpiar rastros que puedan filtrar la IP

No puedes borrar el historial DNS de terceros, pero sí lo que controlas:

• Eliminar páginas de prueba (phpinfo.php, info.php, etc.)
• Desactivar modo debug y salida de errores
• Bloquear acceso externo a .git (regla en nginx)
• Revisar el código y eliminar IP hardcodeadas

Preparación 3: Planificar la estrategia DNS

Decide qué dominios pasan por Cloudflare y cuáles no:

• Dominio principal y www: obligatorio por Cloudflare
• Todos los subdominios públicos: también por Cloudflare (blog, api, img)
• Servidor de correo: si es propio, mejor terceros
• Servicios internos: admin, base de datos — sin DNS público; acceso por IP interna

Mejores prácticas de configuración en Cloudflare

Con la preparación hecha, así ocultas bien la IP de origen.

Práctica 1: CDN en todo el sitio, todos los subdominios por Cloudflare

Lo más importante. En DNS de Cloudflare cada registro tiene un icono de nube:

• Nube naranja: tráfico por proxy de Cloudflare, oculta la IP de origen
• Nube gris: sin proxy, resuelve directo a la IP de origen

Todos los dominios públicos deben estar en nube naranja. Muchos solo ponen el principal en naranja y los subdominios en gris: no sirve.

Solo en gris registros que Cloudflare no puede proxyar: MX, TXT de verificación, etc.

[Imagen: interfaz DNS de Cloudflare]
Prompt: cloudflare DNS settings screenshot, orange cloud vs gray cloud comparison, highlight the proxy status toggle, clean interface, 16:9

Práctica 2: Correo con terceros, no propio

Las cabeceras filtran la IP del servidor emisor. La solución más simple es no enviar desde tu servidor:

• SendGrid: 100 correos/día gratis, suficiente para sitios pequeños
• Amazon SES: pago por uso, 62 000 correos/mes gratis (requiere cuenta AWS)
• Mailgun: también tiene cuota gratuita e interfaz amigable

Ofrecen API y SMTP; el cambio no es complicado y la entregabilidad suele ser mejor que con servidor propio.

Práctica 3: Lista blanca en firewall, solo IP de Cloudflare

Defensa central: aunque conozcan tu IP, si el firewall solo acepta rangos de Cloudflare, el ataque no entra.

Cloudflare publica la lista de rangos:

https://www.cloudflare.com/ips/

Configura el firewall del servidor. Ejemplo con iptables:

# ⚠️ Importante: asegúrate de no bloquear SSH
# Prueba primero en entorno de prueba para no quedarte fuera
# Vaciar reglas existentes
iptables -F
# Permitir loopback
iptables -A INPUT -i lo -j ACCEPT
# Conexiones establecidas
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Permitir SSH (cambia al puerto que uses)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# Solo rangos de Cloudflare en 80 y 443
# Aquí algunos segmentos IPv4; descarga la lista completa del sitio oficial
iptables -A INPUT -p tcp -m multiport --dports 80,443 -s 173.245.48.0/20 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports 80,443 -s 103.21.244.0/22 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports 80,443 -s 103.22.200.0/22 -j ACCEPT
# ... añade todos los rangos de CF ...
# Denegar resto en 80/443
iptables -A INPUT -p tcp -m multiport --dports 80,443 -j DROP
# Guardar reglas
iptables-save > /etc/iptables/rules.v4

Precauciones de configuración:

1. Probar antes en entorno de prueba
2. Mantener acceso SSH (puerto 22)
3. Probar desde otro dispositivo (móvil) tras configurar
4. En la nube, usar grupos de seguridad del panel es más seguro y cómodo

En la mayoría de proveedores cloud, los grupos de seguridad en el panel evitan quedarte fuera por error.

Tras configurar, prueba acceder a la IP de origen con datos móviles: no debería conectar.

[Imagen: diagrama de configuración de firewall]
Prompt: firewall protection layers diagram, cloudflare IP whitelist, block non-cloudflare traffic, security shield icon, professional tech illustration

Práctica 4: Desactivar respuesta a ping

Evita que escaneos de segmentos localicen tu servidor:

# Desactivar ping
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
# Permanente: editar /etc/sysctl.conf
net.ipv4.icmp_echo_ignore_all = 1
# Luego ejecutar
sysctl -p

Así tu servidor no responde al escaneo y parece una IP inválida.

Medidas de protección avanzadas

Si tu sitio es importante o ya te atacaron, considera estas medidas adicionales.

Medida 1: Cloudflare Tunnel (antes Argo Tunnel)

Permite no exponer la IP de origen.

Ejecutas cloudflared en tu servidor; se conecta activamente a Cloudflare formando un túnel seguro:

• No necesitas abrir 80/443
• El exterior no alcanza la IP de origen
• Todo el tráfico llega por el túnel desde Cloudflare

Pasos (simplificado):

# Instalar cloudflared
wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
dpkg -i cloudflared-linux-amd64.deb
# Iniciar sesión en Cloudflare
cloudflared tunnel login
# Crear túnel
cloudflared tunnel create mytunnel
# Configurar ruta
cloudflared tunnel route dns mytunnel yourdomain.com
# Ejecutar túnel
cloudflared tunnel run mytunnel

Casi la solución perfecta para ocultar IP; algo más compleja y algunas funciones avanzadas requieren plan de pago.

Medida 2: Rotar la IP de origen periódicamente

Para sitios de alto riesgo, cambiar IP cada 3-6 meses es buena práctica. Aunque la IP anterior filtró, el atacante golpea al vacío. El coste depende de la importancia del sitio.

Medida 3: Monitorizar tráfico anómalo

Si detectas accesos desde IP que no son de Cloudflare, alerta de inmediato:

# Ejemplo simple de script de monitorización
tail -f /var/log/nginx/access.log | grep -v -E "(173\.245\.|103\.21\.|103\.22\.)" | while read line
do
    echo "Alerta: acceso desde IP que no es de CF! $line"
    # Puedes añadir alerta por correo o SMS
done

Así sabes al instante si alguien intenta conectar directo al origen.

Medida 4: No hardcodear IP en el código

Básico pero importante: todas las llamadas API y carga de recursos deben usar dominio, no IP.

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

// Ejemplo incorrecto
fetch('http://123.456.78.90/api/data')
// Ejemplo correcto
fetch('https://api.yourdomain.com/data')

Aunque alguien vea el frontend, no encontrará la IP de origen.

Qué hacer si ya filtró

Si descubriste que la IP de origen filtró, no entres en pánico. No puedes borrar registros ya guardados por terceros, pero sí reducir el riesgo.

Paso de remediación 1: Cambiar la IP del servidor de inmediato

Lo más efectivo. Solicita un servidor nuevo o cambia la IP pública y migra los datos.

Estimación de costes:

• Cambio de IP en la nube: gratis o poca tarifa (unos 10-20 yuanes)
• Servidor nuevo: configuración mínima ~30-50 yuanes/mes
• Migración: media hora en sitios pequeños

No destruyas el servidor viejo de inmediato; guárdalo unos días para verificar que el nuevo funciona bien.

Paso de remediación 2: Lista blanca en firewall

Aunque filtró, con firewall bien configurado no entran.

Sigue la configuración de iptables o grupos de seguridad: solo rangos de Cloudflare en 80/443. El tráfico de ataque queda bloqueado.

Cuidado al configurar:

1. Probar en entorno de prueba
2. Mantener acceso SSH (puerto 22)
3. Probar desde otro dispositivo

Yo me quedé fuera por un error y tuve que entrar por VNC del proveedor para arreglarlo.

Paso de remediación 3: Cloudflare Rate Limiting

Limita la frecuencia de acceso por IP.

El plan gratuito tiene límites; Pro (~20 USD/mes) permite reglas más finas:

• Máximo 10 solicitudes por IP cada 10 segundos
• Por encima del umbral: bloqueo o Challenge (verificación humana)
• Protección por rutas específicas

Útil contra ataques de escala pequeña.

Paso de remediación 4: Servicio de IP anti-DDoS

Si te atacan a menudo o el negocio es crítico, considera IP con protección DDoS.

Alibaba Cloud, Tencent Cloud y Baidu Cloud ofrecen productos anti-DDoS:

• Por ancho de banda: tarifa fija con cierta capacidad (por ejemplo 20 G)
• Por volumen de ataque: bajo coste habitual, cobro al atacar
• Coste: según nivel, de cientos a decenas de miles al mes

Para sitios personales o PYME el coste puede ser alto; para e-commerce o servidores de juegos que exigen estabilidad, puede valer la pena.

Paso de remediación 5: Monitorización y respuesta rápida

Configura alertas ante tráfico anómalo o acceso directo al origen:

• Notificaciones de Cloudflare ante tráfico anómalo
• Herramientas en el servidor (zabbix, prometheus)
• Si hay ataque, cambiar DNS temporalmente a servidor de respaldo

La velocidad importa. He visto facturas enormes por descubrir el ataque horas después.

Conclusión

En resumen:

La filtración de IP de origen es un problema sistémico; Cloudflare solo no lo resuelve para siempre. Desde historial DNS hasta cabeceras de correo, subdominios y certificados SSL, las vías son muchas.

Las medidas de protección más críticas:

1. CDN en todo el sitio — todos los dominios públicos por Cloudflare, nube naranja activada
2. Lista blanca en firewall — solo rangos de Cloudflare; última línea de defensa
3. Correo externalizado — SendGrid, SES, etc.; no envíes desde tu servidor
4. Autocomprobación periódica — usa las herramientas de este artículo de forma preventiva

Si aún no tienes Cloudflare, empieza bien desde el principio. Si ya lo tienes pero no estás seguro, dedica diez minutos a la autocomprobación.

Si la IP ya filtró, cambia de IP, configura el firewall y refuerza las protecciones: el problema es manejable.

Recuerda: proteger la IP de origen es un proceso continuo, no un trabajo de una vez. Cada subdominio nuevo debe pasar por CDN; al cambiar configuración no expongas la IP por error; revisa periódicamente que las medidas sigan vigentes.

Puedes empezar ahora: consulta SecurityTrails para ver el historial DNS y comprobar si hay filtración. Si hay problema, sigue los pasos de este artículo. Es más trabajo que no hacer nada, pero mejor que quedarte offline bajo ataque, ¿no?