Using secure protocols for remote connections in Windows 10
If you’ve ever had calls come in at two o’clock in the morning where something requires your immediate attention at work, you know it’s never fun. Sometimes you do have to get ready and head in, but in most cases you really don’t want to spend an hour taking care of something that only really needs five minutes. This is where remote connection comes in.
There are dozens of different ways to connect remotely to servers, but the recommended method for quite some time has been through the use of remote desktop connections. Unfortunately, while the use of the Remote Desktop Protocol (RDP) is relatively well protected over short distances, it can be vulnerable to attacks if left unsecured on the web. Worse, it’s become an even more lucrative target to exploit with the recent increases in working from home.
In this article, we’ll be going over protocols and methods that can be used to help better secure RDP sessions both internally and externally.
Let’s start with a look at internal modifications.
The first and most effective recommendation is to make sure that both your local workstation and destination server are current on their Windows updates. There have been a considerable number of vulnerabilities discovered over the years in regard to RDP, and these have been addressed regularly through Windows updates.
In addition, we want to make sure that our RDP sessions are using secure protocols to communicate to and from the servers. This is because while the RDP channel itself is encrypted, it is possible in older versions of RDP to leverage a vulnerability in order to allow unauthorized access via a man-in-the-middle attack. Therefore it is strongly recommended wherever possible to secure your connections via SSL/TLS.
Please note that the exact method you use to perform this task or get to this area will vary considerably, depending on your OS of choice. Additionally, the use of TLS 1.0 has already been prohibited in some environments, so this option may not be viable for all systems. For our example, we will want to go to Control Panel, Administrative Tools, Remote Desktop Services, Remote Desktop Session Host Configuration.
Under Connections, right-click on RDP-Tcp and select Properties.
On the General tab, we are going to want to make sure the following settings are selected:
Under Security, be sure that the Security Layer is set to SSL (TLS 1.0). For Encryption Level, make sure this is High and click the box labeled “Allow connections only from computers running Remote Desktop with Network Level Authentication”.
Finally, under Certificate, click on the Select button to choose which of the certificates you have already uploaded to the server you wish to use. Unfortunately, obtaining and installing a certificate is beyond the scope of this article.
While not a protocol as such, it’s recommended — if your environment can support it — to enable two-factor authentication (2FA) for your RDP sessions. There are a multitude of third-party vendors as well as potential built-in options in newer versions of Windows that allow for 2FA, which can take some time to implement properly but will help make your authentication considerably more secure.
Change your ports
The default port for RDP traffic is TCP 3389, and anyone scanning the network deliberately for this port will be able to quickly find any number of servers listening. Changing this port to something less obvious would be tremendously helpful, but can take a considerable amount of time to initially set up.
Firewall access limitations
Not every user on your network needs access to RDP into servers. If your network allows, you can create a Group Policy Object (GPO) for your servers that would restrict access to a specific range of IP addresses.
Another option, again if your environment supports it, is to do this at the hardware level via the use of Access Control Lists (ACL). It may be a little annoying if you’re roaming around and want to log in to a particular server and can’t from your current location, but it reduces the risk of unauthorized connections considerably.
While it is certainly possible to leave your systems directly exposed on the internet and RDP in directly with no security at all, this is a very bad idea. Fortunately there are two very well-used and secure methods that can help to not only keep your network more secure but to log who is attempting to breach it.
Similar to the recommendation above regarding using SSL/TLS to secure the connection to a remote server, a Remote Desktop Services (RDS) gateway allows for a similar method to be used via a standard online portal. This provides a central access location that users can RDP from to a large number of target servers, as well as the use of remote apps. In addition to permitting access in a secure manner, this also allows for logging of legitimate users as well as potential brute-force attack attempts.
If you need more than just RDP access or require more than what just one RDS gateway will allow, then a Virtual Private Network (VPN) connection may be just what you require. These access methods are highly secure and allow for any supported device to communicate as if it were directly attached to your network.
VPNs can also allow for other security measures to be logged and checked on such as Windows Updates, making sure that your antivirus stays up to date and unmodified and other Windows settings remain in compliance with your organization’s standards.
RDP is one of those tools that is so ubiquitous that we can forget about it sometimes until it doesn’t work. What we do need to be sure of though is that it remains safe and secure for when we need it, and that only the people that are supposed to have authorized access have it.
Least permissions is critical when it comes to server access, and that goes for administrators as well in addition to users — if you don’t need access to it for your functions, don’t give yourself access under normal situations. An important thing to remember, though, is that there can still be other ways to access a system in addition to RDP, regardless if it is physical or virtual.