Como configurar 2FA para contas de staff no MU Online

Contas de staff são o alvo mais valioso de qualquer servidor de MU Online. Um GM comprometido pode gerar itens excellent, dar reset infinito, banir jogadores legítimos ou drenar o Web Shop em minutos. E, ao contrário de uma conta de jogador comum, o dano de uma conta administrativa comprometida é praticamente irreversível para a reputação do servidor. A autenticação de dois fatores (2FA) é a defesa mais eficiente em relação ao custo que você pode implantar: mesmo que a senha de um administrador vaze em um phishing, o atacante ainda precisa do segundo fator físico.

Neste tutorial você vai configurar 2FA em todas as camadas relevantes de um servidor de MU Online: o painel web (AMS/UserControlPanel ou painel próprio), o acesso SSH/RDP à máquina, o banco de dados SQL Server e, quando possível, o próprio login de GM dentro do jogo. Os exemplos assumem uma stack comum (Windows Server + SQL Server + painel PHP), mas os conceitos valem para qualquer combinação. Detalhes de arquivos e nomes de tabelas variam por season e emulador (IGCN, MuEMU/Season 6, X-Files, entre outros), então trate os caminhos como EXEMPLO e adapte.

Pré-requisitos

Antes de começar, garanta que você tenha:

1. Acesso administrativo à máquina (física ou VPS) onde o servidor roda.
2. Acesso ao painel web do servidor com permissão para editar o código-fonte, ou ao repositório do painel.
3. Acesso ao SQL Server com uma conta sysadmin (para criar tabelas de suporte ao 2FA).
4. Um aplicativo autenticador TOTP instalado nos celulares da equipe (Google Authenticator, Aegis, Authy ou similar).
5. Um inventário atualizado de todas as contas com privilégios: administradores do site, GMs in-game, contas de banco e usuários de sistema operacional.
6. Um segundo canal verificado de contato com cada membro da equipe (para recuperação), preferencialmente presencial ou por telefone conhecido.

Reserve uma janela de manutenção. Habilitar 2FA de forma incorreta pode trancar você para fora do próprio painel, então tenha sempre uma conta de emergência documentada em local seguro (cofre offline).

Como o TOTP funciona (o conceito real)

O padrão mais usado é o TOTP (Time-based One-Time Password), definido na RFC 6238. O servidor e o aplicativo do usuário compartilham um segredo secreto (uma string em Base32) gerado uma única vez no cadastro. A cada 30 segundos, ambos os lados calculam um código de 6 dígitos usando HMAC-SHA1 sobre o segredo e o horário atual. Se os dois códigos batem, o login é aprovado.

Isso tem três implicações práticas:

• O relógio do servidor precisa estar sincronizado (use NTP). Se o horário derivar mais de 1-2 janelas, todos os códigos falham.
• O segredo nunca trafega após o cadastro inicial, o que torna o TOTP resistente a interceptação de rede.
• Você deve armazenar o segredo cifrado no banco, nunca em texto puro.

Passo 1 — Preparar o banco de dados

Crie uma tabela para armazenar os segredos e o estado do 2FA por conta de staff. Exemplo para SQL Server (adapte nomes conforme seu emulador):

CREATE TABLE Staff2FA (
    AccountID     VARCHAR(10)  NOT NULL PRIMARY KEY,
    SecretEnc     VARBINARY(256) NOT NULL,  -- segredo TOTP cifrado
    Enabled       BIT          NOT NULL DEFAULT 0,
    RecoveryCodes VARBINARY(512) NULL,       -- hashes dos códigos de backup
    LastUsedStep  BIGINT       NULL,         -- previne replay do mesmo código
    CreatedAt     DATETIME     NOT NULL DEFAULT GETDATE()
);

O campo LastUsedStep guarda o último passo de tempo aceito e impede que um código válido seja reutilizado dentro da mesma janela de 30 segundos (proteção contra replay). Cifre SecretEnc com uma chave que fique fora do banco (por exemplo, em uma variável de ambiente ou no cofre da aplicação), para que um dump de banco não vaze os segredos.

Passo 2 — Habilitar 2FA no painel web

O painel web costuma ser a porta de entrada mais exposta, então comece por ele. O fluxo de cadastro (enrollment) é:

1. O administrador loga normalmente com usuário e senha.
2. O painel gera um segredo Base32 aleatório de 20 bytes.
3. O painel exibe um QR Code (formato otpauth://totp/MeuMU:usuario?secret=BASE32&issuer=MeuMU) para escanear no app.
4. O administrador digita o código atual para confirmar que o app foi configurado corretamente.
5. Só então Enabled é marcado como 1 e os códigos de recuperação são exibidos uma única vez.

Exemplo mínimo de verificação em PHP usando uma biblioteca TOTP:

require 'vendor/autoload.php';
use OTPHP\TOTP;

// segredo recuperado e decifrado do banco
$totp = TOTP::createFromSecret($secretBase32);
$totp->setPeriod(30);

if ($totp->verify($_POST['codigo'], null, 1)) { // janela de tolerância = 1
    // valida também LastUsedStep para evitar replay
    liberarLogin($accountId);
} else {
    registrarFalha2FA($accountId, $_SERVER['REMOTE_ADDR']);
}

O terceiro parâmetro (1) permite uma janela de tolerância para pequenas dessincronizações de relógio. Não aumente esse valor além de 1 sem necessidade, pois amplia a janela de ataque.

Passo 3 — Proteger o acesso ao sistema operacional

O painel protegido não adianta nada se o atacante consegue RDP ou SSH direto na máquina. Em servidores Windows, evite expor a porta 3389 (RDP) à internet; coloque tudo atrás de uma VPN e, se possível, exija 2FA na VPN. Para RDP em si, ferramentas como Duo ou soluções equivalentes adicionam um prompt de aprovação. Em Linux, configure o pam_google_authenticator no SSH:

sudo apt install libpam-google-authenticator
google-authenticator   # gera o QR e os códigos de recuperação por usuário

Depois, edite /etc/pam.d/sshd para incluir auth required pam_google_authenticator.so e ajuste ChallengeResponseAuthentication yes (ou KbdInteractiveAuthentication yes em versões recentes) no sshd_config. Combine sempre com autenticação por chave pública, nunca 2FA sozinho substituindo a chave.

Passo 4 — Proteger o banco de dados

O SQL Server não tem TOTP nativo, mas você reduz o risco assim:

• Nunca exponha a porta 1433 à internet. Acesso só via VPN ou túnel.
• Use autenticação do Windows (Integrated) sempre que possível, herdando o 2FA do login do SO.
• Crie contas de aplicação com privilégio mínimo (apenas as tabelas necessárias), separadas das contas administrativas.
• Registre e alerte sobre logins da conta sa.

Passo 5 — 2FA para GM dentro do jogo

Alguns emuladores permitem exigir um passo extra para comandos de GM. Como poucos suportam TOTP nativo, uma abordagem prática é liberar os comandos administrativos mais perigosos (criar item, dar zen, ban) apenas a partir de contas cujo login web já passou por 2FA, ou exigir uma senha administrativa secundária in-game. Isso varia bastante por season/emulador; consulte a documentação do seu core antes de editar binários.

Tabela de camadas e métodos recomendados

Tabela de fatores por sensibilidade da conta

Erros comuns e soluções

Boas práticas de recuperação e rotação

Gere de 8 a 10 códigos de recuperação de uso único no cadastro e armazene apenas o hash deles no banco. Instrua a equipe a guardá-los offline. Defina um processo de reset que exija verificação por segundo canal conhecido (ligação, presença física), porque a engenharia social contra o suporte é o vetor mais comum para derrubar o 2FA. Faça rotação periódica dos segredos e revogue imediatamente o acesso de qualquer membro que saia da equipe.

Checklist de lançamento

• Todas as contas de staff inventariadas e classificadas por sensibilidade
• Tabela Staff2FA criada com segredos cifrados
• Relógio do servidor sincronizado via NTP (UTC)
• 2FA obrigatório no painel web para todo staff
• Proteção contra replay (LastUsedStep) validada
• Limite de tentativas e bloqueio por força bruta ativos
• VPN com MFA na frente de RDP/SSH/SQL
• Porta 1433 e 3389 fechadas para a internet
• Códigos de recuperação gerados e guardados offline
• Processo de reset por segundo canal documentado
• Conta de emergência testada e guardada em cofre
• Equipe treinada sobre phishing e SIM swap

Com o 2FA implantado em todas as camadas, você elimina a maioria dos cenários em que uma senha vazada vira um servidor comprometido. Se você ainda está montando a estrutura do zero, vale revisar o guia de como criar servidor de MU Online para garantir que a base de segurança esteja correta desde o início. Lembre-se: 2FA é uma camada, não uma bala de prata. Combine-o com senhas fortes, privilégio mínimo e monitoramento contínuo para uma defesa realmente sólida.

Perguntas frequentes