Como proteger o seu servidor de MU Online contra ataques DDoS
A mitigação de rede já vem inclusa, mas metade da proteção depende de você. As portas a fechar, o banco a esconder e como saber se a queda foi ataque mesmo.
Servidor de MU Online cai no dia do lançamento, some no meio do Castle Siege, volta sozinho meia hora depois. A conclusão automática é sempre a mesma: fui atacado.
Às vezes foi. Muitas vezes não. E em qualquer um dos casos, existe uma parte da proteção que a hospedagem entrega e outra que depende inteiramente de como a sua máquina está configurada.
Este guia cobre as duas.
Por que servidor de MU Online é alvo
Não é preciso ser grande para ser atacado. O cenário de MU Online tem três características que fazem disso rotina:
Muitos servidores disputando o mesmo público. Quando dezenas de projetos brigam pelos mesmos jogadores, derrubar o concorrente no dia do lançamento é uma tática que, infelizmente, alguém sempre usa.
Momentos previsíveis. Lançamento, abertura de season, Castle Siege, evento grande. O atacante sabe exatamente quando o estrago é maior.
O IP é público por natureza. Ele está no seu site, no launcher, no seu Discord, no print que alguém postou. Não tem como esconder de verdade.
Some a isso o fato de que contratar um ataque virou coisa barata, e você entende por que servidor pequeno também apanha.
A parte que já está resolvida
Na WyzeHost a proteção DDoS vem inclusa em todos os planos, sem custo extra e sem configuração da sua parte. O IP já nasce protegido, com o tráfego passando continuamente por filtragem em vez de ser descartado quando o ataque começa.
Essa diferença importa mais do que parece. Muita hospedagem responde a ataque com null-route: joga fora todo o tráfego do seu IP, o legítimo junto com o malicioso. O ataque para e o seu servidor também. Explicamos isso em detalhe em proteção DDoS: o que é e por que importa.
Com a mitigação inline, o ataque volumétrico deixa de ser problema seu. Mas ele é só um dos vetores.
A parte que depende de você
Proteção de rede cuida do ataque que tenta entupir a banda. Ela não fecha porta aberta, não cria senha forte e não esconde o seu banco de dados. Essa metade é configuração da sua máquina, e é onde a maioria dos servidores está vulnerável.
Feche tudo que não precisa estar aberto
Um servidor de MU Online precisa de exatamente três portas abertas para os jogadores:
| Porta | Serviço |
|---|---|
| 44405 | ConnectServer |
| 55901 | GameServer |
| 55919 | GameSSiege |
Se o site da comunidade estiver na mesma máquina, some a 80 e a 443. Só isso.
O erro comum é liberar o programa em vez da porta, ou abrir uma faixa inteira "por garantia". Cada porta aberta a mais é uma superfície que alguém pode sondar, sem nenhuma contrapartida.
O passo a passo de criar a regra correta está em como configurar e ligar um servidor de MU Online, e a versão genérica em como abrir uma porta na sua VPS.
Não deixe o SQL Server exposto
Esse é o ponto mais negligenciado, e o mais perigoso.
Para o site e os editores funcionarem, o SQL Server precisa aceitar conexão externa na porta 1433. O problema é deixar essa porta aberta para a internet inteira.
Banco exposto recebe tentativa de login automatizada todos os dias. E o alvo é
sempre o mesmo usuário, o sa, que existe em toda instalação. Se a senha for
fraca, não é questão de se, é de quando.
Duas medidas resolvem quase tudo:
- Restrinja a porta 1433 por IP no firewall, liberando apenas o endereço de onde você acessa. Se o site roda na mesma máquina, ele nem precisa da porta aberta para fora.
- Senha longa no
sa, sem palavra de dicionário e sem repetir de outro serviço
Vale lembrar: quem entra no seu banco não precisa derrubar nada. Ele apaga, copia ou vende os personagens dos seus jogadores, o que é bem pior que uma hora offline.
Proteja o acesso remoto
A porta padrão do acesso remoto do Windows é varrida o tempo todo. Trocar não é segurança absoluta, mas derruba quase todo o volume de tentativa automática.
O procedimento está em como trocar a porta RDP da sua VPS.
E o mesmo raciocínio da porta 1433 se aplica aqui: se você sempre acessa do mesmo lugar, restrinja o acesso remoto ao seu IP.
Cuidado com o que vaza sem você perceber
Você não consegue esconder o IP do servidor, mas consegue evitar entregar o resto:
- Print de painel com IP, senha ou nome de usuário visível
- Vídeo de tutorial gravado com a área de trabalho da VPS aberta
- Arquivo de configuração enviado no Discord "para alguém ajudar", com a senha do banco dentro
Antes de mandar um GameServer.lua para alguém, apague a senha. Antes de postar
um print, olhe a barra de título.
Backup fora da máquina
Backup não impede ataque, mas é o que separa um susto de um projeto encerrado.
Backup que mora no mesmo servidor não é backup: se a máquina for comprometida, ele vai junto. Guarde em outro lugar e mantenha uma rotina, não uma cópia de seis meses atrás.
Nem toda queda é ataque
Antes de concluir que foi DDoS, vale eliminar as causas mais comuns. No MU Online, "o servidor caiu" costuma ser uma destas:
| Sintoma | Causa provável |
|---|---|
| GameServer fecha sozinho, os outros seguem | Erro de script ou conexão com o banco |
| Tudo trava junto e a máquina fica lenta | Memória no limite, geralmente o SQL Server |
| Servidor no ar, mas ninguém conecta | Firewall, ODBC ou serviço parado |
| Cai sempre no mesmo horário | Tarefa agendada, backup ou reinício automático |
| Cai só em evento cheio | Plano pequeno demais para o pico |
| Cai do nada, com a máquina saudável | Aí sim, provavelmente ataque |
A checagem rápida: abra o Gerenciador de Tarefas na VPS. Se você consegue acessar a máquina normalmente e o processador e a memória estão tranquilos, mas os jogadores não conectam, o problema está na rede. Se a máquina está sufocada, o problema é dimensionamento, e o caminho está em como escolher a VPS para o seu servidor de MU Online.
Errar esse diagnóstico é caro: tem gente que troca de hospedagem por causa de um script em loop.
O que fazer quando acontecer
Não troque de IP no susto. Trocar significa reconfigurar os três arquivos do servidor, gerar o cliente de novo e distribuir para todo mundo. Com mitigação inline, isso é desnecessário.
Abra um ticket com horário e sintoma. Quanto mais preciso, mais rápido o diagnóstico: a que horas começou, se você conseguia acessar a máquina, se todos os jogadores caíram ou só alguns.
Não anuncie o ataque em detalhes. Confirmar publicamente que o ataque funcionou é o incentivo que quem atacou está esperando. Avise que houve instabilidade e siga.
Depois que passar, revise a lista acima. Ataque costuma ser o momento em que as pessoas descobrem que estavam com a 1433 aberta para o mundo.
Resumindo quem cuida do quê
| Camada | Quem resolve |
|---|---|
| Ataque volumétrico contra a rede | A hospedagem, com mitigação inclusa |
| Portas abertas sem necessidade | Você, no firewall |
| Banco de dados exposto | Você, restringindo por IP |
Senha fraca no sa ou no Windows | Você |
| Acesso remoto na porta padrão | Você |
| Perda de dados | Você, com backup fora da máquina |
As duas metades se somam, não se substituem. A melhor mitigação do mundo não
protege um banco com senha 123456.
O restante das práticas está em como manter a segurança da sua VPS, e os detalhes técnicos da nossa estrutura na página de proteção DDoS.
Nos planos para MU Online da WyzeHost a proteção já vem inclusa em todos, do plano de entrada ao maior, com servidores no Brasil e suporte 24 horas.
