Proxies Residenciais vs. Bloqueio por IP: o Que Funciona

Cerca de um quarto dos nós de saída de proxies residenciais vendidos pelos principais provedores roda em dispositivos cujos donos não fazem ideia de que fazem parte da infraestrutura de alguém. Essa estimativa vem de anos de trabalho acadêmico medindo essas redes, e ela explica muita coisa, inclusive como uma empresa de segurança recentemente encontrou saídas de proxies residenciais dentro de um espaço de IP alocado ao Escritório Executivo do Presidente dos EUA. Quando os pesquisadores notaram esse tráfego, metade dele concentrado entre 17h e meia-noite no horário do Leste dos EUA, a internet fez o que a internet faz. Mas por trás das piadas há uma lição real para o resto de nós: proxies residenciais são a forma mais eficaz de derrubar defesas baseadas em IP, e se o seu modelo de ameaça ainda trata “IP residencial” como sinal de confiança, você está uma geração atrás.

Passei quatro anos cuidando de detecção em uma empresa de SaaS de porte médio, e a mudança era visível em nossos painéis em tempo real. Mais ou menos na época em que as equipes de credential stuffing migraram de proxies de datacenter para saídas residenciais, nossas listas de bloqueio de IP passaram de barrar 80% do tráfego de ataque para quase nada. Mesmos ataques, mesmas ferramentas, outro último salto. Este artigo trata de por que isso acontece e do que realmente funciona quando a reputação de IP deixa de funcionar.

Como os Proxies Residenciais Realmente Funcionam

Um proxy residencial é apenas um nó de saída rodando em um dispositivo de consumo — um celular, uma smart TV, um set-top box, um roteador doméstico. O cliente da rede de proxy paga pelo tráfego que sai desses aparelhos, e o trabalho do provedor é ter milhões deles disponíveis em todas as regiões. A oferta vem de três fontes, em ordem decrescente de respeitabilidade.

1. SDKs com adesão voluntária. Apps gratuitos — VPNs, widgets de previsão do tempo, jogos para celular, apps do tipo “ganhe dinheiro compartilhando sua banda” — embutem um SDK de proxy. O consentimento está enterrado em termos de uso que ninguém lê, mas tecnicamente existe. Esse é o modelo que os grandes provedores citam quando falam de ética.
2. Firmware comprometido e malware. Botnets monetizam há anos a revenda de proxies. Um box de streaming Android barato com firmware suspeito gravado de fábrica já é um nó de proxy no instante em que se conecta. O dono acha que comprou um player de mídia.
3. Aluguel de botnet puro e simples. A ponta mais baixa do mercado nem finge. Se um provedor oferece cinquenta milhões de IPs rotativos sem nenhuma política declarada de origem, basta fazer a conta.

O importante é como isso parece do lado do defensor. O tráfego chega de um ASN residencial da Comcast, da BT ou da Deutsche Telekom. O IP geolocaliza para uma cidade plausível. O DNS reverso retorna algo como pool-96-225-14-7.nycmny.fios.verizon.net. Toda heurística que construímos nos anos 2010 diz que é uma pessoa em casa. Não é. É um relay de US$ 3 por gigabyte, e a pessoa em casa não faz ideia de que ele existe.

Esse último ponto merece destaque, porque é a parte da história que deveria preocupar você mesmo que nunca compre ou combata proxies. O mesmo SDK que repassa banda é um software sob controle remoto de outra pessoa, rodando dentro do perímetro da sua rede. Hoje ele vende banda. Nada na arquitetura impede o operador — ou quem comprometer o operador — de mandar esses nós fazerem algo pior. Um SDK de proxy em um dispositivo dentro de uma rede sensível não é um problema de banda. É um ponto de apoio com departamento de faturamento.

Por Que as Defesas Baseadas em IP Morreram

A reputação de IP fazia sentido quando o abuso vinha de lugares que pareciam abuso: hospedagem à prova de balas, faixas de datacenter sequestradas, proxies abertos em VPS esquecidas. Você podia listar os bairros ruins. Os proxies residenciais encerraram essa era ao levar o tráfego ruim para os bairros bons, uma sala de estar comprometida de cada vez.

