Cloudflare es un proxy excelente. Pone una capa entre el mundo y tu servidor, filtra tráfico malicioso, ahorra ancho de banda. Pero esa capa a veces se puede rodear con técnicas completamente legales y públicas. Si eres dueño de una web, este artículo te sirve para cerrar las fugas. Si investigas la tuya propia antes de un pentest, lo mismo.
Importante: estas técnicas solo son legales contra webs tuyas o con autorización. No las uses para atacar terceros.
Técnica 1: registros MX del correo
Cloudflare no proxya el tráfico SMTP por defecto. Cuando el dueño configura su correo, normalmente apunta mail.midominio.com o los MX a una IP directa — que suele ser la del mismo servidor web.
dig MX midominio.com
dig A mail.midominio.com
Si mail.midominio.com resuelve a una IP que no está en los rangos de Cloudflare, esa IP probablemente aloja también el servidor web. Confírmalo haciendo curl -H "Host: midominio.com" http://IP_ENCONTRADA. Si la web responde, has encontrado el origen.
Técnica 2: subdominios no proxyados
Muchos dueños configuran bien midominio.com y www tras Cloudflare, pero se olvidan de subdominios como:
cpanel.midominio.comwebmail.midominio.comdev.midominio.com,staging.midominio.comold.midominio.com,backup.midominio.com
Cualquiera de esos puede resolver a la IP real del servidor. Herramientas como subfinder, amass, sublist3r los enumeran en segundos.
Técnica 3: Certificate Transparency logs
Cada certificado SSL emitido queda en un log público (CT logs). Buscas midominio.com en crt.sh:
https://crt.sh/?q=midominio.com
Y obtienes todos los subdominios para los que se ha emitido alguna vez un certificado SSL. Bingo: internal-admin.midominio.com, ftp.midominio.com… todos ellos potenciales fugas.
Técnica 4: histórico de DNS
SecurityTrails, DNSDumpster y ViewDNS guardan la IP de midominio.com de los últimos años. Muchas veces el dominio estuvo sin Cloudflare durante un tiempo y hay una IP histórica que, si el dueño no la cambió, sigue siendo la del hosting real.
Técnica 5: fugas en código fuente
Algunas webs filtran la IP real en:
- Cabecera
X-Originating-IPo similar en correos enviados desde el servidor (ver un email que te mandaron). - El
favicon.icocon hash exclusivo buscado en Shodan: si alguna IP indexada por Shodan sirve el mismo favicon.ico, hay una fuerte posibilidad de que sea tu origen. - Errores PHP o stack traces que muestran paths del servidor.
Técnica 6: Shodan y Censys
Buscas en Shodan:
ssl.cert.subject.cn:"midominio.com"
Y Shodan te muestra qué IPs públicas han servido un certificado con ese CN. Si una IP fuera de Cloudflare sale, es probablemente el origen. Técnica clásica de bug bounty.
Cómo cerrarlas (si la web es tuya)
- Proxya todos los registros en Cloudflare (nube naranja), incluidos subdominios viejos.
- Ajusta el firewall del origen para solo aceptar IPs de Cloudflare (lista oficial). Esto es crítico.
- Mueve el correo a un servicio separado (Google Workspace, Zoho). Así los MX no apuntan al mismo servidor web.
- Revoca certificados SSL antiguos que contenían subdominios que ya no existen.
- Rota la IP del origen cada cierto tiempo si es posible.
Qué hace QueUsan
Cuando detectamos Cloudflare delante, marcamos el hosting como "detrás de Cloudflare" y aplicamos solo técnicas 1 y 4 (MX y reverse DNS histórico cuando está disponible). Las técnicas más intrusivas (favicon hashing, CT logs exhaustivos) las reservamos para el plan Agencia porque requieren correlaciones externas.
Relacionado: identificar el hosting real · guía completa de detección.