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.
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.
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.
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.
Continue reading here to learn on ways to detect rouge RDP use:
http://searchsecurity.techtarget.com/tip/Remote-Desktop-Protocol-security-How-to-secure-RDP-network-endpoints