We rely on remote access to provide secure network connectivity to external locations. In this video, you’ll learn about VPN types, clientless VPNs, remote desktop connections, remote desktop gateways, and more.
If you’re on a public network at a coffee shop or a hotel and you’d like to have a secure communication back to your home office, you may want to use a VPN, or Virtual Private Network. Normally, you would be connecting to a VPN concentrator. This might be something integrated into a firewall, or it might be a standalone device specifically designed for VPNs. There are many ways to implement a virtual private network.
You could use specialized hardware, such as the one here, or you could have a software-based VPN that’s using an existing server. This is usually integrated with software that’s running on a client device. This is sometimes software that’s built into the operating system or it may be additional software that you install.
Here’s a common use case for a client to site VPN. Our corporate network is the site, and your client might be a laptop that’s at a local coffee shop. You want to be able to send and receive data to some of these devices on the corporate network, but you want to be sure that all of this communication is encrypted. We would use software on the laptop to be able to create this VPN tunnel.
This software is commonly configured as on demand, so you would turn it on or off as needed, or it may be configured to be always on. And if this laptop is outside of the building, then it will always have a VPN connection back to corporate. When you start this software, it will encrypt all of the data that you send between your in station and the VPN concentrator.
Anyone in the middle who intercepts this traffic would not be able to see or understand anything that’s being sent to the corporate office. The VPN concentrator receives the encrypted data, decrypts the information, and sends it into the corporate network. The process is reversed on the way back, and the laptop is responsible for decrypting the data when it’s received on the other side.
A site-to-site VPN works a little bit differently. We might have a corporate network and a remote site, and we would like all communication between those sites to be encrypted over a VPN. This would be a configuration that will be set to always be on, because there would never be a time when you would not want to secure the data between those locations. Often, the firewall is used as the VPN concentrator on both sides, so you would create an encrypted tunnel between those two firewalls and each firewall as the VPN concentrator would be responsible for decrypting that data and sending it into the local network.
The latest browsers in our devices are able to use hypertext markup language version 5, or HTML5. HTML5 includes a number of enhanced capabilities, including API support and a web cryptography API. This means your browser has the ability to perform cryptographic functions within the browser itself and can effectively act as a VPN endpoint. This means you would not have to install any additional software or have any support for VPNs built into your operating system.
Instead, you would have a clientless VPN that all operates from the HTML5 browser. As long as you’re running an HTML5 compliant browser, you can connect to your clientless VPN concentrator and be able to have secure communication between your device and your remote office. In our previous example from the coffee shop, our remote user had a VPN tunnel to a VPN concentrator, and that dropped off all of that traffic onto the corporate network.
But there may be times when this remote user needs to communicate with devices that are elsewhere on the internet. If this is configured to be a full tunnel, then all of the traffic sent to the corporate network would be sent over that tunnel and any traffic that needed to go elsewhere on the internet would first need to go to the VPN concentrator at the corporate network and then be redirected to the devices out on the internet. This full tunnel means that all of the traffic between the remote user and the rest of the world is all going through the existing VPN concentrator.
With a split tunnel, the VPN administrator can determine what traffic is sent over the VPN and what traffic could be sent outside of the scope of the VPN tunnel. Let’s take the same scenario with a remote user that needs to communicate to the corporate network. Anything sent to the corporate network would go through the VPN tunnel, but the client on the remote user’s device might need to send information to professormesser.com, which is not located on the corporate network.
Any traffic that’s not internal to the corporation can be sent outside the scope of the VPN tunnel, creating what’s called a split tunnel. This allows the client to communicate to the internet without using any resources located on the VPN concentrator at the corporate network. If you’ve ever worked on a help desk, then you’re probably very familiar with a remote desktop connection.
This allows you to be in one location but be able to see and control the desktop that’s on a remote device. If you’re in a Windows environment, you’re probably using RDP, or Microsoft’s remote desktop protocol. There are clients available for remote desktop protocol in Mac OS, Linux, Windows, and other operating systems as well. This means you could remotely control a Windows device, even though you might be using a completely different operating system.
If you’re using a remote desktop on a Linux or a Mac OS device, then you’re probably using VNC, or virtual network computing. This uses RFB, or the remote frame buffer protocol, to be able to share the screen and control the remote desktop. Of course, we commonly use this remote desktop functionality for remote access to systems and to provide remote support, but you’ll often find that scammers will also use this to gain access to your system and take information from your computer.
In an enterprise environment, you may need a secure gateway to provide access to these remote desktops. To provide this functionality, you might have remote desktop clients communicating to a centralized remote desktop gateway over SSL. This is Secure Sockets Layer, or what today we call TLS or transport layer security, and it allows someone to authenticate to the remote desktop gateway and then be able to connect to remote desktop services that may be on an internal network.
There’s no special configurations required, because the remote desktops are using well-known protocols, such as SSL or TLS to communicate to the gateway, and the gateway is acting as a proxy to all of these remote desktop services. This is commonly started from a browser, so you would need a browser on your remote desktop client that provides the SSL tunnel into the remote desktop gateway. From there, you’re able to use the Remote Desktop Protocol from the gateway to any of the remote desktop services on the internal network.
If you’re communicating into the terminal session of a remote device, especially a Mac OS or Linux device, then you’re probably using SSH, or secure shell. SSH allows you to have a terminal screen, similar to what you might find with Telnet, but with SSH, the entire communication is secure and encrypted. This usually communicates over TCP port 22 to provide this encrypted connection to a command line.
In some environments, you may find that the user doesn’t have a full sized desktop or laptop computer at their desk. Instead, they have a thin client and they connect to a virtual desktop infrastructure. If you move that VDI to the cloud, you can now have a cloud hosted virtual desktop and be able to access nearly any operating system from your browser. And almost all of these implementations, the communication from your local machine to the cloud based virtual desktop, is all over an encrypted channel, very similar to performing a remote desktop connection.
This allows you to have a desktop set up in the cloud that you can then access from a browser but all of that communication will be secure. Accessing a device remotely can be a significant security concern. Take for example the situation that occurred with subway sandwiches between 2008 and May 2011. 200 of their locations were breached because they were running remote desktop software on their point of sale systems, and the attackers were able to determine the authentication to gain access into that point of sale.
This means that they were able to steal 80,000 credit card numbers and make millions of dollars of unauthorized purchases. If you are configuring remote desktop for a system, you want to be sure you have more security enabled on that device. You certainly don’t want to have the default credentials, and you want to be sure that any passwords you’re using would not be susceptible to a brute force attack.
And once someone connects to that device remotely, you want to be sure that their access is limited to only what they need to have. These limited access rights might prevent the scope of someone gaining access to credit cards or other information that normally they would not have access to. And if you’re a network administrator, you’re probably very familiar without of band management. You have many different infrastructure devices at these remote sites, and if you lose your primary internet connection to those sites, you need some way to get around that problem to be able to manage those systems.
In those cases, you would use out-of-band management. Almost all of your switches, routers, firewalls or other infrastructure devices have a management interface on them that you can connect to using a modem or third party communications method. These usually have some type of serial connectivity like this nine pin serial connection or a USB connection. That makes it very easy to connect a modem or some other type of communication device that allows you to get around any outages.
If your remote site has a number of different devices that you need to connect to, you might want to install a console router or what we call a comm server. This allows you to connect to the comm server first, and from there, you’re able to connect to the serial interface on all of your infrastructure devices.