Como configurar o firewall por porta (game/connect/web) no MU Online

Configurar o firewall por porta é uma das tarefas mais importantes — e mais mal executadas — na administração de um servidor de MU Online. Muitos donos de servidor simplesmente desligam o firewall inteiro para "resolver" um problema de conexão, e com isso escancaram o SQL Server, o painel administrativo e serviços internos para toda a internet. O resultado é previsível: contas invadidas, banco de dados vazado e servidor derrubado. A abordagem correta é o oposto: negar tudo por padrão e liberar apenas as portas que os jogadores e o site realmente precisam. Neste guia você vai aprender a separar as portas em três grupos — game, connect e web — e a criar regras cirúrgicas no Windows Firewall que mantêm o servidor acessível e, ao mesmo tempo, fechado para o que não deve ser exposto.

Este tutorial assume um servidor Windows (Windows Server 2016/2019/2022 ou Windows 10/11 em ambiente de testes) com um MuServer já instalado. Se você ainda está montando a base do seu projeto, comece pelo passo a passo de como criar servidor de MU Online e volte aqui quando os processos já estiverem subindo corretamente.

Pré-requisitos

Antes de tocar em qualquer regra, garanta que você tem:

• Acesso administrador ao Windows do servidor (PowerShell ou Prompt de Comando elevado).
• Acesso alternativo ao servidor via console KVM/VNC do painel do provedor de VPS. Isso é inegociável: se você errar uma regra e perder o RDP, o console é a única forma de recuperar o acesso sem chamar o suporte.
• O IP fixo do seu computador de administração (descubra em sites como "meu ip"). Ele será usado para restringir o RDP.
• Os arquivos de configuração do seu MuServer em mãos, principalmente o ConnectServer.ini e o arquivo de definição dos GameServers.
• Um bloco de notas para documentar cada porta antes de liberar.

Entendendo os três grupos de portas

O erro conceitual mais comum é tratar todas as portas igual. Na prática, um servidor de MU tem portas com três finalidades muito diferentes, e cada grupo pede uma política distinta.

Connect é o ponto de entrada. Quando o jogador abre o cliente, o main.exe conecta no ConnectServer, recebe a lista de sub-servidores e o IP/porta de cada um. Essa porta precisa estar aberta para o mundo inteiro, senão ninguém sequer vê a tela de seleção de servidor.

Game são os sub-servidores propriamente ditos. Depois de escolher o servidor na lista, o cliente abre uma nova conexão direto no GameServer correspondente. Cada sub-servidor costuma ter sua própria porta. Também precisam estar públicas.

Web é o site/painel do servidor (registro de conta, ranking, loja de doação). Só existe exposição aqui se o site estiver na mesma máquina do jogo. É o grupo mais sensível porque atrai ataques de aplicação (SQL injection, força bruta no login do admin).

Além desses três, existe um quarto grupo que nunca deve ser exposto: as portas internas (DataServer, JoinServer, EventServer) e o SQL Server. Elas conversam apenas dentro da própria máquina.

Etapa 1: mapear as portas reais do seu servidor

Não confie em números "de cor". Abra os arquivos de configuração e anote o que está realmente configurado. Os caminhos e nomes variam por provedor/versão de MuServer, mas a lógica é sempre a mesma.

No ConnectServer.ini (dentro da pasta do ConnectServer, algo como ConnectServer/Data/ConnectServer.ini) procure algo como:

[ConnectServerInfo]
ConnectServerPortTCP = 44405
MaxUserCount = 1000

No arquivo de lista de servidores que o Connect entrega ao cliente (frequentemente ServerList.dat ou um .xml/.ini equivalente), confira as portas de cada GameServer:

[Server1]
ServerName = ViciadosMU - Season 6
IP = 0.0.0.0
Port = 55901

[Server2]
ServerName = ViciadosMU - PvP
IP = 0.0.0.0
Port = 55902

Monte uma tabela como esta com os seus valores (os abaixo são apenas exemplo, variam por provedor/versão):

Confirme quais portas estão de fato em escuta com:

netstat -ano | findstr "LISTENING" | findstr "44405 55901 55902 1433 3389"

Etapa 2: definir a política padrão de bloqueio

O princípio de segurança correto é o default deny: bloqueie tudo que entra e libere só o necessário. Antes de aplicar, crie a regra de RDP (Etapa 3, passo 1) — mas conceitualmente a política vem primeiro.

netsh advfirewall set allprofiles state on
netsh advfirewall set allprofiles firewallpolicy blockinbound,allowoutbound

O primeiro comando garante que o firewall está ligado nos três perfis (Domínio, Privado, Público). O segundo define a política: bloquear entrada, permitir saída.

Etapa 3: liberar as portas na ordem correta

Siga esta ordem numerada. Ela foi pensada para você nunca se trancar para fora.

