Como implementar um honeypot contra bots de login no seu servidor de MU Online

Bots de criação de conta em massa e scripts de força bruta de login são uma dor de cabeça constante para administradores de servidores privados de MU Online: eles inflam números falsos de cadastro, tentam adivinhar senhas de contas valiosas e, em servidores com sistema de recompensa por primeiro login, exploram esse tipo de benefício em escala. Um honeypot é uma armadilha discreta — um campo, endpoint ou comportamento que só um script automatizado interagiria, nunca um humano real — que permite identificar e bloquear esses bots sem prejudicar a experiência de jogadores legítimos. Este tutorial detalha como implementar honeypots tanto no site de cadastro quanto no ConnectServer do seu emulador, com exemplos práticos de código e configuração.

O que é um honeypot e por que ele funciona

A lógica do honeypot é simples: você cria um "isca" que está tecnicamente presente na página ou no protocolo, mas invisível ou irrelevante para um usuário humano normal. Bots que analisam o HTML/DOM de forma automatizada, ou que enviam pacotes de rede de forma genérica sem reproduzir o comportamento exato de um cliente real, acabam interagindo com essa isca — preenchendo um campo que deveriam ignorar, ou acessando um endpoint que nenhum humano acessaria diretamente. Diferente de um CAPTCHA, o honeypot não exige nenhuma ação extra do usuário real, o que o torna praticamente invisível à experiência legítima.

Honeypot no formulário de cadastro do site

A implementação mais simples e amplamente usada em qualquer site com formulário é o campo invisível. Adicione um campo de input ao formulário de cadastro, escondido via CSS (nunca via type="hidden", que alguns bots já ignoram por padrão), e rejeite qualquer submissão em que esse campo venha preenchido.

<style>
  .hp-field { position: absolute; left: -9999px; top: -9999px; }
</style>

<form method="POST" action="/cadastro">
  <input type="text" name="usuario" placeholder="Usuário">
  <input type="password" name="senha" placeholder="Senha">
  <input type="email" name="email" placeholder="E-mail">

  <!-- Campo honeypot: invisível para humanos, visível para bots que leem o DOM -->
  <input type="text" name="website" class="hp-field" tabindex="-1" autocomplete="off">

  <button type="submit">Criar conta</button>
</form>

<?php
if (!empty($_POST['website'])) {
    // Campo honeypot preenchido = bot. Rejeita silenciosamente.
    http_response_code(200); // finge sucesso para não alertar o bot
    exit;
}
// segue o fluxo normal de cadastro para submissões legítimas

Note o detalhe de responder com sucesso falso (200) em vez de erro explícito — isso evita que o operador do bot ajuste o script ao perceber rejeição imediata, mantendo a armadilha eficaz por mais tempo.

Honeypot de tempo de preenchimento

Complementando o campo invisível, meça o tempo entre o carregamento do formulário e o envio. Bots frequentemente submetem formulários em menos de 1-2 segundos, tempo impossível para um humano ler os campos e digitar usuário, senha e e-mail.

<?php
session_start();
if (!isset($_SESSION['form_loaded_at'])) {
    $_SESSION['form_loaded_at'] = time();
}

// No processamento do POST:
$tempo_decorrido = time() - $_SESSION['form_loaded_at'];
if ($tempo_decorrido < 3) {
    // Submissão rápida demais para ser humana
    http_response_code(200);
    exit;
}

Honeypot no ConnectServer (nível de protocolo)

Para bots que atacam diretamente o ConnectServer (força bruta de login, criação de conta via protocolo sem passar pelo site), a estratégia envolve monitorar padrões de pacote que um cliente oficial nunca produziria: sequência de pacotes fora de ordem, ausência do handshake de versão esperado, ou volume de tentativas de login vindo do mesmo IP em intervalo impossível para digitação humana. A maioria dos emuladores (IGCN, MuEMU) já expõe log de tentativa de login em tabela própria; a consulta abaixo identifica padrões suspeitos.

SELECT IP, COUNT(*) AS tentativas, MIN(LoginTime) AS primeira, MAX(LoginTime) AS ultima
FROM LoginAttemptLog
WHERE LoginTime > DATEADD(minute, -10, GETDATE())
GROUP BY IP
HAVING COUNT(*) > 15
ORDER BY tentativas DESC;

IPs com dezenas de tentativas em poucos minutos, especialmente contra usuários sequenciais ou inexistentes, indicam força bruta ou scanner automatizado, e podem ser adicionados a uma blacklist temporária no firewall ou no próprio ConnectServer.

Tabela de tipos de honeypot e onde aplicar

Endpoint isca no site (rota falsa)

Além do formulário, crie uma rota que nunca é linkada em nenhum lugar visível do site (por exemplo /wp-login.php ou /admin-old), mas que scanners automatizados tentam acessar por padrão ao varrer qualquer domínio. Qualquer acesso a essa rota é, por definição, automatizado — nenhum humano navegando normalmente chegaria lá. Registre o IP de acesso e adicione a uma lista de bloqueio automática.

Conta isca monitorada no banco de dados

Uma técnica mais avançada é criar uma conta "isca" com credenciais nunca divulgadas publicamente e nunca usadas pela equipe, mas presente no banco de dados como qualquer conta real. Se essa conta específica sofrer tentativa de login, é evidência forte de que alguém está testando credenciais obtidas de vazamento de outro serviço (reuso de senha) ou de dump anterior do próprio servidor — um alerta valioso para revisar a segurança geral do banco.

Resposta gradual: soft-block antes de ban definitivo

Para minimizar o risco de falso positivo prejudicar um jogador real, aplique respostas em camadas crescentes de severidade em vez de banir na primeira detecção:

Integrando o honeypot ao painel de administração

Centralize os alertas de honeypot (formulário, endpoint isca, conta isca, protocolo) em um único painel ou canal de notificação (webhook para Discord da staff, por exemplo), para que a equipe de segurança veja o quadro completo em vez de logs espalhados. Um webhook simples pode disparar uma mensagem sempre que um honeypot for acionado, incluindo IP, timestamp e tipo de armadilha ativada, permitindo resposta manual rápida em casos ambíguos que a automação não deveria resolver sozinha.

Erros comuns e soluções

Checklist de implementação do honeypot

• Campo invisível adicionado ao formulário de cadastro e login.
• Verificação de tempo mínimo de preenchimento implementada.
• Endpoint isca criado e sem nenhum link visível no site.
• Conta isca monitorada cadastrada no banco de dados.
• Consulta de padrão de tentativas de login agendada no ConnectServer.
• Resposta gradual (soft-block antes de ban) configurada.
• Alertas centralizados em painel ou webhook para a equipe de segurança.
• Nenhum detalhe técnico da implementação divulgado publicamente.

Com o honeypot ativo, você reduz significativamente o ruído de bots no cadastro e no login sem sacrificar a experiência de jogadores reais; para fechar o ciclo de segurança da sua infraestrutura, revise também o tutorial de criação de servidor de MU Online e confirme que as demais camadas de proteção (firewall, anti-DDoS) estão alinhadas com essa estratégia.

Perguntas frequentes