Pular para o conteúdo
Prevenção de fraude

A partir de qual pontuação de fraude de IP você deve bloquear?

Limites de pontuação de fraude de IP para login, cadastro e checkout, testados em cinco IPs reais: uma pontuação, três ações, e por que um usuário de relay ou CGNAT nunca chega ao bloqueio.

PorEquipe GeoIPHubPublicadoAtualizadoTempo de leitura12 min de leitura
Três portais luminosos com soleiras de luz em alturas diferentes, representando limites de pontuação de fraude para login, cadastro e checkout

Não existe um único limite de pontuação de fraude de IP para bloquear: a mesma pontuação pode aprovar um login, marcar um cadastro para revisão e enviar um checkout para o 3-D Secure. A escala de 0 a 100 do GeoIPHub tem como padrão permitir até 25, revisar até 50, exigir verificação adicional até 75 e bloquear acima de 75, e este guia ajusta essas linhas por ação, com testes em cinco endereços públicos em 22 de outubro de 2026.

Uma faixa dividida em quatro zonas, do azul ao índigo, com um marcador em uma das fronteiras, representando as faixas de permitir, revisar, verificação adicional e bloquear
Permitir, revisar, verificar, bloquear: o limite certo depende da porta.

Uma pontuação, três portas: cinco IPs que passamos pelos limites

O mesmo veredito da API tem efeitos diferentes em cada porta, e dois tetos de pontuação decidem até onde um endereço compartilhado pode chegar. Às 04:56 UTC de 22 de outubro de 2026, consultamos cinco endereços públicos com a API sem chave e mapeamos cada resultado para os limites iniciais da próxima seção. As duas últimas linhas não são consultas. São os tetos definidos na nossa configuração de pontuação.

EndereçoO que éPontuação, açãoLoginCadastroCheckout
185.220.101.1Saída Tor, TORSERVERS-NET, Hamburgo100, blockBloquearBloquearBloquear
185.213.155.73Servidor VPN da Mullvad, Frankfurt, na própria lista da Mullvad100, blockBloquear, ou MFA conforme a políticaBloquearBloquear
5.39.1.230AhrefsBot verificado na OVH, listado no Spamhaus ZEN35, reviewEntrar, registrar o motivoCriar, marcar para revisão3-D Secure
104.28.46.99Saída do iCloud Private Relay na Cloudflare9, allowPermitirPermitirPermitir
45.33.32.156scanme.nmap.org, um servidor Linode10, allowPermitirPermitirPermitir
Qualquer endereço do Private RelayTeto de relayNo máximo 60No máximo MFANo máximo verificaçãoNo máximo 3-D Secure
Qualquer endereço de CGNATTeto de NAT de nível de operadoraNo máximo 50Entrar, registrarNo máximo marcar para revisãoNo máximo 3-D Secure

Quatro pontos dessa tabela merecem ação.

  • Os dois 100 têm motivos diferentes. Os métodos da saída Tor são tor_exit, datacenter_blocklisted, no_ptr_datacenter e known_spammer: um anonimizador com histórico de spam. Os do servidor da Mullvad são known_vpn_server, wireguard_open, datacenter_with_vpn_proxy e no_ptr_datacenter, com threat.is_spammer falso e nenhuma entrada em lista de bloqueio de DNS. Se os seus clientes usam VPN, uma regra de login que transforma um bloqueio motivado apenas por VPN em MFA é defensável, e ela nunca seria acionada para a saída Tor.
  • A linha do meio é onde os limites por ação mostram seu valor. O AhrefsBot com 35 passa no login, é marcado no cadastro e vai para o 3-D Secure no checkout. Ainda assim, um rastreador de SEO verificado não tem motivo para enviar nenhum desses formulários, e a pontuação sozinha não diz isso.
  • Essa linha do meio mudou em duas semanas. O mesmo endereço obteve 23 em 8 de outubro e 59, step_up, em 19 de outubro, com abusive_listed entre os métodos. Em 22 de outubro esse método havia sumido e a pontuação era 35, então o login caiu de MFA para uma entrada simples. Analisamos esse endereço em detalhes em como investigar um endereço IP. Armazene a pontuação, os métodos e a data com cada decisão e refaça a consulta antes de agir com base em um veredito antigo.
  • Endereços compartilhados não chegam ao bloqueio. O Private Relay tem teto de 60 (relay_max_score), então nunca pode cruzar a linha de bloqueio padrão de 76. O CGNAT tem teto de 50 (cgnat_max_score), o topo da faixa de revisão. Nossa linha de bloqueio mais rígida, 66 no checkout, fica acima dos dois de propósito. Com 60 ou menos, um usuário de relay com pontuação no teto poderia ser recusado por compartilhar um endereço.

