Remote access is obviously a very sensitive (often we’d call it intimate) matter. So, security is a major concern here. Many remote desktop software vendors claim their products are secure, but sometimes the details are a bit vague. Let’s try and figure out what we need to know when choosing remote access tools.
The very first step of any project is to understand in sufficient detail what we are trying to get in the long run. Then we’d just keep it in mind all the time, acting consistently to reach it. While this might sound obvious, problems often become evident when your result is so far from the specification that it’s barely usable, and the resources have already been spent.
We’d need to be sure, if the system has to comply with certain standards, be usable for a certain group of users from specific departments, have certain fault tolerance and uptime, etc.
This step is to describe the existing inventory in detail: every stakeholder of the project, each part of the system and so on:
It is hard to find an isolated and completely Internet-agnostic system today. More and more often, companies allow remote access to their infrastructure, connect geographically distributed departments and make workplaces available from everywhere on mobiles. These trends bring certain requirements for secure access and data transmission.
It is important to discriminate between authentication and data transmission. Authentication may include many parts:
Accessing remote systems can be done in a variety of ways. It can be data transfer (file transfer, remote printing, etc.) or full control over a remote system. Remote control happens between two units: the host that is under control and the client who is controlling the host. So, a remote access solution (and, more specifically, a remote desktop solution) is a software that runs on an operating system and interacts with many other parts of the infrastructure.
Before choosing any solution, the important part is to thoroughly check whether existing components are good enough for our final solution and that they don’t require any fundamental changes. This includes the operating systems and their authentication mechanisms, network connections and many other things.
Secure data transmission requires transport layer encryption prior to the transmission. Encryption is provided using AES ciphers with 128 or 256 bit keys (sometimes even 512 bit). AES is known as a secure and reliable algorithm and the only known method to crack it is brute force. It will take thousands of years to crack a 128 bit key while 256 bit keys are indecipherable in any foreseeable future.
In addition to transport layer data encryption, many remote desktop solutions use TLS or DTLS to secure the transport layer transfer (done over TCP and UDP, for example). This is done via native OS interfaces or libraries such as OpenSSL. However, some legacy browsers or software (i.e. old Java versions) may not be able to support new and secure algorithms of cipher suites, so avoid them whenever possible.
Network tunneling with encryption is a good way of improving security with some security measures already in place. The decision, of course, depends on the data gathered during the previous steps (listing the assets and the existing security measures). Here are some cases where tunneling wouldn’t hurt, and some ways to implement tunneling:
In most cases, VPN or SSH is the best response to the above challenges.
SSH
SSH is pretty much the weapon of choice for UNIX and Linux admins (including OS X which is POSIX compatible). SSH provides simple and powerful command line access to remote systems. It is also known to be able to make tunnels, and the level of security is up to the user. The interesting news is Microsoft bringing OpenSSH to Windows admins. We hope that it’s there before 2017, but we can’t be sure, of course.
VPN
Another industry standard here is virtual private networks (aka VPN). It is a broad set of technologies for creating secured networks (tunnels) between two points another. Some solutions such as Tinc VPN provide options for creating mesh networks. However, the most known and widespread open-source solution is OpenVPN. It available for Linux, Windows, OS X, Android, iOS, and some routers support this implementation out of the box.
Many vendors provide their own solutions for secure tunnels, including Cisco and Microsoft among others. The problem of such solutions is their proprietary nature, lack of support of some operating systems and being closed source. It doesn’t mean you should avoid such solutions at all costs. It means that when considering them, be sure to check all your existing inventory for possible compatibility and integration issues.
Meeting the requirements set forth in a broad range of public and non-public standards (many of them aimed at securing personal information, such as HIPAA, etc.) often depends on whether these standards are actually standards and there’s a certification procedure or they are just a set of basic rules and guidelines. That means, for example, that not all components that claim to be “HIPAA-ready” or “HIPAA-compliant” out of the box will actually allow your entire and well-running HIPAA-compliant solution to pass the audits, when they are integrated into it.
DeskRoll’s client side (one that enables you to control the remote host) is working inside web browser, DeskRoll website works through HTTPS, which ensures that all transferred data is encrypted with AES. The website doesn’t support obsolete cipher suites.
DeskRoll UA component which is installed on the remote host is used for unattended access. This is a convenient method for frequent access at any time, and the UA component works as a Windows service. Here 3-step authentication is possible: a password to your web-based DeskRoll account, an optional password to the remote host inside your account, plus, the remote system’s authorization mechanism.
DeskRoll Remote Desktop is another component intended for ad-hoc remote support. It has to be run by a user who’s already logged into the remote system. Hence it’s suitable for ad-hoc remote support only (the user can choose to keep the component but remote connection will still require their permission).
DeskRoll applications do not require ports to be open and is able to work in complex network environments. They only open ports temporarily, while maintaining constant connection to DeskRoll’s central communication server. To avoid dependence on the communication server, self-hosted DeskRoll is available (i.e. you will have your own communication server).
We covered the basic principles and technologies for maximizing remote access security. We hope that help someone.
In our previous posts, we have already dwelled some aspects of security. Feel free to read and comment them!