Prevenção de fraudeComo impedir cadastros falsos: detecção de contas falsas por tipo de IP
Impeça cadastros falsos por tipo de IP: sete consultas reais de 2 de novembro de 2026, a ação de cadastro que cada uma recebe e limites de velocidade por /24 e /64 para o seu próprio código.
A Okta Threat Intelligence descreveu um serviço de vídeo com IA cujo teste gratuito atraiu uma enxurrada de tentativas de cadastro falso. Nos logs de um cliente, "Entre 1º de junho de 2026 e 1º de julho de 2026, os logs mostram mais de 105.000 tentativas de cadastro por força bruta a partir de 251 IPs distintos, provavelmente ligados a bots." Os registros "estavam ligados a provedores de proxy e VPNs". Pelas contas do GeoIPHub sobre os números da Okta, isso dá cerca de 418 tentativas por endereço ao longo do mês, ou cerca de 14 por dia, então um limite de alguns cadastros por IP por hora pode nunca ser acionado.
A parte difícil é que cadastros falsos e clientes reais compartilham as mesmas redes. Pessoas reais também usam VPNs e desktops em nuvem, e os endereços que pessoas reais compartilham, como iCloud Private Relay, operadoras móveis e NAT de nível de operadora, parecem movimentados por natureza. Uma regra que só bloqueia vai deixar o pool entrar ou trancar clientes do lado de fora.
A seguir: sete endereços de onde um cadastro pode vir, o que a API de consulta de IP do GeoIPHub retornou para cada um em 2 de novembro de 2026 e o que faríamos no formulário, por que endereços compartilhados nunca devem ser recusados apenas pela pontuação, limites de velocidade com código testado e o que o IP não consegue ver.
O que a detecção de contas falsas verifica no cadastro, e o único sinal que você sempre tem
A detecção de contas falsas pontua cada novo cadastro em rede, velocidade, e-mail, telefone, dispositivo e comportamento. No momento em que o formulário é enviado, o IP é o único desses sinais que o seu servidor sempre tem sem pedir nada ao usuário, e é por isso que uma pontuação de fraude de IP costuma ser a primeira verificação.
A OWASP chama o ataque de OAT-019 Account Creation: "Criação de contas em massa, e às vezes preenchimento de perfis, usando os processos de cadastro de contas da aplicação." A criação de contas falsas raramente é o objetivo; é a preparação para farming de promoções e indicações, para um único operador por trás de muitas contas burlando um banimento ou para montar campanhas de credential stuffing.
A fraude em cadastros é comum o bastante para entrar no planejamento. O Customer Identity Trends Report 2025 da Okta, baseado na sua plataforma Auth0, diz: "Em 2024, em média 46% de todas as tentativas de registro na plataforma Auth0 foram identificadas como ataques de cadastro." A Stripe, ao anunciar o Sessions 2026 em 29 de abril de 2026, apresentou o número da própria rede assim: "Nos serviços de IA que rodam na Stripe, um em cada seis cadastros tentados é feito por um agente mal-intencionado."
Veja do que cada camada precisa e quais delas uma consulta de IP consegue responder:
| Camada | Exemplos | Uma consulta de IP consegue ver? |
|---|---|---|
| Rede | Saída Tor, servidor VPN, servidor em nuvem, relay, operadora móvel | Sim |
| Velocidade | Cadastros por endereço, prefixo ou rede em uma hora ou um dia | Apenas as chaves; a contagem é feita pelo seu código |
| Domínios descartáveis, variantes com sinal de mais e com pontos | Não | |
| Telefone | Números VoIP, números reciclados | Não |
| Dispositivo | Características de navegador e hardware que se repetem entre contas | Não; veja fingerprinting de dispositivos |
| Comportamento | Velocidade de preenchimento do formulário, copiar e colar, movimento do mouse | Não |
A linha de dispositivo é outra ferramenta; nossa comparação entre fingerprinting de dispositivos e dados de IP explica como os dois se combinam.
Sete IPs de cadastro, sete decisões: o que o GeoIPHub retornou em 2 de novembro de 2026
O GeoIPHub consultou sete endereços de onde um cadastro pode vir entre 04:51 e 04:52 UTC de 2 de novembro de 2026. Aqui estão a pontuação, os motivos e o que faríamos no formulário, usando a linha de cadastro dos limites iniciais de pontuação de fraude do GeoIPHub. As duas últimas linhas são regras da nossa configuração de pontuação, não consultas.
| Endereço | O que é | Pontuação, ação | detection_methods | No cadastro |
|---|---|---|---|---|
| 185.220.101.1 | Saída Tor, também em zen.spamhaus.org | 100, block | tor_exit, datacenter_blocklisted, no_ptr_datacenter, known_spammer | Recusar |
| 185.213.155.73 | Servidor VPN; vpn_provider indica Mullvad | 100, block | known_vpn_server, wireguard_open, datacenter_with_vpn_proxy, no_ptr_datacenter | Recusar por padrão; verificar em vez disso se os seus usuários usam VPN e nenhum motivo de abuso foi acionado |
| 45.83.220.7 | Endereço da rede VPN da Mullvad, vpn_provider "Mullvad (31173 Services)" | 46, review | known_vpn_server, datacenter_ip | Criar, restringir, marcar |
| 45.33.32.156 | scanme.nmap.org, um servidor em nuvem da Linode | 10, allow | datacenter_ip | Permitir; contar por rede de hospedagem |
| 104.28.46.99 | Saída do iCloud Private Relay | 9, allow | relay_ip | Permitir; limites de velocidade mais folgados |
| 66.249.66.1 | Googlebot verificado (crawler.operator Google) | 0, allow | datacenter_ip, verified_crawler | Sem conta: um rastreador não se cadastra |
| 162.142.125.10 | Scanner da internet Censys (is_scanner verdadeiro) | 0, allow | Nenhum motivo retornado | Sem conta |
| Qualquer endereço de CGNAT | Regra da nossa configuração de pontuação, não uma consulta | Teto de 50 | O teto só é removido com evidência própria do endereço de VPN, proxy, Tor, protocolo, botnet ou abuso | Nunca recusar pela pontuação |
| Qualquer endereço de operadora móvel | Regra da nossa configuração de pontuação, não uma consulta | Reduzida em 12 | mobile_carrier, quando não há evidência de ameaça | Nunca recusar pela pontuação |
Os dois 100 parecem idênticos, mas não são. A saída Tor carrega histórico de spam; o servidor VPN carrega apenas motivos de anonimato, sem nenhuma evidência de abuso. Essa diferença decide se um cadastro via VPN é recusado ou verificado.
O próprio recommended_action da API só bloqueia acima de 75. Os limites iniciais de cadastro do GeoIPHub bloqueiam a partir de 71, e nenhuma linha em 2 de novembro de 2026 ficou entre as duas linhas.
A banda larga doméstica não tem linha, porque não publicamos endereços residenciais. A pontuação do GeoIPHub só dá o desconto residencial a uma linha doméstica quando o endereço tem um nome de DNS reverso com padrão residencial, então uma linha doméstica sem ele não recebe desconto residencial, e qualquer motivo de ameaça conta integralmente.
Leia os motivos, não o número: um cadastro rastreado de ponta a ponta
A pontuação diz quão arriscado é um endereço; scoring.detection_methods diz por quê, e o porquê decide entre restringir, verificar e recusar. Aqui está a resposta reduzida para 45.83.220.7, consultado às 04:51:58 UTC de 2 de novembro de 2026:
{
"ip": "45.83.220.7",
"asn": {
"asn": 39351,
"org": "ESAB-AS - 31173 Services AB",
"connection_type": "datacenter"
},
"detection": {
"is_vpn": true,
"is_hosting": true,
"is_relay": false,
"is_mobile": false,
"vpn_provider": "Mullvad (31173 Services)"
},
"threat": { "is_cgnat": false },
"scoring": {
"fraud_score": 46,
"recommended_action": "review",
"detection_methods": ["known_vpn_server", "datacenter_ip"]
}
}
Dois motivos foram acionados. known_vpn_server soma 36 (40 pontos com confiança de 0,9) e datacenter_ip soma 10 (20 com 0,5), então a pontuação é 46. Isso cai na faixa de 26 a 50 dos limites iniciais de cadastro do GeoIPHub: criar e marcar. Criaríamos a conta em estado restrito, sem créditos de teste nem bônus até o e-mail ser confirmado. Como detection.is_hosting é verdadeiro, o cadastro também conta contra o AS39351 na verificação de velocidade abaixo. No primeiro evento de valor, como o início de um teste ou a concessão de créditos, consulte o IP novamente.
O servidor da Mullvad em 185.213.155.73 obteve 100 block, e todos os seus quatro motivos são sobre anonimato, não abuso. O padrão no cadastro é recusá-lo. Produtos cujos usuários reais usam VPN podem escrever regras com base nos motivos e enviar um 100 como este, com motivos de anonimato e nenhum motivo de abuso, para verificação por e-mail ou telefone. Uma VPN sozinha é uma escolha de privacidade, e as pessoas que ela protege costumam ser as que são sinalizadas por engano. Uma saída Tor com histórico de spam continua recusada em qualquer caso.
Uma pontuação 0 não é aprovação: rastreadores e scanners no seu formulário de cadastro
Os dois resultados mais amigáveis nas consultas do GeoIPHub de 2 de novembro de 2026, o Googlebot verificado em 66.249.66.1 e o scanner Censys em 162.142.125.10, obtiveram 0 allow, e são justamente os dois que nunca deveriam criar uma conta. Isso nos surpreendeu mais do que qualquer 100.
O motivo verified_crawler do GeoIPHub subtrai 28,5, então um rastreador verificado fica no fundo da escala. Isso está certo para rastreamento e errado para um POST de formulário. Se threat.crawler.verified for verdadeiro em uma requisição de cadastro, não crie a conta. Leia crawler.verified e crawler.operator para isso, nunca crawler.name.
threat.is_scanner não entra na pontuação: o endereço da Censys não retornou nenhum motivo. Verifique o indicador diretamente e recuse o cadastro quando ele for verdadeiro.
Nunca recuse um endereço compartilhado apenas pela pontuação: relays, CGNAT e redes móveis
Uma saída do iCloud Private Relay, um endereço de NAT de nível de operadora ou um gateway móvel pode atender muitas pessoas reais. A pontuação do GeoIPHub limita endereços de relay a 60 e endereços de CGNAT a 50, a menos que o endereço tenha evidência própria de ameaça, e dá desconto a endereços móveis limpos, enquanto um endereço móvel com evidência de ameaça recebe uma penalidade. Suas regras devem manter esses endereços fora da faixa de bloqueio, a menos que tenham evidência própria.
Na pontuação do GeoIPHub, relay_ip soma 8,5 e não há desconto para relay, então a nossa amostra de relay obteve 9. O teto de CGNAT só é removido com evidência própria do endereço de VPN, proxy, Tor, protocolo, botnet ou abuso. Endereços de operadoras móveis recebem mobile_carrier, que reduz a pontuação em 12 quando não há evidência de ameaça.
Nada disso significa "confiar". Significa que o IP sozinho não consegue separar o único agente mal-intencionado dos muitos clientes por trás do mesmo endereço. Então desafie esses cadastros, nunca os recuse pela pontuação e dê a eles dez vezes os limites de velocidade habituais. Para o Private Relay especificamente, a recomendação é deixá-los passar e pontuar a sessão com base no que a conta faz em seguida.
Conte cadastros por IP, /24, /64 de IPv6 e rede de hospedagem no seu próprio código
A API do GeoIPHub pontua um endereço; ela não conta quantas contas aquele endereço, seu /24, seu /64 ou sua rede criaram nas últimas 24 horas. Esse contador fica no seu código, e a consulta diz quais chaves usar: asn.asn, detection.is_hosting, detection.is_relay, detection.is_mobile, asn.connection_type e threat.is_cgnat.
No caso do serviço de vídeo com IA da Okta, as tentativas de cadastro falso tiveram média de cerca de 14 por endereço por dia, distribuídas por 251 endereços. Um contador apenas por IP pode nunca ser acionado nesse cenário. Os contadores por prefixo e por rede existem exatamente para esse caso.
Estes são pontos de partida que escolhemos, não referências do setor; ajuste-os com base nos seus próprios cadastros.
| Chave | Janela | Limite inicial | Observações |
|---|---|---|---|
| Endereço IPv4 exato | 1 hora | 3 | |
| /24 de IPv4 | 1 hora | 10 | Pega um pool que rotaciona dentro de um bloco |
| /64 de IPv6 | 1 hora | 3 | Trate um /64 como um único endereço IPv4; amplie para /56 ou /48 quando novos /64 continuarem chegando de uma mesma alocação |
| ASN, apenas hospedagem (detection.is_hosting verdadeiro) | 24 horas | 20 | Clientes reais raramente se cadastram a partir de um servidor em nuvem |
| Endereços compartilhados (relay, CGNAT ou móvel) | Mesmas janelas | Dez vezes os limites de IP e de prefixo | Nunca bloquear apenas pela velocidade |
Passar do limite significa verificação adicional (por e-mail ou telefone, ou um CAPTCHA) ou criação restrita, não recusa. Em IPv6, conte o prefixo, nunca o endereço completo, ou um único agente vira milhares de cadastros "diferentes". Residências costumam receber um /56 ou /48, e é por isso que a tabela amplia; nosso guia sobre limitar a taxa de IPv6 por prefixo cobre os tamanhos de alocação.
O código abaixo roda no Node 18 ou posterior, sem dependências. Ele espera o endereço do cliente como o Node o informa, incluindo formas IPv4 mapeadas como ::ffff:192.0.2.1, depois que você o extrai da sua cadeia de proxies confiáveis. Ele usa janelas fixas, uma simplificação de uma janela deslizante.
// Signup velocity keys: exact IP, IPv4 /24, IPv6 /64, and ASN for hosting.
// Starting limits, not benchmarks. Tune them on your own signups.
import { isIPv4, isIPv6 } from "node:net";
const HOUR = 3600e3, DAY = 24 * HOUR;
const LIMITS = {
ip: { window: HOUR, max: 3 }, // one IPv4 address, or one IPv6 /64
v4_24: { window: HOUR, max: 10 },
asn: { window: DAY, max: 20 }, // hosting networks only
};
const SHARED_FACTOR = 10; // relay, CGNAT and mobile egress
function expandIPv6(addr) {
const [head, tail = ""] = addr.toLowerCase().split("::");
const h = head ? head.split(":") : [];
const t = tail ? tail.split(":") : [];
const fill = addr.includes("::") ? 8 - h.length - t.length : 0;
return [...h, ...Array(fill).fill("0"), ...t].map((g) => g.padStart(4, "0"));
}
export function velocityKeys(ip, lookup) {
const keys = [];
const m = ip.match(/^(?:::|(?:0{1,4}:){5})ffff:(\d+\.\d+\.\d+\.\d+)$/i);
const v4 = m && isIPv4(m[1]) ? m[1] : ip;
if (isIPv4(v4)) {
keys.push(["ip", v4], ["v4_24", v4.split(".").slice(0, 3).join(".") + ".0/24"]);
} else if (isIPv6(ip)) {
keys.push(["ip", expandIPv6(ip).slice(0, 4).join(":") + "::/64"]);
}
const asn = lookup?.asn;
if (lookup?.detection?.is_hosting && asn?.asn) keys.push(["asn", `AS${asn.asn}`]);
return keys;
}
const counters = new Map(); // in-memory and unbounded; for a demo only; use Redis INCR + EXPIRE in production
export function checkVelocity(ip, lookup, now = Date.now()) {
const shared = Boolean(
lookup?.detection?.is_relay || lookup?.threat?.is_cgnat ||
lookup?.detection?.is_mobile || lookup?.asn?.connection_type === "mobile");
const hits = [];
for (const [level, value] of velocityKeys(ip, lookup)) {
const { window, max } = LIMITS[level];
const limit = shared && level !== "asn" ? max * SHARED_FACTOR : max;
const key = `${level}:${value}:${Math.floor(now / window)}`;
const count = (counters.get(key) ?? 0) + 1;
counters.set(key, count);
if (count > limit) hits.push({ level, value, count, limit });
}
return { overLimit: hits.length > 0, hits }; // over the limit: step up, don't block
}
Rodamos 16 testes unitários contra exatamente este código em 2 de novembro de 2026, no Node 24.20.0, usando faixas de endereços de documentação e privadas, além do endereço do scanme.nmap.org da tabela, sem consultas. Todos os 16 passaram: formas IPv4 mapeadas como ::ffff:45.33.32.156 foram tratadas como IPv4, a rotação dentro de um /64 foi acionada no 4º cadastro, 11 endereços em um mesmo /24 acionaram apenas a chave /24, e 30 cadastros de uma mesma saída de relay passaram enquanto o 31º foi sinalizado. Uma consulta que falha (null) ainda produz as chaves de IP e de prefixo, então o contador continua funcionando quando a API não responde.
Onde a camada de IP fica cega
Uma consulta de IP não consegue ver uma conta falsa criada a partir de uma conexão doméstica alugada ou de um celular real, e nunca vê o e-mail, o dispositivo nem como o formulário foi preenchido.
Os proxies residenciais são a lacuna mais clara. O GeoIPHub sinaliza proxies que observamos em linhas residenciais e móveis, incluindo endereços que uma lista de terceiros relata como relays, mas não temos detecção própria de proxies residenciais, e uma linha doméstica limpa pode passar. Fazendas de cliques e fazendas de dispositivos rodando em chips SIM reais parecem clientes móveis, e a nossa pontuação trata clientes móveis com suavidade de propósito.
O GeoIPHub pontua o IP; ele não verifica endereços de e-mail nem números de telefone. Combine a verificação de IP com suas próprias verificações de e-mail (domínios descartáveis, normalização de sinal de mais e de pontos), verificação de telefone, sinais de dispositivo e agrupamento de contas que compartilham chaves depois do cadastro.
O estado restrito é o que torna a faixa intermediária barata de operar. Crie a conta, retenha os créditos e libere-os depois da verificação ou da primeira ação real. Uma conta falsa que nunca é verificada custa a você uma linha no banco de dados, não um período de teste.
Como impedir cadastros falsos antes de a conta existir
A verificação inteira é uma consulta e uma contagem de velocidade entre "enviar" e "criar", nesta ordem:
- Obtenha o IP do cliente a partir da sua cadeia de proxies confiáveis, não de um cabeçalho
X-Forwarded-Forbruto, que o cliente pode definir como quiser. - Consulte o IP.
- Recuse saídas Tor, rastreadores verificados e scanners. Recuse por padrão um servidor VPN com 100 ou envie-o para verificação se os seus usuários usam VPN e nenhum motivo de abuso foi acionado. Nunca recuse endereços de relay, CGNAT ou móveis pela pontuação. Aplique os limites iniciais de cadastro do GeoIPHub a todo o resto.
- Rode a verificação de velocidade e exija verificação adicional quando houver um acerto.
- Se a consulta falhar, recorra à verificação de velocidade e à confirmação de e-mail; não recuse.
- Armazene a pontuação, os motivos e o horário da consulta com a conta e consulte o IP novamente no primeiro evento de valor (início do teste, concessão de créditos, primeiro pagamento).
Nossa integração testada em Node e Python mostra as etapas 2 e 3 como código funcional. O plano gratuito do GeoIPHub cobre 1.500 consultas por dia com todos os campos incluídos.
Cole os últimos dez IPs do seu log de cadastros no verificador de pontuação de fraude de IP e distribua-os nas linhas da tabela. A pontuação diz o que cada endereço é; o contador diz quantas contas ele criou.
Perguntas frequentes
Como impedir cadastros falsos sem bloquear usuários reais?
Consulte o IP de cada cadastro com a API do GeoIPHub antes de criar a conta. Recuse saídas Tor e as pontuações mais altas, verifique a faixa intermediária por e-mail ou telefone e deixe passar endereços compartilhados, como iCloud Private Relay, NAT de nível de operadora e gateways móveis, com limites de velocidade mais folgados, porque um desses endereços pode atender muitos clientes reais.
Quão comum é a fraude em cadastros?
Na plataforma Auth0 da Okta, em média 46% das tentativas de registro em 2024 foram identificadas como ataques de cadastro. A Stripe disse em abril de 2026 que um em cada seis cadastros tentados em serviços de IA na sua rede é feito por um agente mal-intencionado. Ambos são números de fornecedores sobre as próprias plataformas.
Um endereço IP sozinho consegue detectar contas falsas?
Não. Uma consulta de IP mostra de que tipo de rede veio o cadastro e por que ele recebeu aquela pontuação, mas não vê o e-mail, o telefone, o dispositivo nem uma conta falsa criada a partir de uma conexão doméstica alugada. Use-a como primeira camada e combine-a com verificações de e-mail, telefone e dispositivo.
O GeoIPHub verifica endereços de e-mail?
Não. A API do GeoIPHub pontua apenas o endereço IP. Verifique e-mail e telefone com suas próprias ferramentas e combine esses resultados com a pontuação e os motivos do GeoIPHub.
Um usuário de VPN deve poder se cadastrar?
Muitas vezes, sim. Uma VPN, por si só, é uma escolha de privacidade, então você pode enviar cadastros vindos de VPN para verificação por e-mail ou telefone em vez de recusá-los e reservar bloqueios diretos para saídas Tor e endereços com histórico de spam ou abuso.
Como devo limitar a taxa de cadastros em IPv6?
Conte por /64, não por endereço, porque um único assinante pode rotacionar por um /64 inteiro. Amplie para /56 ou /48 quando novos /64 da mesma alocação continuarem chegando e mantenha limites mais folgados em operadoras móveis.
A equipe por trás da API do GeoIPHub
Escrito pela equipe do GeoIPHub, as pessoas que constroem a API de inteligência de IP do GeoIPHub e seu scanner. Os rascunhos são preparados com auxílio de IA e editados pela equipe; os exemplos de API são consultas reais à API em produção, salvo quando indicados como ilustrativos.
