42 — Securing a Home Lab
Level: Intermediate · Time: ~20 min · Prerequisites: Lesson 41 — Securing a Home Network
Why this matters
A security lab is a collection of deliberately vulnerable machines sitting in your house. That is the point of it, and it is also the problem: the most exploitable systems you will ever own are the ones you built to be exploited, and they are connected to the same network as your laptop, your phone and the box holding your photographs. Left on a bridged network adapter, an intentionally vulnerable machine is a permanent, unfixed foothold on the home network, reachable by anything on it and capable of reaching everything on it. This lesson is not about making the lab harder to attack. It is about making sure the attack never leaves the room. The discipline in it — isolate, verify isolation, snapshot, clean up — is the difference between a practitioner and someone who eventually causes an incident with their own tools.
The mental model: the lab is the most dangerous thing on your network
State the goal in four lines and treat every decision below as a way of achieving one of them.
| Requirement | What it means in practice |
|---|---|
| Attack traffic stays inside the lab | an exploit, a scan or a payload runs between lab machines only |
| The lab cannot reach the home network | no route, explicit deny rules, and no shared segments |
| The internet cannot reach the lab | no port forwards, no UPnP, no exposed management interfaces |
| Nothing real is stored in it | synthetic data only, and no production credentials anywhere |
Everything else — snapshots, resource limits, credential hygiene, cleanup — exists to keep those four true after the first time something goes wrong.
[!WARNING] The single commonest lab mistake is the bridged network adapter. A virtual machine set to bridged asks your home router for an address, appears on the home network as a normal peer, is reachable by every device in the house, and can reach every device in the house. Choose that adapter on a deliberately vulnerable machine and you have published a known-exploitable host onto your own LAN — plus, with a vulnerable target that still has an internet path, an exploited machine may call out to real infrastructure.
Isolation: the hard checklist
Work through this before you run anything offensive, and treat every line as a requirement rather than a preference.
- The lab gets its own network segment or virtual switch, with no route to the home network. A virtual switch with no uplink, an internal or host-only network in the hypervisor, or a dedicated bridge with no physical port attached.
- The lab sits behind its own firewall, and the rules between the lab and the home network are explicit deny. Default deny in both directions, with each allowance written down and justified.
- No inbound forwarding from the internet to any lab host, and no UPnP anywhere near it. A public address on a vulnerable machine means strangers find it.
- The lab assigns its own addresses. Its own DHCP service on the lab segment, so no lab machine receives a lease from the home router and no home device receives anything from the lab.
- Name resolution cannot leak out of the lab. The lab uses its own resolver, and lab queries never reach the home resolver — a leak there shows up in the home query log and in the home network's view of what your devices are doing.
- No bridged adapters on anything you intend to attack, ever. See the warning above.
| Hypervisor network mode | What it actually gives you | Use it for a vulnerable target? |
|---|---|---|
| Bridged | the machine is a peer on your home network, with a home DHCP lease | never |
| NAT (outbound only, host-assisted) | the machine reaches the internet through the host and is not reachable from the home network | only when the exercise genuinely needs internet access |
| Internal network (VirtualBox), private switch (Hyper-V) | machines talk to each other and to nothing else | yes — this is where targets belong |
| Host-only (VirtualBox, VMware) | lab machines and the host talk to each other; there is no internet path | yes, when your attacking machine is on the host |
| Isolated bridge with no physical uplink (for example a bridge with no attached port on Proxmox VE; a libvirt network defined with forwarding disabled) | a realistic segment with real addressing, and no path anywhere | yes — the closest thing to a real network you can build safely |
# Verify isolation instead of assuming it. From inside a lab machine:
# 1. It must NOT reach the router's admin page or any home device
curl -m 3 http://192.168.1.1 || echo "no route to the home gateway - good"
# 2. It must NOT reach the internet where the exercise does not need it
curl -m 3 https://example.com || echo "no egress - good"
# 3. It SHOULD reach the other lab machines
ping -c 2 10.10.10.20
If the first two commands succeed when you expected them to fail, stop and fix the network before you run any tool. Isolation you have not tested is a belief, not a control.
Hypervisor hardening
The hypervisor is now one of the most privileged systems you own: it can read the memory and disks of every machine on it. Treat it like a server, not like a desktop application.
| Control | What to do | The failure if you skip it |
|---|---|---|
| Patch the host | apply operating system updates on the same schedule as any server, and keep the hypervisor software current | a host flaw is a path to every virtual machine on it, including anything with real credentials |
| Unique credentials with a second factor | one strong, unique administrator password for the hypervisor itself, never reused, with a second factor where the platform supports it (Proxmox VE supports TOTP for the web interface and SSH) | a credential shared with anything else turns one compromise into two |
| Management interface never exposed to the internet | no port forward to the hypervisor console, ever, and no UPnP entry | the console is a full-control interface and it will be found |
| Remote management restricted | management answered only on the home network, or over a virtual private network with a second factor; SSH by key rather than password | an exposed console is a total compromise of the lab and its stored images |
| Snapshots as the rollback mechanism | snapshot before each exercise, revert afterwards; understand that a snapshot is not a backup — it grows, it lives on the same disk, and it retains whatever was in the machine | you lose the ability to start clean, and a rebuilt target costs an evening |
| Resource limits | CPU limits, memory limits or ballooning bounds, and disk quotas per machine | one runaway target, fork bomb or endless scan takes the host down and everything on it |
| Disable guest integration and shared folders | switch off shared folders, shared clipboard and drag-and-drop for vulnerable machines | a compromised target reads host files through the integration layer that was meant to be convenient |
A non-standard management port is not a security control — a port scan finds the console in seconds, and the same is true of a moved SSH port. Restrict who can reach it, and add a second factor; do not rely on hiding it.
Credentials, data and secrets in a lab
| Rule | Why it exists |
|---|---|
| Lab credentials are distinct from every real account | the lab is where you practise breaking authentication, so a lab password that also opens a real account is a liability |
| Keys rather than passwords for administrative access | a passphrase-protected SSH key is harder to reuse accidentally and is not typed into a vulnerable target |
| A separate password manager vault for lab work | if a vault is ever exposed through a lab machine, real credentials are not in it |
| A credential used in a vulnerable target is never used anywhere real | when you practise credential dumping, that password, key or token is effectively public from the moment the exercise starts |
| No real personal, client or customer data — use synthetic data | a virtual machine is a file: it gets copied, exported, restored and shared. Real data in a lab is real data in every backup of that lab |
| Lab API keys and tokens separate from real ones, with separate scopes | an application key created for a lab exercise becomes a real API key the moment it is reused, and the exercise is exactly where it gets leaked |
| Rotate or revoke lab secrets when the exercise ends | keys created for an exercise outlive the exercise unless someone removes them |
The snapshot point deserves repeating. A snapshot or exported image contains whichever credentials existed at the moment it was taken — a password typed into a vulnerable application, a key sitting in a home directory, a captured hash in a wordlist. Anyone who obtains that image, including you in six months, has those credentials. Snapshot deliberately, and delete snapshots deliberately.
Target hygiene and decommissioning
Before and during
- Snapshot before use. Start from a known state so the exercise costs minutes rather than an evening to undo.
- Cut the network path to the internet where the exercise does not require it. An exploited machine tries to phone home: a real sample calls its real command-and-control server, a dropped miner mines on your connection, and a payload that beacons home puts your address into someone else's logs. If the exercise needs internet access, allow it deliberately and watch what leaves.
- Treat the target as compromised from the moment the exercise starts. Do not reuse it as something trusted afterwards, do not copy files out of it to a clean machine without thinking about what is in them, and do not leave it running when you finish for the day.
- Match the isolation to the sample. If you are handling a real malware sample rather than a synthetic vulnerable machine, it gets its own virtual machine, no network at all, no shared folders and no clipboard — and it never shares a host with the machines you use for real work.
Decommissioning, which nobody documents
This is the part that separates a lab from permanent unmanaged infrastructure.
- Revert or delete the machines the exercise touched. Reverted, not "cleaned up by hand".
- Remove any forwarding rules you added — check the router's port-forwarding table and its UPnP list, because both are easy to forget.
- Delete the snapshots and images that contain credentials. A snapshot holding a captured password or key is a password store with no owner.
- Remove the lab's supporting infrastructure: virtual networks, DHCP scopes, DNS entries, firewall rules and any VPN peer you created for the exercise.
- Collect the evidence and notes you actually need — screenshots, log excerpts, the command that worked — then delete the rest.
- Update the inventory, so the lab no longer appears to hold hosts that no longer exist and nobody has to investigate them later.
- Confirm from the home network that nothing answers. Run one scan from a normal home machine against the lab segment and verify that nothing replies.
Pre-flight and post-exercise checklists
Paste these into your lab notes. The first one takes two minutes and saves an incident; the second takes five and stops the lab becoming permanent.
Pre-flight — before any offensive exercise
- Isolation verified, not assumed: from a lab machine, the home network and (where not required) the internet are unreachable.
- Snapshots taken on every machine about to be touched.
- No inbound forwarding from the internet to any lab host, and UPnP confirmed off.
- No real data, credentials or client material present in the target.
- Logging on: host logging, the lab's own logs, and a packet capture if the exercise will need one for its write-up.
- Resource limits set, so a runaway target cannot take the host down.
- Authorisation confirmed: you own the machines, or you hold written permission to test them. Attacking systems you do not own is an offence in most jurisdictions — describing the obligation is not legal advice, so check your own position before you scan anything.
- Scope and time noted: what you are testing, for how long, and what success would look like.
Post-exercise cleanup
- Machines reverted to their snapshot, or deleted.
- Forwarding rules and UPnP entries removed from the router.
- Snapshots and images containing credentials deleted.
- Lab networks, DHCP scopes, DNS entries and VPN peers removed.
- Evidence kept, working files deleted.
- Inventory updated.
- One scan from the home network confirming nothing in the lab answers.
[!IMPORTANT] The professional framing worth internalising: your lab is a controlled environment, and the control is the whole value of it. The people who cause incidents with their own tools are not the ones who lacked skill — they are the ones who skipped the isolation check and the cleanup, once. Do the boring two minutes every time.
Attack it / Defend it
| The attack | How it works | The control that stops it |
|---|---|---|
| Vulnerable target escapes onto the home network | a bridged adapter gives the machine a home DHCP lease and makes it a peer of your laptop | internal or isolated virtual network only; never bridge a machine you intend to attack |
| An exploited target phones home | the payload contacts its real command-and-control server or mines on your connection | no internet path unless the exercise needs it; outbound rules explicit deny |
| An internet scan finds the lab | a forwarded port or a UPnP entry exposes a lab host publicly | no inbound forwarding to lab hosts, UPnP off, and review the forwarding table |
| The lab is used to attack a real system | an automated exploit or a malicious sample pivots out of the lab | explicit deny between lab and home networks, and sample analysis with no network at all |
| Credential reuse from lab to real life | a password practised in a vulnerable application also opens a real account | separate vault, distinct credentials, keys rather than passwords |
| A lab image leaks your own credentials | a snapshot or exported appliance contains a password, key or captured hash | no real data in the lab, deliberate snapshots, and deliberate deletion |
| Hypervisor management console exposed | the console is reachable from the internet and taken over | management local-only, or over a VPN with a second factor |
| A runaway machine starves the host | one target consumes all memory, CPU or disk | resource limits per machine, and capacity monitoring on the host |
| A vulnerable machine left running after the exercise | an intentionally exploitable host stays on the network permanently | decommission: revert or delete, remove forwards, verify nothing answers |
| Lab queries leaking into the home resolver | the lab's name resolution is forwarded to the household resolver | the lab runs its own resolver and never forwards to the home one |
Key takeaways
- A lab is a collection of deliberately vulnerable machines, so the lab itself is the most dangerous thing on your network. The goal is not a harder lab; it is a lab nothing can escape from.
- Bridged is the mistake that causes incidents. A bridged adapter publishes an intentionally exploitable machine onto the home network in one dropdown.
- Verify isolation with a command, not with confidence. If the lab can reach the gateway or the internet and the exercise does not need it, fix the network before touching a tool.
- No real data and no real credentials belong in a lab, because a virtual machine is a copyable file and a snapshot is a credential store if you were careless.
- Decommissioning is part of the exercise. Revert the machines, remove the rules, delete the snapshots with secrets in them, and confirm that nothing answers.
Check yourself
- Your attacking machine is on a host-only network and the target is internal-only. Which of the four requirements in the mental model are satisfied, and which one still needs a check?
- Why is a non-standard management port not a security control, and what would you do instead?
- An exercise needs a vulnerable target with internet access to download packages. What do you allow, and what do you watch?
- A snapshot you took three months ago contains a password you now use for a real service. What is the finding, and what do you do?
- Name four things a post-exercise cleanup removes that are not virtual machines.