De acordo, amigos, Pat Reeves aqui, aparecendo em seus feeds desde botsec.net. Estamos em 23 de março de 2026, e eu recentemente tive uma dor de cabeça relacionada a bots de um tipo particular. Não o tipo sofisticado, patrocinado por nações – embora isso ainda seja interessante de analisar – mas a perturbação automatizada, um pouco esperta demais, que visa um dos meus projetos secundários.
Meu projeto secundário, para colocar em contexto, é um pequeno fórum de nicho para entusiastas de informática retro. Nada notável, apenas um lugar para nós, os mais velhos, reclamarmos dos processadores modernos e debatermos sobre a melhor forma de emular um Amiga. O tráfego não é enorme, mas a paixão está lá, e por meses, o fórum esteve alegremente livre de bots. Até o mês passado.
De repente, bots de registro. Não apenas um punhado, mas ondas. Centenas de contas falsas, todas com nomes de usuário levemente randomizados, endereços de email genéricos (muitas vezes provenientes de domínios recém-registrados), e absolutamente nenhum histórico de publicação. Eles não estavam fazendo spam imediatamente, o que era estranho. Eles estavam apenas… se registrando. E preenchendo meu banco de dados de usuários, tornando sua gestão penosa, e honestamente, me dando a impressão de que meu pequeno refúgio digital estava invadido.
Então, este mês, estamos falando sobre Vulnerabilidade: A onda silenciosa – Por que registros de bots de baixo esforço são uma ameaça maior do que você imagina (e como pará-los).
O tédio que se torna uma ameaça
Você pode pensar: “Pat, são apenas registros. Não é para tanto, certo? Exclua-os e passe para outra coisa.” E por um tempo, esse era exatamente meu raciocínio. Configurei um trabalho cron para purgar contas sem publicações após 24 horas. Problema resolvido, certo? Errado.
Os bots se adaptaram. Começaram a fazer uma única publicação inocente. “Oi!” ou “Feliz por estar aqui.” Nada que acionaria meus filtros anti-spam. Apenas o suficiente para evitar a purgação de contas sem publicações. Agora, eu tinha centenas de contas com uma publicação desnecessária, continuando a entupir meu banco de dados, ainda exigindo uma revisão manual.
Não é apenas um aborrecimento. É um ataque sutil e insidioso. Veja por que:
- Desperdício de recursos: Cada registro, cada entrada no banco de dados, cada pequena publicação consome recursos do servidor. Para um site pequeno como o meu, isso não é desprezível. Se o volume aumentar, isso pode levar à degradação do desempenho ou até mesmo a um ataque de negação de serviço para os usuários legítimos.
- Poluição de dados: Minhas tabelas de usuários estavam bagunçadas. Encontrar usuários reais, analisar a atividade, ou mesmo simplesmente fazer backup do banco de dados se tornou mais complicado.
- Risco à reputação: Se essas contas começassem de repente a fazer spam ou phishing, a reputação do meu fórum poderia ser afetada. Os motores de busca não apreciam sites associados a atividades maliciosas.
- Pré-requisito para ataques maiores: Muitas vezes, os 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 mais tarde, como credential stuffing ou até mesmo spear-phishing de usuários autênticos.
- Riscos de credential stuffing e de tomada de controle de conta (ATO): Este é o grande ponto. Se um bot registra uma conta e um usuário legítimo tenta mais tarde se registrar com o mesmo nome de usuário/email (ou um comum), o operador do bot agora tem um alvo potencial para o credential stuffing se eles adquiriram credenciais de outra violação. Eles podem tentar essas credenciais no meu site.
Então, o que começou como um problema de “meh, eu limpo depois” rapidamente se transformou em uma situação de “isso precisa parar agora”.
Minhas primeiras tentativas (fracas): A armadilha CAPTCHA
Minha reação inicial, como a de muitos, foi lançar um CAPTCHA. Mais especificamente, o reCAPTCHA v2. Todo mundo conhece o reCAPTCHA, não é? A caixa de seleção “Não sou um robô”, talvez alguns sinais de trânsito borrados.
Eu o coloquei em prática. Durante cerca de três dias, os registros caíram quase a zero. Fiquei satisfeito. “Aha! Resolvido!”
Então, eles voltaram. Não tanto, mas o suficiente. Como? Bem, para o reCAPTCHA v2, existem serviços que pagam humanos em centavos para resolver CAPTCHAs. Ou, cada vez mais, modelos de IA estão se tornando suficientemente eficazes 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 que usuários legítimos sejam sinalizados).
Além disso, os usuários legítimos ODEIAM CAPTCHAs. Recebi algumas reclamações. Meu público sobre informática retro, que Deus os abençoe, nem sempre é o mais paciente em relação às irritações modernas da web. Eu precisava de algo menos intrusivo, mais eficaz contra os bots, e menos irritante para os humanos.
Além da caixa de seleção: Defesas práticas
Depois de desistir do CAPTCHA visível, comecei a pensar sobre o 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 armadilha de mel
Este é um clássico por um motivo. É simples, eficaz e completamente invisível para os usuários humanos. A ideia é adicionar um campo extra, escondido, ao seu formulário de registro. Os bots, sendo menos sofisticados que os humanos, muitas vezes tentarão preencher todos os campos que encontrarem. Os humanos não o verão, então não o preencherão.
Aqui está um exemplo simplificado do que eu 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 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">Cadastrar</button>
</form>
E no lado do servidor (usando um exemplo em Python/Flask, mas a lógica se aplica universalmente):
@app.route('/register', methods=['POST'])
def register():
# Verifique o campo armadilha de mel
if request.form.get('fax_number'):
# Bot detectado! Registre, talvez bloqueie o IP, e retorne um erro
print(f"Armadilha de mel acionada 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 os navegadores o preencham automaticamente. Escolhi “fax_number” porque é um campo old-school que não tem lugar em um formulário de registro moderno, fazendo um bom “isca.”
2. Análise baseada no tempo (verificação de timestamp)
Os bots normalmente enviem formulários incrivelmente rápido. Os humanos levam pelo menos alguns segundos para preencher até mesmo um formulário simples. Eu registro o tempo em que o formulário é carregado 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">Cadastrar</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 do IP: {request.remote_addr}, levou {time_taken}s")
return "Falha no registro. Por favor, tente novamente.", 400
# ... resto da sua lógica de registro ...
return "Registro bem sucedido!"
Eu defini um mínimo de 5 segundos. Isso imediatamente capturou 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 de taxa por IP (com um toque)
A limitação de taxa padrão por IP é boa: “Não mais do que 5 registros desse IP por hora.” Mas os bots frequentemente usam proxies ou mudam de IP. Então, eu adicionei um toque: a impressão de IP e User-Agent.
Comecei a registrar a string User-Agent com o endereço IP. Se eu notasse um aumento repentino nos registros provenientes de diferentes IPs, mas com a mesma string User-Agent, um pouco incomum, isso era um forte indicativo de um 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 fosse claramente não navegável ou repetido de forma suspeita.
Isso não é um trecho de código que você pode simplesmente inserir, pois requer um certo logging e análise em backend. Mas, conceitualmente, trata-se de examinar padrões além do simples IP de origem. Muitos firewalls de aplicação web (WAFs) oferecem esse tipo de limitação avançada de taxa e detecção de anomalias.
4. Verificação do domínio do e-mail (usando dados públicos)
Muitos registros de bots vêm de domínios de e-mail recém-registrados, frequentemente descartáveis. Estabeleci uma verificação contra uma pequena lista organizada de provedores de e-mail descartáveis conhecidos, mas mais efetivamente, comecei a observar a idade do domínio de e-mail em si.
Existem APIs (algumas pagas, outras gratuitas com limitações) que podem lhe indicar quando um domínio foi registrado. Se um endereço de e-mail vem de um domínio registrado nos últimos 30 dias, isso é um enorme sinal de alerta. 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 ativado, envio muito rápido), eu simplesmente bloquearia o registro. Para domínios com menos de 30 dias, eu os sinalizaria para uma revisão manual e potencialmente pediria uma confirmação por e-mail antes da ativação.
Os Resultados: A Paz (Quase) Restaurada
Implementar essas etapas não foi uma solução rápida, mas foi incrivelmente eficaz. O honeypot e as verificações baseadas em tempo imediatamente reduziram a maioria dos registros automatizados. A análise dos padrões de 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 superioridade do chip SID do Commodore 64, em vez de excluir centenas de contas falsas.
É importante entender que isso não é uma solução “para instalar e esquecer”. Os bots evoluem. Os atacantes encontram novas metodologias. Eu terei que monitorar e me adaptar. Mas, por enquanto, essas técnicas práticas e de baixo custo me devolveram o controle do meu pequeno canto da internet.
Pontos a Lembrar
Se você está enfrentando registros de bots de baixo esforço ou incômodos automáticos semelhantes, aqui está o que você deve fazer agora:
- Implemente um Honeypot: É incrivelmente simples, eficaz e invisível para os usuários. Faça isso.
- Adicione uma Verificação Baseada em Tempo: Meça o tempo entre o carregamento do formulário e o envio. Bloqueie envios que sejam anormalmente rápidos.
- Vá além do Bloqueio Simples de IP: Procure padrões nas strings User-Agent, nos referenciadores e em outros cabeçalhos de solicitaçã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 provedores de e-mail descartáveis conhecidos e considere a idade do domínio para novos registros.
- Monitore e Adapte: Os bots estão sempre evoluindo. Fique atento aos seus logs, analise a atividade suspeita e esteja pronto para ajustar suas defesas.
- Não Incomode Usuários Reais: Priorize a experiência do usuário. Evite CAPTCHAs muito rigorosos ou regras excessivamente rigorosas que possam bloquear registros legítimos. A melhor defesa contra bots é aquela que os humanos nem notam.
Mantenha-se atento e mantenha esses bots afastados!
Artigos Relacionados
- Exercícios da equipe vermelha sobre bots de IA
- Arquitetura de zero confiança para bots de IA
- Proteção contra injeção de prompt: Erros comuns e soluções práticas
🕒 Published: