A Windows RDP server is only as safe as the day you hardened it — this guide takes you from a fresh box to a locked-down, offshore remote desktop you can actually trust.
Remote Desktop Protocol (RDP) is the fastest way to run a full Windows environment from anywhere, but it is also one of the most relentlessly scanned services on the internet. The default configuration is convenient and dangerous in equal measure.
This guide covers the real work: initial Windows RDP setup, the settings that actually stop brute-force and exploitation, and how to keep the whole thing offshore from provisioning to daily use.
What you are actually setting up
RDP ships with every Windows Server edition and Windows Pro. It exposes a graphical desktop over TCP port 3389 by default, protected by whatever credentials and network rules you configure — or fail to configure.
The protocol
RDP streams the desktop and input over an encrypted channel. Encryption alone does not authenticate the client — that is what NLA is for.
The risk
Port 3389 is mass-scanned continuously. An exposed server with a weak password is compromised in hours, not weeks.
The goal
A server reachable only by you, authenticated before the desktop ever loads, and not tied to your real identity.
Step 1 — Enable and configure RDP correctly
- 1
Enable Remote Desktop
System > Remote Desktop, toggle it on. Or run the PowerShell equivalent: set fDenyTSConnections to 0 in the Terminal Server registry key.
- 2
Require Network Level Authentication
Turn on NLA so clients must authenticate before a session is created. This alone blocks a huge class of pre-auth attacks.
- 3
Create a dedicated admin account
Never run RDP as the built-in Administrator. Create a named account, give it a long passphrase, and add only it to the Remote Desktop Users group.
- 4
Disable the default Administrator
Rename or disable the built-in Administrator account so automated tooling cannot target a known username.
NLA is the single highest-value setting on this list. If your client cannot do NLA, fix the client — do not disable it on the server.
Step 2 — Lock down the network path
Most RDP compromises are not clever exploits — they are credential attacks against a port left open to the entire internet. Shrink that exposure first.
- Change the listening port away from 3389 — this stops the bulk of automated scanners, though it is obfuscation, not real security.
- Restrict the Windows Firewall RDP rule to specific source IPs if you have a static address to connect from.
- Better still, do not expose RDP to the public internet at all — tunnel it through a VPN or WireGuard interface and firewall 3389 to that interface only.
- Disable RDP entirely on any server that does not need interactive login.
Warning: changing the port is cosmetic against a targeted attacker. Combine it with IP allow-listing or a VPN — never treat a non-standard port as a security boundary.
Step 3 — Harden authentication
Assume attackers will find the port eventually. The next line of defence is making credentials useless to guess and painful to brute-force.
Long passphrases
Use 20+ character random passphrases, not clever-looking passwords. Length beats complexity against modern cracking.
Account lockout policy
Set a lockout threshold so repeated failures freeze the account for a period. This turns brute-forcing into a denial of the attacker's own progress.
Limit RDP users
Only accounts in Remote Desktop Users can log in. Keep that group as small as physically possible — ideally one account.
Add a second factor
Layer an MFA solution or a certificate/gateway in front of RDP where your workflow allows it. A password alone is a single point of failure.
Step 4 — Patch, log, and watch
RDP has a history of serious pre-auth vulnerabilities. An unpatched server is exploitable regardless of how strong your password is.
- Keep Windows Update current — the worst RDP CVEs were wormable and patched long before they were widely exploited.
- Enable auditing of logon events so you can see failed and successful sign-ins in the Security event log.
- Review Event ID 4625 (failed logons) and 4624 (successful) periodically — a spike in 4625 means you are being probed.
- Consider a tool that auto-bans IPs after repeated failures to blunt sustained brute-force campaigns.
Making it offshore
Hardening protects the server. Privacy protects you. The two are separate problems, and most RDP tutorials ignore the second one entirely.
Privacy starts at provisioning
You cannot bolt privacy on after the fact. If the server was ordered with your real name, email and card, the box is technically hardened but personally exposed. The identity trail is set the moment you pay.
- Provision through a host that does not require KYC or personal verification to spin up a server.
- Pay from a prepaid crypto balance rather than a card tied to your name — Monero in particular leaves no public ledger trail.
- Use a dedicated email alias, not your primary inbox, for the account.
- Connect to the finished server over a VPN or Tor-friendly path so your real IP is never the one touching 3389.
This is exactly the model ChainVPS is built around. Our offshore RDP servers are provisioned with no KYC and paid from a prepaid crypto balance across 21 coins including Monero, so the machine is never linked to a real-world identity — see the /offshore-rdp page for the current Windows configurations.
Key takeaway: a secure RDP server ordered under your real identity is still a privacy liability. Privacy is a provisioning decision, not a post-setup checkbox.
Choosing where the server lives
Jurisdiction matters as much as configuration for a privacy-first setup. A server in a location with strong data protection and no data-retention overreach is meaningfully harder to compel.
Picking a privacy-tier region such as Switzerland or Iceland pairs the technical hardening above with a legal environment that respects it. For heavier interactive workloads, the same offshore model extends to our dedicated and GPU servers.
A tight pre-launch checklist
- NLA enabled and enforced.
- Built-in Administrator disabled; a single named account in Remote Desktop Users.
- RDP not exposed to the open internet — VPN, IP allow-list, or both.
- Long random passphrase plus account lockout policy.
- Windows fully patched and logon auditing on.
- Server provisioned with no KYC and paid from a prepaid crypto balance.
Is changing the RDP port from 3389 enough to secure it?
No. It hides you from indiscriminate scanners but does nothing against a targeted attacker who scans all ports. Treat it as noise reduction and combine it with NLA, IP restrictions or a VPN, and a strong account lockout policy.
What is Network Level Authentication and why does it matter?
NLA forces the client to authenticate before Windows creates a desktop session. This blocks a wide class of pre-authentication attacks and reduces the resources an attacker can consume, which is why it should never be turned off.
Can an RDP server really be offshore?
Yes, but only if privacy is built in from provisioning. Order from a no-KYC host, pay from a prepaid crypto balance such as Monero, use an email alias, and connect over a VPN so your real IP never touches the server.
Which location should I choose for a private RDP server?
A privacy-tier jurisdiction with strong data protection — ChainVPS offers NL, CH, RO, IS, MD and LU among 15 locations. Pairing a strong legal environment with the hardening steps above gives you the best overall posture.
