Como proteger o seu servidor de Tibia contra ataques DDoS
No OTServer o site fica na mesma máquina que o jogo, e isso dobra a superfície de ataque. O que a hospedagem resolve e o que depende da sua configuração.
O OTServer tem uma particularidade que muda a conversa sobre ataque: o site costuma morar na mesma máquina que o jogo.
Isso significa que existem dois caminhos para derrubar o seu servidor. Um pelas portas do jogo, outro pelo site da comunidade. E o segundo é o mais barato de explorar, porque site aguenta menos que servidor de jogo.
Este guia cobre as duas frentes, e separa o que a hospedagem resolve do que depende de você.
Por que servidor de Tibia é alvo
Concorrência. O cenário de OT é cheio de projetos disputando o mesmo público, e derrubar o concorrente no dia da abertura é tática antiga.
Momentos previsíveis. Abertura do servidor, guerra marcada, evento anunciado. Quem ataca sabe quando dói mais.
Rivalidade dentro do jogo. Guerra de guild não fica só no jogo. É comum a retaliação sair do servidor e virar ataque à infraestrutura.
O IP é público. Ele está no seu site, no seu launcher e no OTServList. Não tem como esconder.
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 tráfego passa continuamente por filtragem em vez de ser descartado quando o ataque começa.
Isso importa porque muita hospedagem responde com null-route: descarta todo o tráfego do seu IP, o legítimo junto com o malicioso. O ataque para e o seu servidor também. Explicamos em proteção DDoS: o que é e por que importa.
O ataque volumétrico deixa de ser problema seu. O resto é configuração.
A parte que depende de você
Feche tudo além do necessário
Um OTServer com site na mesma máquina precisa de poucas portas abertas:
| Porta | Para quê |
|---|---|
| 7171 | Login do servidor |
| 7172 | Jogo |
| 80 e 443 | Site da comunidade, se estiver na mesma máquina |
As portas do jogo são as padrão do OTServ e podem estar diferentes no seu
config.lua. Confira lá antes de criar a regra.
Tudo além disso fica fechado. Se você estiver no Linux, o passo a passo está em como ativar o firewall e liberar portas; se estiver no Windows, em como abrir uma porta na sua VPS.
O MySQL nunca vai para a internet
O banco conversa com o servidor e com o site dentro da própria máquina. Não existe motivo para a porta 3306 estar acessível de fora.
Se você precisa acessar de casa para editar alguma coisa, restrinja ao seu IP em vez de abrir para todos. Banco exposto recebe tentativa automatizada todos os dias, e quem entra não derruba nada: ele copia, apaga ou vende os personagens dos seus jogadores.
O site é o elo mais fraco
Aqui está o ponto específico do Tibia.
Nem todo ataque é volumétrico. Existe o ataque de aplicação, que não entope a banda: ele faz milhares de requisições ao seu site, geralmente nas páginas mais pesadas, como highscore, últimas mortes ou criação de conta.
O efeito é que o site consome a máquina inteira e o jogo cai junto, mesmo sem uma gota de tráfego malicioso chegando na porta 7172.
O que ajuda:
- Manter o AAC atualizado. Versões antigas de Gesior, MyAAC e afins têm falhas conhecidas e públicas.
- Colocar o site atrás de uma CDN, que absorve boa parte desse tipo de requisição antes de chegar na sua máquina
- Separar o site do servidor, se o projeto crescer. Duas máquinas significam que derrubar uma não derruba a outra.
Proteja o acesso administrativo
Se a sua VPS é Linux, o acesso é por SSH, e a porta 22 é varrida o tempo todo. Trocar a porta derruba quase todo o volume de tentativa automática, e o procedimento está em como alterar a porta do SSH.
Melhor ainda é usar chave em vez de senha e instalar o fail2ban, que bloqueia sozinho o IP que insiste em errar.
Se for Windows, o equivalente é trocar a porta do RDP.
Backup fora da máquina
Backup no mesmo servidor cai junto com ele. Guarde em outro lugar, com rotina, e inclua as duas coisas: o banco de dados e a pasta do servidor com o mapa e os scripts, que muita gente esquece.
Nem toda queda é ataque
Antes de concluir DDoS, elimine o que é mais provável:
| Sintoma | Causa provável |
|---|---|
| Site lento e jogo travando junto | Site consumindo a máquina |
| Trava só em guerra ou evento cheio | Processamento ou script |
| Piora ao longo do dia, melhora ao reiniciar | Memória ou vazamento |
| Login demorado, resto normal | Banco de dados |
| Cai sempre no mesmo horário | Backup ou tarefa agendada |
| Delay para todos, o dia inteiro | Distância até o público |
| Cai do nada, com a máquina saudável | Aí sim, provavelmente ataque |
A checagem rápida: acesse a VPS e olhe o consumo. Se processador e memória estão tranquilos e ainda assim ninguém conecta, o problema é rede. Se a máquina está sufocada, é dimensionamento ou script, e o caminho está em como escolher a VPS para o seu servidor de Tibia.
O que fazer quando acontecer
Não troque de IP no susto. Com mitigação inline é desnecessário, e trocar significa mexer no site, no launcher e avisar todo mundo.
Abra um ticket com horário e sintoma. A que horas começou, se você conseguia acessar a máquina, se o site também caiu ou só o jogo. Essa última informação é a que mais acelera o diagnóstico.
Não detalhe o ataque publicamente. Confirmar que funcionou é o incentivo que quem atacou está esperando.
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 acessível de fora | Você, restringindo por IP |
| Site desatualizado ou sem CDN | Você |
| SSH ou RDP na porta padrão | Você |
| Perda de dados | Você, com backup fora da máquina |
As duas metades se somam. Mitigação de rede não conserta um AAC desatualizado.
O restante das práticas está em como manter a segurança da sua VPS, e os detalhes da nossa estrutura na página de proteção DDoS.
Nos planos de Tibia da WyzeHost a proteção já vem inclusa em todos, com servidores no Brasil e suporte 24 horas.
