Bloqueie tráfego de botnets antes que ele chegue ao seu banco de dados

A maior parte das stacks de aplicação foi desenhada para ser educada. Uma requisição chega, o roteador encaminha para um controller, o controller abre uma conexão com o banco, executa uma consulta e renderiza uma resposta. Para pessoas, esse fluxo funciona bem. Para uma botnet, é um presente.

Uma botnet distribuída não precisa explorar uma vulnerabilidade para causar prejuízo. Ela só precisa que a sua aplicação continue dizendo sim: sim para o formulário de login, sim para o endpoint de busca, sim para o e-mail de redefinição de senha, sim para mais uma conexão no pool. Quando o tráfego chega ao seu ORM, você já pagou por TLS, consulta de sessão e ida ao banco — multiplicado por milhares de nós por minuto.

A requisição mais barata é aquela que você nem chega a processar. Essa é a lógica por trás da filtragem por IP na borda.

Como uma botnet aparece na camada de IP

O tráfego de botnet raramente vem de um único endereço. Ele chega de muitos lugares, e a mistura costuma cair em alguns grupos bem reconhecíveis:

• Dispositivos residenciais comprometidos. Roteadores domésticos, dispositivos IoT e desktops infectados. Sozinhos, geram pouco volume; juntos, viram uma massa enorme.
• Capacidade alugada em datacenters. Instâncias baratas de VPS criadas em grande escala. Um cliente humano quase nunca navega pelo seu checkout a partir de uma faixa da AWS, OVH ou Hetzner.
• Redes comerciais de proxy. Pools de proxies residenciais e móveis revendidos por gigabyte, muitas vezes anunciados justamente como forma de contornar bloqueios por IP.
• VPN pública e saídas TOR. Legítimas para usuários preocupados com privacidade, mas desproporcionalmente presentes em abuso.

Nada disso é automaticamente malicioso. Um IP de datacenter pode ser uma sonda de monitoramento que você mesmo configurou. Uma saída de VPN pode ser um cliente usando o Wi-Fi de um hotel. É exatamente por isso que a decisão precisa estar nas suas mãos, não em uma blocklist genérica: você precisa da classificação e, a partir dela, aplica a sua política.

Bloquear antes do banco, não depois

A ordem das etapas importa mais do que a precisão de qualquer sinal isolado. Compare duas versões do mesmo endpoint de login.

| Stage | Without IP filtering | With IP filtering first | | --- | --- | --- | | Parse request | Yes | Yes | | IP classification | — | ~1 lookup, cached | | Session / user lookup | Yes | Only if allowed | | Password hash verify | Yes (expensive by design) | Only if allowed | | Rate-limit write | Yes | Only if allowed |

O hash de senha é lento de propósito — essa é a função dele. Em um ataque de credential stuffing contra um login desprotegido, o seu próprio controle de segurança vira vetor de negação de serviço. Ao mover a decisão por IP para antes dessa etapa, um nó atacante recebe um 403 pelo custo de uma consulta em hash-map, enquanto o pool de conexões do banco continua disponível para clientes reais.

O mesmo raciocínio vale para endpoints de busca que acessam índices full-text, formulários de cadastro que disparam e-mails transacionais e qualquer rota que grave uma linha de auditoria a cada tentativa.

Uma política prática, não um muro

Bloquear tudo que parece suspeito é o caminho mais curto para abrir chamados irritados no suporte. Uma resposta em camadas funciona melhor — e fica simples de expressar quando você tem um risk score e um tipo para cada endereço:

• Permitir em silêncio. Endereços de ISPs residenciais e corporativos com baixo risk score. É a esmagadora maioria do tráfego legítimo.
• Adicionar atrito. Saídas de VPN ou TOR apenas em ações sensíveis — cadastro, redefinição de senha, alterações de pagamento. Exiba um desafio, exija confirmação por e-mail, não conceda o teste grátis automaticamente.
• Limitar com rigor. Faixas de datacenter e hosting acessando endpoints voltados a humanos. Integrações legítimas devem usar a sua API com uma chave, não o seu formulário de login.
• Rejeitar na borda. Infraestrutura de proxy já conhecida por abuso martelando autenticação, ou qualquer origem que tenha estourado o orçamento por IP.

Repare que o passo 4 é o menor grupo, não o padrão. O objetivo é tornar o abuso caro, não deixar o seu produto inacessível.

Onde a verificação entra na sua stack

Há três pontos possíveis, em ordem aproximada de efetividade:

• CDN ou reverse proxy. O ponto mais cedo possível. A requisição nem toca em um servidor de aplicação. É o melhor lugar para regras amplas contra faixas obviamente hostis.
• Middleware na aplicação. Roda antes do roteamento e antes de qualquer chamada ao banco. É aqui que vivem políticas mais refinadas por endpoint — mais rígidas em /login, mais flexíveis em /pricing.
• Dentro da lógica de negócio. Para decisões que dependem de contexto da conta, como sinalizar um login vindo de IP de datacenter em uma conta que sempre usou apenas uma operadora móvel.

Para a maioria dos times, o middleware deve vir primeiro. São poucas linhas antes do roteador, protegendo tudo que vem depois.

Use cache agressivo e falhe aberto

Duas regras operacionais impedem que a checagem de reputação de IP vire ela mesma uma indisponibilidade:

Faça cache por endereço. Botnets reutilizam nós. Um TTL curto em memória — minutos, não dias — transforma milhares de requisições em uma única consulta e mantém a latência adicional na casa dos microssegundos para ofensores reincidentes. A Guarda faz cache das consultas no lado do servidor exatamente por esse motivo, e a janela de cache é configurável.

Falhe aberto, mas registre tudo. Se o serviço de reputação estiver indisponível, deixe a requisição passar e registre o evento. Um controle antiabuso que derruba seu checkout quando um terceiro tem um dia ruim pode custar mais caro do que o próprio abuso. Reserve o fail-closed para ações realmente críticas, como saques.

O que medir depois

Ative o filtro primeiro em modo somente log e compare uma semana de tráfego com uma semana de bloqueio:

• Requisições rejeitadas antes de chegar ao banco, como proporção do total.
• Saturação do pool de conexões do banco durante janelas de abuso.
• Tentativas de login malsucedidas por hora.
• Chamados de suporte mencionando "não consigo entrar" — o canário dos falsos positivos.
• Relação entre cadastros e contas verificadas, que costuma melhorar bastante quando cadastros descartáveis vindos de datacenter deixam de passar.

Se os dois últimos indicadores piorarem, afrouxe a camada em vez de desligar tudo.

Limites honestos

Reputação de IP é uma camada, não um firewall completo. Pools de proxies residenciais giram por endereços reais de consumidores, muitas vezes indistinguíveis dos seus clientes. Carrier-grade NAT significa que um único IP móvel pode representar milhares de pessoas. Atacantes com orçamento sempre encontrarão infraestrutura mais limpa do que atacantes sem orçamento.

O que a filtragem por IP faz com consistência é remover a maioria barata e volumosa — floods automatizados em servidores alugados e listas de proxies queimados — para que suas defesas mais lentas e inteligentes, como device fingerprinting, análise comportamental, MFA e rate limits por conta, precisem avaliar uma população muito menor e mais relevante.

Esse é o ganho realista: não um perímetro impenetrável, mas um banco de dados que continua respondendo consultas enquanto você está sob ataque.

Você pode classificar qualquer endereço com os sinais de proxy, VPN, TOR, hosting e risk score da Guarda usando a verificação gratuita na homepage e, depois, conectar a mesma chamada ao middleware antes das suas rotas.