Last updated: 6 Nov 2012

Using VMs in the IAN Lab

• Background
• Host Login
• Simple Standard Windows Operation
• Configuring the Standard Windows VM

Background

In the summer of 2010, the IAN Lab workstations were converted from natively running Windows XP to running a version of Windows in a virtual machine (VM) hosted on Linux. This was done to provide a better learning environment for students. It allows:

• restoring a Windows virtual machine to an initial state to allow reuse

  Basically, the virtual disk on which the operating system is installed is reverted to an initial state. Consequently, students re-using that virtual machine don't need to worry about what the previous students did or didn't do.

• defining one or more virtual machines with student-defined operating systems

  The students define the characteristics of the virtual machine (e.g., virtual RAM, disk space, networking device) and either install the operating system to the virtual disks or use a "live CD/DVD" version of the operating system to do their work. Often, this work is in preparation for an annual collegiate cyberdefense competition, but can also be used for other reasons.

Host Login

A user must first login to the host computer to be able to start any virtual machine. Since the IAN Lab has very limited access to the rest of the world, use of student or faculty logins is not feasible. A generic Linux user account called ituser is used to login; its password is supplied by the instructor.

The ituser login account is not privileged, despite its name, since we don't want the host machine to be controlled by the users of the lab workstations. Control over virtual machines and their guest operating systems is allowed, and is in fact the primary reason for supporting virtual machines.

Other login accounts may be possible for special projects. For example, the Grey Hat Group is provided a login so they can organize their security-oriented activities, often in preparation for the cyberdefense competition.

Simple Standard Windows Operations

• Starting the Windows VM
• Using the Windows VM
• Stopping the Windows VM

Starting the Windows VM

After logging into the host as ituser, the user opens a Terminal application window and runs this command:

~/start_win7

to start the Windows VM. The command is mainly a convenience for the user, so the instructions can be made clear on what to do, vs. introducing the user to VirtualBox's graphical user interface (GUI).

The standard Windows VM provides a version of the operating system that is preconfigured, but can be modified by the user. Once the VM is started and the operating system has finished booting up, the user logs in as ituser again, within that guest operating system. This login account is privileged; i.e., it has the same rights as the Administrator account. The password for the Windows ituser account is also supplied by the instructor.

Using the Windows VM

Once logged into Windows, the user can install, configure and/or simply use applications, or modify the Windows operating system, as her course or project requires. All changes are made to the virtual disk, and are preserved across restarts of the virtual machine.

Stopping the Windows VM

The user should always stop the Windows VM when it is no longer needed. This conserves resources on the host and makes it easier for the next user to do their work.

There are two ways to stop the Windows VM -- by shutting down the Windows operating system in a way that preserves disk writes, and by powering off the virtual machine (which may not preserve all disk writes). If possible, the user should shut down the operating system rather than powering off the virtual machine, but sometimes it is necessary to power it off quickly.

Configuring the Standard Windows VM

Sometimes the default virtual machine configuration isn't enough to do the desired work. Reasonable defaults were chosen to conserve resources, so they should only be changed with considerations for what else may be running at the same time. Sometimes you need more RAM or more disk storage (i.e., additional disks -- expanding a disk is too difficult to cover here), to access a CD or DVD (usually, an on-disk image or ISO file), or to configure the network.

Most VM configurations must be done while the virtual machine is powered off, as a real machine would need to be powered off to add RAM or an extra disk. In these instructions, the configuration changes are made using the VirtualBox graphical user interface, but they could also be done using the VBoxManage command.

• Starting VirtualBox
• Configuring RAM
• Configuring Disk Storage
• Configuring CDs and DVDs
• Configuring Networking

Starting VirtualBox

VirtualBox can be started:

• from the windowing environment:

  Select the Activities/VirtualBox icon (or search for the VirtualBox application).

• from the command line (inside a Terminal application window):

    VirtualBox &
    

You should see all of the virtual machine names of the virtual machines this account knows about.

Select the one desired; e.g., select Windows 7 by clicking on it.

There are three tabs in the panel to the right of the VM names. We will be concerned mostly with the Details tab for configuration changes. In the Details tab, there are several categories; for example, System, Storage, Network.

Click on the Details tab to see those categories.

Configuring RAM

In the Details tab, click on the category System, then:

1. In the Motherboard sub-tab, change the value in the textbox before MB to the number of megabytes of virtual RAM you want this VM to have.
2. Click OK

Configuring Disk Storage

In the Details tab, click on the category Storage. You will see either an IDE Controller, a SATA Controller, or both. Either support virtual hard disk drives, but only the IDE Controller supports virtual CD/DVD drives as well. There are only four IDE Controller ports, while there are many SATA Controller ports. However, IDE Controller use may be more familiar to you -- we use the IDE Controller here:

1. Click IDE Controller
2. To add a port, click on the rightmost icon (looks like a bare, multi-platter disk drive with a plus on it).

   VirtualBox will automatically select one of the available virtual disks to attach to that controller.

3. Click the New button.
4. Click the Next button.
5. Click the New button again -- the default dynamically-expanding space saves a lot of disk space.
6. Change the Size value to the value desired.
7. Click the Finish button to create the virtual disk.
8. Later, after you have started and logged into the Windows VM, you will need to start the Windows Logical Disk Manager, initialize the disk, format it, and assign it a drive letter before it can be used.

Configuring CDs and DVDs

In the Details tab, click on the category Storage, then:

