Certo, amigos, Pat Reeves aqui, entrando nos seus feeds de notícias desde botsec.net. Hoje é 23 de março de 2026, e recentemente me deparei com um certo tipo de dor de cabeça relacionada a bots. Não o tipo sofisticado patrocinado por uma nação – embora esses sejam sempre divertidos de dissecar – mas a inconveniência automatizada que é um pouco inteligente demais e que mira um dos meus projetos paralelos.
Para dar um pouco de contexto, meu projeto paralelo é um pequeno fórum de nicho para entusiastas de informática retrô. Nada de notável, apenas um lugar para nós, os velhos de guerra, nos lamentarmos sobre os CPUs modernos e debater sobre a melhor forma de emular um Amiga. O tráfego não é enorme, mas é apaixonado, e por meses, esteve livre de bots. Até o mês passado.
De repente, bots de registro. Não apenas um fio, mas ondas. Centenas de contas falsas, todas com nomes de usuário levemente randomizados, endereços de e-mail genéricos (geralmente provenientes de domínios recém-registrados) e absolutamente nenhum histórico de postagens. Eles não estavam spammando imediatamente, o que era estranho. Eles apenas… se registravam. E preenchiam meu banco de dados de usuários, tornando sua gestão penosa e, francamente, me fazendo sentir que meu pequeno refúgio digital estava sendo invadido.
Portanto, este mês, estamos falando sobre Vulnerabilidade: A subida silenciosa – Por que registros de bots de baixo esforço representam uma ameaça maior do que você pensa (e como pará-los).
A monotonia que se torna uma ameaça
Você pode pensar, “Pat, são apenas registros. Não é nada para se fazer um drama, certo? Apague-os e passe para outra coisa.” E por um tempo, esse foi exatamente meu raciocínio. Criei um cron job para purgar as contas sem postagens após 24 horas. Problema resolvido, certo? Errado.
Os bots se adaptaram. Eles começaram a fazer uma única postagem inofensiva. “Olá!” ou “Feliz por estar aqui.” Nada que acionasse meus filtros anti-spam. Apenas o suficiente para evitar a purgação das contas sem postagens. Agora, eu tinha centenas de contas com uma postagem inútil, ainda ocupando meu banco de dados, exigindo uma revisão manual.
Não é apenas um simples aborrecimento. É um ataque sutil e insidioso. Aqui está o porquê:
- Exaustão de recursos: Cada registro, cada entrada no banco de dados, cada pequena postagem consome recursos do servidor. Para um site pequeno como o meu, isso não é insignificante. Se o volume aumentar, isso pode levar a uma degradação de desempenho ou até mesmo uma negação de serviço para os usuários legítimos.
- Poluição de dados: Minhas tabelas de usuários estavam uma bagunça. Encontrar usuários reais, analisar a atividade ou mesmo apenas fazer backup do banco de dados se tornou mais trabalhoso.
- Riscos para a reputação: Se essas contas de repente começassem a spammar ou a realizar phishing, a reputação do meu fórum poderia sofrer. Os motores de busca não apreciam sites associados a atividades maliciosas.
- Precursor para ataques maiores: Muitas vezes, bots de registro de baixo esforço são uma etapa de reconhecimento. Eles testam as águas, identificam fraquezas e estabelecem uma base para ataques mais sofisticados depois, como o credential stuffing ou até mesmo o spear-phishing de usuários reais.
- Riscos de Credential Stuffing e de Tomada de Controle de Conta (ATO): Esse é o maior problema. Se um bot registra uma conta e um usuário legítimo tenta se registrar com o mesmo nome de usuário/e-mail (ou um comum), o operador do bot agora tem um alvo potencial para o credential stuffing se ele adquiriu credenciais de outra violação. Ele pode tentar essas credenciais no meu site.
Portanto, o que começou como um problema “meh, vou limpar isso depois” rapidamente se transformou em uma situação “isso precisa parar agora”.
Minhas primeiras (fracassadas) tentativas: O truque CAPTCHA
Minha reação inicial, como a de muitos, foi jogar um CAPTCHA. Especificamente, reCAPTCHA v2. Todo mundo conhece reCAPTCHA, não é? A caixa de seleção “Não sou um robô”, talvez alguns sinais de trânsito borrados.
Eu implementei. Por cerca de três dias, os registros caíram quase a zero. Eu me bati nas costas. “Aha! Resolvido!”
Então, eles voltaram. Não tanto, mas o suficiente. Como? Bem, para reCAPTCHA v2, existem serviços que pagam humanos em centavos para resolver CAPTCHAs. Ou, cada vez mais, os modelos de IA estão ficando sofisticados 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 do reCAPTCHA v3 (que pode ser um pesadelo configurar sem que usuários legítimos sejam sinalizados).
Além disso, usuários legítimos odeiam CAPTCHAs. Recebi algumas reclamações. Meu público apaixonado por informática retrô, Deus os abençoe, não é sempre o mais paciente com os aborrecimentos da web moderna. Eu precisava de algo menos intrusivo, mais eficaz contra bots e menos chato para humanos.
Além da caixa de seleção: Defesas práticas
Depois de desistir do CAPTCHA visível, comecei a pensar sobre o que faz de um humano um humano e de um bot um bot, além do simples ato de clicar em uma caixa. Aqui está o que realmente funcionou para mim:
1. O campo Honeypot
É um clássico por uma razão. É simples, eficaz e completamente invisível para 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 tentarão preencher cada campo que encontrarem. 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 Honeypot -->
<div style="display:none;">
<label for="fax_number">Número de fax (deixar vazio):</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">Inscrever-se</button>
</form>
E do lado do servidor (usando um exemplo Python/Flask, mas a lógica se aplica universalmente):
@app.route('/register', methods=['POST'])
def register():
# Verificar o campo honeypot
if request.form.get('fax_number'):
# Bot detectado! Registre, talvez bloqueie o IP, e retorne um erro
print(f"Honeypot acionado pelo IP: {request.remote_addr}")
return "Falha no registro. Por favor, 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')
# ... restante da sua lógica de registro ...
return "Registro bem-sucedido!"
O display:none; o torna invisível. tabindex="-1" impede a navegação por teclado até ele. autocomplete="off" ajuda a impedir que navegadores o preencham automaticamente. Eu escolhi “fax_number” porque é um campo antiquado que não tem lugar em um formulário de registro moderno, o que o torna um bom “isca”.
2. Análise baseada em tempo (verificação de timestamp)
Os bots frequentemente enviam formulários incrivelmente rápido. Os humanos levam pelo menos alguns segundos para preencher mesmo um formulário simples. Eu registro o tempo de carregamento do formulário e o tempo de submissão.
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">Inscrever-se</button>
</form>
Do 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 "Falha na inscrição. Por favor, tente novamente.", 400
# ... resto da sua lógica de inscrição ...
return "Inscrição bem-sucedida!"
Eu optei por um mínimo de 5 segundos. Isso imediatamente captou boa parte dos bots restantes. Cuidado para não tornar esse limite muito alto, pois usuários autênticos podem digitar rapidamente ou ter formulários pré-preenchidos.
3. Limitação de taxa por IP (com um toque)
A limitação padrão de taxa por IP é boa: “Não mais de 5 inscrições desse IP por hora.” Mas os bots muitas vezes usam proxies ou trocam de IP. Então, eu adicionei um toque: impressão do IP e User-Agent.
Comecei a registrar a string User-Agent com o endereço IP. Se eu visse um aumento repentino nas inscrições provenientes de diferentes IPs, mas com a mesma string User-Agent, ligeiramente incomum, isso era um forte indicativo de um botnet ou de um único bot trocando os IPs. Isso me permitiu bloquear temporariamente ou sinalizar não apenas o IP, mas também o User-Agent se fosse claramente não-browser ou repetido de maneira suspeita.
Esse não é um trecho de código que você pode simplesmente implementar, pois requer um certo registro e análise no backend. Mas, conceitualmente, é sobre observar os padrões além do IP de origem. Muitos firewalls de aplicação web (WAF) oferecem esse tipo de limitação avançada de taxa e detecção de anomalias.
4. Verificação do domínio de email (usando dados públicos)
Muitas inscrições de bots vêm de domínios de email recentemente registrados, muitas vezes descartáveis. Eu implementei uma verificação contra uma pequena lista selecionada de provedores de emails descartáveis conhecidos, mas mais eficazmente, comecei a olhar para a idade do domínio do email em si.
Existem APIs (algumas pagas, outras gratuitas com limites) que podem lhe dizer quando um domínio foi registrado. Se um endereço de email vem de um domínio registrado nos últimos 30 dias, isso é um enorme sinal vermelho. Não é infalível – novos sites legítimos são lançados o tempo todo – 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 outros sinais de bot estivessem presentes (honeypot acionado, envio muito rápido), eu bloquearia diretamente a inscrição. Para domínios com menos de 30 dias, eu os sinalizaria para uma revisão manual e exigiria potencialmente uma confirmação por email antes da ativação.
Os Resultados: A Paz (Quase) Restauração
A implementação dessas etapas não foi uma solução instantânea, mas foi incrivelmente eficaz. O honeypot e as verificações baseadas no tempo imediatamente reduziram a maioria das inscrições automatizadas. A análise dos padrões de IP/User-Agent me ajudou a identificar e bloquejar 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 superioridade do chipset SID do Commodore 64, em vez de excluir centenas de contas falsas.
É importante entender que isso não é uma solução “para implementar e esquecer”. Os bots evoluem. Os atacantes encontram novos métodos. Eu terei que monitorar e me adaptar. Mas por enquanto, esses métodos práticos e de baixo custo me devolveram o controle do meu pequeno canto da internet.
Pontos a Lembrar
Se você está enfrentando inscrições de bots como essas ou perturbações automatizadas semelhantes, aqui está o que você deve fazer agora mesmo:
- Implemente um Honeypot: É incrivelmente simples, eficaz e invisível para os usuários. Vá em frente.
- Adicione uma Verificação Temporal: Meça o tempo entre o carregamento do formulário e o envio. Bloqueie os envios que são anormalmente rápidos.
- Vá além do Simples Bloqueio de IP: Procure padrões nas strings User-Agent, nos referenciadores e em outros headers de requisição para identificar bots sofisticados que estão trocando de IP. Considere um WAF se seu tráfego justificar.
- Valide os Domínios dos Emails: Verifique os provedores de emails descartáveis conhecidos e considere a idade do domínio para novos registros.
- Monitore e Adapte: Os bots estão sempre evoluindo. Fique de olho em seus logs, analise atividades suspeitas e esteja pronto para ajustar suas defesas.
- Não Perturbe Usuários Reais: Priorize a experiência do usuário. Evite CAPTCHAs muito restritivos ou regras excessivamente rigorosas que possam bloquear inscrições legítimas. A melhor defesa contra bots é aquela que os humanos nem notam.
Mantenha-se atento por aí, e mantenha os bots à distância!
Artigos Relacionados
- Exercícios da equipe vermelha contra bots de IA
- Arquitetura de confiança zero para bots de IA
- Defesa contra injeção de prompt: erros comuns e soluções práticas
🕒 Published: