If you’re running a server with Remote Desktop Protocol enabled, you’re sitting on one of the most frequently attacked entry points on the internet. I learned this the hard way a few years back when I noticed suspicious login attempts on a client’s Windows Server – over 2,000 failed attempts in just 48 hours. The server was running RDP on the default port 3389, essentially broadcasting “come attack me” to every bot scanning the internet.
RDP is incredibly convenient for managing Windows servers remotely, but that convenience comes with serious security implications. Every day, automated bots scan millions of IP addresses looking for open RDP ports, attempting brute-force attacks with common usernames and passwords. If you’re not protecting these ports properly, it’s not a question of if you’ll be compromised, but when.
Why RDP Ports Are Such Attractive Targets
Remote Desktop Protocol allows administrators to control Windows machines from anywhere in the world. This makes it invaluable for server management, but also makes it a prime target for attackers. Once someone gains access through RDP, they essentially have full control of your system – they can install ransomware, steal data, or use your server as a launching pad for further attacks.
The problem is compounded by the fact that many administrators leave RDP exposed directly to the internet on port 3389. This is like leaving your front door wide open with a neon sign pointing to it. Attackers know exactly where to look, and they’re looking constantly.
Change the Default Port (But Don’t Rely On It)
One of the first things many administrators do is change RDP from port 3389 to something less obvious, like port 51299 or another high-numbered port. This does reduce automated attacks significantly – the low-hanging fruit scanners will pass right by. However, this is security through obscurity, not real security. A determined attacker running a full port scan will still find your RDP service, regardless of which port it’s on.
I still recommend changing the port as one layer in a multi-layered security approach, but never as your only protection. Think of it as locking your car doors – it won’t stop a professional thief with the right tools, but it will deter opportunistic criminals.
Implement Network-Level Authentication
Network-Level Authentication (NLA) requires users to authenticate before establishing a full RDP session. This means attackers can’t even reach your login screen without valid credentials. It’s a simple checkbox in your RDP settings but provides substantial protection against automated attacks that try to exploit vulnerabilities in the RDP protocol itself.
Every Windows Server from 2008 onwards supports NLA, and it should be enabled by default. If you’re running older systems without NLA support, that’s a clear sign you need to upgrade – you’re running on borrowed time security-wise.
Use a VPN or Jump Box
The single best practice for RDP security is to never expose it directly to the internet. Instead, require users to connect through a VPN first, or use a jump box (bastion host) that sits between the internet and your internal servers.
With a VPN setup, users must first establish an encrypted VPN connection to your network before they can even see your RDP servers. This adds a crucial authentication layer and makes it virtually impossible for random internet attackers to reach your RDP ports. The VPN itself becomes your security perimeter.
A jump box works similarly – it’s a hardened server that accepts connections from the internet, and users RDP into the jump box first, then from there to internal servers. This way, your production servers never touch the public internet directly.
Enforce Strong Password Policies and Account Lockouts
If you must expose RDP to the internet (though I strongly discourage it), at least make brute-force attacks impractical. Require complex passwords of at least 14 characters with a mix of uppercase, lowercase, numbers, and symbols. Implement account lockout policies that disable accounts after five failed login attempts.
Better yet, disable password authentication entirely and use certificate-based authentication or smart cards. This eliminates the most common attack vector – weak or stolen passwords.
Enable Two-Factor Authentication
Two-factor authentication (2FA) adds another critical security layer. Even if an attacker somehow obtains valid credentials, they still can’t log in without the second factor – typically a code from a mobile app or SMS message. Solutions like Duo Security or Microsoft’s own Azure MFA can integrate with RDP relatively easily.
Monitor and Audit RDP Access
You need visibility into who’s accessing your servers and when. Enable detailed logging of all RDP connections and regularly review these logs for suspicious activity. Look for failed login attempts, connections from unusual geographic locations, or access during off-hours.
This is where services like PortVigil come in handy – continuous external port scanning helps you verify that your RDP ports are properly secured and not unexpectedly exposed. I run weekly scans on all my servers to ensure no configuration changes have accidentally opened security holes.
Keep Everything Updated
RDP vulnerabilities are discovered regularly, and attackers move quickly to exploit them. The BlueKeep vulnerability (CVE-2019-0708) from 2019 is a perfect example – it allowed attackers to execute arbitrary code on affected systems without any authentication whatsoever. Microsoft released patches, but thousands of servers remained vulnerable because administrators didn’t apply updates promptly.
Set up automatic updates for critical security patches, and don’t delay on RDP-related updates. The few minutes of potential downtime during a patch cycle are nothing compared to the cost of a security breach.
Consider RDP Alternatives
Sometimes the best way to secure RDP is not to use it at all. For many administrative tasks, SSH tunneling, PowerShell remoting, or web-based management interfaces might be better options. These often have smaller attack surfaces and more mature security implementations.
If you’re managing Linux servers alongside Windows machines, you might already be using SSH. Consider using SSH tunneling to access RDP instead of exposing RDP directly – this gives you the security benefits of SSH with the convenience of RDP.
Common Misconceptions About RDP Security
Many administrators believe that simply having a firewall is enough protection. While firewalls are important, they don’t help if you’re allowing RDP traffic through them to reach your servers. The firewall needs to be configured to block RDP from the internet entirely, allowing it only from trusted networks.
Another myth is that small businesses or personal servers aren’t targets. Attackers don’t discriminate – automated bots scan every IP address they can find. Your small server is just as likely to be attacked as a major corporation’s infrastructure.
Final Thoughts
Securing RDP isn’t about implementing one magic solution – it’s about layers of protection that work together. Change default ports, use strong authentication, implement VPN access, enable logging, and stay updated. Each layer makes it exponentially harder for attackers to succeed.
The effort you put into securing RDP today will save you from the nightmare of dealing with a compromised server tomorrow. Take it from someone who’s seen the aftermath of successful RDP attacks – the few hours spent implementing these protections are worth months of headaches and potential data loss.