Snapshots & lab safety

You've got a Kali VM. Before you point it at anything, spend ten minutes on the two habits that separate a professional's lab from a beginner's mess: snapshots and network isolation.

Why safety matters — even in a lab

• You'll download and run tools whose behaviour you don't fully understand yet.
• Some deliberately-vulnerable targets you'll practise on (Metasploitable, DVWA) are actually insecure — you don't want them exposed to your real network.
• Malware analysis (Path 16) genuinely runs live samples.
• A misconfigured tool run against the wrong target is a career-ending mistake.

Snapshots and network isolation cost minutes. Not using them can cost days.

Snapshots — undo, forever

A snapshot is a saved photo of the VM's state — RAM, disk, everything. You can restore it in seconds to the exact moment you took it. Think Git commits, but for whole machines.

When to take snapshots

• fresh-install — right after import, before anything else. Done last lesson.
• base-configured — after updates and any personal config (hostname, packages, dotfiles).
• Before each engagement or big experiment — a snapshot named pre-<what-you're-about-to-try>.
• Before installing a big new tool you're unsure about.

How to take one

In VirtualBox Manager: select the VM → Snapshots panel (top right) → Take → give it a clear name and description.

To restore: select a snapshot → Restore. You'll lose changes since that snapshot — that's exactly the point.

Use date-purpose style names, e.g. 2026-01-15_before-msf-lab. Future-you will thank present-you when there are 20 snapshots to sort through.

Snapshots eat disk

Each snapshot stores the differences from the parent. Ten snapshots on a VM you've been changing heavily can easily use 20–30 GB. Delete old ones (Delete in the Snapshots panel) to reclaim space. Deleting merges changes into the parent, so you don't lose newer state.

Network modes — where does your VM talk to?

VirtualBox offers several network modes. The two that matter most:

The rules that keep you safe

1. General practise / internet needed → NAT. Safe default. Your VM gets internet but is isolated from your home LAN.
2. Attacking a target VM → Host-only or Internal network. Both VMs on the same isolated segment; no internet, no LAN. Perfect for Metasploitable-style targets.
3. Never Bridged unless you have a specific reason. Bridged puts your VM on your real home network — your family's devices are now reachable to Kali (and its tools). Bad idea by default.

[Safe lab topology]

You can add two adapters to Kali: adapter 1 as Host-only (for talking to targets), adapter 2 as NAT (for updates and downloads from the internet). Best of both worlds.

Configure a host-only network

1. VirtualBox Manager → File → Tools → Network Manager.
2. Host-only Networks tab → Create. Note the network name (e.g., vboxnet0) and the IP range it gives out (usually 192.168.56.0/24).
3. For each VM: Settings → Network → Adapter 1 → Attached to: Host-only Adapter → pick the one you just made.

Now those VMs form a private ethernet segment. Kali and your target VM can scan and attack each other; the outside world can't see either.

Managing snapshots well

A few practical habits that save real frustration later: name snapshots descriptively (before-privesc-attempt, not snapshot 3) so you can actually find the right restore point weeks later; snapshots consume real disk space, since each one stores the differences from the previous state — an old VM with dozens of forgotten snapshots can quietly consume tens of gigabytes; and snapshot chains have a direction — restoring an old snapshot discards everything that happened after it, so always double-check which snapshot you're restoring before confirming, since there's no "undo the restore" once other snapshots depending on that history are gone.

Golden rules of a safe home lab

1. Vulnerable VMs never go on Bridged mode. They shouldn't be reachable from anywhere but Kali.
2. Snapshot before every experiment.
3. Only run malware in a fully-isolated VM with Internal network mode — no internet, no host access.
4. Don't share folders between host and a testing VM unless you must.
5. Reset target VMs regularly — they get progressively "dirty" as you attack them.

Metasploitable, DVWA, and the like are real machines with real, exploitable flaws. If they touch the internet, they will be attacked by random scanners within minutes and become someone else's foothold. Always keep them on Host-only or Internal.

🧪 Lab — Set up a two-adapter Kali

1. Shut down Kali if running.
2. In VirtualBox Manager → Kali → Settings → Network.
3. Adapter 1: Host-only Adapter → your vboxnet0.
4. Adapter 2: enable it → NAT.
5. Start Kali. In a terminal, run ip a — you'll see two interfaces, one with a 192.168.56.x address (the host-only network), one with a 10.0.x.x address (the NAT internet path).
6. Take a snapshot named base-configured.

You're now set up like a professional. Every future lesson in this course assumes you can get here.

Which VirtualBox network mode puts your VM on your real home LAN alongside your family's devices — and why is that usually a bad idea for lab work?

Key terms

• Snapshot — a restorable saved state of a VM.
• NAT / Host-only / Bridged / Internal — VirtualBox network modes.
• Two-adapter setup — Host-only for targets + NAT for internet.
• Metasploitable / DVWA — deliberately vulnerable practice targets.

Recap

• Snapshots are your undo button — take them liberally.
• Use Host-only or Internal networks for vulnerable VMs; never Bridged.
• Give Kali two adapters: Host-only (targets) + NAT (internet).
• Snapshot before every risky experiment; restore in seconds if things break.

References

• Metasploitable 2 — a deliberately-vulnerable Linux VM to practise on.
• VulnHub — dozens more vulnerable VMs.
• VirtualBox Networking docs — the full explanation.
• DVWA — Damn Vulnerable Web App, great for Path 11.

Next up → Meet the terminal