Lab: building a safe, isolated virtual security lab

Aim and what you need

The aim is to create a safe practice environment that every other cyber security lab on this site can use. Isolation matters for two reasons: deliberately vulnerable machines must not be reachable by others, and your scans and tests must never touch systems you do not own. In most countries, including under the UK Computer Misuse Act 1990, accessing or testing someone else's system without permission is a crime.

• A PC with at least 16 GB of RAM, a CPU with virtualisation turned on in the firmware, and 150 GB of free disk space.
• A hypervisor. This lab uses Oracle VirtualBox (free); VMware Workstation, Hyper-V or Proxmox VE work in the same way.
• Installers: Kali Linux (or another Linux with security tools), Ubuntu Server LTS, a Windows evaluation image from Microsoft, and optionally a deliberately vulnerable VM from a trusted training source.

Design

Steps

1. Install VirtualBox and create the VMs from their installers. While installing, give each VM temporary NAT access so it can download updates.
2. Fully update each VM, then shut it down.
3. Move every VM's network adapter to the internal network labnet. Internal networks have no DHCP by default, so either set static addresses or add a DHCP server for the network.
4. Turn off shared folders, shared clipboard and drag-and-drop for vulnerable VMs.
5. Take a "clean baseline" snapshot of every VM.

VBoxManage list vms
VBoxManage modifyvm "kali" --nic1 intnet --intnet1 "labnet"
VBoxManage modifyvm "ubuntu-srv" --nic1 intnet --intnet1 "labnet"
VBoxManage modifyvm "win-eval" --nic1 intnet --intnet1 "labnet"
VBoxManage dhcpserver add --network=labnet --server-ip=10.10.10.1 --netmask=255.255.255.0 --lower-ip=10.10.10.100 --upper-ip=10.10.10.199 --enable
VBoxManage modifyvm "ubuntu-srv" --clipboard-mode disabled --drag-and-drop disabled
VBoxManage snapshot "ubuntu-srv" take "clean-baseline" --description "patched, before any testing"

On Ubuntu Server, a static address can be set with a Netplan file such as /etc/netplan/50-lab.yaml, then applied:

network:
  version: 2
  ethernets:
    enp0s3:
      addresses: [10.10.10.20/24]

sudo netplan apply

Verify

Check each VM's adapter setting from the host, then test from inside the lab. Success means lab VMs can ping each other, but cannot reach your home router, your host PC's real address, or any internet name.

VBoxManage showvminfo "kali" --machinereadable | grep -i -E "nic1|intnet1"

ip -br address
ping -c 3 10.10.10.20
ping -c 3 192.168.1.1
ping -c 3 example.com

Replace 192.168.1.1 with your real home router address. Both of the last two pings must fail.

Troubleshooting and clean-up

• VMs cannot see each other: the internal network name is case-sensitive; labnet and LabNet are different networks.
• No addresses: the DHCP server is not enabled for the internal network, or the VM is still set to NAT.
• VM is slow: give it fewer VMs running at once, not more RAM than the host can spare.
• Need updates later: switch one VM back to NAT briefly, update, then return it to labnet. Never do this with a deliberately vulnerable VM.

After each exercise, restore the clean snapshot so the next lab starts from a known state. When you finish with the lab altogether, delete the VMs and their disks from VirtualBox. Document your lab (VM names, addresses, snapshots) as you would a real network: it makes a good portfolio piece too.

VBoxManage snapshot "ubuntu-srv" restore "clean-baseline"
VBoxManage unregistervm "old-vm" --delete