Como verificar se um endereço IP é um proxy (passo a passo)

Entendendo o desafio de detectar proxies

Identificar se uma conexão de entrada vem de um proxy é uma necessidade comum ao investigar abusos, proteger endpoints de autenticação ou depurar tráfego de rede fora do padrão. Proxies podem aparecer de várias formas: encaminhadores HTTP/SOCKS abertos, servidores de VPN comerciais, relays de scraping em datacenters, nós de saída Tor e redes de proxy residencial.

Como cada arquitetura de proxy interage de um jeito diferente com a camada de roteamento IP e com os protocolos de transporte, não existe um único comando manual que entregue uma resposta definitiva de sim ou não. Na prática, a detecção depende da análise de vários sinais de rede independentes. Este guia mostra como inspecionar um IP manualmente e como lidar com a detecção em escala.

Step 1: Inspect Reverse DNS (rDNS) and PTR Records

Consultas de DNS reverso mapeiam um endereço IP de volta para o nome de domínio configurado. Muitos provedores de hospedagem, ISPs de banda larga e operadoras móveis seguem padrões de nomenclatura em seus registros PTR que ajudam a revelar o contexto operacional daquele IP.

Você pode consultar o registro PTR usando dig:

bash dig -x 198.51.100.42 +short

O que esse sinal indica

• ISP residencial ou de banda larga: Hostnames com trechos como pool, cable, fiber, dhcp ou formatos dinâmicos com octetos, como 198-51-100-42.dyn.exampleisp.net, geralmente representam endpoints comuns de usuários finais.
• Datacenter ou VPS: Hostnames com padrões como vps, server, compute, hosted-by, linode, ovh ou nomes brutos de hosts em nuvem, como ec2-198-51-100-42.compute-1.amazonaws.com, apontam para infraestrutura de datacenter. Usuários comuns raramente geram tráfego legítimo de navegador diretamente de uma VPS, a menos que estejam passando por uma VPN própria ou por um proxy.
• PTR ausente ou genérico: Muitos operadores de proxy usam VPS baratas sem configurar DNS reverso confirmado por DNS direto, o chamado FCrDNS.

Limitações

Atacantes que usam redes de proxy residencial roteiam o tráfego por equipamentos de consumidores, comprometidos ou alugados. Nesse caso, o registro PTR vai mostrar um ISP residencial comum, contornando completamente as checagens por rDNS.

Step 2: Query Autonomous System Number (ASN) and Routing Data

Todo endereço IP pertence a um Autonomous System (AS). O registro do AS indica a entidade que controla o bloco de IPs e o anuncia via BGP. Usuários residenciais costumam receber IPs de ASNs de operadoras de telecomunicações, enquanto proxies comerciais e servidores de VPN ficam quase sempre em ASNs de hospedagem, nuvem ou colocation.

Você pode consultar detalhes de ASN pelos serviços DNS ou WHOIS da Team Cymru:

bash whois -h whois.cymru.com " -v 198.51.100.42"

Outra opção é consultar diretamente os registros regionais da internet, como ARIN, RIPE e APNIC:

bash whois 198.51.100.42 | grep -iE "origin|org-name|descr|nettype"

Avaliando sinais de ASN

• Se o IP pertence à DigitalOcean, Hetzner, OVH, AWS ou M247, e o usuário afirma ser um visitante web interativo, ele está passando por algum intermediário, como uma VPN, um encaminhador comercial ou um script automatizado.
• Verifique o NetType ou a atribuição do registro. Blocos realocados ou portáveis associados a agregadores de proxy muitas vezes revelam nomes de empresas diferentes da operadora de telecomunicações por trás da rede.

Limitações

Checagens em nível de ASN não identificam proxies residenciais quando a operadora subjacente continua sendo AT&T, Comcast ou alguma operadora móvel internacional.

Step 3: Check Known Tor Exit Nodes and Threat Lists

A rede Tor publica uma lista autoritativa e dinâmica de endereços IP de nós de saída ativos. Como relays de saída Tor são públicos, comparar um IP com essa lista oferece um alto grau de confiança.

Você pode baixar a lista ativa de saídas diretamente:

bash curl -s https://check.torproject.org/torbulkexitlist | grep -x "198.51.100.42"

Também é possível fazer uma checagem baseada em DNS contra a DNSBL do Tor Project:

bash # Reverse the target IP octets and query the dnsel zone dig 42.100.51.198.ip-port.exitlist.torproject.org A +short

Se essa consulta retornar 127.0.0.2, o IP é um nó de saída Tor ativo.

Limitações

Tor é apenas uma subcategoria das ferramentas de anonimização. Blocklists públicas para proxies abertos em geral são notoriamente voláteis: elas coletam proxies que muitas vezes saem do ar em poucos minutos, o que aumenta a taxa de falsos positivos quando faixas de IP são realocadas.

Step 4: Passive and Active Port Analysis

Proxies frequentemente executam softwares escutando em portas padrão ou auxiliares. Embora fazer uma varredura invasiva de portas contra toda conexão de cliente seja intrusivo, lento e muitas vezes problemático do ponto de vista legal, uma triagem manual durante uma investigação de incidente pode justificar a inspeção de portas comuns.

bash nc -zv -w 2 198.51.100.42 8080 3128 1080 8888 80

• Porta 1080: Porta padrão de proxy SOCKS.
• Porta 3128: Porta padrão do proxy HTTP Squid.
• Portas 8080, 8888: Alternativas comuns para encaminhadores HTTP.

Se a conexão com essas portas retornar um cabeçalho HTTP como Proxy-Agent, Via: 1.1 squid ou encerrar um handshake SOCKS inesperado, o host é um servidor proxy.

Limitações

VPNs comerciais de produção, proxies reversos e daemons de proxy residencial não costumam escutar publicamente nas interfaces voltadas ao cliente. Eles estabelecem túneis reversos de saída para um nó de orquestração, sem deixar portas de entrada expostas.

Manual Checks vs. Reality

| Technique | Primary Signal | Major Blind Spot | | :--- | :--- | :--- | | Reverse DNS | Hostnames de datacenter, PTR ausente | Proxies residenciais se passam por ISPs de consumidores | | ASN Lookup | Classificação de provedor de hospedagem/nuvem | Não sinaliza tráfego encaminhado por sub-redes residenciais | | Tor Exit Lists | Lista determinística de saídas Tor ativas | Não enxerga VPNs, SOCKS e proxies comerciais | | Port Probing | Daemons de proxy expostos, como Squid e SOCKS | Túneis modernos usam conexões reversas de saída |

Step 5: Automated IP Intelligence at Runtime

A inspeção manual funciona bem para triagem depois de um incidente, mas aplicações interativas precisam de checagens em menos de um segundo durante fluxos de autenticação, checkout ou cadastro. Nessa camada, o principal desafio é detectar proxy residencial: identificar quando um IP pertencente a um ISP legítimo de consumidores está executando um túnel de proxy backconnect.

Resolver isso exige agregar anúncios BGP, telemetria de sondagens ativas, honeypots e padrões comportamentais de conexão em uma única consulta. Um serviço de inteligência de IP como o guarda.net consolida esses sinais em uma resposta JSON unificada:

bash curl -s "https://api.guarda.net/v1/ip/198.51.100.42" \ -H "Authorization: Bearer YOUR_API_KEY"

Uma resposta típica retorna classificações booleanas separadas junto com uma pontuação composta de risco:

{ "ip": "198.51.100.42", "is_proxy": true, "is_vpn": false, "is_tor": false, "is_datacenter": true, "asn": { "number": 16276, "org": "OVH SAS" }, "risk_score": 88 }

Usar campos estruturados permite que seu firewall ou o código da aplicação aplique políticas precisas. Por exemplo: bloquear IPs de datacenter durante o cadastro e, ao mesmo tempo, permitir VPNs corporativas; ou exigir uma etapa adicional de autenticação apenas quando is_proxy for true ou quando o risk_score geral ultrapassar um limite definido.

Se você quiser avaliar um IP imediatamente sem configurar scripts, é possível fazer uma consulta gratuita diretamente na página inicial do guarda.net, que já processou mais de 594,400 consultas.