A economia piora as coisas. O espaço de IP de datacenter é finito e muito monitorado — queime um /24 e ele estará em todas as listas de bloqueio em um dia. Já os nós de saída residenciais são praticamente infinitos e se regeneram. Uma única campanha de credential stuffing pode rodar por dezenas de milhares de IPs domésticos distintos, cada um fazendo duas ou três requisições, sem nunca estourar os limites de taxa por IP. Seu WAF enxerga dez mil “usuários” diferentes. Bloquear um IP específico não adianta nada; bloquear o ASN inteiro significa bloquear seus clientes reais.

Por isso “o tráfego veio da Casa Branca” precisa de uma ressalva, e os céticos em qualquer discussão sobre essa história têm razão em levantá-la. Ser dono de um espaço de IP não significa que cada anúncio dele corresponda a um único local físico. Grandes organizações anunciam faixas de muitos sites, mantêm redes de convidados, laboratórios e sobreposições de NAT de operadoras. Um IP de saída dentro da faixa de uma organização diz a quem o espaço está registrado, não por qual mesa os pacotes passaram. Quando você fizer essa análise na sua própria rede — e deveria fazer —, trate a atribuição como uma hipótese a ser testada contra logs de fluxo internos, não como conclusão.

Os Sinais de Detecção que Ainda Funcionam

A reputação de IP morreu, mas o tráfego não é invisível. Saídas de proxy têm impressões digitais. Nenhum desses sinais basta sozinho — todos têm explicações legítimas —, mas combinados são surpreendentemente eficazes. Essa é a jogada padrão na engenharia de detecção moderna: parar de procurar uma arma fumegante e começar a construir uma pontuação a partir de sinais fracos. A mesma filosofia aparece na fingerprinting comportamental de scripts ofuscados — você não precisa ler o código se consegue caracterizar como ele se comporta.

Análise de ASN e do formato da conexão

Comece pelo ASN, mas não pare em “é residencial?”. A pergunta útil é se o ASN combina com o cliente que se apresenta. Uma requisição com user agent de Chrome para desktop chegando de uma faixa 5G de consumo de operadora móvel é suspeita. Também é suspeito tráfego de um ASN de provedor residencial atingindo sua API com concorrência de datacenter. Nós de proxy individuais são casas de verdade, e casas de verdade têm limitações reais: upload de banda doméstica, tabelas NAT, compartilhamento de endereços por CGNAT. Um IP de saída que atende quarenta clientes de proxy diferentes em uma hora produz padrões de conexão que nenhuma residência geraria.

Fingerprints de TLS e TCP

É aqui que você pega os operadores descuidados. A maioria dos clientes de proxy passa o tráfego pelo software cliente do provedor ou por bibliotecas HTTP padrão — o requests do Python, o net/http do Go, o Node. Cada uma tem um ClientHello de TLS distinto: ordem de suítes de cifra, listas de extensões, grupos suportados. Os hashes JA3 e JA4 permitem comparar o que o handshake TLS diz que o cliente é com o que o user agent afirma ser. Um “Chrome 126 no Windows” que envia um fingerprint TLS do Go é um bot fantasiado. Algumas redes de proxy sofisticadas fazem passthrough TLS completo a partir da máquina do cliente, o que preserva a mentira — mas muitas não fazem, e até as boas vazam na camada TCP. Um cliente que alega ser Windows, mas tem TTL e tamanho de janela que apontam para Linux, é mais um ponto na pontuação.

Latência e padrões de tempo

Todo proxy residencial adiciona um salto por hardware de consumo em uplinks de consumo. Esse salto tem um custo. Se seu serviço também enxerga a latência real do cliente por meio de WebRTC, de uma medição na borda de CDN ou até da distribuição de tempos das requisições dentro de uma sessão, você pode comparar o RTT da rede com a geografia alegada. Um “usuário em Denver” com RTT de 4 ms até seu datacenter na Virgínia não está em Denver. O tempo dentro das sessões também importa: a navegação humana tem pausas para leitura, movimento de mouse e cadência irregular. Tráfego canalizado por um proxy a partir de um script de automação tem qualidade de metrônomo — intervalos constantes entre requisições, nenhum desvio ocioso, envios de formulário instantâneos. Mesmo quando atacantes adicionam jitter, é um jitter sorteado de uma distribuição que um humano jamais produziria.