As duas linhas de permissão mostram que a pontuação é aditiva. O sinal relay_ip do relay vale 10 pontos com confiança de 0,85, o que arredonda para 9. O datacenter_ip do servidor Linode vale 20 pontos com 0,5, o que dá 10. Hospedagem é motivo para olhar com atenção, não para bloquear, e relays devem passar, como explicamos em como detectar tráfego do Private Relay e do WARP.

Limites iniciais de pontuação de fraude de IP para login, cadastro e checkout

Os limites iniciais apertam a linha de bloqueio à medida que aumenta o custo de uma permissão errada: 76 no login, 71 no cadastro, 66 no checkout. Trate-os como pontos de partida e ajuste-os com os seus próprios dados de fraude.

AçãoPermitirRevisar ou verificação adicionalBloquearPor quê
Login0 a 50, registrar de 26 a 5051 a 75: exigir MFA76 ou maisA senha e o MFA ainda protegem a sessão
Cadastro0 a 2526 a 50: criar e marcar; 51 a 70: verificar e-mail ou telefone71 ou maisContas falsas são baratas de criar
Checkout0 a 2526 a 65: 3-D Secure66 ou maisUma permissão errada vira chargeback
API ou leitura0 a 6970 a 84: limitar a taxa85 ou maisIntegrações rodam a partir de servidores em nuvem

Combine a pontuação com algumas regras sobre os sinais para os casos claros:

  • Bloqueie qualquer ação quando detection.is_tor for verdadeiro. Esse é o único caso em que o motivo sozinho justifica uma recusa.
  • Nunca faça bloqueio rígido pela pontuação quando detection.is_relay ou threat.is_cgnat for verdadeiro. Os tetos já garantem isso aqui; a regra protege você caso alguém reduza uma linha de bloqueio no futuro.
  • No checkout, trate review como step_up. Nosso tutorial da API de detecção de fraude de IP traz código testado em Node e Python exatamente para essa substituição, além de tratamento tolerante a falhas quando uma consulta excede o tempo limite.

Para ver o que cada tipo de endereço retorna no cadastro, e os limites de velocidade por prefixo que capturam o que uma pontuação deixa passar, leia detecção de contas falsas no cadastro.

Para entender o que cada faixa significa e como uma única pontuação é construída, comece por como interpretar uma pontuação de fraude de IP.

Uma saída Tor obtém 100, e os métodos dizem por quê

Aqui está uma cópia reduzida da resposta real para 185.220.101.1, consultada às 04:56 UTC de 22 de outubro de 2026:

GeoIPHub API
curl "https://api.geoiphub.com/v1/lookup/185.220.101.1" \ -H "x-api-key: YOUR_API_KEY"
GeoIPHub API
{ "ip": "185.220.101.1", "asn": { "asn": 60729, "org": "TORSERVERS-NET - Stiftung Erneuerbare Freiheit", "asn_type": "hosting", "connection_type": "datacenter" }, "detection": { "is_proxy": false, "is_vpn": false, "is_tor": true, "is_hosting": true, "is_anonymous": true, "anonymity_level": "high" }, "threat": { "is_spammer": true, "threat_types": ["spammer", "tor"], "dnsbl_sources": ["zen.spamhaus.org"] }, "scoring": { "fraud_score": 100, "recommended_action": "block", "detection_methods": ["tor_exit", "datacenter_blocklisted", "no_ptr_datacenter", "known_spammer"] } }

Um fraud_score de 100 ultrapassa todas as linhas de bloqueio da tabela, então login, cadastro e checkout recusam essa requisição. Três motivos bastam sozinhos para chegar lá: tor_exit (45 pontos com 0,99), known_spammer (40 com 0,9) e datacenter_blocklisted (30 com 0,75) somam 103 antes do teto de 100. detection.is_vpn é false, porque o Tor é sinalizado separadamente, então você pode bloquear de forma rígida detection.is_tor e continuar desafiando usuários comuns de VPN.

O quarto motivo é uma falha do nosso lado. no_ptr_datacenter diz que o endereço não tem DNS reverso, mas dig -x 185.220.101.1 retornou um hostname de saída Tor às 04:57 UTC daquela manhã. Nosso banco de dados não tem esse registro armazenado, e a correção está registrada. O veredito se sustenta nos outros três sinais, mas é um bom motivo para escrever regras com base em sinais em que você confia, e não no total bruto.

Por que um único limite global falha

Um único limite falha porque cada endpoint enfrenta um ataque diferente. As páginas de login absorvem credential stuffing: o Verizon DBIR 2025 constatou que ele representou uma mediana de 19% de todas as tentativas de autenticação por dia, e 44% no pior dia. Os checkouts enfrentam teste de cartões e os cadastros enfrentam contas falsas. E, em 2 de dezembro de 2025, humanos geraram apenas 47% das requisições HTML, segundo o Cloudflare Radar 2025 Year in Review.

Sistemas maduros já atuam em faixas. A pontuação de bots da Cloudflare vai de 1 a 99, e os clientes escrevem regras para bloquear, desafiar ou permitir com base nela (pontuações de bots da Cloudflare). A OWASP diz que o bloqueio de IP "não deve ser usado como a única defesa nem como a principal, devido à facilidade de contorná-lo" (OWASP Credential Stuffing Cheat Sheet). A mesma página cita a análise da Microsoft segundo a qual o MFA teria impedido 99,9% dos comprometimentos de conta. Isso torna a faixa de verificação adicional no login um seguro barato. O NIST SP 800-63B diz que uma geolocalização ou um bloco de endereços IP inesperado "pode motivar o uso de controles adicionais baseados em risco" e não "substitui um fator de autenticação" (NIST SP 800-63B).

O GeoIPHub constrói sua pontuação de risco explicável de 0 a 100 a partir de 36 motivos ponderados e nomeia cada um que foi acionado em scoring.detection_methods. Alguns reduzem a pontuação: um motivo de ISP residencial tira 17 pontos (menos 20 com confiança de 0,85) e um rastreador verificado tira 28,5 (menos 30 com 0,95).

Um limite baixo pune endereços compartilhados e privados

Uma linha de bloqueio definida baixa "por segurança" recusa clientes que compartilham ou ocultam o endereço por motivos comuns:

  • Usuários de VPN. No relatório de VPN de 2026 da Security.org, uma pesquisa com 1.008 adultos dos EUA em agosto de 2026, 42% disseram usar VPN para fins pessoais ou de trabalho. Privacidade em geral (56%) e segurança em geral (51%) foram os principais motivos.
  • NAT de nível de operadora. A RFC 6598 reserva 100.64.0.0/10 para CGNAT, e a Cloudflare observa que, por trás dele, "centenas ou até milhares de clientes podem parecer vir de um único endereço IP". A Cloudflare também constatou que IPs de CGNAT sofrem limitação de taxa três vezes mais do que outros IPs, embora a taxa mediana de bots seja quase idêntica: 4,8% contra 4,7% (Cloudflare sobre CGNAT).
  • iCloud Private Relay. A Cloudflare, que opera um dos saltos do relay, diz que sites que usam endereços IP para prevenção de fraude "podem confiar" nas conexões do Private Relay, porque a Apple valida o dispositivo e a conta (Cloudflare sobre o Private Relay).

O GeoIPHub retorna detection.is_mobile, detection.is_relay e threat.is_cgnat, e aplica o teto de 50 para CGNAT e o teto de 60 para relays antes de retornar a pontuação.

Pontue o IP certo, ou todo limite perde o sentido

