Somebody needed to reach a Windows server from home, so somebody forwarded port 3389 on the firewall. It worked, nobody touched it again, and it is still there. This is the single most common way a Remote Desktop host ends up on the internet, and it is worth understanding why it is a bad trade.
What exposing RDP actually means
Remote Desktop Protocol listens on TCP port 3389 by default. Exposing it means that port answers connections from anywhere, not just from your office or your VPN. Microsoft is plain about this in its own documentation. On port forwarding it warns: “You’re opening your PC up to the internet, which isn’t recommended.” It adds that a VPN is preferable.
The reason is the access RDP grants. Microsoft describes a connected user as having “access to all of your apps, files, and network resources as if you were sitting at your desk.” The port is the front door to a full desktop session.
Why it is dangerous
It is a known way in for ransomware. CISA’s #StopRansomware guide says: “Threat actors often gain initial access to a network through exposed and poorly secured remote services, and later traverse the network using the native Windows RDP client.” It lists RDP among the services to audit and recommends you “close unused RDP ports.”
A flaw in RDP can bypass your password entirely. BlueKeep (CVE-2019-0708) is the standard example. CISA’s advisory says the exploit “requires no user interaction” and “must occur before authentication to be successful.” It also called the flaw “wormable”, meaning malware could spread from one vulnerable machine to the next. A strong password protects you from guessing. It does nothing for a bug that runs before the login prompt.
Changing the port doesn’t hide it. Scanners check every port and identify services by how they respond. We covered the same logic for SSH in does changing the SSH port improve security. Moving RDP to 3390 or 49152 reduces noise, not exposure.
Why “we only use it occasionally” doesn’t help
An exposed RDP port does not care how often you use it. It is reachable at 3 a.m. on a public holiday exactly as it is at 10 a.m. on a Tuesday, and the people probing it are not in your time zone or on your calendar. Microsoft’s advice for the home user applies to a server rack as well: if you only need to use a machine locally, there is no need to enable Remote Desktop at all. The same logic holds for a production server. If nobody has a documented need to reach it from outside, the right number of open RDP ports is zero.
When there is a need, the question changes from “is RDP safe?” to “what is the one controlled way in?” That is a much smaller problem to defend than a forwarded port on every server that someone once needed.
What helps, and how much
| What you do | Reduces guessing | Hides the service | Removes pre-login exploit risk |
|---|---|---|---|
| Strong passwords and account lockout | Yes | No | No |
| Network Level Authentication (NLA) | Partly | No | Partly |
| Allow-list source IP addresses | Yes | Mostly | Mostly, for other addresses |
| VPN in front of RDP | Yes | Moves it to the VPN | Moves it to the VPN |
| RD Gateway in front of RDP | Yes | Moves it to the gateway | Moves it to the gateway |
| No inbound listener at all | Yes | Yes | Yes |
The “Partly” for NLA is deliberate. Microsoft says NLA requires users to authenticate before a session is established, which cuts the risk from unauthorised users and software. CISA’s BlueKeep advisory lists enabling it among its mitigations. Keep it on. It just isn’t a substitute for closing the port.
The gateway rows deserve a note. Microsoft says the RD Gateway role “is supposed to be public”, which tells you exactly where the exposure went. A gateway or VPN is a real improvement over raw 3389, but it is still an internet-facing service that has to be patched, monitored and protected with MFA.
A checklist if RDP must stay reachable for now
- 1Find every 3389Audit what is open
- 2Close what isn't neededNo documented need, no port
- 3One path in, with MFAVPN, gateway or broker
- 4Remove the listenerNothing left to scan
- Audit first. Find every host with 3389 open. CISA recommends auditing the network for systems using RDP.
- Close what you don’t need. CISA’s exposure guidance is to “close or restrict access to ports that do not have a documented operational need.”
- Block 3389 at the perimeter firewall. This was CISA’s first BlueKeep mitigation, and it still stands.
- Keep NLA on and patch Windows promptly.
- Enforce account lockout and MFA, and log RDP login attempts, all of which CISA’s ransomware guide lists.
- Route access through one controlled path. CISA advises routing “all necessary remote access through a secure gateway, firewall, VPN, or other centrally managed access solution.”
- Put MFA on that path. CISA says to “implement MFA on all VPN connections.”
Where SSHepherd fits
If you would rather the Windows server had nothing to scan, that is what SSHepherd® does for RDP. It closes the listening port on the server. The server and your administrators each connect outward to a broker, which joins them only for authorised identities, so a scan finds no 3389 to try. Sessions can be monitored, recorded and ended on demand, and the server can be protected in about ten minutes without re-architecting the network. The details are on the Windows RDP use case and the SSHepherd page.
The bottom line
No, exposing RDP to the internet is not safe, and passwords, NLA and a new port number only make it less bad. Close 3389, put one controlled path with MFA in front of it, and ideally remove the inbound listener altogether.