Heurísticas comportamentais

O sinal mais forte é o que o cliente faz, não o que ele é. Usuários reais vagueiam. Bots executam planos. Uma sessão que faz login, navega direto para a página de configurações por uma URL à qual nenhum caminho da interface leva, troca o e-mail e envia um pedido de saque em noventa segundos não é uma pessoa, seja qual for o IP. Acompanhe a entropia das sequências: as sessões percorrem sua aplicação do jeito que o seu frontend de fato as conduz, ou atingem endpoints em ordens que só alguém lendo sua documentação de API escolheria? A agregação entre sessões é o grande diferencial aqui. Um IP residencial fazendo três requisições parece inocente. Trezentos IPs residenciais fazendo três requisições cada, com fingerprints TLS idênticos, mesmas resoluções de tela e a mesma sequência de endpoints, são uma única operação com trezentas fantasias.

Caça a Ameaças por SDKs de Proxy na Sua Própria Rede

O problema de entrada recebe a atenção, mas a história que deu início a tudo é, na verdade, uma história de saída: um dispositivo em uma rede que deveria saber das coisas estava repassando o tráfego de outras pessoas. Esse é o cenário em que você pode fazer algo de fato, porque controla o perímetro. Parta do princípio de que algum usuário vai, em algum momento, conectar um box de streaming comprometido ou instalar uma “VPN grátis” em um celular de trabalho. Seu trabalho é fazer esse evento ser barulhento.

A lógica de detecção é direta, porque SDKs de proxy têm uma postura característica. Um nó existe para receber instruções e repassar tráfego, o que significa:

• Conexões persistentes de controle. Sessões TLS de longa duração para domínios ou IPs desconhecidos, muitas vezes com pequenas cargas periódicas. Crie uma linha de base dos seus destinos de saída; um dispositivo cliente mantendo uma conexão de seis horas com um host em um país onde nenhum dos seus fornecedores de software opera merece uma olhada.
• Alto fan-out de conexões a partir de um dispositivo cliente. Uma estação de trabalho que faz conexões de saída para centenas de IPs externos distintos por hora se comporta como infraestrutura, não como uma pessoa. Notebooks navegam; relays repassam.
• Fluxos iniciados de fora para sub-redes de clientes. Muitos frameworks de proxy abrem túneis de entrada ou usam travessia de NAT no estilo STUN. Se um dispositivo na sua VLAN de convidados ou de IoT recebe conexões da internet, algo está muito errado com sua segmentação — encontre o problema.
• Padrões assimétricos de upload. Um celular ou box de TV cujo volume de upload se aproxima do volume de download está servindo conteúdo ou repassando tráfego. Nenhuma das duas coisas é normal para dispositivos de consumo.
• Linhas de base por horário do dia. Os pesquisadores que identificaram as saídas na rede governamental se apoiaram exatamente nisso: atividade concentrada no período da noite sugeria um dispositivo numa rede pessoal, não de convidados. Sua versão própria é mais simples — alerte quando o padrão de tráfego de um dispositivo mudar de caráter, não apenas de volume.

Nada disso exige inspeção profunda de pacotes, o que importa se você se preocupa em operar uma rede em que as pessoas possam confiar. Metadados de fluxo — NetFlow, logs de conexão do Zeek, logs de fluxo de VPC — carregam todos os sinais acima. Se você ainda não retém e não cria linhas de base dos dados de fluxo de saída, essa é a lacuna a fechar antes de comprar qualquer coisa. Os pontos cegos aqui rimam com os da geração de logs de autenticação em nuvem: os dados existem, mas ninguém olha para eles até que haja um incidente.

