Setting Up Your Security Lab

CAP, ACID vs BASE, latency numbers, back-of-envelope estimation, single points of failure — the vocabulary every system designer thinks in.

Core Philosophy: You cannot learn to attack systems by attacking real ones — that is a crime, full stop. You also cannot learn by only reading. The answer, used by every professional, is a personal lab: deliberately vulnerable machines you fully own, sealed inside an isolated network where nothing you do can escape or cause harm. This lab is the single most important thing you build in Phase 0. Every later hands-on lab runs inside it.

Part 1: The Problem

The rest of this curriculum is full of instructions like “exploit this,” “escalate privileges,” “intercept this traffic.” You need somewhere to do that which is:

• Legal — machines you own and control, so no authorization question ever arises.
• Safe — isolated, so a mistake (or real malware in a practice target) can’t reach your real files, your home network, or the internet.
• Repeatable — restorable to a clean state, so you can attack the same machine again and again.

That place is a virtual lab. This section builds it.

Part 2: The Concept — Virtual Machines

A virtual machine (VM) is a complete computer that runs as software inside your real computer. It has its own virtual disk, memory, and network card. To the software inside it, it looks like a real, separate PC.

The program that runs VMs is a hypervisor. Common free ones: VirtualBox (free, all platforms) and VMware Workstation Player.

Why VMs are perfect for security learning:

• Isolation — what happens in the VM stays in the VM. Attack it, infect it, break it — your real machine is untouched.
• Snapshots — you can save a VM’s exact state and roll back to it instantly. Compromise a machine, learn from it, then revert it to pristine in seconds.
• Disposable — a VM ruined beyond repair is just deleted and rebuilt.

        YOUR REAL COMPUTER (the "host")
   ┌──────────────────────────────────────┐
   │  Hypervisor (VirtualBox)             │
   │   ┌──────────────┐  ┌──────────────┐ │
   │   │  VM: Kali    │  │  VM: victim  │ │
   │   │  (attacker)  │  │  (target)    │ │
   │   └──────────────┘  └──────────────┘ │
   │   isolated lab network between them  │
   └──────────────────────────────────────┘

Part 3: The Two Machines You Need

A lab is, at minimum, two VMs:

1. The attacker machine — Kali Linux.Kali Linux is a free Linux distribution built for security work. It comes with hundreds of tools pre-installed — Nmap, Burp Suite, Metasploit, and most of what this curriculum uses. Using Kali means you don’t install tools one by one. (Parrot OS is a fine alternative; either works.)

2. The victim machine — a deliberately vulnerable target. This is a VM intentionally built to be broken into, for training. Well-known free ones include Metasploitable (a deliberately vulnerable Linux server) and various beginner-friendly vulnerable VMs from training sites. You attack these.

🔑 The golden rule of the lab: You attack the victim VM. You attack machines on hosted training platforms that explicitly invite it. You attack nothing else, ever. The lab exists precisely so that “what may I attack?” always has a clear, safe answer.

Part 4: The Critical Setting — Isolated Networking

This is the part you must not get wrong. When you create the VMs, the hypervisor asks how they should connect to networks. The options matter:

Set your attacker and victim VMs to a host-only / internal network so they can see each other but nothing else. A deliberately vulnerable machine on a bridged network is a genuine hazard — it’s a broken computer exposed to your whole home. The isolated network is the wall around your lab.

   ✅ SAFE LAB                  ❌ DANGEROUS
   ┌─────────────────┐         Kali ── home network ── internet
   │ Kali ─── victim │              victim ──┘
   │  (isolated net) │         a vulnerable VM exposed
   └─────────────────┘         to everything
   nothing leaks in or out

Part 5: Snapshots — Your Undo Button

A snapshot saves the complete state of a VM at a moment in time. Later, you “restore” the snapshot and the VM returns exactly to that state — every file, every setting.

Why this transforms your learning:

• Take a snapshot of each VM when it’s freshly set up and clean.
• Attack, experiment, break things, install malware-y practice payloads.
• When you’re done — or when something goes wrong — restore the clean snapshot. The machine is pristine again, ready to attack from scratch.

Habit to build now: snapshot a VM before anything risky, and keep a permanent “clean baseline” snapshot you never overwrite. This is the same habit the On-Prem module taught — and it matters even more here, because security labs deliberately break things.

Part 6: Hosted Lab Platforms — The Other Half of Practice

Your local lab is yours forever and works offline. Alongside it, hosted hacking-practice platforms give you a constantly refreshed supply of legal targets:

• They run deliberately vulnerable machines and web apps in their cloud.
• You connect (often over a VPN, as in 0.5) and attack their targets — fully sanctioned, that’s the entire purpose of the platform.
• They offer guided beginner paths, so you’re never staring at a blank target.

This curriculum’s labs use a mix: your local VM lab for things you want to own and break repeatedly, and hosted platforms for breadth and structured challenges. Both are 100% legal because the targets exist to be attacked. Section 3.7 builds this into an ongoing practice habit.

📓 Key Terms

🧪 Hands-On Lab — Build Your Lab

This is the deliverable of section 0.5. Take your time; you’ll use this lab for months.

Task 1 — Install a hypervisor. Download and install VirtualBox (free, virtualbox.org). It runs on Windows, Mac, and Linux.

Task 2 — Create the attacker VM. Download the Kali Linux image (kali.org — it offers ready-made VirtualBox images that import in a couple of clicks). Import it. Boot it. Log in. You now have a fully equipped attacker machine.

Task 3 — Create the victim VM. Download a deliberately vulnerable VM (Metasploitable is the classic starting point). Import it into VirtualBox. Do not expose it — see Task 4.

Task 4 — Lock the network down. (The most important task.) In VirtualBox, set both VMs’ network adapters to Host-only or Internal Network, the same network for both. Verify: from Kali, you should be able to ping the victim VM; from the victim, you should not be able to reach the internet. That confirms the wall is up.

Task 5 — Snapshot both VMs while clean. With both VMs freshly set up, take a snapshot of each and label it clearly, e.g. CLEAN-BASELINE. Never overwrite this one. It’s your permanent reset point.

Task 6 — Do a first, gentle attack-surface scan. From Kali, find the victim’s IP (ip addr), then run nmap -sV <victim-ip>. You’ll see the victim’s open ports and services — its attack surface. You won’t exploit anything yet; you’re confirming the two machines can see each other and the lab works. Phase 2 and 3 take it from here.

Task 7 — Create an account on one hosted practice platform. Sign up for a beginner-friendly hacking-practice platform and start its introductory path. This gives you legal targets beyond your local lab.

⚠️ Common Mistakes

• Putting a vulnerable VM on a bridged network. This exposes a deliberately broken machine to your whole home network. Always host-only / internal for the lab.
• Never taking the clean snapshot. Without a CLEAN-BASELINE, a messed-up VM means a full rebuild. Snapshot first, snapshot often.
• Skipping the lab to “save time.” Every later section assumes this lab exists. There is no shortcut around it.
• Treating hosted platforms as a license to attack anything. They authorize their targets only. Outside their scope, normal law applies.
• Under-resourcing the host. VMs need RAM and disk. If your machine is light on memory, run one VM at a time, or use hosted platforms more heavily.

✅ Recap & What’s Next

• A virtual machine is an isolated computer-in-software; a hypervisor like VirtualBox runs them.
• Your lab is an attacker VM (Kali) plus a vulnerable victim VM, on an isolated host-only network, with a clean snapshot you can always restore.
• Hosted lab platforms add a renewable supply of legal targets; together they give you everywhere you’ll ever need to practice — safely and legally.

Next (0.6): Tools cover most of the work, but not all of it. The final foundation is light scripting — using Python to automate, customize, and understand security tasks that no off-the-shelf tool quite handles.