Problem solve Get help with specific problems with your technologies, process and projects.

Remote Desktop Protocol security: How to secure RDP network endpoints

What is RDP and why does it pose a security threat? Expert Matt Pascucci explains why it’s needed and how best to secure RDP it in the enterprise.

Remote Desktop Protocol: What it is and how to secure it

Recent flaws in Remote Desktop Protocol (RDP) have shined a spotlight on the remote access protocol. In fact, noted...

network security expert Dan Kaminsky recently said RDP is in use on more than 5 million Internet endpoints today. As you can imagine, if enterprises don’t properly secure RDP, network and endpoint security can be compromised.

In this tip, I’ll briefly examine what RDP is, why it’s needed, and how it is most often used on enterprise endpoints. I will then examine how enterprises can ensure RDP is used securely or, when appropriate, how to ensure it’s not in use.

What is RDP?

Remote Desktop Protocol is a proprietary protocol created by Microsoft. It allows a system user to connect to a remote system with a graphical user interface. The client-side agent is built into the Microsoft operating system by default, but can be installed on non-Microsoft operating systems, such as those from Apple, various flavors of Linux, and even mobile OSes like Android.

Knowing how RDP works, why it’s being used, and what can be done to secure it will allow administrators to get a better hold of securing their systems.

The server-side portion of RDP is installed on a Microsoft operating system and receives requests from the client agents to display some graphical form of a published application, or remote access to the system itself.  By default, a system will listen on port 3389 for requests from clients to connect via the RDP.

How is RDP most often used in enterprises?

Normally, an RDP or terminal service sessions are configured on servers that have a need for a distributed client machine to connect to them. This can either be for management, remote access or publishing an application for central use.  This protocol is also commonly used by desktop administrators to remotely access user systems to assist with troubleshooting. It’s this specific function that can become an issue if not configured properly, allowing unauthorized access to key enterprise systems.

How to secure RDP

Now that we understand what RDP is and how organizations use it, here are a few ways to secure RDP implementations:

  • Verify 128-bit encryption is in use between clients and servers; 128-bit encryption allows for stronger keys that are less likely to be cracked. By default, the RDP connection will try to use 128-bit, but if it can’t, the client will most likely fall back to 64-bit encryption. As a precaution to verify systems won’t fall back to a lower level of encryption, administrators can configure Group Policy Objects (GPOs) to have the encryption level set to their individual standard. It’s recommended that it’s enabled to “High Level.”
  • If access to a system is needed via the external network, instead of leaving the port open for anyone to abuse, configuring a VPN to tunnel back into the network and then using RDP is recommended. Even better than this would be to create a remote desktop gateway that would allow remote connections using HTTPS and the RDP to create a more secure and encrypted connection to the endpoint. Both of these methods are recommended over leaving RDP port 3389 open on the perimeter network. 
  • With newer versions of Windows operating systems (Vista, Windows 7 and Server 2008), administrators can enable network-level authentication (NLA) as an additional layer of authentication before establishing a connection to the RDP host server. This takes the authentication away from the system and uses fewer resources.  This can also help by reducing potential denial-of-service (DoS) attacks against brute-force attempts; the NLA would serve as a buffer, preventing an attacker from barraging the RDP host server with access requests.
  • By default, the RDP host system listens on port 3389 for connections from RDP clients. It is possible to change the listening port of the RDP service, which would protect the network from any malware or attackers scanning systems for RDP on port 3389. However, this “security by obscurity” approach can lead to errors and oversight. It’s possible to change the port, but you need a good reason for doing so.
  • Using firewalls either on the perimeter or on the OS to filter incoming requests to only approved sources and permitted destinations via RDP connections can limit who can actually connect to these servers. If there’s a particular group of people that are only supposed to connect to a particular group of servers, wrapping firewall rules around these requests will help contain access.
  • Verify who’s capable of creating an RDP connection to a server. Consider restricting RDP access to specific groups (via Group Policy or manually on target machines) instead of leaving it open to everyone. Restricting access, too, is always preferable. Also, removing the local admin account from RDP access is recommended. All users’ accounts should be clearly defined on the system ahead of time.
  • While NLA performs some form of authentication, using SSL certificates to authenticate a client request to a host system is the best method of authentication available for RDP. Installing the certificate on the system and the RDP client will allow certificate authentication before an RDP session can be established.
  • Verify all patches to systems running RDP are up to date, especially after the recent events resulting in Microsoft security bulletin MS12-020.
  • Lastly, use GPOs to force a password policy to allow a certain password length in the domain and set a lockout policy to stop hackers from tying to brute force their way into a server.

Defending against rogue RDP use

The above-mentioned methods are ways in which an organization can secure the use of RDP in an organization. Now, let’s take a look at a few ways a company can verify RDP isn’t in use to protect itself against rogue or unauthorized installations of RDP.

  • Running vulnerability or port scans across the network, both internally and externally, can help decipher if there are any systems listening for RDP connections. Running these scans internally can help show which systems are running RDP. It’s then up to a company’s team to verify if they’re supposed to be running this software. From an external point of view, if scans show up with RDP listening from the outside, it’s a queue to take action as soon as possible. Many vulnerability scanners will find RDP running on non-standard ports, so that will help if someone is trying to hide the installation.
  • Using logging or a security incident and event management (SIEM) system to verify what devices are listening and accepting RDP sessions can give your organization insight into what type of RDP connections are occurring on the network.  Are there multiple failed logins to certain systems? Are others accepting connections that shouldn’t be?
  • Lastly, the best method to ensure systems aren’t using RDP inappropriately is by defining a Group Policy that allows only approved systems to run the RDP.

In conclusion, RDP is a great tool used by administrators and users alike to establish multiple connections to a system from a centralized location. It’s also used by admins for remote systems management, but just like anything else, if the connections and software aren’t secure, companies are putting themselves at risk. Knowing how RDP works, why it’s being used, and what can be done to secure it will allow administrators to get a better hold of securing their systems.

More on RDP security

About the author:
Matthew Pascucci is an information security engineer for a large retail company where he's involved with vulnerability and threat management, security awareness and daily security operations. He’s written for various information security publications, has spoken for many industry companies, and is heavily involved with his local InfraGard chapter. You can follow him on Twitter at @matthewpascucci or check out his blog at

This was last published in July 2012

Dig Deeper on IPv6 security and network protocols security