Connecting to a Windows server over RDP, and the risk of leaving it open
Connecting to a Windows server is technically easy: an IP address, a username, a password and Remote Desktop. The hard part is knowing what it means to leave that port open to the internet.
Connecting
Windows: Start → "Remote Desktop Connection" (mstsc). Type the IP into the computer field and click Connect.
macOS: "Windows App" from the App Store (formerly Microsoft Remote Desktop).
Linux: remmina or freerdp:
xfreerdp /v:185.137.98.29 /u:Administrator /dynamic-resolutionA certificate warning on the first connection is normal — the server uses a self-signed certificate.
Open RDP: what you need to know
From the moment port 3389 is opened to the internet it attracts automated password-guessing traffic. This is not a guess; an open RDP port starts accumulating failed login records in Event Viewer within hours.
The size of the risk is this: RDP is a desktop session, so a single successful login means control of the entire machine. There is no intermediate state such as "can only read files", as there is with SSH.
Three protective steps
1. Close the port to everyone
The most effective step, and the most often skipped: in the firewall, allow 3389 only from your own IP address. If you do not have a static IP, use a VPN, or open and close access as you need it.
If you are on Datafex, port and access management is handled from the customer panel.
2. Rename the Administrator account
Most automated attempts try the Administrator username directly. Renaming the account makes all of that traffic pointless. Creating a new administrator account and disabling Administrator is better still.
3. Account lockout policy
secpol.msc → Account Lockout Policy:
- Lockout threshold: 5 failed attempts
- Lockout duration: 15 minutes
This makes password guessing practically impossible. To avoid locking yourself out, verify your key/access method first.
Network Level Authentication (NLA)
In System Properties → the Remote tab, "Allow connections only from computers running Remote Desktop with Network Level Authentication" should be ticked. NLA performs authentication before a session is opened; with it off, the server spends session resources on every connection attempt.
A note on resources
The RDP session itself consumes RAM and CPU — on an 8 GB server an open desktop session is a noticeable share. When you are finished, log off (simply closing the window leaves the session open):
logoffWindows' baseline consumption and how it compares with Linux: Windows or Linux?
A fallback access route
The risk of losing access to RDP is real: a wrong firewall rule, locking yourself out, a broken Windows update. Find out whether your provider offers console/VNC access before you set the server up — without that access a wrong rule becomes a permanent problem.
Related reading
- Server security: the basic steps
- How to set up a Knight Online server — a typical workload that requires Windows