# Quick-and-dirty hunt: client devices acting like relays
# Feed this Zeek-style conn logs; flag RFC1918 sources with
# high distinct-destination fan-out and heavy upload ratios.
awk -F'\t' '
$3 ~ /^(10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01]))/ {
src=$3; dst=$5
up[src]+=$10; down[src]+=$12
seen[src SUBSEP dst]=1
}
END {
for (k in seen) { split(k,a,SUBSEP); fanout[a[1]]++ }
for (s in fanout)
if (fanout[s] > 200 && up[s] > down[s] * 0.5)
printf "%s dsts=%d up=%d down=%d\n", s, fanout[s], up[s], down[s]
}' conn.log | sort -t= -k2 -nr | head -20

Isso é uma primeira versão, não um produto acabado — ajuste o limiar de fan-out com base nas suas próprias linhas de base e espere falsos positivos dos seus servidores de mídia e agentes de backup até colocá-los na lista de permissões. O ponto é que a caça é barata. Uma tarde de análise de logs encontra o que um equipamento de seis dígitos encontraria.

A Segmentação É a Solução Real

Aqui vai minha opinião forte, formada da forma difícil: você nunca vai vencer a corrida armamentista da detecção contra dispositivos de consumo comprometidos. A oferta é grande demais, e os fabricantes que enviam firmware inseguro não sofrem consequências. O que você pode fazer é tornar um dispositivo comprometido entediante. Um box de streaming infectado em uma VLAN de IoT bem segmentada pode vender sua banda para uma rede de proxy — irritante, potencialmente constrangedor se a sua faixa de IP for sensível —, mas não consegue alcançar seus compartilhamentos de arquivos, suas APIs internas ou qualquer coisa que transformaria um constrangimento em uma violação.

O padrão é sempre o mesmo nas análises pós-incidente. A organização tinha uma rede plana, ou uma rede de “convidados” que alcançava o DNS interno e as interfaces de gerenciamento, ou uma política de traga seu próprio dispositivo imposta apenas por um termo aceito com um clique. Então um box Android barato ou um celular com um SDK embutido entrou na rede, e o IP de saída da organização começou a aparecer em inventários de provedores de proxy. A correção depois do fato é aquilo que deveria ter sido feito antes: isolamento de clientes nas redes de convidados, dispositivos de IoT em uma VLAN com acesso somente de saída e destinos RFC1918 negados, dispositivos pessoais bem longe das zonas de confiança de produção. Defesa em profundidade não é glamorosa, mas, como argumentamos no contexto de defesas em camadas versus controles únicos e fortes, são as camadas que salvam você quando qualquer controle falha — e sempre há um que falha.

Também vale uma conversa interna sobre política. Apps “gratuitos” são como esses SDKs chegam. Se sua equipe pode instalar softwares arbitrários em dispositivos que tocam sua rede, você terceirizou seu perímetro para empresas de ad-tech mobile. Algumas organizações respondem com MDM e listas de permissão de apps; para a maioria, a segmentação de rede alcança a mesma contenção com menos custo político.

O Que Essa História Realmente Nos Ensina

Descontando a especulação política, a história é uma demonstração clara de dois fatos. Primeiro, a detecção de proxies residenciais amadureceu e virou uma categoria de produto — pesquisadores agora conseguem enumerar nós de saída em escala e mapeá-los para espaços de IP, o que é telemetria genuinamente útil. Segundo, e mais desconfortável, toda rede está a uma compra descuidada de dispositivo de distância de ser infraestrutura de outra pessoa. As redes mais protegidas do mundo ainda têm humanos dentro delas, e humanos plugam coisas.

Se você levar uma coisa disso: verifique se os IPs de saída da sua própria organização aparecem em inventários de proxies residenciais. Vários serviços dizem isso, e seu feed de threat intel pode já incluir essa informação. Encontrar sua faixa listada não é prova de comprometimento — CGNAT e espaço de endereços compartilhado turvam o quadro —, mas é um ponto de partida barato e de alto sinal para uma caça. Depois, olhe para o seu fan-out de saída, suas conexões de longa duração e o desenho das suas VLANs.

Os atacantes se mudaram para os bairros bons anos atrás. Os defensores que perceberam isso são os que pararam de checar endereços e começaram a observar comportamentos.