#CyberDen

A segmented, enterprise-style cyber range that one engineer can build, attack, observe, break and rebuild.

CyberDen started in August 2025 as one mini PC running pfSense and a victim VM. Today it's three Proxmox nodes behind a pfSense edge and a VyOS core router, carved into trust zones the way a real enterprise would be: management, SOC, directory services, DevSecOps, vulnerable applications, AI, storage, and attacker infrastructure.

Its design rule: compromise in one domain must not imply compromise of every other domain.

CyberDen is where claims on this site become checkable. It's used for:

• Offensive security: attack paths, pivoting, AD attacks, vulnerable-app and CVE reproduction
• Defensive engineering: SOC tooling, telemetry, detection validation, DFIR
• Threat intelligence: MISP and OpenCTI fed with real feeds
• Infrastructure and networking: routing, VLANs, firewalling, DNS, storage, observability
• DevSecOps and product security: k3s, CI/CD, security gates
• AI infrastructure and AI security: a GPU inference node and agent/MCP experiments

Internet ── pfSense (edge firewall, NAT, north–south policy)
               │  transit /30
            VyOS (core router, inter-segment routing, east–west policy)
               │  802.1Q trunk
        Managed switch ── VLAN-aware Proxmox bridges ── workloads

• pfSense owns the edge: WAN, NAT, outbound policy.
• VyOS owns everything inside: one trunked interface with a sub-interface per segment (router-on-a-stick).
• Proxmox hosts stay on management. VMs get tagged virtual NICs, so the hypervisor never joins a workload segment.
• The admin workstation routes the lab via VyOS, so management traffic never hairpins through the edge firewall. That fix is documented in the W01–W03 series.

Read more: W01–W03 Hunting the 60-second SSH drop · W04 Locked out of my own lab · W05 VyOS answered everyone except me

Segments are grouped the way an enterprise groups them, not by "lab number":

Infrastructure: management · transit · DNS · storage · monitoring/observability
Defense: SOC · threat intelligence · DFIR
Identity: Active Directory / corporate · IAM
Engineering: DevSecOps / Kubernetes · product security · dev
Offense: attacker infrastructure · vulnerable apps · victim systems
Research verticals (planned): AI/ML · cloud · ICS/SCADA · telecom · automotive · medical · finance

Red-team segments deliberately keep flexible DNS and egress so rogue-DNS, DoH and tunneling tests stay possible. Infrastructure segments are locked down.

Read more: D02 Designing a 30-segment range on two mini PCs

• Security Onion for network security monitoring, sized to fit alongside everything else on a mini-PC node, later rebalanced
• MISP on a dedicated box with curated feeds
• OpenCTI in a container host on the T320
• Designed next: TheHive + Cortex, and Timesketch/Plaso for DFIR

Read more: W15 Placing Security Onion in a small lab · W09 OpenCTI restart loop

Pi-hole is the single DNS authority for infrastructure: pfSense, both hypervisors, and the server VMs resolve through it. Offensive segments are exempt by design.

Read more: W06 One DNS authority for a segmented lab

• ZFS pool tank on the T320 for datasets: backups, exports, logs, MISP data, packet captures
• TrueNAS on the NAS PC for retention
• Design rule: ingest nodes may write to storage, never read or control it
• Planned pipeline: rsyslog/journald → Fluent Bit → TrueNAS, with lifecycle cleanup so test-scoped logs don't live forever

Read more: D01 A log-offload pipeline for a homelab · W12 T320 storage notes

devops-k3s-01: a single-node k3s cluster with Traefik, local-path storage, Helm, Gitea (PostgreSQL + Valkey) and Jenkins, with Jenkins state persisted on the T320's ZFS pool.
Next: Harbor + Trivy, then one end-to-end pipeline with security gates (SAST/SCA/container scan) from commit to deploy.

Read more: W07 Jenkins on k3s that survives a reboot

• VulnHub VMs (OVA/VMDK) imported onto the victim node
• **vuln-apps-01**: a deliberately small Debian container host (2 GB / 40 GB to start) for Vulhub and VWAD targets
• Every CVE becomes one writeup: reproduce → exploit/validate → detect → remediate

Read more: W11 Getting VulnHub OVAs into Proxmox

• **ai-core-01** on the T320: GTX 1070 passed through via VFIO, running local models
• Workstation AI lab: RTX 3070, Docker on an external SSD, Ollama + Open WebUI. Tested Qwen3 8B and DeepSeek-R1 14B (~10 tok/s with partial CPU offload)
• Next: a gateway (LiteLLM), RAG, MCP servers and agent frameworks, plus AI-security experiments against them

Read more: W08 GPU passthrough on a PowerEdge T320 · W17 Docker on an NTFS SSD with a GPU

1. Freeze the management plane. Never migrate management and workloads in the same change window.
2. One truth per layer. Switch, hypervisor, router and firewall must agree on what each segment is.
3. Test the hypothesis before buying hardware.
4. Prove it with packets. tcpdump and traceroute beat guessing.
5. Not everything runs 24/7. The lab is interconnected like a real datacenter, so it gets powered up by role.
6. Write it down. If it isn't documented, it didn't happen.