Home lab, part 1: network and hypervisor

This is part one of a build-along series for a red team practice lab. Before any vulnerable machine goes in, the lab needs a shape that keeps offensive tooling — C2, scanners, half-working exploits — from ever touching your home network or the internet. Isolation is the foundation; get it wrong and every later part inherits the risk.

Warning

A lab exists to run things you would never run on a network you care about. Treat every segment below as hostile and build accordingly.

The single rule #

Lab traffic never reaches your home LAN or the internet unless you explicitly route it. Everything else is detail in service of that rule. If you remember nothing else from this part, remember that the default answer to "can the lab reach X" is no.

Segment layout #

Three segments, isolated by default:

Segment	Purpose	Internet
`mgmt`	Your attack box, tooling, the hypervisor UI	Via a controlled gateway only
`lab`	Vulnerable targets — AD, web apps, the range	None by default
`detect`	SIEM, log collectors, monitoring	None

The lab segment having no route out is the point. A reverse shell that calls home should hit nothing. When a technique genuinely needs egress — pulling a tool onto a target, say — you open that path deliberately and close it after.

Hypervisor choice #

Any of these gives you the segmentation primitives; the differences are ergonomic:

Proxmox VE — free, clustered, strong internal virtual-networking. My default for a permanent lab.
VMware Workstation / ESXi — polished, ubiquitous in write-ups, so tutorials map cleanly.
VirtualBox — fine for a laptop-scale lab you tear down often.

Pick the one you'll actually maintain. A lab you keep patched and snapshotted beats a theoretically better one you let rot.

Isolated virtual networks #

The mechanism differs by platform but the intent is identical: an internal-only switch with no uplink to the host's physical NIC.

text

Proxmox:  Datacenter → Network → Create → Linux Bridge
          Leave "Bridge ports" empty → no physical uplink → isolated

Attach lab VMs to that bridge and they can talk to each other and nothing else. The absence of an uplink is what makes it safe; there's no firewall rule to misconfigure because there's no path to misconfigure.

Controlled egress, when you want it #

A small firewall VM (pfSense or OPNsense) with one NIC on mgmt and one on lab lets you grant egress per-rule, log it, and revoke it — instead of choosing between fully-open and fully-closed. This is also the first thing your detect segment gets to watch, which sets up a later part nicely.

Snapshot discipline #

Snapshot every VM clean before you attack it. When an exploit corrupts a target — and it will — you roll back in seconds rather than rebuilding. Name snapshots by state (clean, domain-joined, pre-exploit) so a month from now the restore point still means something.

Next #

Part 2 builds the vulnerable Active Directory domain that lives in the lab segment: a domain controller, a couple of workstations, and a set of deliberately weak configurations to practise the classic attack paths against.