1. Click IDE Controller

   If there is no icon directly underneath it that looks like a CD/DVD disc, then click on the icon to the immediate right of IDE Controller to create one.

2. Click on the CD/DVD icon under the IDE Controller.

   If you've already inserted a CD/DVD into the host machine, it may already appear. If you are using an .iso file, and the Virtual Media Manager already knows about it, then select it from the drop-down list to the right of CD/DVD Device. In either case, you are done -- the contents of the CD/DVD should appear in the virtual CD/DVD drive after you start the standard Windows VM and login.

3. Creating an .iso file from a CD/DVD is left as an exercise for the reader, as is using the menu item File/Virtual Media Manager to select it.

Configuring Networking

Networking is a bit more complicated to set up, because you have to understand the two main ways that VirtualBox does networking, that is, how it uses the host's network device to communicate with the rest of the world. The default networking method is NAT, which is usually pronounced as spelled and stands for "Network Address Translation". The second major method (there are several) is bridging. Consequently, you may see either method used in the lab, and you need to know what they can and can't do.

NAT

You may have encountered NAT when setting up a wireless router at your home. This is the same thing, only it's done in VirtualBox's software vs. in hardware.

In this context, NAT provides the guest operating system with an IP address, subnet and gateway, in the 10.0.0.0/8 subnet. That is well-defined private IP subnet, which means that routers will not route packets to the internet from that subnet. The IP address provided to the guest operating system is typically 10.0.2.15, the subnet is 255.255.255.0, and the gateway is 10.0.2.2. VirtualBox provides a DHCP server and the virtual gateway, tying it to the real ethernet network device (e.g., em1 on Fedora 17 Linux). The real network device should have either another NATed address or a public IP address -- let's say it is 128.208.244.63.

The guest operating system in the VM normally is set up for DHCP, so it is assigned the dynamic address 10.0.2.15. When the OS wants to communicate via the network, it sends out a packet with the destination IP address (e.g., 128.208.244.213) and port (e.g., 80) in it. The NAT mechanism in VirtualBox inspects the packet, records the guest's source IP address (10.0.2.15) and destination IP address (128.208.244.213), changes -- this is the translate part of network address translation -- the packet's source IP address to itself (e.g., 10.0.2.2), and sends the packet to its destination. When the reply packet comes back from the network, VirtualBox's NAT mechanism inspects the packet, looks up which IP address sent the original packet, and changes or translates the new destination IP address to the guest operating system's IP address (10.0.2.15), and sends the packet to the guest.

The advantage of NAT is that you can have a large number of computers behind the NAT mechanism that share just one public IP address, thereby preserving scant public IP (IPv4) addresses. Another advantage is that since there is no external, public IP address for the NAT'ed devices (a device such as the Windows VM is said to be NAT'ed), behind the NAT mechanism, unsolicited packets can be dropped. That is, since only the NAT mechanism knows who started a network communication, any packets sent to the one public IP address that aren't the result of a NAT'ed device can be ignored... hackers can't get in -- at least, as easily.

There are limitations to NATing. You can't put a server behind a simple NAT mechanism -- it only translates IP addresses. You can put a server behind a more complicated NAT mechanism -- one that "translates" ports as well as IP addresses. In addition, in a simple NAT it is not possible to ping from behind the NAT mechanism to the rest of the world; however, since pinging is such a critical aspect of IP networking, extra work is done to support inside to outside pinging. However, pinging won't ever work from the outside to the inside. VirtualBox's NAT mechanism can support port forwarding and inside to outside pings.

Bridging

Bridging is a data link layer (layer 2) mechanism that looks at devices on one network segment (e.g., A) and devices on another network segment (e.g., B), and allows devices in A or B to communicate efficiently amongst themselves, but also allows less-efficient communication between devices in A with devices in B. All of this is done transparently to the network layer (layer 3), making it transparent to routing (e.g., IP packet routing).

VirtualBox uses bridging to allow the guest operating system to act as if it had a real network device. It essentially passes through the packets from the guest to the host's network device, which pass them on to the internet. No address translation is done. If the guest is set up to get a dynamic IP address, it gets one from the same pool as the host does. If the guest uses a static IP address, it had better not conflict with the rest of the devices on the subnet, just like a real network device.

There are no restrictions on the use of a bridged network device. Consequently, if you have enough IP addresses, bridging is the most versatile way to go.

Configuring Bridging in VirtualBox

In the Details tab, click on the category Network, then:

1. Click the Adapter 1 tab

   There may be multiple network devices, but usually there is only this one.

2. Make sure Enable Network Adapter is checked.
3. In the Attached to: drop-down box, select Bridged adapter
4. In the Name: drop-down box, select the ethernet device corresponding to an real network device connected to the network.

   In a terminal window, enter:

     ifconfig | grep -E "(em|p1|inet)"
     

   For the drop-down box mentioned above, use the device starting with "em" corresponding to the IPv4 address ("inet ") you want to use. For the IAN Lab, you want to use the em1 device with an IP address starting with 10.208.244. Other network cards in the host computer may show up as pxp1, where x ranges from 2 to 5.

5. Click OK
6. Start the Windows VM, and login
7. Using Control Panel/Windows Firewall, in the Advanced tab, turn on the ability to receive pings

   Check ICMP/Settings.../Allow incoming echo request

   You normally only have to do this once, but check it always since someone else could turn it off.

With a bridged network and the guest operating system being able to accept ICMP echo requests (pings), and act as any other networked computer, even as a server.

Change Log