// networking basics — module 01

Module 1 — Build Your Lab (Virtualization & Safe Practice)

Soren Brumbach · · 8 min read

Thesis: You cannot learn this safely or legally on the open internet or on machines you don't control. You need an isolated sandbox where breaking things is free and nothing leaks out. Building that sandbox is itself the first hands-on skill of the course — and the snapshot habit you learn here will save you more hours than any other single trick.

Prerequisite: Module 0 — Orientation: The Shared Language of Security — especially §0.7. The lab is the place the ethics rule sends you.

1.1 Why a lab, specifically

Module 0 gave you the rule: only touch what you own or are authorized to touch. A lab is how you own an entire miniature network to break at will. It buys you three things:

  1. Isolation — nothing you do escapes. You can run genuinely hostile software and fire real attacks, because the whole thing is walled off from your real network and the internet.
  2. Legality — you own every machine in it, so §0.7 is satisfied by construction. No permission slip needed; you are the owner.
  3. Repeatability — with snapshots (below), you can reset any machine to a known-good state in seconds. You can detonate malware, watch what it does, and roll back as if it never happened.

Every hands-on exercise from here to the capstone assumes this lab exists. Build it before continuing.

1.2 Virtual machines and the hypervisor

A virtual machine (VM) is a whole computer — CPU, RAM, disk, network card — emulated in software, running as a guest inside your real ("host") computer. To the operating system installed inside it, a VM looks exactly like real hardware. It boots, installs an OS, and runs programs, all inside a window on your desktop.

The software that creates and runs VMs is a hypervisor. There are two kinds, and the distinction matters:

  • Type 1 (bare-metal) — the hypervisor runs directly on the hardware, with no host OS beneath it. Examples: VMware ESXi, Proxmox, and Linux's KVM. This is what data centers use; it's fast and it's what "the cloud" runs on.
  • Type 2 (hosted) — the hypervisor runs as an application on top of your normal OS. Examples: VirtualBox and VMware Workstation/Player. You double-click an app, and it runs VMs in windows. This is where you'll start, because it installs on the laptop you already have.
   TYPE 2 (hosted)                 TYPE 1 (bare-metal)
 ┌───────────────┐               ┌───────────────┐
 │  Guest VMs    │               │  Guest VMs    │
 ├───────────────┤               ├───────────────┤
 │  Hypervisor   │  (an app)     │  Hypervisor   │  (the OS itself)
 ├───────────────┤               ├───────────────┤
 │  Host OS      │               │   Hardware    │
 ├───────────────┤               └───────────────┘
 │   Hardware    │
 └───────────────┘

On NixOS or any Linux host you already run, VirtualBox or virt-manager (a GUI over KVM/QEMU) are both fine choices. Pick one and stick with it for the course.

1.3 The essentials of a VM

When you create a VM you'll allocate:

  • CPU cores — how many of the host's cores the guest may use. One or two is plenty for a lab machine.
  • RAM — memory given to the guest. 2–4 GB for a Linux box, more for Windows. Never allocate so much that your host starves.
  • Disk — a virtual hard drive, stored as one big file on your host. Usually "dynamically allocated" so it only grows as the guest fills it.

