Secure RDP Configuration for Windows VPS

Setting up Remote Desktop (RDP) on a fresh Windows VPS is your first step to actual work. But leaving the default config, any user, any network, port 3389 wide open, is asking for trouble. Bots scan the entire IPv4 space for port 3389 and hammer it with password attempts immediately. This article runs through the practical hardening: a few targeted changes that knock out the bulk of the attacks. It is based on running Windows Server VPS deployments in a real IPv4 datacenter environment (the same kind you get with a Windows VPS at thueVPS, full Administrator access, no shared hypervisor tricks).

• Key takeaways:
• Change the default RDP port (3389), bots scan only the default; a non-standard port drops 99% of junk traffic.
• Enforce Network Level Authentication (NLA), stops credential exposure over the unencrypted pre-auth phase.
• Restrict RDP access to a specific set of users, no Administrator logins via RDP.
• Tighten Windows Firewall to allow RDP only from source IPs you trust (or a jump box / VPN).
• Enable logging and audit RDP login events, you will see the failed attempts drop to zero after you lock it.

Prerequisites

• A Windows VPS, any version from Windows Server 2019, 2022, or 2025 works. The commands and GUI paths are identical across these versions. You need Administrator access (RDP or console).
• The VPS must be joined to a network with internet access, you will download nothing for this guide, but you need to apply firewall rules afterwards.
• Basic familiarity with Registry Editor (regedit), Windows Firewall snap‑in, and Local Group Policy Editor (gpedit.msc) is assumed. If you have never opened regedit before, do a dry run first.
• A static public IP address from which you intend to connect. If you connect from a dynamic IP, use a VPN into your VPS first, then RDP over the VPN tunnel.

Why default RDP config is an active risk

Windows RDP listens on TCP port 3389 by default. Public scanners (Shodan, Censys, and random botnets) sweep every possible IPv4 address for this port. The moment they find it, they launch credential stuffing attacks, common usernames (Administrator, admin, user) paired with the Top-1000 worst passwords. If you leave the default Administrator account enabled with a trivial password, the VPS gets compromised within hours. Even with a strong Administrator password, a determined attacker with patience can brute‑force it over days or weeks if the port is open to the whole internet. The fixes below cut that surface area drastically.

Step 1, Change the default RDP port (3389 → something else)

Changing the port stops automated mass‑scanning. It does not make you invisible to a targeted scan (someone can scan all 65535 ports of your IP), but the noise level drops from thousands of daily attempts to zero unless someone specifically targets you. This is a Registry change, followed by a firewall rule update and a reboot.

Open Registry Editor as Administrator (regedit). Navigate to:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Find the PortNumber value (type REG_DWORD). Double‑click it, select Decimal, and type a number above 1024 and below 65535 that does not conflict with known services. I personally use the range 50000, 55000. For this example, set it to 50001.

Do not use obvious alternate ports (3390, 3391, 33890), botnets already check common alternates. Pick a random five‑digit number you can remember. Write it down.

Close Registry Editor. Now update Windows Firewall before you reboot, otherwise you will lock yourself out (RDP won’t respond on the new port).

Step 2, Update Windows Firewall for the new RDP port

Open Windows Defender Firewall with Advanced Security (run wf.msc). Locate the inbound rule named Remote Desktop, User Mode (TCP-In). There are usually two such rules, one for TCP and one for UDP. For each rule:

1. Right‑click → Properties → Protocols and Ports tab.
2. Under Local Port, change 3389 to your new port, e.g. 50001.
3. Click OK.

Remove the old 3389 rule: there is usually a separate rule named Remote Desktop (TCP-In) with the local port 3389. Disable it (right-click → Disable Rule), do not delete it, you may want to revert. Check both Private and Domain profiles.

Now add a scope restriction (optional but recommended) on the same rule: Properties → Remote IP Address → These IP addresses → add the public IP address (or IP range) you will connect from. If you have a fixed office IP, add that. If you use a VPN, add the VPN server’s internal IP or the VPN client‑assigned subnet. If you cannot add a scope (dynamic IP), skip this, but pair it with a VPN tunnel for real security.

Reboot the VPS (shutdown /r /t 0). After reboot, connect using mstsc /v:YOUR_VPS_PUBLIC_IP:50001 (replace port). Do not proceed until you have a successful connection on the new port.

Step 3, Enforce Network Level Authentication (NLA)

NLA forces the RDP client to authenticate before the full RDP session starts. This means the initial credential exchange happens inside an encrypted TLS tunnel, not in plaintext during the early session negotiation. Attackers who attempt a brute‑force over RDP without NLA can detect the Windows version and try older protocol downgrade attacks. With NLA enabled, pre‑authentication is mandatory, no credential exposure before encryption.

Open System Properties (right‑click This PC → Properties → Remote desktop → Advanced settings). Under Remote Desktop, check:
“Require use of Network Level Authentication to connect”.

If this is greyed out, you have a group policy override, verify via gpedit.msc:

Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Security

