The SBHVL project - Part 3: Management, Remote Access and more Security

This is the third and last part of the SBHVL (Small Budget Hosted Virtual Lab) project post series (I will assume that you have already read at least Part 1, see also Part 2). This time I will explain how to remotely access, use and manage the environment.


Managing and securing the host and the router VM

As you will probably remember from the network setup we have two machines that are directly exposed to the Internet: the physical host and the Linux router VM. On the one hand this makes it easy to access and manage them from any computer that has an Internet connection. On the other hand this imposes security risks that you need to take care of. Luckily both machines already have their own built-in firewall, and you can open incoming ports on it by using the well known management tools:

The ESXi firewall can be configured through the vSphere client (see Configuration/Security). By default it allows all incoming and outgoing traffic that is necessary to ensure proper functionality and manageability of the system. So you normally do not need to tinker with it. However, you will sometimes need to enable ssh access to the host for advanced management tasks (like installing ESXi patches) using esxcli commands. You can enable ssh in the vSphere client by opening the Service properties in the Configuration/Security dialog and starting the SSH service there:

Enabling SSH access in the vSphere client

I recommend that you stop the ssh service again (using the same dialog) once you do not need the access anymore, because this is certainly one of the most preferred hacker targets. I can hardly think of any reason for leaving ssh access permanently enabled, but if you really need or want to do this then you should at least consider changing the port used by ssh (the default is 22). Unfortunately this is not easy to accomplish in ESXi... - for the curious: KB2011818 describes how this can be done. It's really quirky ...

With the Router VM the situation is different: For remotely managing a Linux machine ssh access is almost inevitable. You will want to leave it permanently enabled, but to make it as secure as possible you should

• not permit the root user to log in via ssh: this is the default. Use a non-root account to log in and then use su to switch to the root account. 
• change the ssh port: Unlike with ESXi this can be done quite easily using Yast (see "Network Services / SSHd configuration"), but also remember to open the new ssh port in the Firewall (in the "Allowed Services" section click on the "Advanced..." button to enter the port number there). 
• keep your Linux system updated: Be sure to use a current Linux distribution and update it regularly with the latest security patches. 

For accessing your host and the router VM via ssh from a Windows system I recommend using the free putty client. It is very lightweight and consists only of a single executable file (putty.exe), but is nevertheless fully featured.

Accessing the lab VMs on the private network

Your lab VMs on the internal network are not directly connected to the Internet which greatly enhances security, but leaves one important question open: How can you access them from the outside? To accomplish this you need to somehow tunnel through the firewall of your Linux router VM. I will outline two different ways to do this.

Option 1: The masquerading firewall

Configuring a masquerading firewall in YaST

The first and most easy to use option is to configure masquerading on the Linux firewall of your router VM. This means that the router VM will provide access to specific TCP or UDP ports of your internal machines through arbitrary ports on its own external interface. In the above example we have configured three such forwardings:

1. If you connect to the port 33890 of the Router VM's external IP address using a Remote Desktop Client then you will really open an RDP session on the Windows VM that has the internal IP address 192.168.33.2, because the connection will be forwarded to its port 3389 (that is the standard listening port for RDP connections).
2. The port 33891 of the Router VM is forwarded to the RDP port of another internal Windows VM (with IP address 192.168.33.3).
3. You can also keep the original port number like we do in the third example: If you open a https connection (on the standard port 443) to the external IP address of the Router VM then you really open a https connection to the internal VM with the IP address 192.168.33.4.

The big advantage of this method is that you can transparently connect to any service offered by an internal VM from anywhere on the Internet and without the need for any special prerequisites. However, you drill holes into the firewall to accomplish this ... and make distinct ports of your internal VMs directly accessible from the Internet. That means that you need to take care of any possible vulnerabilities that the exposed services might have. For Windows Remote Desktop Connections e.g. you should configure the Windows servers to require Network Level Authentication (NLA) to enhance protection (see this Microsoft article for background and instructions).

Option 2: Using ssh tunnels

The second remote access option avoids opening additional ports on the firewall and uses only the ssh connection to the Router VM. This time the port forwarding is configured on the client's end and is tunneled through the ssh connection that was established previously:

Configuring ssh tunnels in putty

