cdncheck: identificando infraestrutura de CDN e WAF antes de escanear

cdncheck · MIT

O cdncheck diz se um IP pertence a uma CDN, um WAF ou um provedor de nuvem. Parece pouco. É a diferença entre escanear a infraestrutura do seu cliente e escanear a da Cloudflare.

Instalação

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

Comandos principais

# classifica uma lista de IPs
cdncheck -i ips.txt

# só o que está atrás de uma CDN
cdncheck -i ips.txt -resp -mcdn

# exclui faixas de CDN antes de uma varredura ativa
cdncheck -i ips.txt -exclude > direct-ips.txt

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

Saída

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

Onde ele entra no Tandera

O cdncheck roda na fase de discovery de três fluxos, incluindo o recon_cloud_enum. Ele fica deliberadamente cedo — antes de qualquer varredura ativa ser agendada — porque sua saída muda o que as fases posteriores têm permissão de tocar.

Um IP classificado como pertencente a CDN não é ativo do cliente. O Tandera usa essa classificação ao aplicar o teto de risco de um fluxo, de modo que a varredura ativa do recon_web_full não aponte o nmap ou o masscan para uma faixa de provedor compartilhado.

Usando em um pentest

Isto é um controle legal, não uma otimização. Fazer port scan numa faixa da Cloudflare ou da AWS é escanear um terceiro que não te autorizou. Rode o cdncheck antes de qualquer fase ativa e exclua o que ele sinalizar.

Uma CDN na frente significa que seus findings podem não ser da origem. Headers, configuração TLS e páginas de erro que você observa podem pertencer à borda. Anote isso no relatório em vez de atribuir comportamento da borda ao servidor do cliente.

Uma classificação de WAF muda sua metodologia, e o cliente deve saber. Se o teste ocorreu através de um WAF, diga — senão o relatório implica um nível de cobertura que o engajamento não teve.