Virtual Machines with VirtualBox or VMware: Principles

A pilot learns in a simulator before flying a real plane, and a surgeon practises before the operating room. Security learners need the same thing: a place where mistakes cost nothing and where nobody else can be harmed. That place is a virtual laboratory. In this lesson you will understand what a virtual machine is, how to choose a hypervisor, and how to plan the resources of your lab before installing anything.

Chapters 1 and 2 gave you the theory of networks and the habit of observing them. From now on, your lab notebook gets a new section: the lab itself, with a diagram, a list of machines and their addresses. This lesson is about the foundations of that lab.

What is a virtual machine?

A virtual machine (VM) is a complete computer simulated by software, running inside a window on your real computer. It has a virtual processor, virtual memory, a virtual disk and virtual network cards. Inside it, you install an operating system exactly as you would on real hardware, and that operating system believes it is running on a physical machine.

The vocabulary is simple:

• The host is your real computer and its real operating system.
• The guest is the operating system running inside the virtual machine.
• The hypervisor is the software that creates and runs the virtual machines.

Think of a block of flats. The building is the host, the flats are the virtual machines. Residents of each flat have their own door, their own furniture and their own mess, and a flood in one flat does not automatically wreck the others. That isolation is what makes VMs ideal for experimenting with things that could be dangerous.

Why a lab is indispensable for security learning

• Safety: you can run intentionally vulnerable software and security tools without exposing your real data and real network.
• Legality: testing techniques on machines that you own is the only way to learn offensive skills without breaking the law. It is the basis of this whole track.
• Reproducibility: you can return a machine to a known state in seconds (snapshots, lesson 3), so a failed experiment is never a disaster.
• Economy: you can build a network of several machines on a single laptop, with no hardware to buy.

Type 1 and type 2 hypervisors

There are two families. A type 1 hypervisor runs directly on the hardware and is used in data centres and servers. A type 2 hypervisor is an ordinary application that you install on your normal operating system. For a home lab, you will use a type 2 hypervisor. The two most common options are:

• VirtualBox: free and open source, available for Windows, Linux and macOS, with a large community and many tutorials. It is the usual choice for beginners.
• VMware (Workstation or Fusion for desktops): a very polished product line, with free versions for personal use available under conditions that the vendor may change, so check the current licence on the vendor's site.

Other solutions exist, such as the virtualisation built into some operating systems, or tools designed for ARM-based computers. If you use a recent Mac with an Apple-designed processor, be aware that the host processor architecture matters: you generally need guest images built for the same architecture, and support differs between hypervisors. Read the official documentation of your chosen tool before downloading images. The concepts of this course are identical whichever you pick.

Is your computer ready?

Check three things before installing:

1. Hardware virtualisation: modern processors support it (called VT-x on Intel and AMD-V on AMD), but it is sometimes disabled in the firmware settings (BIOS or UEFI). If your hypervisor complains, look for this option.
2. Memory (RAM): every running VM takes a share of your RAM, and the host needs its own. A machine with 8 GB can run one or two light VMs; 16 GB or more is much more comfortable for a network of three or four machines.
3. Disk space: each VM has a virtual disk file, and snapshots add more. Plan for several tens of gigabytes per machine to be safe, and prefer an SSD for speed.

It is better to start small, with one or two machines, than to saturate your computer. You can always add more.

The key settings of a virtual machine

When you create a VM, you choose a few important settings. Here is what each means:

Setting	What it does	Beginner advice
CPU cores	Processing power allocated	1 or 2 cores per machine, never all your cores
Memory	RAM allocated	Follow the recommendation of the guest OS, then adjust
Virtual disk	The guest's storage, stored as a file on the host	Dynamically allocated disks start small and grow
Network adapter	How the VM connects to networks	The most important setting for security: see lesson 3
Shared folders, clipboard	Convenience features linking host and guest	Disable for machines that run untrusted software

The last row deserves attention. Features that connect the host and the guest (shared clipboard, shared folders, drag and drop) are convenient, and they also weaken the isolation. For machines where you run vulnerable or suspicious software, turn them off.

Installing the operating system in a VM

Most of the time you install a guest OS from an ISO file, the image of an installation disc. The hypervisor lets you "insert" it in a virtual optical drive, and the installation proceeds just as on a real computer. Some projects also publish ready-to-use pre-built VM images that you import directly, which saves time. In both cases:

• Download images from the official website of the project only. A modified image from an unknown source could contain malware, and a lab built on it is worthless.
• Verify the checksum (a hash, which we study in chapter 6) published by the project, to make sure that the file is complete and unmodified. On Linux or macOS: sha256sum file.iso or shasum -a 256 file.iso; on Windows PowerShell: Get-FileHash file.iso -Algorithm SHA256.
• Install the guest additions (VirtualBox) or VMware Tools after installation: they provide better screen resolution, performance and optional integration features.

The lab plan

Here is the target for the end of this chapter. You will adapt it to your hardware:

• Machine 1: attacker workstation, a Kali Linux VM (lesson 2).
• Machine 2: a Linux target, a small Ubuntu or Debian server VM that you will use for chapter 4, and later as the host for intentionally vulnerable web applications in the next course.
• Optional machine 3: a Windows VM for chapter 5, using an official evaluation edition from the vendor, within the terms of its licence.
• An isolated virtual network that links them (lesson 3).

For the vulnerable applications, only use the legal training environments that the track recommends: DVWA, OWASP Juice Shop, and the free labs on platforms such as TryHackMe, HackTheBox and the PortSwigger Web Security Academy. They are designed to be attacked, and they are safe to practise on.

Your turn: prepare the ground

On your computer, check how much RAM and free disk space you have, and whether hardware virtualisation is enabled (on Windows, the Task Manager's "Performance" tab shows "Virtualization: Enabled"; on Linux, lscpu mentions virtualisation support). Then write in your lab notebook a lab budget: how many machines you can run at the same time, with what RAM for each. Install VirtualBox or VMware from the official website, and create an empty VM (no OS yet) named lab-test, with 1 CPU, a modest amount of RAM and a 20 GB dynamically allocated disk. Then delete it.

See a solution

A possible budget for a laptop with 16 GB of RAM: keep at least 6 to 8 GB for the host, and give the rest to the VMs, for instance 4 GB for the Kali VM and 2 GB for a Linux server VM, which lets you run both at once. With 8 GB of RAM, run one VM at a time and close the browser tabs of the host. The goal of creating and deleting an empty VM is to become familiar with the wizard, and to see that a VM is just a configuration plus a disk file on your host. If the hypervisor refuses to start a VM, enter the firmware settings of your computer and enable virtualisation, and, on Windows, check that other virtualisation features of the system do not conflict with your hypervisor, according to its documentation.