Every Windows VPS that exposes Remote Desktop on the default port 3389 gets hit by brute-force attempts \u2014 usually within hours of deployment. The Windows event log on a fresh, unprotected instance routinely shows hundreds of failed logon events per day, most of them from botnets cycling through username\/password lists. The good news is that a small set of configuration changes, none of them requiring third-party software, stops the overwhelming majority of these attacks. Here are eight RDP hardening settings that actually work on a Windows VPS.<\/p>\n\n\n\n
NLA requires the client to authenticate before a full RDP session is established, which means unauthenticated scanners and most automated attack tools are rejected at the door instead of consuming a session. It is enabled by default on Windows Server 2022 and 2025, but verify it on older images: open System Properties \u2192 Remote<\/em> and confirm “Allow connections only from computers running Remote Desktop with Network Level Authentication” is checked. NLA also reduces the server load from connection floods, since the CPU-heavy session initialization only happens for authenticated users.<\/p>\n\n\n\n Account lockout is the single most effective defense against password guessing. Open Local Security Policy \u2192 Account Policies \u2192 Account Lockout Policy<\/em> and set a threshold of 5 failed attempts with a 15-minute lockout duration. This turns a botnet that can try thousands of passwords per minute into a botnet that locks the account after five tries. The trade-off is that legitimate users can also lock themselves out, which is why a lockout duration of 10\u201315 minutes is the sweet spot \u2014 long enough to deter attackers, short enough not to annoy your team.<\/p>\n\n\n\n Port 3389 is the first thing every RDP scanner probes. Moving RDP to a high, non-standard port (for example, 54389) requires a registry change under If your team connects from a static office IP or through a VPN endpoint, add an inbound Windows Defender Firewall rule that only allows RDP from those addresses and blocks it from everywhere else. This is stronger than any authentication setting, because the attack never reaches the RDP service at all. If your provider offers a network-level firewall or security group in its control panel, apply the same allowlist there \u2014 filtering at the network edge protects you even if the Windows firewall is ever misconfigured or disabled.<\/p>\n\n\n\n Brute-force scripts almost always try Windows Server enforces password complexity by default, but legacy images and manually created accounts can slip through with weak or blank passwords. Run The most secure configuration is to not expose RDP to the public internet at all. Run a VPN server (WireGuard or OpenVPN) on the same VPS and require clients to connect to the VPN before they can reach the RDP port, or deploy Remote Desktop Gateway, which fronts RDP with an HTTPS endpoint that supports MFA. This is more setup work, but it changes your exposure model completely: instead of defending a public login service, you defend a VPN endpoint with authenticated, encrypted tunnels. For teams of more than a handful of users, the RD Gateway route is the professional standard.<\/p>\n\n\n\n Hardening without monitoring leaves you blind. Enable auditing of logon events (Event ID 4625 for failures, 4624 for successes) via Local Security Policy \u2192 Advanced Audit Policy<\/em>, then check the count periodically with PowerShell: Settings 1, 2, 5, and 6 take about 20 minutes total and eliminate the vast majority of automated attacks by themselves. Settings 3, 4, and 7 add layers for anyone connecting over the public internet. And setting 8 makes sure you notice if anything slips through. When you are evaluating providers, check whether they offer network-level firewalls, DDoS protection, and snapshots \u2014 features that make RDP hardening dramatically easier \u2014 and compare Windows VPS plans on our comparison table<\/a> to see which hosts include them.<\/p>\n\n\n\n For an affordable test environment to practice these settings on, InterServer’s Windows VPS is available for $0.01 for the first month with code TRYINTERSERVER<\/a>. If you need a production box with hourly billing for quick iteration, Vultr’s Windows instances<\/a> are a solid choice. Whichever you pick, apply these eight settings before you do anything else \u2014 the brute-force attempts will start arriving long before you finish reading this article.<\/p>\n","protected":false},"excerpt":{"rendered":"2. Enforce an Account Lockout Policy<\/h2>\n\n\n\n
3. Change the Default RDP Port<\/h2>\n\n\n\n
HKLM\\System\\CurrentControlSet\\Control\\Terminal Server\\WinStations\\RDP-Tcp<\/code> and a matching firewall rule, plus clients that specify the new port. This is security by obscurity \u2014 a determined attacker can discover the port with a full scan \u2014 but it filters out the vast majority of opportunistic botnet traffic, which only targets 3389. It costs ten minutes and eliminates most of the noise in your event log.<\/p>\n\n\n\n4. Restrict RDP by Source IP in the Firewall<\/h2>\n\n\n\n
5. Disable the Built-In Administrator Account<\/h2>\n\n\n\n
Administrator<\/code> as the username first, because it exists on every Windows system. Rename it via Local Users and Groups<\/em>, and \u2014 more importantly \u2014 disable it once you have a second account with administrator rights. Create a dedicated admin user with a non-obvious name, use that for daily administration, and keep the renamed built-in account disabled. This single change removes the most common username from every automated attack list in existence.<\/p>\n\n\n\n6. Require Strong Passwords and Disable Blank Passwords<\/h2>\n\n\n\n
net accounts<\/code> to verify the password policy, and confirm that “Limit blank passwords to console logon only” is disabled in Local Security Policy. For extra protection on servers facing the internet, consider a 14+ character minimum \u2014 modern GPU-based cracking tools can exhaust 8-character NTLM hashes in hours, while 14+ character passphrases remain impractical to brute-force.<\/p>\n\n\n\n7. Put RDP Behind a VPN or RD Gateway<\/h2>\n\n\n\n
8. Audit Failed Logons and Set Up Alerts<\/h2>\n\n\n\n
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} | Measure-Object<\/code>. A sudden spike in failed logons is your early-warning signal that something is probing the box. Free tools like RDPGuard or Windows Defender Firewall’s built-in IP filtering can auto-block IPs after a threshold of failures, adding an automated response on top of your manual monitoring. If you are setting this up across multiple servers, providers with snapshot and template features make it easy to replicate the same hardened baseline \u2014 compare Windows VPS plans on our comparison table<\/a> to see which hosts offer them.<\/p>\n\n\n\nPutting It Together<\/h2>\n\n\n\n