Then you install a guest OS from an ISO image (the same installer file you'd burn to a USB stick for real hardware). After install, most hypervisors offer guest additions / guest tools — a small package installed inside the guest that improves integration (better screen resolution, shared clipboard, smoother mouse). Install them; they make the VM pleasant to use.

1.4 Snapshots — the single most valuable habit

A snapshot is a saved copy of a VM's entire state — disk and memory — at a moment in time. Take one, then do something risky, and you can roll back to exactly that moment in seconds, as if the risky thing never happened.

This changes how you learn. Instead of being afraid to break things, you snapshot first and break things deliberately, because recovery is free. The workflow becomes reflexive:

  snapshot  →  try something dangerous  →  observe  →  roll back  →  repeat

Get in the habit now: snapshot a clean install of every lab machine the moment it's set up and updated, and name it something like clean-baseline. You'll return to that baseline constantly.

1.5 Virtual networking modes — how you keep the lab from leaking

This is the most important section in the module for safety, and the one beginners most often get wrong. Your hypervisor can connect a VM's virtual network card in several modes. Understand each precisely, because choosing the wrong one is how a lab "escapes."

  • NAT — the VM shares the host's internet connection through a private translated address. The VM can reach the internet; the internet (and your local network) generally cannot reach the VM. Isolated inbound, connected outbound. Good for a machine that needs updates but shouldn't be reachable.
  • Host-only — the VM can talk only to the host and to other VMs on the same host-only network. No internet at all. This is a private bubble.
  • Internal — the VMs can talk only to each other. Not even the host joins in. The most isolated mode.
  • Bridged — the VM appears as a real, first-class device on your physical network, with its own address on your LAN, as if you'd plugged another laptop into the router. Use with caution — a bridged attack VM is loose on your real network.
  NAT:        VM ─→ host ─→ internet         (out only)
  Host-only:  VM ─ host ─ VM                  (no internet)
  Internal:   VM ─ VM                         (no host, no internet)
  Bridged:    VM ─ your real LAN ─ everything (fully exposed — careful)

The rule for attack/defense practice: keep your targets and your attacker on a host-only or internal network so nothing you do can escape to the real world. Give a machine NAT only temporarily when it genuinely needs to download updates, then switch it back. Reserve bridged for when you specifically understand and want it.

1.6 A starter lab

The minimum useful lab is three machines on one isolated (host-only/internal) network:

  1. An attacker box — a security-focused Linux distribution that comes pre-loaded with tooling (the well-known ones are Kali Linux and Parrot OS). This is where you'll run scans, captures, and tools from later modules.
  2. A Linux target — an ordinary Linux server VM to attack and defend.
  3. A Windows target — because most real environments are Windows-heavy, and Module 8 makes you learn the Windows security model. (Microsoft publishes free time-limited evaluation Windows VMs for exactly this.)

Put all three on the same isolated virtual network so they can reach each other but nothing else. Snapshot each one clean.

1.7 Deliberately vulnerable targets

You don't attack random software to learn — you attack software built to be attacked, so the vulnerabilities are known, safe, and instructive. These come in two flavors:

  • Vulnerable VMs — whole machines seeded with weaknesses, meant to be compromised end to end (Metasploitable is the classic; "boot-to-root" images abound).
  • Vulnerable web apps — deliberately broken web applications you run on a target and practice web attacks against (DVWA — "Damn Vulnerable Web Application" — and OWASP Juice Shop are the standards; they matter in Module 6).

Run these inside your isolated lab only. Their whole design is to be insecure — you never want one reachable from the internet.

1.8 → Red/Blue

Same lab, both tracks. Red teams build lab replicas of a target environment to develop and test attacks safely before running them for real on an authorized engagement. Blue teams build labs to practice detection and incident response, and to detonate suspicious files in isolation and watch what they do. The snapshot-and-rollback loop is how a defender safely studies malware and how an attacker safely iterates on an exploit. One lab, two uses, identical construction.

Lab 1

This is the foundational build. Take your time; you'll live here for the rest of the course.

  1. Install a Type 2 hypervisor on your host (VirtualBox or virt-manager/KVM). Confirm it launches.

  2. Stand up one Linux VM. Download a Linux ISO, create a VM (2 GB RAM, ~20 GB dynamic disk), install the OS, and log in. Install guest additions.

  3. Prove snapshots work. Take a snapshot named clean-baseline. Now deliberately break something — for example, as root, rename a config file the system needs, or delete a package. Reboot and confirm it's broken. Then roll back to clean-baseline and confirm the machine is healthy again. You've just made breaking things free.

  4. Prove isolation works. Set the VM's network to host-only. From inside the VM, try to reach the internet (ping 8.8.8.8 or open a browser) — it should fail. Then confirm the VM can reach your host (ping the host's host-only address). You've just built a bubble nothing escapes.

  5. (Stretch) Add a second machine and a target. Create the attacker box and at least one deliberately-vulnerable target on the same host-only/internal network. Confirm the two VMs can ping each other but neither can reach the internet. Snapshot both clean. This is the lab every later module assumes.

✅ Mastery Check — do not proceed until true

Answer out loud, without notes:

  1. What three things does a lab give you, and why does each matter for security practice specifically?
  2. What is the difference between a Type 1 and a Type 2 hypervisor? Which are you using and why?
  3. What exactly does a snapshot capture, and what is the snapshot-and-rollback workflow?
  4. Describe NAT, host-only, internal, and bridged networking. Which do you use for attack/defense practice, and which is dangerous if used carelessly?
  5. Why do you practice on deliberately vulnerable targets instead of ordinary software?

And perform cold:

  • Create a VM, snapshot it, break it, and roll it back.
  • Set a VM to host-only and prove it cannot reach the internet but can reach the host.

When your lab exists and all of that is effortless: Module 2 — Networking I: The Models, Addressing, and the Stack