One of the major benefits of running Windows is the built-in Remote Desktop protocol. It is, in fact, the #1 thing that I missed most when Linux was my host operating system. When I was forced to install Windows as my host operating system after numerous driver issues when attempting to run 2 nVidia graphics cards at once, I was eager to get RDP re-enabled on my workstation. While it requires a bit more administrative work upfront, particularly due to its numerous security issues (and these aren’t insignificant either), it certainly provides better performance than any of its competitors (especially if you use a modern version of the Windows client). Here is what you should know about the protocol and how to implement it properly:
RDP has been a magnet for 0-day exploits and users of it should not ignore the real possibility that they will eventually fall victim to these exploits if they don’t protect their machine from attackers. The attractiveness of RDP to attackers is partly due to the protocol’s power – since it’s designed to give remote users full access to their accounts on a remote host, it is likely that an attacker will gain significant privileges on the remote host by compromising a local account. The protocol may be even more attractive to attackers simply due to the fact that most targets with the protocol enabled are of high value (either they’re servers or they are machines within an enterprise).
Regardless, it is imperative that users of the protocol take precautions to protect themselves from attack. If possible, try to isolate remote access to only approved clients. This should be done at the network level, possibly using a VPN. In my specific case, I’m limited to only restricting access by setting firewall settings to only allow connections from IP addresses I trust. Assuming the firewall is correctly configured and does not have remote access vulnerabilities (which is not necessarily guaranteed), this provides pretty decent protection against 0-days, since an attacker would need to either compromise a trusted IP address or masquerade as that IP address.
The VPN route is a much better option if you’re able to control the machines that are acting as clients to your server. This provides the best protection, since it requires a potential client to authenticate to the VPN server first, prior to connecting to the RDP server. Of course, the security of this option is wholly dependent upon the chosen VPN server and requires the administrator of the VPN server to properly configure it to only allow authorized access (PPTP in Windows is such an example, as the MS CHAPv2 authentication protocol that it’s dependent upon is vulnerable to brute-force attacks).
Importantly, configuring the network connection to the server is not a substitute for properly updating the host. Although not perfect, Microsoft frequently releases patches for the protocol that improve performance and patch security vulnerabilities. This should not be trusted alone, since Microsoft may not be able to update the protocol before it’s being actively exploited, but it should be included in an overall protection strategy.
USING LINUX WITH IT (THE BEST WAY)
I should note that RDP has several open-source implementations that provide reasonable performance and compatibility with native clients. Often, however, these implementations are not as fast or efficient as their native counterparts. One of common techniques used to accomplish this is encapsulating a VNC instance inside of an RDP session. This allows the server to accept connections from clients on the RDP protocol and to offer some compression, but it does not provide very good performance.
Another option is to virtualize your Linux desktop. This is what I’m doing right now and the experience is close to using a native machine (as long as your host for the virtual machine has enough memory and a reasonably modern processor with CPU-based virtualization extensions). I’m having no issues accessing my Fedora 20 VM while I type this article in Emacs inside of the guest OS. RDP actually handles the virtual machine’s screen quite well, although it does suffer from slightly worse performance than an application with native Windows UI elements (see below for information on why). As a side benefit, once you’re using a virtualization environment extensively, adding new VMs to test software or do development work on a target platform becomes a lot easier.
HOW THE PROTOCOL WORKS BETTER THAN ITS COMPETITORS
I’m sure I will get some flack for claiming that RDP provides better performance and usability than it’s competition, but this is mostly true (only when connecting to Windows hosts). Since the protocol is deeply integrated into Windows, it benefits from being able to truly emulates local experience on a remote machine.
Technically, RDP “cheats” in rendering a remote host by calling local versions of common Windows UI library elements instead of trying to render these elements remotely. It also keeps track of which portion of the screen has changed during a connection. This contrasts other protocols, such as VNC, which sends a bitmap “image” of the remote screen. VNC polls the screen several times a second and sends a new version of the bitmap image to the client to keep client in “sync” with the remote host. Compression helps mitigate some of the latency issues, but it does not provide ideal performance, since it is still sending the whole screen each time a change occurs.
RDP, by comparison, sends only the changed portions of the screen, which helps to reduce the latency (less packets to compress and send each update) and reduces the overall network utilization, so it can be fast on a reasonably slow network. Obviously, actual utilization and latency is dependent upon the workload that you’re trying to push through the protocol. If you’re attempting to watch a full-screen HD video through RDP, you’re likely to be dissatistifed with the choppiness and poor image quality of the video that you’re watching. If, however, you’re working with text and static images (or small videos), your performance will likely be excellent. Right now, I’m accessing my workstation from my older laptop running Windows 8.1 over a fairly slow wireless connection (>500kbps) and the performance is quite good.
It also handles client access better than any of its competition. For one, it allows the user to be signed into their machine remotely without giving them direct access to the host’s screen. This is important in a business environment, where it is not acceptable to leave an unattended machine logged into a user account. RDP “locks” the host’s screen and allows the remote user to interact with the system without “broadcasting” all events to people walking by the host’s monitor. This feature is available in other solutions (such as an X server which allows you to have multiple X sessions at once, each independent of each other), but these solutions either don’t allow users to keep the host “locked” or don’t allow the user to connect to an existing login.
RDP also handles clients with different screen resolutions quite well. My desktop has 3 monitors attached to it, whereas my laptop has a single 1920×1200 display. When I connect to my workstation, my session is adjusted to fit the native resolution of my client. There is no need for me to manually specify my screen resolution before connecting, since my session is automatically adjusted to my local screen configuration. As an aside, RDP also allows for multiple remote monitors on the client end, so you can take advantage of all available hardware on your client.
Needless to say, I’m a fan of the protocol. While I often despise Windows for the lack of flexibility or control, Remote Desktop Protocol, despite it’s security problems, is one of the best features of Windows. It’s fast, simple, yet insanely powerful. There are several other features that I did not touch upon in the article (namely remote audio, device sharing (allows you to share a client-side printer, USB device, or storage option)) that truly make this the best remote desktop option to-date. My main gripe is the proprietary nature of the protocol and the lack of a Linux or Mac OS X server that provides similar performance.