Firewall de Aplicação Web (WAF) para proteger o site do seu servidor de MU Online

O site de um servidor de MU Online — com login de conta, ranking, loja de doação e painel administrativo — é um dos alvos mais visados por concorrentes e jogadores mal-intencionados. Um Web Application Firewall (WAF) é a camada que fica na frente dessa aplicação e filtra requisições maliciosas antes que elas cheguem ao seu código: tentativas de SQL injection contra o formulário de login, XSS no chat do site, brute force na área administrativa e bots que raspam o ranking para clonar seu servidor. Este tutorial mostra como planejar, configurar e testar um WAF de ponta a ponta, tanto em nuvem quanto autogerenciado.

Por que o site de MU precisa de um WAF dedicado

Diferente de um blog estático, o site de um servidor de MU tem múltiplas superfícies sensíveis: formulário de registro de conta, login (compartilhado com o jogo, em muitos casos), painel de resgate de código de doação, API de ranking consumida por terceiros, e às vezes um painel administrativo exposto publicamente. Cada uma dessas superfícies é um vetor de ataque diferente, e um WAF bem configurado cobre todas com um único ponto de controle, sem precisar alterar o código da aplicação a cada nova ameaça descoberta.

Tipos de ataque que um WAF bloqueia

Escolhendo entre WAF em nuvem e autogerenciado

Para a maioria dos servidores de MU, começar com Cloudflare (mesmo no plano gratuito) já cobre uma fatia grande dos ataques automatizados, deixando ModSecurity como complemento para regras muito específicas do seu painel.

Passo 1 — Colocar o domínio atrás de um proxy com WAF

Se ainda não usa, aponte o DNS do domínio para o Cloudflare (ou provedor equivalente) e ative o proxy (nuvem laranja). Isso já esconde o IP real do servidor web e habilita o WAF gerenciado padrão. Confirme que o certificado SSL está em modo Full (strict), não apenas Flexible, para evitar loop de redirecionamento e manter a criptografia ponta a ponta.

Passo 2 — Ativar o conjunto de regras gerenciadas (OWASP)

No painel de segurança do Cloudflare (ou WAF equivalente), ative o conjunto de regras gerenciadas baseado no OWASP Core Rule Set. Rode inicialmente em modo log por 3 a 7 dias, observando quais requisições seriam bloqueadas, antes de mudar para modo de bloqueio ativo — isso evita derrubar tráfego legítimo por falso positivo.

Passo 3 — Criar regras customizadas para endpoints sensíveis

Regras genéricas não cobrem tudo. Adicione regras específicas para o seu site de MU:

# Exemplo de regra (sintaxe Cloudflare Rules)
(http.request.uri.path eq "/login" and rate(1m) > 20) => Block
(http.request.uri.path contains "/api/ranking" and rate(1m) > 60) => Challenge
(http.request.uri.path eq "/admin" and ip.geoip.country ne "BR") => Block

• Login: limite de tentativas por IP em janela curta, bloqueando brute force.
• API de ranking: desafio (captcha) acima de um volume que só bot atingiria.
• Painel admin: restrição geográfica ou por IP fixo, se a equipe é conhecida.

Passo 4 — Configurar ModSecurity como camada complementar (opcional)

Para quem hospeda o próprio servidor web (Nginx/Apache), o ModSecurity com o OWASP Core Rule Set adiciona uma segunda camada, útil mesmo com Cloudflare na frente (defesa em profundidade):

# nginx.conf — habilitando ModSecurity
load_module modules/ngx_http_modsecurity_module.so;

server {
    listen 443 ssl;
    server_name painel.seuservidor.com;

    modsecurity on;
    modsecurity_rules_file /etc/nginx/modsec/main.conf;

    location /admin {
        modsecurity_rules '
            SecRuleEngine On
            SecRule REQUEST_URI "@streq /admin" "id:1001,phase:1,deny,status:403,chain"
            SecRule REMOTE_ADDR "!@ipMatch 203.0.113.10"
        ';
    }
}

Esse exemplo bloqueia qualquer IP diferente do IP fixo da equipe ao acessar /admin, mesmo que a requisição passe pelas regras genéricas.

Passo 5 — Proteger o formulário de doação/pagamento

O painel de doação processa dados sensíveis mesmo quando o pagamento em si é feito por gateway externo (PagSeguro, Mercado Pago). Garanta que o WAF valide: tamanho máximo de campos, tipos de caractere esperados (nome não deve aceitar tags HTML), e rate limiting agressivo no endpoint de confirmação de pagamento, que é alvo comum de tentativas de fraude por replay de requisição.

Passo 6 — Testar o WAF sem quebrar o site

1. Rode uma varredura básica com uma ferramenta de teste de segurança (ex.: OWASP ZAP) apontando para um ambiente de staging, nunca produção sem aviso.
2. Envie manualmente um payload de teste inofensivo (' OR '1'='1 em um campo de busca) e confirme que é bloqueado.
3. Teste o fluxo normal do jogador (registro, login, resgate de código) para garantir que nenhuma regra legítima foi bloqueada por engano.
4. Monitore o painel de eventos do WAF nas primeiras 48h após ativar o modo de bloqueio.

Ajustando falsos positivos

Monitoramento contínuo

Configure alertas (e-mail ou webhook para Discord) quando o WAF bloquear um volume anormal de requisições em curto período — isso frequentemente indica um ataque em andamento e não apenas ruído de fundo. Revise o log de eventos do WAF semanalmente nas primeiras semanas após o lançamento do servidor, período de maior exposição a ataques de concorrentes.

Erros comuns e soluções

Checklist de segurança do WAF

• Domínio atrás de proxy com SSL Full (strict).
• Conjunto de regras OWASP ativado, testado em modo log antes do bloqueio.
• Regras customizadas para login, ranking e painel admin.
• ModSecurity como camada complementar (se autogerenciado).
• Formulário de doação com validação e rate limiting.
• Testes de payload malicioso realizados em staging.
• Alertas de bloqueio anômalo configurados.
• Log de eventos do WAF revisado semanalmente no lançamento.

Com o WAF ativo protegendo o site, o próximo passo natural é revisar a segurança da infraestrutura por trás dele — o próprio GameServer e banco de dados — para fechar o ciclo de proteção completo, como descrito no tutorial de criação de servidor de MU Online.

Perguntas frequentes