My InfoSec HomeLab

Purpose

A small, fully isolated lab for practising both sides of security: attacking deliberately vulnerable targets (Metasploitable 2, OWASP Juice Shop, DVWA, later Active Directory) and detecting those attacks with a SIEM (Wazuh) and Windows endpoint logging (Sysmon). It is built so that nothing vulnerable can ever reach the home network or the internet.

Architecture

Prerequisites

• Hardware: mini PC with AMD Ryzen 5 7640HS (6 cores / 12 threads), 32 GB DDR5, 512 GB NVMe, two 2.5 GbE ports. Hypervisor: Proxmox VE 9 on ext4.

• ISOs (all official, free):

  • Proxmox VE 9 — proxmox.com

  • OPNsense 26.7 (DVD image) — opnsense.org

  • Ubuntu Server 24.04.5 — releases.ubuntu.com

  • Metasploitable 2 — sourceforge.net/projects/metasploitable

  • Windows 11 Enterprise Evaluation (90 days) and Windows Server 2022 Evaluation (180 days) — Microsoft Evaluation Center

  • VirtIO drivers for Windows — fedorapeople.org (virtio-win.iso)

How the network works (in plain words)

The whole design rests on two virtual switches (Linux bridges) inside the Proxmox host:

Because vmbr1 has no cable to the outside, a lab VM physically cannot talk to the home network on its own. The only way out is through the OPNsense VM, which has one leg in each bridge, like a router with two cables. That makes OPNsense the single checkpoint for everything leaving the lab, and its firewall rules decide what passes.

Three traffic paths, step by step:

1. Kali attacks a lab target (e.g. nmap 10.10.10.55)

   • Kali has a static route: "for 10.10.10.0/24, go via 192.168.178.11" (the Proxmox host).

   • Proxmox forwards the packet from vmbr0 into vmbr1 (IP forwarding on).

   • On the way in, Proxmox rewrites the source address to its own lab address 10.10.10.2 (an iptables MASQUERADE rule). Without this, the target would send its reply to its default gateway (OPNsense) instead of back to Proxmox, and the connection would break.

   • Side effect worth knowing for detection work: in the lab's logs (Wazuh, Sysmon, web logs), attacks from Kali show up as coming from 10.10.10.2, not from Kali's home IP.

   • This path doesn't touch OPNsense's firewall at all, so the isolation rules never get in Kali's way.

2. A lab VM tries to reach the internet (e.g. malware on Metasploitable "phoning home")

   • The VM sends it to its gateway 10.10.10.1 (OPNsense) → OPNsense checks its LAN rules → rule 4 blocks and logs it. Nothing leaves.

3. A lab VM needs updates (Windows Update, apt, Docker images)

   • Only while patching, rule 3 is switched on for the three update hosts (.20, .30, .40). OPNsense then NATs their traffic out through the FritzBox. Afterwards rule 3 goes off again.

Proxmox System → Network: vmbr0 with port nic0, vmbr1 with no port.

Network isolation

OPNsense Firewall → Rules → LAN, evaluated top to bottom, first match wins:

The two factory rules "Default allow LAN to any" (IPv4/IPv6) are disabled, not deleted. Their absence is what makes rule 4 effective.

Admin access to OPNsense goes through an SSH tunnel via the Proxmox host (ssh -L 4430:10.10.10.1:443 root@<proxmox>), so the firewall GUI is never exposed on the home network.

Verified on 15–16 Oct 2026:

Build steps

Detailed click-by-click guides live in the vault cheat sheets ([[proxmox-install]], [[opnsense-install]], [[metasploitable-install]], [[wazuh-install]], [[windows-install]], [[docker-host-install]]). The short version:

Step 1 — Proxmox host

BIOS: confirm 32 GB is detected, enable SVM (AMD virtualisation). Install Proxmox VE 9 on ext4 with a static address, switch to the no-subscription repository, fully upgrade. Then add the lab bridge to /etc/network/interfaces:

auto vmbr1
iface vmbr1 inet static
        address 10.10.10.2/24           # Proxmox's own address inside the lab
        bridge-ports none               # no physical port: the lab is cut off by design
        bridge-stp off
        bridge-fd 0
        # Let the host route between home network and lab (for Kali)
        post-up echo 1 > /proc/sys/net/ipv4/ip_forward
        # Rewrite Kali's packets to 10.10.10.2 so lab replies come back the same way
        post-up iptables -t nat -A POSTROUTING -s 192.168.178.0/24 -o vmbr1 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s 192.168.178.0/24 -o vmbr1 -j MASQUERADE

