D’acordo, amigos, Pat Reeves que fala diretamente para vocês do botsec.net. Estamos em 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 analisar – mas aquela preocupação automatizada ligeiramente inteligente que visa um dos meus projetos colaterais.
Para dar um pouco de contexto, meu projeto colateral é um pequeno fórum de nicho para entusiastas de computação retrô. Nada de especial, apenas um lugar para nós, os veteranos, nos lamentarmos sobre CPUs modernas e discutirmos como emular da melhor forma 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 ou dois, mas ondas. Centenas de contas falsas, todas com nomes de usuário ligeiramente randomizados, endereços de e-mail genéricos (geralmente de domínios recém-registrados), e absolutamente nenhum histórico de postagens. Eles não estavam enviando spam imediatamente, o que era estranho. Eles apenas… se registravam. E enchiam meu banco de dados de usuários, tornando sua gestão incômoda e, francamente, me fazendo sentir que meu pequeno canto digital estava sendo invadido.
Então, este mês falamos sobre Vulnerabilidades: A ascensão silenciosa – Por que os registros de bots de baixo esforço representam uma ameaça maior do que você pensa (e como detê-los).
Tédio que se torna uma ameaça
Você pode pensar: “Pat, são apenas registros. Não é um grande problema, certo? Apague-os e siga em frente.” E por um tempo, esse foi exatamente meu raciocínio. Configurei um trabalho cron para excluir contas sem postagens após 24 horas. Problema resolvido, certo? Errado.
Os bots se adaptaram. Começaram a fazer uma única postagem inofensiva. “Oi!” ou “Feliz por estar aqui.” Nada que ativasse meus filtros anti-spam. Justo o suficiente para evitar a exclusão das contas sem postagens. Agora, eu tinha centenas de contas com uma postagem inútil, que continuavam a ocupar espaço no meu banco de dados, necessitando ainda de uma revisão manual.
Não é apenas um simples incômodo. É um ataque sutil e insidioso. Aqui está o porquê:
- Esgotamento 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 é desprezível. Se o volume aumentar, pode levar a uma degradação do desempenho ou até mesmo a uma negação de serviço para usuários legítimos.
- Contaminação de dados: Minhas tabelas de usuários estavam uma bagunça. Encontrar usuários reais, analisar a atividade, ou mesmo fazer o backup do banco de dados, tornou-se mais tedioso.
- Riscos para a reputação: Se essas contas começassem de repente a enviar spam ou a fazer phishing, a reputação do meu fórum poderia sofrer. Os motores de busca não gostam de sites associados a atividades maliciosas.
- Prelúdio a ataques maiores: Muitas vezes, os bots de registro de baixo esforço são uma fase de reconhecimento. Eles testam as águas, identificam fraquezas e colocam as bases para ataques mais sofisticados posteriores, como o credential stuffing ou mesmo o phishing direcionado a usuários reais.
- Riscos de Credential Stuffing e Account Takeover (ATO): Esse é o problema principal. 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 uma potencial vítima para o credential stuffing se obteve credenciais de outra violação. Ele pode testar essas credenciais no meu site.
Portanto, o que começou como um problema “meh, vou limpar tudo mais tarde” rapidamente se transformou em uma situação “isso tem que acabar agora”.
Minhas primeiras (falhas) tentativas: A armadilha CAPTCHA
Meu impulso inicial, como muitos, foi adicionar um CAPTCHA. Especificamente, reCAPTCHA v2. Todos conhecem reCAPTCHA, certo? A caixinha para marcar “Não sou um robô”, talvez alguns sinais de trânsito borrados.
Eu o implementei. Por cerca de três dias, os registros caíram para praticamente zero. Me dei um tapinha nas costas. “Aha! Resolvido!”
Pois, eles voltaram. Não tantos, mas o suficiente. Como? Bem, para o reCAPTCHA v2, há serviços que pagam humanos em centavos para resolver os CAPTCHA. Ou, cada vez mais, os modelos de IA estão se tornando bons o suficiente para decifrá-los, especialmente os mais simples. É um jogo de gato e rato, e para um site de baixo tráfego, não valia o custo do reCAPTCHA v3 (que pode ser um pesadelo para configurar sem que usuários legítimos sejam sinalizados).
Além disso, usuários legítimos odeiam os CAPTCHA. Recebi algumas reclamações. Meu público apaixonado por informática retro, Deus os abençoe, nem sempre é o mais paciente com as inconveniências da web moderna. Eu precisava de algo menos intrusivo, mais eficaz contra bots e menos entediante para os humanos.
Além da caixa de seleção: Defesas práticas
Depois de abandonar o CAPTCHA visível, comecei a refletir sobre o que torna um humano um humano, e um bot um bot, além do simples clique 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 os usuários humanos. A ideia é adicionar um campo extra, oculto, ao seu formulário de registro. Os bots, sendo menos sofisticados que os humanos, geralmente 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 (deixe 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">Registrar</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 ativado pelo IP: {request.remote_addr}")
return "Registro falhou. 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')
# ... resto da sua lógica de registro ...
return "Registro bem-sucedido!"
O display:none; o torna invisível. tabindex="-1" impede a navegação via teclado. autocomplete="off" ajuda a evitar que navegadores o preencham automaticamente. Escolhi “fax_number” porque é um campo ultrapassado que não faz sentido em um formulário de registro moderno, tornando-o um bom “apetito”.
2. Análise baseada no tempo (verificação de tempo)
Os bots costumam enviar formulários incrivelmente rápido. Os humanos levam pelo menos alguns segundos para preencher até mesmo um formulário simples. Vou registrar o tempo de carregamento do formulário 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>
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 rápido demais (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 bem-sucedido!"
Optei por um mínimo de 5 segundos. Isso imediatamente capturou uma boa parte dos bots restantes. Cuidado para não definir esse limite muito alto, pois usuários autênticos podem digitar rapidamente ou ter formulários pré-preenchidos.
3. Limitação de tráfego por IP (com um toque)
“`html
A limitação padrão do tráfego IP é boa: “Não mais de 5 registros deste IP por hora.” Mas os bots costumam usar proxies ou mudam os IPs. Então, adicionei um toque: impressão IP e User-Agent.
Comecei a registrar a string User-Agent com o endereço IP. Se eu notasse um aumento repentino de registros provenientes de diferentes IPs, mas com a mesma string User-Agent, ligeiramente incomum, isso era um forte indicador de um botnet ou de um único bot que mudava 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 forma suspeita.
Este não é um fragmento de código que você pode simplesmente inserir, pois requer algum registro e uma análise em backend. Mas, conceitualmente, trata-se de observar os padrões além do IP de origem. Muitos firewalls de aplicativos web (WAF) oferecem esse tipo de limitação avançada de tráfego e detecção de anomalias.
4. Verificação do domínio de email (usando dados públicos)
Muitos registros de bots vêm de domínios de email recentemente registrados, muitas vezes descartáveis. Implementei uma verificação contra uma pequena lista selecionada de provedores de email descartáveis conhecidos, mas de forma mais eficaz, comecei a observar a idade do domínio de email em si.
Existem APIs (algumas pagas, outras gratuitas com limitações) que podem te dizer 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 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 bloquearia diretamente o registro. Para os domínios com menos de 30 dias, os sinalizaria para uma revisão manual e poderia solicitar uma confirmação por email antes da ativação.
Os Resultados: A Paz (Quase) Restabelecida
A implementação desses passos não foi uma solução instantânea, mas foi incrivelmente eficaz. O honeypot e as verificações baseadas no tempo reduziram imediatamente 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 chipset SID do Commodore 64, em vez de eliminar centenas de contas falsas.
É importante entender que não é uma solução “para configurar e esquecer”. Os bots evoluem. Os atacantes encontram novos métodos. Eu precisarei monitorar e me adaptar. Mas por agora, esses métodos práticos e de baixo custo me trouxeram de volta o controle do meu pequeno canto da internet.
Pontos a Lembrar
Se você estiver enfrentando registros de bots pouco envolventes ou distúrbios automatizados semelhantes, aqui está o que você deve fazer imediatamente:
- 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 as submissões que são anormalmente rápidas.
- Vá além do Simples Bloqueio do IP: Procure padrões nas strings User-Agent, nos referenciadores e em outros headers de requisição para identificar bots sofisticados que mudam os IPs. Considere um WAF se seu tráfego justificar.
- Valide os Domínios dos Emails: Verifique provedores de email 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 nos 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 excessivamente restritivos ou regras muito severas que possam bloquear registros legítimos. A melhor defesa contra bots é aquela que os humanos nem notam.
Fique atento lá fora e mantenha esses bots afastados!
Artigos Relacionados
- Exercícios da equipe vermelha contra bots IA
- Arquitetura de zero trust para bots IA
- Defesa contra injeção de prompt: erros comuns e soluções práticas
“`
🕒 Published: