Remote desktop access is the easiest way to work remotely. No doubt about that. And mostly everyone with remote users has direct RDP and of those, most are aware how risky it is to open a hole in your firewall for a direct RDP connection with no encryption or any type of VPN. In fact, Microsoft released a security bulletin a few years ago about how an unauthenticated attacker may be allowed to run random code remotely by sending “a sequence of specially crafted RDP packets”.
But again a good percentage of users ignore the risk because it’s so much easier to set a direct RDP rather than setting up a proper gateway proxy or VPN – and cheaper, too. Pair ease of use with lower cost and you have a very convincing argument to embrace unnecessary risk.
Problem #1 Security
RDP uses port 3389. Opening up this port on the firewall means that as attackers scan for open ports, your vulnerability can easily be found. Once found, hackers can instantly launch a brute force attack against your server resulting in 1000s of authentication attempts with random user names and/or dictionary passwords to see if any of them matches and passes the authentication. If a match is found, the attacker is in. And everyone knows what that means.
Not using proper encryption for the end-to-end connection is another issue. This means that your connection is prone to man-in-the-middle attacks. Setting up VPNs may be tricky. And SSL encryption means buying a SSL certificate and renewing it every year. While these steps may be time consuming – they certainly are not good reasons to ignore encryption.
Problem #2: Performance
During brute force attacks the server is being constantly slammed with login attempts trying to create 1000s of sessions every minute. This negatively affects the performance of the system – the average system will become bogged down. I have witnessed this countless times for users reporting slow performance on RDP servers with direct RDP. To see if your system is slow due to a brute force attack check the session numbers. If some of the session numbers are insanely high (in the thousands), brute force may be the issue.
Workarounds, not Solutions
There are some workarounds to the whole default RDP port thing. We can change the default RDP port on the system to another number (not 3389). This requires making changes to the registry.
Another shortcut is to use port forwarding. In other words, set up a source port on the firewall to forward connections made to that port on the firewall to the default port on the RDP destination system (Example – use 3309 on the firewall to forward to 3389 to the internal RDP server).
One other option is to use a third party tool or a script to detect the number of failed attempts from an IP and when it reaches the threshold, block the IP on the firewall. There is third party software that will do this easily.
However, all of these workarounds are not solutions and I would not recommend as they are still unencrypted.
The Best Solution
In environments where security is the primary concern, which nowadays ought to be every environment, there are a couple of best practices to follow for setting up the RDP access. The first being setting up some sort of VPN connection creates an encrypted tunnel into the network and thus RDP ports are no longer needed to be opened on the firewall. This will also prevent man-in-the-middle attacks.
A RDP gateway proxy gateway can also be utilized for securing the connection with SSL. This requires an SSL certificate to be purchased. The connection will be made on port 443 and encrypted using SSL. Windows Offers a remote desktop gateway role as part of Windows server OS which is extremely easy to setup.
Bottom-line, use the best practice in your environment to reflect the security expectations of your environment. In the long run, unsecure methods of direct RDP can be very costly.