Verificações de visitantes de VPN: pontuar reputação e latência com segurança

Um painel de fraude sinaliza um visitante como VPN, o analista pede um bloqueio, e o pedido chega à equipa da plataforma sem nada além de um booleano do fornecedor. Esse booleano é uma estimativa, e falha numa direção diferente de uma medição de latência. Antes de agir, separe o que o próprio pedido prova, o que um serviço de reputação afirma e o que o tempo apenas sugere. Depois escolha uma resposta que possa reverter quando a estimativa se revelar errada.

Recolha os factos do pedido que pode defender

O único endereço que o seu servidor conhece com certeza é o par TCP que concluiu a ligação. Quando um CDN ou proxy inverso termina essa ligação, o par é a extremidade, e o endereço do cliente viaja num cabeçalho de reencaminhamento em que só se pode confiar se a sua própria extremidade o tiver acrescentado. Leia a entrada que o seu proxy escreveu, nunca a cadeia mais à esquerda, porque um cliente pode enviar qualquer valor nessa posição. Tudo o que vem depois tem de preservar essa distinção.

Dois enriquecimentos baratos tornam o endereço algo revisível: o sistema autónomo que o anuncia e o registo PTR que aponta de volta para ele. Ambos descrevem o registo e não o comportamento, e ambos são reproduzíveis mais tarde.

IP=203.0.113.10
dig +short -x "$IP"
whois "$IP" | grep -iE "origin|netname" | head -5

Um ASN de alojamento é uma pista forte e não um veredicto. Os concentradores de VPN empresariais, as saídas de nuvem e algumas redes universitárias também estão em centros de dados, por isso o mesmo sinal que apanha uma saída comercial também apanha um escritório legítimo. Guarde o endereço apenas enquanto a revisão precisar dele, porque um IP é dado pessoal na maioria dos regimes de privacidade. Elimine-o segundo um calendário em vez de o manter indefinidamente.

Pontue o visitante antes de o restringir

Execute qualquer novo sinal primeiro em modo de observação. Registe as entradas e um código de motivo, deixe passar todos os pedidos e compare a distribuição de pontuações com contas que sabe serem legítimas. Isso produz uma estimativa de falsos positivos antes de alguém perder o acesso, e é esse número que decide se uma regra é segura de ativar.

Mapeie o total em três ações em vez de duas: permitir, desafio de escalonamento, revisão manual. Um bloqueio permanente deve exigir abuso repetido confirmado por uma pessoa, porque um falso positivo num viajante empresarial custa um ticket de suporte e uma sessão perdida, enquanto um falso negativo num pedido custa quase nada.

Mantenha a consulta de reputação no servidor e limitada

Chame o serviço de reputação a partir do backend com um curto tempo limite, guarde o veredicto em cache por um período fixo e trate um tempo limite como desconhecido em vez de limpo. Nunca coloque a chave da API em código do lado do cliente e nunca deixe a consulta bloquear a renderização da página; um terceiro lento deve degradar a pontuação, não o site.

Guarde em cache por endereço e não por intervalo. Classificar um /24 inteiro a partir de uma consulta espalha um veredicto errado por vizinhos que nunca mediu. Registe o fornecedor, a data de resposta e o valor de classificação junto ao código de motivo, para que uma revisão posterior saiba qual julgamento estava em vigor.

Dois fornecedores podem classificar o mesmo endereço de forma diferente num dia, por isso o veredicto pertence à coluna das provas e não à coluna da identidade. É também uma relação de tratamento: enviar o endereço de cada visitante a um terceiro exige uma base legal, uma regra de conservação e uma linha no aviso de privacidade.

Meça a latência com uma mediana, não com uma única amostra

O tempo de ida e volta descreve o caminho no momento em que o mediu. Uma extremidade anycast próxima pode servir um utilizador distante, uma rede móvel acrescenta atraso que nada tem a ver com a geografia, e uma saída VPN no próprio país do visitante parece local. A geolocalização ao nível da cidade relata frequentemente o centro de dados e não a pessoa.

Recolha várias amostras e use a mediana para que um pedido lento não desloque o resultado. O ciclo abaixo imprime a mediana de cinco.

for i in 1 2 3 4 5; do
  curl -o /dev/null -s -w "%{time_connect} %{time_starttransfer}\n" https://www.example.com/
done | sort -n | sed -n 3p

Compare o número com a distribuição de utilizadores sabidamente bons em vez de um limiar absoluto, e combine-o com o ASN. Dois sinais fracos que concordam são mais fortes do que qualquer um sozinho, mas a conclusão continua a ser sobre um caminho e não sobre uma intenção, pelo que pertence a uma pontuação e não a uma proibição.

Decida, registe e reverta

Antes de ativar uma regra, reproduza um dia de tráfego em modo de observação e conte o que teria acontecido. Guarde as entradas da pontuação, o código de motivo e a versão da regra, mas conserve os endereços em bruto apenas para a janela de revisão. Se a regra disparar numa conta legítima, o registo deve explicar porquê sem uma segunda investigação.

Dê a cada regra o seu próprio interruptor. Quando a conclusão do escalonamento cair ou os tickets de suporte dispararem, desative essa regra e mantenha o resto do pipeline a funcionar; um único interruptor global transforma um problema de afinação numa falha. Depois da alteração, acompanhe a taxa de conclusão dos desafios e a fila de recursos, não apenas o número de bloqueios.

Por fim, mantenha a resposta proporcionada ao prejuízo que está a evitar. Na fraude publicitária, o estado de VPN é um indicador fraco de um clique falso, e os sinais de comportamento como os padrões de conversão e a consistência do dispositivo tratam do dano real. Um desafio reversível protege a receita e o utilizador real ao mesmo tempo.