Remote Desktop Protocol (RDP) is a tried and tested protocol that sysadmins have been using for years. It’s so widely used I would be shocked to meet a sysadmin that hasn’t used it. But, just because something is widely used doesn’t mean that it’s without its flaws. Remote Desktop has been host to a wide array of vulnerabilities over the years. While Microsoft has been vigilant in releasing updates and patching exploits for RDP, new attack vectors emerge all the time. Sysadmins have to do their part to ensure their environments remain secure.
As stated, Remote Desktop has been around for a while. Every version of Windows since Windows XP has included a Remote Desktop Connection client (formally known as Terminal Services). In fact, the client name “mstsc.exe” is a relic from the past, which stands for Microsoft Terminal Services Client.
Remote Desktop made it possible for users to remotely access and control Windows computers as if they were right in front of them. This was a game-changer for sysadmins. If you had terminal services configured, you could remote into workstations and servers without leaving the comfort of your office chair. While this was not beneficial for our waistlines, it made sysadmins much more efficient in their duties.
Remote Desktop has been influential in shaping the current tech landscape. While we still have computers and laptops, and now smartphones and smartwatches, many of the resources we interact with are remote. Just a few years ago, a majority of an organization's applications were local installs. Now, applications are hosted on the cloud and accessed remotely. Dedicated physical servers are also being phased out in favor of virtual servers, which can only be interacted with remotely.
Being able to access resources remotely is certainly advantageous. However, it also provides more opportunities for malicious attacks.
Since RDP is beneficial and adds value to organizations, it’s not something that we want to just disable for the sake of security. Your security officer may feel differently, but let’s see what we can do to ensure we implement RDP as securely as possible.
Many of you may not want to hear this, especially with so many employees working from home, but exposing RDP to the internet is not recommended. Even with all of the ways you can secure RDP, many of which we will cover in this blog post, it’s still too risky to open your network to those threats. While VPNs may have their downside, such as higher bandwidth usage, which may result in slower connections, it’s still a more secure way to connect to your internal network over the internet.
Password complexity may seem like a gimme, but this is one of the simplest ways to increase the security of your remote desktop connections. While the common password complexity recommendations used to be eight characters long with a mixture of uppercase, lowercase, numbers, and symbols, nowadays, that’s not enough. Newer computers can brute force a password with these complexity requirements in just a couple of hours. Some security specialists now recommend passwords have a minimum length of 12 characters with a mixture of uppercase, lowercase, numbers, and symbols. Others suggest even longer passwords. As you increase the password’s length, the time it takes to brute force the password goes up exponentially.
You can configure the Password Policy on your domain through Group Policy. The setting is located in Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Password Policy
Limiting the number of login attempts before locking out an account is another way to deter brute force attacks. Brute force attacks can attempt thousands of passwords in seconds. However, if an account is locked out after three failed attempts, then the brute force attack is stopped in its tracks. While this may sound like the perfect solution to brute force attacks, it does have drawbacks. If an attacker wanted to, and if they had access to usernames, they could lock out hundreds or thousands of users from their accounts in a matter of seconds. Attackers could also use this method to harvest usernames because only valid usernames would become locked out of a system.
You can configure the Account Lockout Policy on your domain through Group Policy. The setting is located in Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Account Lockout Policy.
The advantage of RDP being a Microsoft owned solution is the constant stream of updates. Microsoft is swift to patch vulnerabilities. Make sure you stay vigilant in keeping your systems patched and up to date. Just remember to review updates before applying them. Microsoft has been known to push updates that can break features or introduce new bugs.
Systems that implement MFA (also called 2FA or two-factor authentication) require users to provide multiple forms of authentication before granting access to that resource. While MFA isn’t new, it’s only seen large-scale implementation in recent years.
MFA is highly regarded as an effective method of securing resources, including RDP connections. While phishing scams and brute force attacks have proven to be effective ways of obtaining user credentials, without the second form of authentication, attackers will still be unable to access user accounts.
The most common downside to MFA is the added complexity users experience when authenticating. Since MFA is new to many users, there will be a learning curve that some users will have to overcome. That being said, the benefits greatly outweigh the drawbacks.
There are many more options for MFA today than there were even ten years ago. Some possibilities include phone authentication, SMS and email token authentication, software token authentication, biometric verification, etc. With solutions provided by both Microsoft and third parties, you can find an MFA solution that works for your organization that will help secure your RDP sessions.
The principle of least privilege is an ideology that directs organizations to limit user access to only those resources necessary to perform their duties. If John Doe only needs access to Microsoft Office and a printer to do their job, they should only have access to Microsoft Office and a printer.
Regarding RDP, if most of your users don’t need to access network resources remotely, then they shouldn’t have access to RDP. This advice may be a given, but employees often change roles within an organization. It’s not uncommon for a user to change job responsibilities and never have their network access altered to fit their new position. Regular audits should be conducted to ensure RDP access is limited to only those that require it.
By default, local administrator accounts have RDP access on non-domain joined computers. Using local administrator accounts to remotely access devices limits the effectiveness of logs used to identify users. This situation worsens if an organization uses the same local administrator password on all of its devices instead of using a solution such as LAPS. Any user or attacker who manages to get the local administrator password can now access any machine on the network. To mitigate this problem, restrict local administrators from using remote desktop. This restriction can be configured in the local security policy or through group policy.
This recommendation applies both when working on devices remotely and locally. Whenever possible, users should log in to hosts using non-privileged accounts. You limit the risk of compromising privileged or administrator credentials by logging into workstations and servers with standard user accounts. When a task requires administrative access, elevate privileges using the administrator credentials for that particular task.
There are several settings that we can configure through group policy to increase the security of Remote Desktop. With group policy open, you can locate these settings by going to Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services, Remote Desktop Session Host > Security.
Review these settings to determine which ones would most benefit your organization. Here are a few recommended settings:
Set client connection encryption level: Enabled and set to High Level (if you have a mixed environment with older operating systems, you may want to set this to Client Compatible
Require secure RPC communication: Enabled
Require use of specific security layer for remote (RDP) connections: Enabled and set to SSL security layer
Require user authentication for remote connections by using Network Level Authentication: Enabled
Some individuals recommend changing the default RDP port to enhance security. While I love the phrase “security through obscurity,” obscurity, or changing the port number in this case, doesn’t provide enough protection to be worthwhile. A port scanner can quickly identify your RDP port, in which case you’ve given yourself more work and not accomplished much. There is nothing wrong with implementing this change. It just doesn’t provide any real security.
Remote desktop is a valuable tool, especially for sysadmins. It’s also been the source of many cyber-attacks, which have cost organizations millions of dollars. Ensuring RDP is secure and properly configured is essential to network security.
If you like valuable tools, you should check out PDQ Inventory and PDQ Deploy. With PDQ Inventory, you can quickly scan all of the devices in your environment and return loads of valuable information, such as installed applications, applied patches, hardware information, and much more. With PDQ Deploy, you can easily deploy packages remotely to your systems. The best part is we pre-build hundreds of the most commonly used applications for you. Just download a pre-built package and send it off to your workstations remotely. You can even configure the deployments to happen automatically. If you’re not using PDQ Inventory and PDQ Deploy, you’re working too hard. Try it out for yourself with our free 14-day trial.