1. Libere o RDP apenas para o seu IP (troque 203.0.113.10 pelo seu IP real):

netsh advfirewall firewall add rule name="ADMIN - RDP restrito" dir=in action=allow protocol=TCP localport=3389 remoteip=203.0.113.10

1. Libere o ConnectServer (grupo connect) para todos:

netsh advfirewall firewall add rule name="MU - ConnectServer 44405" dir=in action=allow protocol=TCP localport=44405

1. Libere os GameServers (grupo game). Uma regra por porta deixa o log mais legível:

netsh advfirewall firewall add rule name="MU - GameServer 1 (55901)" dir=in action=allow protocol=TCP localport=55901
netsh advfirewall firewall add rule name="MU - GameServer 2 (55902)" dir=in action=allow protocol=TCP localport=55902

Se você tem muitos sub-servidores em sequência, um intervalo resolve:

netsh advfirewall firewall add rule name="MU - GameServers 55901-55910" dir=in action=allow protocol=TCP localport=55901-55910

1. Libere o grupo web — apenas se o site estiver na mesma máquina:

netsh advfirewall firewall add rule name="WEB - HTTP 80" dir=in action=allow protocol=TCP localport=80
netsh advfirewall firewall add rule name="WEB - HTTPS 443" dir=in action=allow protocol=TCP localport=443

1. Bloqueie explicitamente as portas internas e o SQL para a internet. Como a política já é block, isso é redundante em teoria, mas uma regra de bloqueio explícita protege contra futuras liberações acidentais e serve de documentação:

netsh advfirewall firewall add rule name="BLOCK - SQL 1433 externo" dir=in action=block protocol=TCP localport=1433
netsh advfirewall firewall add rule name="BLOCK - DataServer 55960 externo" dir=in action=block protocol=TCP localport=55960
netsh advfirewall firewall add rule name="BLOCK - JoinServer 55970 externo" dir=in action=block protocol=TCP localport=55970

Etapa 4: reforçar o SQL Server no nível do serviço

Bloquear a 1433 no firewall é bom, mas a defesa em profundidade manda amarrar o próprio SQL ao loopback. Abra o SQL Server Configuration Manager → SQL Server Network Configuration → Protocols → TCP/IP → aba IP Addresses. Deixe habilitado apenas o IPAll/IP1 correspondente a 127.0.0.1 e desabilite os endereços que apontam para o IP público. Assim, mesmo que alguém libere a 1433 por engano, o SQL não estará escutando na interface pública.

Etapa 5: fazer a mesma coisa pela interface gráfica (opcional)

Se preferir clicar em vez de digitar, rode wf.msc e siga:

1. Regras de Entrada → Nova Regra.
2. Tipo Porta → TCP → informe a porta (ex.: 44405).
3. Permitir a conexão.
4. Marque os três perfis (Domínio, Privado, Público).
5. Dê um nome padronizado, como MU - ConnectServer 44405.

Para restringir por IP (caso do RDP), depois de criar a regra: botão direito → Propriedades → aba Escopo → em Endereço IP remoto escolha "Esses endereços IP" e adicione o seu.

Etapa 6: testar de fora para dentro

Testar de dentro do próprio servidor engana, porque o tráfego local não passa pelas mesmas regras de internet. Teste de fora:

• Peça a um amigo (ou use o celular no 4G, fora do Wi-Fi) para abrir o cliente e verificar se a lista de servidores carrega (valida o Connect) e se ele entra no mundo (valida o Game).
• De outra máquina, confirme que a 1433 está fechada. Uma forma simples no PowerShell:

Test-NetConnection -ComputerName SEU_IP_PUBLICO -Port 1433

O resultado esperado é TcpTestSucceeded : False. Se der True, o SQL está exposto — pare tudo e corrija antes de seguir.

Erros comuns e soluções

Checklist de lançamento

• Todas as portas reais mapeadas a partir dos arquivos .ini (não de memória)
• Regra de RDP restrita ao meu IP criada antes do bloqueio geral
• Política padrão definida como blockinbound,allowoutbound
• ConnectServer liberado para a internet
• Cada GameServer com sua regra de entrada
• Portas web (80/443) liberadas somente se o site está na mesma máquina
• SQL (1433) e portas internas explicitamente bloqueadas
• SQL Server escutando apenas em 127.0.0.1
• Teste feito de fora (celular/amigo) validando Connect e Game
• Test-NetConnection confirmando a 1433 fechada
• Backup das regras exportado com netsh advfirewall export
• Acesso KVM/VNC do provedor testado e funcionando

Com esse mapeamento por grupo, seu servidor passa a expor exatamente o que os jogadores precisam e nada além disso. É a base de segurança sobre a qual você vai empilhar depois o anti-flood, o anti-DDoS e o hardening do painel web — mas tudo começa por saber, com precisão, quais portas estão abertas e por quê.

Perguntas frequentes