How to Secure RDP on Windows VPS — VPSGrid Knowledge Base
English
EnglishBeta EspañolPortuguês (Brasil)Coming soonFrançaisComing soonDeutschComing soon
Client Area

How to Secure RDP on Windows VPS

KB-150, Security, VPSGrid, unmanaged 0 found helpful

How to Secure RDP on Windows VPS

Short answer

Keep RDP enabled only if you need it, use a long unique Administrator password, leave NLA on, restrict Windows Firewall to required access, enable account lockout, and prefer connecting from trusted networks. Do not disable the firewall to “fix” RDP.

Overview

Remote Desktop is powerful and internet-exposed by default on many Windows VPS deployments. This guide focuses on practical hardening after you can already connect. Enable/repair steps: How to Enable Remote Desktop. Client connection steps: RDP connection guide.

Before you harden

Keep a working noVNC/console path in the VPSGrid client area. Aggressive firewall or port changes can lock you out of RDP — use the console to recover.

1) Strong credentials first

  • Change the initial Administrator password immediately after first login
  • Use a long, unique password (password manager recommended)
  • Avoid sharing the Administrator account across multiple people — create named admin users when practical
  • Never reuse passwords from other sites

2) Keep Network Level Authentication (NLA) on

NLA requires authentication before a full remote session starts, which reduces some attack noise.

# Ensure NLA is enabled (1 = require NLA)
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name 'UserAuthentication' -Value 1

Or in GUI: System Properties → Remote → keep “Allow connections only from computers running Remote Desktop with Network Level Authentication” checked.

3) Firewall: allow RDP deliberately

  • Keep Windows Defender Firewall on
  • Allow the Remote Desktop rules you need — do not open “any/any”
  • If you only administer from a fixed office IP, prefer a scoped allow rule (example below) instead of the whole internet
# Built-in RDP group should be enabled
Enable-NetFirewallRule -DisplayGroup 'Remote Desktop'

# Example: allow RDP only from a trusted IP (replace x.x.x.x)
New-NetFirewallRule -DisplayName 'RDP from office only' `
  -Direction Inbound -Protocol TCP -LocalPort 3389 `
  -RemoteAddress x.x.x.x -Action Allow -Profile Any

# After testing a scoped rule, disable broad RDP allows you no longer need
# Disable-NetFirewallRule -DisplayName '...'

More firewall commands: Windows Firewall — PowerShell Rules.

4) Enable account lockout for brute-force resistance

Local security policy (or domain policy if you use Active Directory):

  1. Open Local Security Policy (secpol.msc)
  2. Go to Account Policies → Account Lockout Policy
  3. Set sensible values such as lockout threshold 5–10 invalid attempts, with a short lockout duration
# Example via net accounts (local policy style)
net accounts /lockoutthreshold:10
net accounts /lockoutduration:15
net accounts /lockoutwindow:15

Confirm with net accounts. Exact behavior can vary by Windows Server edition and whether domain policy overrides local settings.

5) Optional: reduce public exposure

  • Trusted networks only — administer from office/VPN when possible; scoped firewall rules help
  • Custom RDP port — changing from 3389 reduces casual scans but is not strong security by itself; update firewall + client settings, and keep console access ready
  • VPN front door — if you run a VPN on the VPS or elsewhere, consider allowing RDP only from the VPN network
  • Disable RDP when you do not need interactive desktop access (rare for Windows VPS administration)

6) Quick verification checklist

  1. You can still connect with RDP from your trusted path
  2. NLA remains enabled
  3. Firewall is on; RDP is allowed intentionally
  4. Failed password attempts trigger lockout as configured
  5. Console still opens from the client area as a backup

Important notes

  • Securing RDP does not replace Windows Updates, Defender, and least-privilege habits
  • Windows licensing remains BYOL on VPSGrid Windows plans — see Licensing Requirements
  • VPSGrid is unmanaged — guest hardening is your responsibility

Frequently Asked Questions

I locked myself out while hardening

Use the noVNC/console in the client area, re-enable Remote Desktop firewall rules, and restore a known-good Administrator password if needed.

Is changing the RDP port enough?

No. Treat it as optional obscurity only. Prioritize strong passwords, NLA, firewall scoping, lockout, and updates.

RDP still fails after hardening

Confirm the VPS is online, test via console, then review enablement and troubleshooting guides for RDP.

Related Articles

Need More Help?

Open a ticket at billing.vpsgrid.net with your service ID, primary IP, whether console works, and the hardening step that broke access.

Was this answer helpful?

Related Articles

« Back Browse all articles