That means you have prerequisites on the client's end: You need to have and ssh client and a valid account (username and password) on the Linux Router VM to establish the ssh connection. Once you have this you are able to map any port of any machine on the lab's internal network to an arbitrary port of your local machine!

The putty configuration example shown above creates the same port mappings that we used in the example for option 1 (see the putty manual for detailed instructions). The data flow is as follows:

1. You log in to the ssh port of the Router VM using an ssh client (putty.exe) with the tunnel configuration shown above.
2. Then you connect to your own machine (IP address 127.0.0.1) where the ssh client (putty.exe) listens on the ports 33890, 33891 and 443 (using the Remote Desktop Client resp. a web browser).
3. The ssh client forwards the data through the ssh connection to the ssh server on the Linux Router VM.
4. The ssh server forwards the data to the specified target port on the internal network. 

In the end you have exactly the same connectivity than with option 1, but all data flows through the ssh connection, is encrypted and optionally compressed! So, is this the better choice? It depends ...

It depends on whether you want to provide publicly available services (like a web server) on your internal VMs or a private connection into your test lab only for yourself (or few known people). In the first case you must choose option 1, in the latter case you can also choose option 2 to enhance security, paying with the effort of establishing an ssh connection first.

Of course you may as well use both options at the same time.

And think of the following: You really do not need to make all of your internal lab VMs accessible from the Internet. For my lab I am using the concept of a bridgehead (or jump host) machine. This is a Windows 7 VM on the internal network that has all the tools installed that you need to manage and use your lab. Whenever I want to use my lab I connect to this machine (through one of the options mentioned above) and do my work there. This has two main advantages: The bridgehead machine is inside the internal network, so you do not need to cross any more firewalls, and it has the best possible network connection to all the other lab VMs!

Recommended software for management and remote access

I already mentioned the vSphere Client that you need in any case to manage your physical ESXi host (and maybe some virtualized ESXi instances that you run on top of it). You will also need an ssh client (like putty for Windows) to connect to your ESXi host, the Router VM and any other Linux servers that you might run on your internal network. There are also free ssh clients available for mobile devices.

But what about managing ESXi from mobile devices? Well, this is what some great VMware Engineers developed the vCMA appliance for. vCMA stands for vCenter Mobile Access and is a so-called fling available from the VMware Labs. It is a Linux-based virtual appliance that you can easily deploy on your host and into the internal network. Unlike the name suggests you can not only register vCenter servers with it, but also standalone ESXi servers. These can then be managed through a slim web interface that the appliance provides and that can be used directly on Android devices or the Apple iPhone. For the iPad there is also a free app available that makes it even more comfortable to use than in a browser window: The VMware vSphere Client for iPad.

For managing your Windows VMs you will most likely use the Remote Desktop Client (RDC). For non-Windows machines and mobile devices there are also free Remote Desktop Clients available. I was not able to find a free client for Android or iOS that supports Network Level Authentication (NLA), but there are several inexpensive apps available that even support this.

If you want to remotely use the nice graphical interfaces that your Linux machines offer then one option is to use an X11 server for your client device. For Windows there is the free Xming server that works very well for me. X11 servers are also available for mobile devices, but you should be aware that the X11 protocol requires a certain network bandwidth, and a 3G connection is not really suitable for it. NoMachine's NX protocol adds encryption and compression to the X11 protocol and is much more usable under low bandwidth conditions. There is a free edition of the NX server (for Linux), and the NX client is also freely available, but only for Windows, Linux, MacOS and Solaris, but not for mobile devices.
Another option is to use an Xvnc server on the Linux box and a VNC client on the connecting device. VNC clients are freely available for literally any client platform, and they also offer better performance than pure X11.

This is by far not a complete list of remote access solutions for Windows and Linux, but just a list of the ones that I know and are open source'd or at lease freely available. Feel free to make any additions or suggestions in the comments of this post!

The end and the beginning

This concludes the third and last part of my series of posts about what I have called the Small Budget Hosted Virtual Lab (SBHVL) project. I hope you enjoyed it!

But it is also the beginning of me using the lab to evaluate and test new things (not only VMware or virtualization related things), and in the future I will certainly blog about some of these ...