How to set up secure remote access (RDP) on your MU server

RDP (Remote Desktop Protocol) is the doorway through which you administer your MU server — and that's exactly why it's the favorite target of anyone trying to break in. Leaving port 3389 open to the entire internet, with an "Administrator" account and a mediocre password, is practically an invitation: there are botnets that scan entire IP ranges looking for exposed RDP and testing thousands of passwords per hour. A MU server compromised this way means a stolen database, duplicated items, leaked player accounts and, quite often, ransomware. The good news is that you can keep all the convenience of Remote Desktop while closing off nearly all of that attack surface with a few well-placed layers.

This guide shows how to turn an "open and vulnerable" RDP into a hardened remote access, layer by layer. If you're still building out the server's infrastructure, first take a look at the step-by-step guide on how to create a MU Online server; here we'll assume Windows is already up and you access it via RDP today.

Prerequisites

• Windows server (Windows Server 2016/2019/2022 are the most common on MU VPS setups).
• An account with administrator privileges.
• Access to the KVM/VNC console in your VPS provider's panel — the safety net in case you lock yourself out. Confirm that it works before you start.
• Your public administration IP (check it at "my ip"). If it changes frequently, consider getting a static IP, a VPN, or a second "bastion" server with a static IP.
• 30 to 40 minutes without players depending on the server, or at least an off-peak time slot.

Overview of the defense layers

Remote access security isn't a single setting, it's a stack. Each layer on its own can be bypassed; together, they greatly raise the cost of an attack. We'll apply them in this order:

Order matters: start with IP restriction, which gives the biggest gain for the lowest risk, and keep stacking from there.

Step 1: restrict RDP to your IP in the firewall

This is the single most effective measure. Instead of leaving 3389 open to 0.0.0.0/0, allow only your IP. In an elevated PowerShell/Command Prompt (replace 203.0.113.10 with your real IP):

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

If you administer from two or three fixed locations (home, work), you can list several IPs separated by commas in remoteip. Next, remove or disable any old rule that opens RDP to everyone:

netsh advfirewall firewall show rule name=all dir=in | findstr /i "3389 Desktop Remote"

Identify generic "Remote Desktop" rules and restrict their scope (or disable them), leaving only your IP-based rule in effect.

Step 2: harden the access accounts

Bots assume there's an account named Administrator/Administrador. Take that target off the map.

1. Open lusrmgr.msc (Local Users and Groups).
2. Rename the default Administrator account to something non-obvious (e.g., gm_root_2024).
3. Create a separate administration account, also with a non-obvious name, and use it day to day.
4. Set a strong password: 16+ characters, mixing uppercase, lowercase, numbers and symbols. No server name, "mu123", dates or keyboard patterns.

Enforce the password policy in secpol.msc → Account Policies → Password Policy:

• Minimum length: 14
• Complexity: Enabled
• Maximum age: 90 days (or per your routine)

Step 3: enable account lockout

Without lockout, an attacker can test passwords endlessly. Configure it in secpol.msc → Account Policies → Account Lockout Policy:

With this, after 5 wrong passwords the account locks for 15 minutes, making brute force impractical. Just be careful not to lock yourself out: that's why IP restriction (Step 1) comes first — it keeps bots from consuming your attempts.

Step 4: ensure NLA (Network Level Authentication) is on

NLA requires the user to authenticate before the desktop session is created, which saves resources and blocks a range of attacks. On modern Windows versions it's usually enabled by default, but confirm it:

• SystemPropertiesRemote.exe → Remote tab → check "Allow connections only from computers running Remote Desktop with Network Level Authentication".

Quick check via PowerShell:

Get-ItemProperty "HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name UserAuthentication

A value of 1 indicates NLA is active. If it's 0, enable it through the interface above.

Step 5: change the default RDP port

Changing 3389 to another port is security through obscurity — it doesn't replace the previous layers, but it greatly reduces the noise from automated scans that only hit 3389. The exact number is up to you; use an uncommon high port (the value below is just an example and varies by environment).

1. Edit the registry at HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp, the PortNumber key (set it in decimal, e.g., 53389):

Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name PortNumber -Value 53389

1. Open the new port in the firewall, still restricted to your IP:

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

1. Restart the Remote Desktop service (or the server). From then on, connect by specifying the port in the client: YOUR_IP:53389.

Step 6: audit access attempts

Enable logon auditing to see who's trying to get in. In secpol.msc → Local Policies → Audit Policy, enable "Audit logon events" for failure (and success too, if you want to track your own access).

In the Event Viewer (eventvwr.msc) → Windows Logs → Security, event 4625 records logon failures, including the source IP. You can automate blocking repeat-offender IPs with a scheduled script that reads these events and creates firewall rules:

# Blocks IPs with many logon failures in the last few hours (example, adjust the limits)
$limite = 10
$desde  = (Get-Date).AddHours(-2)

$falhas = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=$desde} -ErrorAction SilentlyContinue
$ips = $falhas | ForEach-Object {
    ($_.Properties | Where-Object { $_.Value -match '^\d+\.\d+\.\d+\.\d+$' }).Value
} | Group-Object | Where-Object { $_.Count -ge $limite }

foreach ($grupo in $ips) {
    $ip = $grupo.Name
    if (-not (Get-NetFirewallRule -DisplayName "AUTOBLOCK RDP - $ip" -ErrorAction SilentlyContinue)) {
        New-NetFirewallRule -DisplayName "AUTOBLOCK RDP - $ip" -Direction Inbound -Action Block -RemoteAddress $ip -Protocol TCP
        Write-Output "$(Get-Date) blocked $ip with $($grupo.Count) failures"
    }
}

Schedule it with Task Scheduler to run periodically. If you've already restricted by IP in Step 1, this script becomes a useful second line of defense, mainly while the port is still reachable from outside.

Step 7: the most secure option — take RDP off the internet with a VPN

The security ideal is for RDP to not be reachable from the internet. With a VPN (WireGuard and OpenVPN are the typical choices), you:

1. Install the VPN server on the VPS itself or on a small bastion host.
2. Make RDP listen only on the internal/private interface.
3. Completely close the RDP port to the public IP in the firewall.
4. Access the server by first connecting to the VPN and then opening RDP over the internal IP.

That way, to an external attacker, the RDP port simply doesn't exist. Alternatively, Windows Remote Desktop Gateway lets you publish RDP over HTTPS (443) with centralized authentication, which also eliminates the direct exposure of 3389. Both approaches take more work, but they're the gold standard for production servers.

Common errors and fixes

Launch checklist

• Provider's KVM/VNC console tested and working
• RDP restricted to my IP in the firewall
• Default Administrator account renamed
• Strong password (14+ characters) and password policy active
• Account lockout configured
• NLA confirmed as active
• Default port changed and new port tested before closing the old one
• Logon auditing enabled and event 4625 being monitored
• Repeat-offender IP blocking script/routine scheduled (if applicable)
• Migration to VPN/bastion evaluated to take RDP off the internet
• Backup of the firewall rules exported
• Documentation of the new access procedure stored in a safe place

With these layers in place, your MU server's remote access is no longer the weakest link. The combination of IP restriction, hardened accounts, lockout and — in the best case — a VPN reduces the attack surface to the point of making an RDP intrusion economically unviable for the overwhelming majority of automated attackers.

Frequently asked questions