|
|
|||||||||
|
||||||||||
|
Last updated: 6 Nov 2012 Using VMs in the IAN LabBackgroundIn 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:
Host LoginA 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 OperationsStarting the Windows VMAfter 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 VMOnce 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 VMThe 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 VMSometimes 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 VirtualBoxVirtualBox can be started:
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 RAMIn the Details tab, click on the category System, then:
Configuring Disk StorageIn 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:
Configuring CDs and DVDsIn the Details tab, click on the category Storage, then:
Configuring NetworkingNetworking 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. NATYou 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. BridgingBridging 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 VirtualBoxIn the Details tab, click on the category Network, then:
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
Hours | Support Information | News | Policies | Emergencies |