cdncheck: identificar infraestructura de CDN y WAF antes de escanear

cdncheck · MIT

cdncheck te dice si una IP pertenece a una CDN, un WAF o un proveedor de nube. Suena menor. Es la diferencia entre escanear la infraestructura de tu cliente y escanear la de Cloudflare.

Instalación

go install -v github.com/projectdiscovery/cdncheck/cmd/cdncheck@latest

Comandos principales

# clasifica una lista de IPs
cdncheck -i ips.txt

# solo lo que está detrás de una CDN
cdncheck -i ips.txt -resp -mcdn

# excluye rangos de CDN antes de un escaneo activo
cdncheck -i ips.txt -exclude > direct-ips.txt

# JSON
cdncheck -i ips.txt -json -o cdn.jsonl

Salida

{"input":"104.16.0.1","cdn":true,"cdn_name":"cloudflare","waf":false,"cloud":false}

Dónde encaja en Tandera

cdncheck se ejecuta en la fase de discovery de tres flujos, incluido recon_cloud_enum. Se sitúa deliberadamente temprano — antes de agendar cualquier escaneo activo — porque su salida cambia lo que las fases posteriores tienen permitido tocar.

Una IP clasificada como propiedad de CDN no es un activo del cliente. Tandera usa esa clasificación al aplicar el techo de riesgo de un flujo, de modo que el escaneo activo de recon_web_full no apunte nmap o masscan a un rango de proveedor compartido.

Uso en un pentest

Esto es un control legal, no una optimización. Hacer port scan a un rango de Cloudflare o AWS es escanear a un tercero que no te autorizó. Ejecuta cdncheck antes de cualquier fase activa y excluye lo que marque.

Una CDN por delante significa que tus findings pueden no ser del origen. Las cabeceras, la configuración TLS y las páginas de error que observas pueden pertenecer al edge. Anótalo en el informe en lugar de atribuir el comportamiento del edge al servidor del cliente.

Una clasificación de WAF cambia tu metodología, y el cliente debe saberlo. Si las pruebas ocurrieron a través de un WAF, dilo — de lo contrario el informe implica un nivel de cobertura que el engagement no tuvo.