Como segmentar a rede do GameServer para proteger seu servidor de MU Online

Um servidor de MU Online privado típico expõe, sem perceber, muito mais do que deveria: é comum ver GameServer, ConnectServer, banco de dados e até o painel administrativo web rodando na mesma rede plana, todos acessíveis pela internet nas mesmas portas. Isso transforma qualquer vulnerabilidade em um componente em uma porta de entrada para todos os outros. Segmentar a rede — isolando cada componente em sua própria zona, com regras de firewall explícitas sobre quem pode falar com quem — é uma das medidas de segurança mais efetivas e menos aplicadas por administradores de servidores privados. Este tutorial mostra como planejar e implementar essa segmentação, do desenho da topologia às regras de firewall específicas.

Por que a rede plana é um risco

Em uma rede plana, se um invasor compromete o servidor web (geralmente o componente mais exposto e mais atacado, por rodar um CMS ou painel PHP), ele ganha acesso de rede direto ao banco de dados e ao GameServer, porque não há nenhuma barreira entre eles. Uma vulnerabilidade em um formulário de login do site vira, em poucos passos, um dump completo do banco de contas e itens. Segmentação de rede quebra essa cadeia: mesmo que um componente seja comprometido, o invasor não consegue "pular" lateralmente para os outros sem passar por uma regra de firewall explícita.

Componentes típicos de um servidor de MU e sua exposição ideal

A regra geral: só o ConnectServer e o site precisam estar acessíveis diretamente da internet. Tudo o mais deve viver atrás de um firewall que bloqueia por padrão e libera apenas o necessário.

Desenhando os segmentos de rede

Uma topologia de referência com três segmentos:

[ Internet ]
     |
[ Segmento Público ]  -- ConnectServer, Site/Painel Web
     |  (regra: só portas específicas liberadas)
[ Segmento de Aplicação ]  -- GameServer, DataServer
     |  (regra: só GameServer fala com o banco)
[ Segmento de Banco de Dados ]  -- MSSQL/MySQL

Cada seta representa uma regra de firewall explícita, não uma via aberta. O tráfego entre segmentos deve ser exceção documentada, nunca padrão.

Implementando com VPC e Security Groups (nuvem)

Se o servidor roda em um provedor de nuvem (AWS, Azure, GCP, ou provedores nacionais com VPC), a segmentação é feita via sub-redes privadas e grupos de segurança. Um exemplo de estrutura em uma VPC:

VPC: 10.0.0.0/16
├── Subnet Pública:   10.0.1.0/24  → ConnectServer, Site
├── Subnet Aplicação: 10.0.2.0/24  → GameServer, DataServer
└── Subnet Banco:     10.0.3.0/24  → MSSQL/MySQL

O ConnectServer na subnet pública tem IP acessível da internet (ou atrás de um Load Balancer); GameServer e banco ficam em subnets privadas, sem rota direta para a internet, acessíveis apenas via IP interno.

Regras de firewall por segmento

A tabela abaixo resume as regras mínimas necessárias entre os segmentos:

Note que o site tem seu próprio caminho até o banco, idealmente com uma conta de banco de dados com permissões restritas (somente SELECT em tabelas de ranking, nunca UPDATE/DELETE).

Configurando com iptables (servidor Linux dedicado)

Se os componentes rodam em servidores Linux próprios (não em nuvem gerenciada), iptables ou nftables cumprem o mesmo papel. Um exemplo de regras no servidor de banco, aceitando conexões apenas do IP interno do GameServer:

# Política padrão: bloquear tudo
iptables -P INPUT DROP

# Permitir loopback
iptables -A INPUT -i lo -j ACCEPT

# Permitir apenas o GameServer na porta do MySQL
iptables -A INPUT -p tcp -s 10.0.2.10 --dport 3306 -j ACCEPT

# Permitir SSH apenas de um IP de gestão conhecido
iptables -A INPUT -p tcp -s 198.51.100.5 --dport 22 -j ACCEPT

# Log e drop do restante
iptables -A INPUT -j LOG --log-prefix "IPTABLES-DROPPED: "
iptables -A INPUT -j DROP

Salve as regras com iptables-save e garanta que elas sejam restauradas no boot, ou uma reinicialização deixa o servidor sem proteção.

Isolando o painel administrativo web

O painel administrativo (onde GMs gerenciam contas, itens, eventos) é um alvo particularmente sensível — ele geralmente tem permissões de escrita direta no banco. Nunca o exponha na mesma URL/porta pública do site de jogadores. Recomendações:

• Coloque o painel em um subdomínio ou porta separada, protegido por VPN ou lista de IPs permitidos.
• Use autenticação de dois fatores para contas de administrador.
• Restrinja a conta de banco usada pelo painel às tabelas estritamente necessárias.

Segmentando também a rede de gestão (SSH/RDP)

Um erro comum é segmentar bem os serviços do jogo mas deixar o acesso administrativo (SSH, RDP, painéis de hosting) aberto à internet sem restrição. Trate o acesso de gestão como mais um segmento: libere SSH/RDP apenas a partir de uma VPN de administração ou de uma lista fixa de IPs de confiança, nunca 0.0.0.0/0.

Monitorando e auditando as regras

Segmentação sem monitoramento é uma falsa sensação de segurança. Configure logs de firewall (bloqueios e liberações) e revise periodicamente:

Testando a segmentação

Depois de implementar, valide ativamente que a segmentação funciona como esperado, tentando conexões que deveriam falhar:

1. A partir da internet pública, tente conectar diretamente à porta do banco — deve falhar (timeout ou connection refused).
2. A partir do segmento público (ConnectServer), tente conectar à porta do banco — deve falhar, pois só o GameServer tem permissão.
3. A partir do GameServer, confirme que a conexão ao banco funciona normalmente.
4. Rode um scanner de portas (nmap) de fora da rede contra o IP público — confirme que só as portas esperadas (ConnectServer, site) aparecem abertas.

Erros comuns e soluções

Checklist de segmentação de rede

• Topologia de segmentos desenhada (público, aplicação, banco).
• Apenas ConnectServer e site expostos diretamente à internet.
• Regras de firewall explícitas por origem/destino/porta, bloqueio por padrão.
• Painel administrativo isolado com VPN ou lista de IPs e 2FA.
• Acesso de gestão (SSH/RDP) restrito a VPN ou IPs de confiança.
• Persistência das regras de firewall configurada (sobrevive a reboot).
• Testes ativos de segmentação realizados (tentativas de conexão que devem falhar).
• Monitoramento e logs de firewall configurados com revisão periódica.

Com a rede do GameServer devidamente segmentada, o próximo passo lógico é aplicar o mesmo rigor à camada de dados — veja o tutorial de segregação de rede do banco de dados para aprofundar especificamente a proteção do componente mais sensível de todo o servidor.

Perguntas frequentes