Policy: “Require user authentication for remote connections by using Network Level Authentication”, set to Enabled.

Test: after applying, try connecting from a client that does not support NLA (e.g. an RDP client from Windows 7 without update). The connection should be rejected before the login screen appears. On a modern Windows 10/11 client, NLA is on by default, you will not notice a difference, but the backend is encrypted from step zero.

Step 4, Restrict RDP access to specific users

By default, any member of the Remote Desktop Users group (and Administrators) can log in via RDP. On a fresh VPS, the built‑in Administrator account is both an Administrator and the only user, that is a single point of failure.

Create a separate non‑admin user for daily RDP work, then remove the Administrator account from the Remote Desktop Users group.

1. Open Computer Management → Local Users and Groups → Users.
2. Right‑click empty area → New User. Set a username (e.g. srvadmin), a strong password (16+ characters, mixed case, numbers, symbol), uncheck User must change password at next logon, check Password never expires only if you have a password rotation policy (otherwise leave it unchecked).
3. Right‑click the new user → Properties → Member Of tab → Add → type Remote Desktop Users → check Ok.
4. Now remove the Administrator account from the same group (optional but recommended: if you keep Administrator in the group, you have two potential login vectors). Right‑click Administrator → Properties → Member Of → select Remote Desktop Users → Remove.

Log out and test: connect with the new user srvadmin on the custom port. If it works, delete or rename the built‑in Administrator account (otherwise a brute‑force attempt against that username is still possible). Renaming is safer than deletion, some older software expects the Administrator SID. Right‑click Administrator → rename to something obscure like svc_localadm. Set a ridiculously long password on it (40+ characters) that you store in a password manager. No one logs in as this user ever again.

Step 5, Lock down RDP via Windows Firewall with IP whitelisting

You already scoped the port change, now add an IP whitelist to the Remote Desktop, User Mode (TCP-In) rule (the same one you edited earlier). This step only works if you connect from one or a small set of static IP addresses. For dynamic IPs, skip the whitelist and use a VPN instead.

Open wf.msc. Find your RDP inbound rule (it now listens on the custom port). Right‑click → Properties → Scope tab. Under Remote IP address → select These IP addresses → add your trusted public IPs one by one. Do not add 0.0.0.0/0. If you connect from a home IP that changes, you will lock yourself out, configure a DDNS hostname and script the firewall rule update, or use a VPN.

For VPN users: if you run a WireGuard or OpenVPN server on the same VPS, add the VPN virtual interface subnet (e.g. 10.0.0.0/24) to the allowed remote IPs, then connect to RDP via the VPN IP (mstsc /v:10.0.0.2:50001). This adds an encryption layer on top of RDP and hides RDP from the public internet entirely.

Step 6, Enable RDP security logging and review it

Windows records every RDP login attempt as Event ID 4625 (failed) and 4624 (successful), logged under Windows Logs → Security. If you have done the hardening above, you should see zero failed attempts after the first hour. If you still see login failures, you have either left a rule open or a back‑door user.

To enable logging (it is on by default in Audit Policy):

gpedit.msc → Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Logon/Logoff → Audit Logon → check Success and Failure.

On a non‑domain machine, the default audit policy already logs logon events. You can verify by running eventvwr.msc → Security → Filter Current Log → Event IDs 4624 and 4625.

Troubleshooting tip: if you see many 4625 events even after hardening, check the firewall scope, an IP outside your whitelist can still reach the port but gets rejected at the RDP layer instead of the firewall layer. That means the firewall rule is too permissive. Re‑check the rule scope and restrict further.

Troubleshooting

I changed the port and cannot connect anymore

First, verify the new port is reachable from your client using a port scanner (Test-NetConnection YOUR_VPS_IP -Port 50001 in PowerShell). If it shows TcpTestSucceeded : True, the firewall is correct and the issue is with the RDP service itself, restart the Remote Desktop Services service (net stop TermService & net start TermService) from an out‑of‑band connection (VPS console). If it shows False, the Windows Firewall rule for the new port is missing or scoped incorrectly, add the rule again and check the profile (Domain/Private/Public).

NLA checkbox is greyed out

This happens when group policy overrides the local setting. Run gpedit.msc and navigate to the path listed in Step 3. Ensure the policy is set to Enabled and not Not Configured. Then run gpupdate /force and reboot. After reboot, the checkbox in System Properties should now be checked and modifiable.

Remote Desktop Users group does not allow the built-in Administrator

If you removed Administrator from the Remote Desktop Users group but still want to allow it (not recommended), add the Administrator account back via the same group membership dialog. In practice, after creating a separate user, you never need administrative RDP access as Administrator, you can do everything with srvadmin plus User Account Control elevation.

FAQ

Bài viết liên quan

• Hardening SSH on a new VPS, keys, ports, fail2ban, and CrowdSec
• Encrypt a VPS disk with LUKS on Ubuntu 24.04
• Security audit and hardening with Lynis on a VPS