Securing RDP

by Ashur Kanoon on December 8, 2022

RDP Introduction

Remote Desktop Protocol (RDP) is a proprietary protocol developed by Microsoft which provides a user with a graphical interface to connect to a Windows-based computer over a network connection. The user employs RDP client software for this purpose, while the other computer must run RDP server software. Browser-based access is also supported, eliminating the need for client software, though it does require an RDP to HTML5 broker.

To access Macs, Virtual Network Computing (VNC) may be used. VNC, developed by Olivetti & Oracle Research Lab at Cambridge in the UK, is a graphical desktop-sharing system that uses the Remote Frame Buffer protocol (RFB) to remotely control another computer. By default, RFB is not a secure protocol. While passwords are not sent in plain-text (as in telnet), cracking could prove successful if both the encryption key and encoded password were sniffed from a network. Many flavors of VNC exist, including free versions.

The following protocols and ports are used, and thus need to be protected:

RDP
- TCP
- Port 3389 is used for internal (LAN)
- Port 3390 is for external (WAN) connections
VNC
- TCP
- Ports 5900, 5800 and 5901 for multi-monitor

Another related technology is Virtual Desktop Infrastructure (VDI). VDI refers to the use of virtual machines to provide and manage virtual desktops. VDI hosts desktop environments on a centralized server and deploys them to end users on request. Popular VDI solutions are available from Citrix and VMware and they have client and client-based methods to access them.

RDP servers may be accessed directly or over a Virtual Private Network (VPN). RDP sessions can use free clients such as Microsoft Remote Desktop. RDP can also be accessed over HTML5-enabled browsers using free, open-source software such as Guacamole. In actual practice, the Guacamole server is typically made accessible behind a firewall and accessed using a tunnel-based VPN. Unfortunately, such approaches suffer from poor performance.

Sponsorships Available

How to Secure RDP Services

Here are some tips to secure your RDP Server:

Hide the server
- First security rule of RDP – it is absolutely unacceptable to leave RDP exposed on the internet for access – no matter how much endpoint and systems hardening is performed. The risks of such exposure are simply far too high. RDP is meant to be used only across a local area network (LAN).
Lock down the server
- Locking down the server itself vs. locking down the access. Be sure that no other services are running on the same machine. Be sure to enable windows (and macOS) firewalls allowing access only from the LAN IP-address range and only to the ports required. Enable activity logging and check it often to ensure that users are not attempting anything they shouldn’t be. It may be best to disable persistent sessions.
- RDP may be enabled on standard end-user machines and also those running RDS. Using standard end-user machines is not preferred and will make it harder to monitor usage.
- Be sure to upgrade the server and OS often. Many CVEs exist for RDP. Running a quick CVE search at https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=RDP returns 104 CVEs for FreeRDP, Windows Remote Desktop Protocol (RDP), and other flavors.
Pick an access method
- With some solutions, two methods may be available: tunneling traffic for RDP and proxying. Each has advantages and disadvantages. With mTLS (mutual TLS), proxying is an option that adds connection-level security onto a standard RDP connection. If tunneling is preferred, be sure to enable granular access to ensure the best end-user experience. Be sure to configure idle timers to ensure that inactive systems are quickly logged out.
Authentication and authorization
- All users should be authenticated. Under no circumstance should generic users be allowed. Generic user accounts make it hard to authorize what a user should do and impossible to know who was signed in if there is a security event.
- Enable MFA (Multi-Factor Authentication) at the access and system level, if possible.
- Check that access is coming from a known system and determine the system’s trust by enabling device identity and trust features. Organizations may decide to give full desktop access to compliant devices and single-application access to non-compliant or unknown (3^rd party) devices.