Security + AI Home Lab

4 HP EliteDesk mini PCs, a NAS and a VLAN switch in a 10-inch, 12U rack. I use it to attack and defend segmented networks, with local AI models on both sides.

Fig 1The rack, taken apart
The rack, taken apartExploded isometric view of a 10-inch rack. From the top: OPNsense firewall, VLAN switch with keystone panel, Proxmox node, blue node, red node, NAS with a 3D-printed cover.654321
  1. 1 Firewall
  2. 2 Switch
  3. 3 Proxmox
  4. 4 Blue
  5. 5 Red
  6. 6 NAS

~/nodes

  1. 01

    Firewall · OPNsense on bare metal

    Every packet between segments crosses this box. One port takes the ISP modem in bridge mode. The other carries all VLANs to the switch. Suricata inspects the traffic as an IDS and IPS. The firewall runs on bare metal, so a hypervisor fault cannot take the network down.

  2. 02

    Switch · VLAN switch

    It puts each port on one segment. It routes nothing. Short patch cables run through a keystone panel to the 3 nodes below.

  3. 03

    Proxmox · Hypervisor for the targets

    It hosts the target VMs in lab-target. It takes a snapshot before each test run and rolls back after it. Every run starts from the same state. Gemma 3 4B runs here in Ollama for dashboards and maintenance. Data lives on the NAS.

  4. 04

    Blue · Defence, on bare metal

    Wazuh collects logs from the targets. Suricata alerts from the firewall land here too. Qwen3-8B reads each alert, writes a short summary and maps it to a MITRE ATT&CK technique. The model has read-only access. It cannot run commands or change rules.

  5. 05

    Red · Attack, on bare metal

    The red team is me plus Qwen3-1.7B-abliterated from huihui-ai. An abliterated model has its refusals removed. It writes the prompt injections and poisoned log lines that a standard model refuses. Red reaches lab-target only. Its internet rule stays off unless a run needs it.

  6. 06

    NAS · Storage

    SSDs and HDDs behind a 3D-printed cover. It answers the Proxmox node and trusted devices. No lab segment reaches it.

Only one node runs Proxmox. Nodes in a Proxmox cluster share root trust, so root on red would mean root on blue and on every target. Red and blue run on separate bare metal, with only the firewall between them.

~/network

Fig 2The network
The networkThe internet reaches the ISP modem in bridge mode, then the OPNsense firewall, then the VLAN switch. The switch feeds 4 groups: home (trusted, guest and iot through the Omada access point), services (services with Pi-hole, dmz, storage, mgmt), lab (lab-attack, lab-target, lab-defense and a planned inference segment) and vision (cameras and ai). Arrows show 2 allowed paths, lab-attack to lab-target and lab-target to lab-defense, and a planned path from cameras to ai.internetISP modem (bridge)OPNsense + SuricataVLAN switchhometrustedguestiotOmada APservicesservicesdmzstoragemgmtlablab-attacklab-targetlab-defenseinference - plannedvisioncamerasairunningplanned

Every segment is a VLAN. Traffic between segments is denied by default. Each rule opens one path, and only OPNsense routes.

The Omada access point tags Wi-Fi traffic with its VLAN. It does not route.

Pi-hole is the only DNS server. The firewall redirects every port 53 query to it and blocks DNS over TLS on port 853.

trusted
Laptops and phones. Internet, NAS shares and iot devices. Mgmt from one admin device only.
guest
Visitor Wi-Fi. Internet only. Clients cannot see each other.
iot
Smart-home devices. Internet only. Nothing here can start a connection inward.
services
Pi-hole on a Raspberry Pi. Upstream DNS only.
dmz
A Raspberry Pi that hosts a website. Internet and Pi-hole. Nothing inside accepts a connection from here.
storage
NAS. Answers Proxmox and trusted. Starts nothing.
mgmt
Admin interfaces for Proxmox, OPNsense, the switch and the Omada controller. Updates only. Reached from one admin device.
lab-attack
Red. lab-target only. Internet off by default.
lab-target
Target VMs on Proxmox. Ships logs to lab-defense. Nothing else.
lab-defense
Blue. lab-target, for response actions. Red cannot reach it.
inference
Model server (planned). Planned: answers lab-attack and lab-defense on its API port, and starts nothing.
cameras
Wired cameras. Nothing. No internet.
ai
NVIDIA Jetson Orin Nano. Planned: pulls the camera streams. No inbound from iot or guest.

~/testing

  1. 01

    Snapshot the target VMs on Proxmox.

  2. 02

    Pick the MITRE ATT&CK techniques for the run.

  3. 03

    Attack from red: by hand, and with the abliterated model writing prompt injections and poisoned log lines aimed at blue.

  4. 04

    Wazuh and Suricata raise alerts on blue.

  5. 05

    Qwen3-8B summarises each alert and names the technique it sees. I check its answer.

  6. 06

    Compare what red ran with what blue caught. Roll the targets back.

Each run ends with a list of techniques caught and missed. The poisoned log lines test one more thing: whether a person can talk an AI triage assistant into hiding an attack.

~/next steps

  1. 01

    A Mac mini model server

    The HP minis run small models on CPU only. A Mac mini with MLX gets its own inference segment. Only lab-attack and lab-defense reach its API port. It starts no connections, and every model download is hash-checked.

  2. 02

    Camera detections on the Orin

    YOLO, compiled with TensorRT, checks every frame. Gemma 3 4B describes only the hits, and alerts go to trusted. The cameras stay off the internet.

  3. 03

    Device attestation

    The TPM in each mini proves the device and its boot state. A USB key proves the person. Access needs both.

  4. 04

    Atomic Red Team

    Repeatable ATT&CK tests, so a detection that breaks shows up on the next run.