ifreload -a                              # apply without reboot
ip -br a                                 # vmbr1 shows 10.10.10.2/24

On Kali, a persistent route to the lab:

sudo ip route replace 10.10.10.0/24 via 192.168.178.11   # now
# plus /etc/network/if-up.d/lab-route so it survives reboots

Step 2 — OPNsense firewall (VM 100)

Two VirtIO NICs: net0 on vmbr0 (WAN, DHCP from the router, address pinned in the router), net1 on vmbr1 (LAN 10.10.10.1/24). Ballooning off (FreeBSD). Install to UFS, assign interfaces on the console, run the web wizard with "Block RFC1918 Private Networks" unticked on WAN (the WAN is a private network here). DHCP pool 10.10.10.100–200, so fixed server addresses stay outside it. Then the four rules above, an encrypted config backup (kept private), and a snapshot.

Step 3 — Metasploitable 2 (VM 101)

Not installed but imported: the VMware disk is downloaded on the Proxmox host and converted.

qm disk import 101 /root/Metasploitable2-Linux/Metasploitable.vmdk local-lvm   # VMware disk → Proxmox disk

Attached as IDE with an Intel E1000 NIC (the 2008 kernel has no VirtIO driver), on vmbr1 only, fixed IP 10.10.10.55, never started at boot.

Step 4 — Wazuh SIEM (VM 102)

Ubuntu Server 24.04 (no LVM, so the full 60 GB is usable), Docker from Ubuntu's own repositories (not the snap), then the official single-node deployment, pinned:

sudo sysctl -w vm.max_map_count=262144                         # the indexer (OpenSearch) refuses to start without it
git clone https://github.com/wazuh/wazuh-docker.git -b v4.14.8  # pinned version, reproducible
cd wazuh-docker/single-node
sudo docker compose -f generate-indexer-certs.yml run --rm generator   # TLS certs between the components
sudo docker compose up -d                                              # indexer + manager + dashboard

Step 5 — Windows 11 endpoint (VM 104)

UEFI (OVMF) + EFI disk + virtual TPM 2.0 (Windows 11 requires both), VirtIO SCSI disk with the driver loaded during setup (vioscsi\w11\amd64), local account labadmin, then the VirtIO guest tools for network + guest agent. Static IP via PowerShell, renamed to WIN11 before any agent or domain join (Wazuh and AD key on the hostname), patched, updates paused, RDP enabled. Microsoft Defender stays on.

Step 6 — Vulnerable web apps (VM 103)

Same Ubuntu routine, then:

R="--restart unless-stopped"                                    # come back after reboots
sudo docker run -d $R --name juice-shop -p 3000:3000 bkimminich/juice-shop
sudo docker run -d $R --name dvwa -p 8080:80 vulnerables/web-dvwa

Step 7 — Lock down and baseline

Switch rule 3 off, re-test isolation, new encrypted OPNsense backup, and a clean-baseline snapshot of every VM (disk only, no RAM; Windows shut down first). After each attack session: qm rollback <id> clean-baseline.

Deliberate misconfigurations (vulnerable labs only)

Validation checklist

• [x] All hosts reachable inside the lab from Kali; the lab cannot reach the home network or the internet

• [x] Isolation tested (pings + curl above), blocked attempts visible in the OPNsense live log

• [ ] Logs from every agent visible in the SIEM (Day 2: Sysmon + Wazuh agent on WIN11)

• [x] Snapshot clean-baseline taken for VMs 100–104

Troubleshooting log

Resource and cost notes

• RAM at full load: OPNsense 4 + Wazuh 6 + Windows 4 + Docker 4 + Metasploitable 1 = 19 GB of 25 GiB usable. The DC (+4 GB, Day 18) needs the BIOS fix. Day to day, only OPNsense and Wazuh run permanently; the rest is started per task.

• Disk: about 200 GB allocated of 512 GB (260 GB with the DC) (thin-provisioned on local-lvm, so real use is lower). A second NVMe only once local-lvm passes ~80 %.

• Licences: everything free. Windows 11 Enterprise Evaluation installed 16 Oct 2026 → expires around 14 Jan 2027 (slmgr /rearm or rebuild). Windows Server 2022 Evaluation: 180 days from its install on Day 18.

• Known limitation / next hardening step: the MASQUERADE rule lets any device on the home network that knows the route reach the lab, not only Kali. Restricting the source to Kali's address (with a DHCP reservation for Kali) would close that.

• Hardware cost: mini PC ~€600 (one-off). Everything else is open source or evaluation licences.