How to harden Windows Server for MU Online

MU Online servers are frequent targets — from automated scanners that sweep the internet looking for exposed RDP and SQL, and from rivals who attack to knock the competition offline. A Windows Server that comes up functional after installation is still far from secure: too many open ports, accounts with predictable names, wide-open RDP and unrestricted SQL are invitations to intrusion. Hardening is the process of reducing that attack surface to the minimum needed for the game to run. This guide covers RDP, accounts, firewall, SQL, updates, logs and monitoring, always with the care of not losing access during the process. Ports, names and paths are examples and vary by environment and version.

Prerequisites

• Windows Server already installed and with a functional MuServer (see the how to create a MU Online server guide if you haven't reached this point).
• Administrator access via RDP.
• Access to the VPS provider's console/VNC — essential for recovering access if a firewall rule blocks RDP.
• The ability to take a snapshot of the machine before starting.
• A fixed administrative IP (yours, from where you manage the server) to restrict RDP and SQL.
• SSMS installed for the SQL Server protection steps.

Part 1 — Harden remote access (RDP)

RDP is the most attacked entry point on a public Windows Server. Brute-force attempts on port 3389 are constant.

Step 1: Restrict RDP to your administrative IP

The most effective defense is to allow RDP only from your network. Replace the example IP with your fixed IP:

# Remove the generic RDP rule (if it exists) and create a restricted one
Remove-NetFirewallRule -DisplayName "RDP-Custom" -ErrorAction SilentlyContinue

New-NetFirewallRule -DisplayName "RDP-Admin-Only" `
  -Direction Inbound -Protocol TCP -LocalPort 3389 `
  -RemoteAddress "203.0.113.10" -Action Allow

# Block RDP from any other source
New-NetFirewallRule -DisplayName "RDP-Block-All" `
  -Direction Inbound -Protocol TCP -LocalPort 3389 `
  -Action Block

If your IP is dynamic, use a VPN with a fixed IP or a DDNS service combined with a script that updates the rule.

Step 2: Enable Network Level Authentication (NLA)

NLA requires authentication before establishing the session, cutting off many attacks early:

# Require NLA for RDP connections
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" `
  -Name "UserAuthentication" -Value 1

Step 3: Change the RDP port (complementary obfuscation)

Changing the port isn't real security, but it reduces the volume of scanner noise. Do it alongside the IP restriction, never in place of it:

# Change the RDP port to a high port (example: 33890)
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" `
  -Name "PortNumber" -Value 33890

# Open the new port only for your IP and restart the service afterward
New-NetFirewallRule -DisplayName "RDP-Alt-Admin" -Direction Inbound `
  -Protocol TCP -LocalPort 33890 -RemoteAddress "203.0.113.10" -Action Allow

Part 2 — Harden accounts and passwords

Step 4: Rename and disable predictable accounts

The name Administrator is the first target of any attack. Rename it and create a named administrator:

# Rename the built-in Administrator account
Rename-LocalUser -Name "Administrator" -NewName "adm_mu_root"

# Disable the Guest account, if it's active
Disable-LocalUser -Name "Guest"

Step 5: Apply a strong password policy and account lockout

Set minimum requirements and lockout after failed attempts to slow brute force:

# Minimum length, complexity and history via net accounts
net accounts /minpwlen:14 /maxpwage:90 /uniquepw:5

# Lockout after 5 attempts, for 30 minutes
net accounts /lockoutthreshold:5 /lockoutduration:30 /lockoutwindow:30

Enable complexity in secpol.msc → Account Policies → Password Policy → "Password must meet complexity requirements" = Enabled.

Step 6: Principle of least privilege

Don't run day-to-day tasks as an administrator. Create a separate account for routine operations (restarting services, reading logs) without full administrative powers, and reserve the admin account for structural changes.

Part 3 — Minimize the port surface

Step 7: Audit what's exposed

Before closing ports, see what's actually listening and on which interfaces:

# List listening ports and the owning process of each one
Get-NetTCPConnection -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess |
  Sort-Object LocalPort

Cross-reference each port with the expected process. Any port listening on 0.0.0.0 that isn't MU's (44405, the GameServer range, the web panel) or the restricted RDP is a candidate to be closed.

Step 8: Keep only the essentials open

The table below is an example of a minimal surface for a typical MU server. Exact ports vary by package.

# Ensure SQL never accepts external connections: block 1433 from outside
New-NetFirewallRule -DisplayName "SQL-Block-External" -Direction Inbound `
  -Protocol TCP -LocalPort 1433 -RemoteAddress Any -Action Block

Remember to replicate the minimal policy on the provider's firewall, in the VPS panel.

Part 4 — Protect SQL Server

SQL holds the server's accounts, items and economy — compromising it is compromising everything.

Step 9: Disable or rename the sa login

sa is the default target of SQL attacks. If the server uses a dedicated login (as recommended), disable sa:

-- Disable the sa login (use a dedicated login in MuServer)
ALTER LOGIN sa DISABLE;
GO

-- If you must keep it, at least rename it
ALTER LOGIN sa WITH NAME = [adm_sql_bkp];
GO

Step 10: Strengthen authentication and permissions

Ensure the MuServer login has only the necessary permissions and that passwords follow the policy:

-- Enforce the password policy on the server login
ALTER LOGIN muserver_user WITH CHECK_POLICY = ON;
GO

-- Review who has dangerous server roles (sysadmin)
SELECT p.name, p.type_desc, r.name AS role_name
FROM sys.server_role_members m
JOIN sys.server_principals p ON m.member_principal_id = p.principal_id
JOIN sys.server_principals r ON m.role_principal_id = r.principal_id
WHERE r.name = 'sysadmin';
GO

Step 11: Trust only local connections

If the GameServer and SQL are on the same machine, force SQL to listen only on 127.0.0.1 in the SQL Server Configuration Manager, or keep the external block on 1433 from step 8. That way, even if the password leaks, there's no way to connect from outside.

Part 5 — Updates, logs and monitoring

Step 12: Keep the system updated without outages

Known security flaws are exploited en masse. Apply updates, but control the reboot so you don't knock players offline:

# Check for pending updates (requires the PSWindowsUpdate module)
# Apply in a maintenance window announced to players
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10

Configure Windows Update to download and notify, rebooting manually during low-traffic hours.

Step 13: Enable logon auditing

Enable logging of logon attempts so you can spot attacks:

# Audit logon success and failure
auditpol /set /category:"Logon/Logoff" /success:enable /failure:enable

Step 14: Review security logs periodically

Monitor spikes of logon failures (event 4625), which indicate brute force:

# Count recent logon failures (event 4625)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-24)} `
  -ErrorAction SilentlyContinue | Measure-Object | Select-Object Count

An abnormal volume from the same IP is a sign of attack; combine the firewall restriction with a block on that address. Also consider scripts that automatically ban IPs with many failures.

Step 15: Regular and tested backups

Security includes recovery. Keep automatic backups of the database in a location separate from the VPS (external storage or cloud), and test the restore periodically — a backup that has never been restored isn't a backup, it's hope.

Common errors and fixes

Launch checklist

• Snapshot and provider console access secured
• RDP restricted to the administrative IP
• NLA enabled on RDP
• RDP port changed (complement) and tested
• Administrator account renamed and Guest disabled
• Strong password policy and account lockout applied
• Operations account without full privileges created
• Listening ports audited
• Port surface reduced to the minimum (Windows and provider)
• Port 1433 blocked externally
• sa login disabled or renamed
• SQL permissions reviewed
• Windows Update in download-and-notify mode
• Logon auditing enabled
• Log review routine defined
• Automatic external backup and a tested restore

Conclusion

Hardening isn't a task you do once and forget — it's the discipline of keeping the attack surface small as the server grows. By restricting RDP to your IP, hardening accounts and passwords, closing every non-essential port, shielding SQL Server and keeping an eye on the logs, you take your MU Online off the list of easy targets that scanners and rivals exploit daily. Apply each step carefully, always with a recovery path open, take a snapshot before touching the firewall, and treat updates, log review and backups as continuous routine. A secure server is the one that's still standing on the day the attack arrives — and it always arrives.

Frequently asked questions