Remote desktops delivered by the remote desktop protocol has received quite a bad reputation when it comes to security concerns and other vulnerabilities that come along with the RDP protocol. There have been many variants of ransomware and other malware that have exploited vulnerable RDP servers that have been presented to the Internet. In this post, we will take a look at how to secure RDS RDP RDSH best practices to provide a much more secure environment for remote workers.
How to Secure RDS RDP RDSH Best Practices
There are many things that need to be considered when you look at how to secure RDS RDP RDSH best practices. We will look at the following:
- Remote Desktop Gateway
- Two-factor authentication
- Remote Desktop IDS brute force login protection
- Visibility to account lockouts
Remote Desktop Gateway
One thing that I see a lot of SMBs do is enable RDP on a Windows Server and stick it out on the Internet for remote users to login from home or other locations. While this is simple and easy to do, without the proper security in place, this can be a dangerous thing to do.
Remote desktop servers can easily get “popped” by brute force password attempts or by Windows Servers exposed to the Internet that are not patched and up-to-date.
You can check out the Remote Desktop Services Architecture from Microsoft here that gives a good overview of secure RDS RDP RDSH best practices when it comes to the design and overall architecture.
As you can see, Microsoft does not recommend placing a remote desktop server in the DMZ or WAN directly exposed to the Internet. Instead they recommend using the remote desktop gateway (RDGW) server which essentially provides a secure SSL tunnel over port 443 for RDP traffic from an end user. This is a much more secure method of deploying RDS for your organization.
This means the RDP enabled RDSH servers are sitting on the internal network and receive the proxied connections from the RDGW server.
There may be reasons that an organization may not use an RDGW server. Even though recommended, there may be limited resources or expertise to configure these correctly as opposed to pinholing an RDP server to the Internet.
There are some tools that can make a directly exposed RDP server a much more secure solution and even those that do make use of the recommended RDGW in front.
Please note, I am not advocating exposing an RDSH server to the Internet, however, if a business decides to do this, there are ways to make it much more secure.
User passwords can be the weak link in your security posture overall. This is especially true when thinking about remote access. Hackers know this and that is why brute-forcing attempts are still very fruitful.
Implementing two-factor authentication for logins on RDSH servers is a great way to exponentially bolster RDS RDP RDSH posture.
One of the best solutions I have seen that can easily be implemented in your environment is the Duo RDP login solution. There is a free version of Duo, however, the pay version has many additional features and management tools for the solution.
When you install Duo on your RDSH server, when user’s authenticate via RDP, they will be prompted for either a text message or what they call a “Duo push” notification that allows you to easily tap a soft button on your smartphone to allow the login.
In the screenshot below, I have initiated an RDP connection to a server. Instead of automatically logging the user in, they will see the Duo prompt with either a push notification (shown below) or a prompt to enter a code that is texted to the end user. If cancel is pushed here or no response within a period of time, the login fails to the RDSH server.
This tremendously bolsters your RDSH login security for connections from the outside. If an attacker does compromise an end user password, they still will be unable to login to the RDSH server.
If you do decide to expose an RDSH server directly to the Internet, this is a must! Even with RDGW server, I would recommend doing this for enhanced security.
Remote Desktop IDS brute force login protection
Another great tool that can be used to bolster your RDS RDP RDSH security is Remote Desktop IDS brute force login protection. There are a couple of free tools that I have used for providing enhanced protection for RDP connections.
What these free RDP IDS tools do is watch your security event logs for failed logins (EventID 4625). When these are seen, it looks at the source IP of the failed login and then after the configured number of failed logins, it will add the IP to a Windows firewall rule, blocking the connection. This is done on the fly, automatically.
There are a couple I will mention here that do work, and again, are free:
Below is a screenshot of an RDSH server exposed to the Internet, running the Cyberarms IDDS tool. As you can see, there are tons of unsuccessful logins from various sources.
I highly recommend running a tool of this sort on your RDSH servers as a best practice and specifically if a server is exposed to the Internet.
Visibility to account lockouts
A dangerous position to be in when it comes to security is “flying blind”. What I mean by that is you have potential security events going on, but you have no visibility to them.
A handy little tool that is also free is the Netwrix Account Lockout Examiner. I have written about this tool in the past. It is a great way to have visibility to brute force attempts in your environment. You can see if you have accounts that are getting “hammered” with incorrect logins or if you just have legitimate user passwords entered incorrectly and locked out.
When looking at How to Secure RDS RDP RDSH Best Practices, there are many things that you can do and tools you can use to make your solution MUCH more secure.
Designing RDSH access in a way that uses Remote Desktop Gateway servers (RDGW) is the recommended approach that prevents exposing RDSH servers directly to the Internet and is the preferred means of providing RDSH services.
If you must expose an RDP server to the Internet, you need to bolster the solution using various tools. This includes two-factor authentication, RDP IDS security, and visibility to account lockouts.