Se você pontuar um valor falsificado de X-Forwarded-For, seus limites ajustados são derrotados antes mesmo de rodar. A RFC 7239 alerta que o cabeçalho Forwarded "não pode ser considerado confiável quanto à correção", porque qualquer nó no caminho, incluindo o cliente, pode modificá-lo (RFC 7239). A regra da MDN é que qualquer uso de X-Forwarded-For para segurança "deve usar apenas endereços IP adicionados por um proxy confiável", encontrados contando a partir da entrada mais à direita de acordo com o número de proxies que você opera (MDN: X-Forwarded-For). Pontuamos qualquer IP que você enviar, então derive-o primeiro da sua cadeia de proxies confiáveis.

Ajuste os limites com base nos seus próprios resultados

Comece pela tabela e depois mova cada linha com base em evidências. Registre a pontuação, recommended_action, detection_methods e a data em cada decisão e, depois de algumas semanas, compare com fraudes e chargebacks confirmados. Se a sua linha de 66 no checkout deixar passar chargebacks entre 55 e 65, reduza-a, mas não para 60 ou menos enquanto você atender usuários do Private Relay. Se a verificação de cadastro entre 51 e 70 raramente pegar uma conta ruim, aumente a linha.

O plano gratuito cobre 1.500 consultas por dia com todos os campos. Para verificar um único endereço manualmente, o verificador de pontuação de fraude de IP mostra a mesma pontuação e os mesmos motivos sem código.

Para o conjunto mais amplo de sinais, veja nossos guias sobre como detectar tráfego anonimizado sem bloquear clientes reais, fraude com proxies residenciais e de datacenter, como impedir account takeover e credential stuffing, como detectar abuso de promoções e cupons na etapa de resgate e onde os sinais de IP se encaixam em uma pilha de detecção de fraude em pagamentos.

Perguntas frequentes

Qual é uma boa pontuação de fraude de IP para bloquear?

Não existe um único limite universal. As faixas padrão do GeoIPHub bloqueiam a partir de 76. Nossos limites iniciais mantêm esse valor para login, reduzem para 71 no cadastro e para 66 no checkout, porque um pedido fraudulento sem cartão presente custa muito mais do que pedir a senha de novo. As escalas de outros fornecedores são diferentes, então interprete qualquer limite de acordo com as faixas do próprio fornecedor.

O que significa uma pontuação de fraude de IP de 75?

Na escala de 0 a 100 do GeoIPHub, 75 é o topo da faixa step_up. O bloqueio começa em 76. Desafie essa requisição em vez de permiti-la em silêncio e leia scoring.detection_methods, porque um 75 vindo de sinais de VPN e um vindo de histórico em listas de bloqueio exigem respostas diferentes. Uma saída Tor real nem fica em 75: 185.220.101.1 obteve 100, block, na nossa consulta de 22 de outubro de 2026.

Devo bloquear automaticamente usuários de VPN e proxy?

Não. Na pesquisa de agosto de 2026 da Security.org com 1.008 adultos dos EUA, 42% disseram usar VPN para fins pessoais ou de trabalho, e privacidade e segurança foram os principais motivos. Trate um indicador de VPN como motivo para um desafio adicional, não para uma recusa automática, e reserve bloqueios rígidos para saídas Tor e endereços com histórico de spam ou de listas de bloqueio.

Um usuário de iCloud Private Relay ou de CGNAT pode ser bloqueado apenas pela pontuação?

Não com os padrões do GeoIPHub. Endereços do Private Relay têm teto de 60 e endereços de NAT de nível de operadora têm teto de 50, ambos abaixo da linha de bloqueio padrão de 76. Mantenha todo limite de bloqueio acima de 60 e um endereço compartilhado só poderá ser desafiado, nunca recusado, apenas com base na pontuação.

Por que o limite de bloqueio é menor no checkout do que no login?

Uma permissão errada no checkout envia mercadorias pagas com um cartão roubado e volta como chargeback, enquanto uma permissão errada no login ainda precisa passar pela senha e por qualquer segundo fator. Por isso o checkout bloqueia a partir de 66, e o login só a partir de 76.

Escrito por

Equipe GeoIPHub

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.

Compartilhe este artigo
Mais artigos

Artigos relacionados