D’acordo, amigos, Pat Reeves aqui falando, aparecendo nos seus feeds de botsec.net. Hoje é 23 de março de 2026 e recentemente tive uma dor de cabeça relacionada a bots de um tipo particular. Não do tipo sofisticado, patrocinado por estados nacionais – embora sempre seja interessante analisar – mas a incômoda automação, um pouco astuta demais, que visa um dos meus projetos secundários.
Meu projeto secundário, para colocar tudo em perspectiva, é um pequeno fórum de nicho para entusiastas de informática retro. Nada de notável, apenas um lugar para nós, pessoas de certa idade, reclamarmos dos processadores modernos e discutirmos a melhor forma de emular um Amiga. O tráfego não é enorme, mas a paixão está presente e, por meses, o fórum esteve felizmente imune a bots. Até o mês passado.
Subitamente, bots de registro. Não apenas um fluxo, mas ondas. Centenas de contas falsas, todas com nomes de usuário ligeiramente aleatórios, endereços de e-mail genéricos (geralmente provenientes de domínios recém-registrados) e absolutamente nenhum histórico de publicação. Não estavam fazendo spam imediatamente, o que era estranho. Estavam simplesmente… em fase de registro. E estavam enchendo meu banco de dados de usuários, tornando sua gestão irritante e, honestamente, me fazendo sentir como se meu pequeno refúgio digital estivesse sendo invadido.
Então, este mês falamos sobre Vulnerabilidade: A onda silenciosa – Por que os registros de bots de baixo esforço são uma ameaça maior do que vocês pensam (e como pará-los).
A monotonia que se torna ameaça
Vocês podem pensar: “Pat, são apenas registros. Não há nada com que se preocupar, certo? Exclua-os e siga em frente.” E por um tempo, era exatamente esse o meu raciocínio. Configurei um trabalho cron para excluir contas sem publicações após 24 horas. Problema resolvido, certo? Errado.
Os bots se adaptaram. Começaram a fazer uma única postagem inocente. “Olá!” ou “Feliz por estar aqui.” Nada que acionaria meus filtros anti-spam. Apenas o suficiente para evitar a purga das contas sem publicações. Agora eu tinha centenas de contas com uma publicação inútil, continuando a sobrecarregar meu banco de dados, exigindo ainda uma revisão manual.
Não é apenas um incômodo. É um ataque sutil e insidioso. Aqui está o porquê:
- Esgotamento de recursos: Cada registro, cada entrada de banco de dados, cada pequena publicação consome recursos do servidor. Para um site pequeno como o meu, isso não é negligenciável. Se o volume aumentar, isso pode levar a um degradação de desempenho ou até mesmo a uma interrupção do serviço para usuários legítimos.
- Poluição de dados: Minhas tabelas de usuários estavam bagunçadas. Encontrar usuários reais, analisar a atividade ou até mesmo fazer um backup do banco de dados se tornou mais complicado.
- Risco reputacional: Se essas contas começassem subitamente a fazer spam ou phishing, a reputação do meu fórum poderia ser comprometida. Os motores de busca não apreciam sites associados a atividades prejudiciais.
- Prelúdio a ataques maiores: Muitas vezes, os bots de registro de baixo esforço são um passo de reconhecimento. Testam as águas, identificam vulnerabilidades e estabelecem uma base para ataques mais sofisticados posteriormente, como o credential stuffing ou até mesmo o spear-phishing de usuários autênticos.
- Riscos de credential stuffing e takeover de conta (ATO): Este é o ponto crucial. Se um bot registra uma conta e um usuário legítimo tenta registrar-se com o mesmo nome de usuário/e-mail (ou um comum), o operador do bot agora tem um potencial alvo para o credential stuffing se tiver adquirido credenciais de outra violação. Eles podem testar essas credenciais no meu site.
Portanto, o que começou como um problema de “meh, vou limpar isso mais tarde” rapidamente se transformou em uma situação de “isto precisa parar agora”.
Minhas primeiras tentativas (falhadas): O truque CAPTCHA
Minha reação inicial, como a de muitos, foi lançar um CAPTCHA. Mais precisamente, reCAPTCHA v2. Todos conhecem reCAPTCHA, certo? A caixa para marcar “Não sou um robô”, talvez alguns sinais de trânsito desfocados.
Configurei tudo isso. Por cerca de três dias, os registros caíram quase a zero. Eu me congratulei. “Aha! Resolvido!”
Pois, eles voltaram. Não tantos, mas o suficiente. Como? Bem, para reCAPTCHA v2, existem serviços que pagam pessoas algumas moedas para resolver os CAPTCHAs. Ou, cada vez mais, modelos de IA estão se tornando bons o suficiente para decifrá-los, especialmente os mais simples. É um jogo de gato e rato e, em um site de baixo tráfego, não valia o custo adicional do reCAPTCHA v3 (que pode ser um pesadelo para configurar sem sinalizar usuários legítimos).
Além disso, usuários legítimos ODEIAM CAPTCHAs. Recebi algumas reclamações. Meu público sobre informática retro, benditos sejam, nem sempre é o mais paciente diante das irritações modernas da web. Eu precisava de algo menos invasivo, mais eficaz contra bots e menos frustrante para os humanos.
Além da caixa de seleção: Defesas práticas
Depois de abandonar o CAPTCHA visível, comecei a pensar no que distingue um humano de um bot, além do simples ato de marcar uma caixa. Aqui está o que realmente funcionou para mim:
1. O campo de armadilha de mel
É um clássico por um motivo. É simples, eficaz e completamente invisível para os usuários humanos. A ideia é adicionar um campo extra, oculto, ao seu formulário de registro. Os bots, sendo menos sofisticados do que os humanos, frequentemente tentam preencher todos os campos que encontram. Os humanos não o verão, então não o preencherão.
Aqui está um exemplo simplificado do que adicionei ao meu formulário de registro HTML:
<form action="/register" method="POST">
<label for="username">Nome de usuário:</label>
<input type="text" id="username" name="username" required>
<label for="email">Email:</label>
<input type="email" id="email" name="email" required>
<!-- Campo de armadilha de mel -->
<div style="display:none;">
<label for="fax_number">Número de fax (deixe em branco):</label>
<input type="text" id="fax_number" name="fax_number" tabindex="-1" autocomplete="off">
</div>
<label for="password">Senha:</label>
<input type="password" id="password" name="password" required>
<button type="submit">Registrar</button>
</form>
E no lado do servidor (usando um exemplo Python/Flask, mas a lógica se aplica universalmente):
@app.route('/register', methods=['POST'])
def register():
# Verifica o campo de armadilha de mel
if request.form.get('fax_number'):
# Bot detectado! Registre, talvez bloqueie o IP, e retorne um erro
print(f"Armada de mel ativada pelo IP: {request.remote_addr}")
return "Registro falhou. Tente novamente.", 400 # Ou uma mensagem de sucesso genérica para confundir os bots
username = request.form.get('username')
email = request.form.get('email')
password = request.form.get('password')
# ... resto da sua lógica de registro ...
return "Registro realizado com sucesso!"
O display:none; o torna invisível. tabindex="-1" impede a navegação por teclado para ele. autocomplete="off" ajuda a evitar que os navegadores o preencham automaticamente. Eu escolhi “fax_number” porque é um campo old-school que não tem lugar em um formulário de registro moderno, fazendo uma boa “isca”.
2. Análise baseada no tempo (verificação do timestamp)
Os bots frequentemente enviam os formulários de forma incrivelmente rápida. Os humanos levam pelo menos alguns segundos para preencher até mesmo um formulário simples. Registro o tempo em que o formulário é carregado e o tempo de envio.
Quando o formulário de registro é servido:
<form action="/register" method="POST">
<!-- Outros campos do formulário -->
<input type="hidden" name="form_load_time" value="{{ current_timestamp_in_seconds }}">
<button type="submit">Registrar</button>
</form>
No lado do servidor:
import time
@app.route('/register', methods=['POST'])
def register():
form_load_time = int(request.form.get('form_load_time', 0))
submission_time = int(time.time())
time_taken = submission_time - form_load_time
# Se o formulário foi enviado muito rapidamente (por exemplo, menos de 5 segundos)
if time_taken < 5:
print(f"Envio muito rápido pelo IP: {request.remote_addr}, levou {time_taken}s")
return "Registro falhou. Por favor, tente novamente.", 400
# ... resto da sua lógica de registro ...
return "Registro realizado com sucesso!"
Estabeleci um mínimo de 5 segundos. Isso imediatamente bloqueou uma boa parte dos bots restantes. Cuidado para não tornar esse limite muito alto, pois usuários legítimos podem digitar rapidamente ou ter formulários pré-preenchidos.
3. Limitação do fluxo por IP (com uma variação)
A limitação do fluxo padrão por IP é aceitável: « Não mais de 5 registros deste IP por hora. » Mas os bots frequentemente usam proxies ou mudam de IP. Então, adicionei uma variação: a impressão IP e User-Agent.
Comecei a registrar a string User-Agent junto com o endereço IP. Se notasse um aumento repentino nos registros provenientes de diferentes IPs, mas com a mesma string User-Agent, ligeiramente incomum, isso era um forte indicador de uma botnet ou de um único bot mudando de IP. Isso me permitiu bloquear ou sinalizar temporariamente não apenas o IP, mas também o User-Agent se parecesse claramente não humano ou repetido de forma suspeita.
Esse não é um fragmento de código que você pode simplesmente inserir, pois requer algum registro e uma análise de backend. Mas, conceitualmente, trata-se de examinar padrões além do simples IP de origem. Muitos firewalls de aplicações web (WAF) oferecem esse tipo de limitação avançada do fluxo e detecção de anomalias.
4. Verificação do domínio do email (utilizando dados públicos)
Muitos registros de bots vêm de domínios de email recentemente registrados, muitas vezes descartáveis. Configurei um controle contra uma pequena lista selecionada de provedores de email descartáveis conhecidos, mas de maneira mais eficaz, comecei a observar a idade do próprio domínio de email.
Existem APIs (algumas pagas, outras gratuitas com limitações) que podem indicar quando um domínio foi registrado. Se um endereço de email vem de um domínio registrado nos últimos 30 dias, é um enorme sinal de alerta. Não é infalível – novos sites legítimos são lançados continuamente – mas combinado com outros sinais, é poderoso.
Para meu fórum, tomei uma decisão pragmática: se o domínio tivesse menos de 60 dias E se houvesse outros sinais de bots (honeypot ativado, envio muito rápido), eu simplesmente bloquearia o registro. Para domínios com menos de 30 dias, os sinalizaria para uma revisão manual e potencialmente pediria uma confirmação via email antes da ativação.
Os Resultados: A Paz (Quase) Restaurada
Implementar esses passos não foi uma solução rápida, mas foi incrivelmente eficaz. O honeypot e os controles baseados no tempo reduziram imediatamente a maioria dos registros automatizados. A análise dos padrões IP/User-Agent me ajudou a identificar e bloquear os operadores de bots mais persistentes.
Meu banco de dados de usuários está limpo novamente. Meus logs de servidor estão menos barulhentos. E posso me concentrar na moderação das discussões sobre a supremacia do chip SID do Commodore 64, em vez de ter que eliminar centenas de perfis falsos.
É importante entender que esta não é uma solução « para instalar e esquecer ». Os bots evoluem. Os atacantes encontram novos métodos. Terei que monitorar e me adaptar. Mas por enquanto, esses métodos práticos e econômicos me devolveram o controle do meu pequeno canto da internet.
Pontos a Lembrar
Se você estiver enfrentando registros de bots sem esforço ou semelhantes a assédios automatizados, aqui está o que você deve fazer imediatamente:
- Implemente um Honeypot: É incrivelmente simples, eficaz e invisível para os usuários. Faça isso.
- Adicione um Controle Baseado no Tempo: Meça o tempo entre o carregamento do formulário e o envio. Bloqueie envios que são anormalmente rápidos.
- Vá além do Bloqueio Simples de IP: Procure padrões nas strings User-Agent, nos referenciadores e em outros headers de requisição para identificar bots sofisticados que mudam de IP. Considere um WAF se seu tráfego justificar.
- Valide os Domínios de E-Mail: Verifique os provedores de email descartáveis conhecidos e considere a idade do domínio para novos registros.
- Monitore e Adapte: Os bots estão sempre se evoluindo. Fique de olho em seus logs, analise atividades suspeitas e esteja pronto para adaptar suas defesas.
- Não Perturbe Usuários Verdadeiros: Priorize a experiência do usuário. Evite CAPTCHA muito severos ou regras muito rígidas que poderiam bloquear registros legítimos. A melhor defesa contra bots é aquela que os humanos nem notam.
Mantenha-se vigilante e mantenha os bots à distância!
Artigos Relacionados
- Exercícios do time vermelho sobre bots IA
- Arquitetura de zero confiança para bots IA
- Proteção contra injeção de prompt: Erros comuns e soluções práticas
🕒 Published: