Page225

Remote Desktop Console Access

Many users require remote access to computers’ consoles. Naturally, some form of secure conduit like an IPsec VPN, SSH, or SSL tunnel should be used to ensure confidentiality of the connection, especially if the connection originates from outside the organization. See the “VPN” section above for additional details on this layer of the remote console access.

Remotely accessing consoles has been common practice for decades with protocols such as the cleartext and poorly authenticated rlogin and rsh on UNIX-like operating systems, which leverage TCP port 513 and TCP port 514, respectively. Two common modern protocols providing for remote access to a desktop are Virtual Network Computing (VNC), which typically runs on TCP 5900, and Remote Desktop Protocol (RDP), which typically runs on TCP port 3389. VNC and RDP allow for graphical access of remote systems, as opposed to the older terminal-based approach to remote access. RDP is a proprietary Microsoft protocol.

Increasingly, users are expecting easy access to a graphical desktop over the Internet that can be established quickly and from any number of personal devices. These expectations can prove difficult with traditional VNC and RDP based approaches, which, for security purposes, are frequently tunneled over an encrypted channel such as a VPN.

A recent alternative to these approaches is to use a reverse tunnel, which allows a user who established an outbound encrypted tunnel to connect back in through the same tunnel. This usually requires a small agent installed on the user’s computer that will initiate an outbound connection using HTTPS over TCP 443. This connection will terminate at a central server, which the user can authenticate to (from outside the office) to take control of their office desktop machine. Two of the most prominent solutions that employ this style of approach are GoToMyPC and LogMeIn.

Desktop and Application Virtualization

In addition to accessing standalone desktop systems remotely, another approach to providing remote access to computing resources is through desktop and application virtualization. Desktop virtualization is an approach that provides a centralized infrastructure that hosts a desktop image that can be remotely leveraged by the workforce. Desktop virtualization is often referred to as VDI, which, depending on the vendor in question, stands for either Virtual Desktop Infrastructure or Virtual Desktop Interface. VDI is also called DaaS (Desktop as an Infrastructure).

As opposed to providing a full desktop environment, an organization can choose to simply virtualize key applications that will be served centrally. Like desktop virtualization, the centralized control associated with application virtualization allows the organization to employ strict access control, and perhaps more quickly patch the application. Additionally, application virtualization can also be used to run legacy applications that would otherwise be unable to run on the systems employed by the workforce.

While the terms and particulars of the approach are relatively new, the underlying concepts of both desktop and application virtualization have existed for decades in the form of thin clients, mainframes, and terminal servers. The main premise of both the refreshed and more traditional approaches is that there might be organizational benefits to having more centralized and consolidated computing systems and infrastructure rather than a large number of more complex systems. In addition to general “economies of scale” justifications, there could be security advantages too from more tightly controlled desktop and application environments. Patching more complex applications in a centralized environment can be easier to manage. Likewise, developing and maintaining desktops to a security baseline can be easier to accomplish when there is one, or even several, central master images that determine the settings of each corresponding virtual desktop.

VPN, leased lines, etc. Extranets are commonly used for remote offices, to provide connectivity to organizations that partner together, and vendor support. These third-party connections represent a significant risk: the third party could become compromised, and the attacker or malware could pivot via the extranet connection and attack the organization itself. These types of connections require an organization to trust third-party security to a certain degree.

Extranet connections should always occur via leased lines or encrypted VPN. Access Control Lists (ACLs) should strictly control which systems may be reached via an extranet connection. From a detective standpoint: enhanced monitoring should be used, including detecting attempted connections to systems that are blocked by ACL. Strong host-based controls should be deployed on systems reachable via extranet connections: patching, hardening, the use of dual-factor authentication, etc.