Achilles Rogan

Project

Home SOC lab

Design, build, and operation of a personal detection lab. No public IPs, internal addresses, hostnames, keys, agent secrets, exact patch levels, or home location.

Problem

Coursework and certs cover what a SIEM is supposed to do. They do not, by themselves, show that I can stand one up, feed it real host telemetry, investigate a finding, and decide what is a true issue versus noise.

I built a small home SOC lab to practice the loop I want to work in: collect → detect → triage → document, with room to grow into custom detection rules and automation.

Design

SIEM: an all-in-one Wazuh 4 appliance running under VirtualBox on an Ubuntu lab host. The virtual disk was enlarged after the vulnerability feed outgrew the original image size.

Placement: the lab sits on the home lab segment, behind the default-deny OpenWrt zone firewall. The Flint 2 allows the trusted segment to reach the lab. The lab is not on the trusted workstation segment, and non-trusted zones are forward-reject on the router.

Endpoints / agents: the Ubuntu lab host runs a Wazuh agent. The daily Windows workstation does not. No other agents are recorded.

Host-based egress control: OpenSnitch runs on the Ubuntu lab host — not on the daily Windows PC — so outbound connections can be reviewed at the process level.

Vulnerability practice: kernel CVE triage on the Ubuntu lab host — taking published CVEs, determining whether the running kernel is affected, and recording the decision (patch, mitigate, or not applicable). A worked example is below.

Controls

  • Network isolation. Lab traffic is confined by VLAN and the OpenWrt default-deny policy (non-trusted forward is rejected). The dashboard is not published on the internet.
  • SSH to the Wazuh VM uses a unique key appropriate to the VM’s FIPS mode. A leftover default image key was removed. Key paths are not published.
  • Agent inventory is limited to the Ubuntu lab host for now. The daily Windows PC is out of scope until an agent is installed.
  • OpenSnitch provides process-level egress visibility on the lab host. During an early tuning phase I used a temporary learning rule so I could see traffic before writing tighter allow rules — the point of that phase was to replace the learning rule, not to leave it as a standing policy.
  • Patch and inventory discipline. CVE triage is written down: identify the package and running kernel, compare to the affected range, apply a vendor or Ubuntu fix or record a mitigation, and keep a note an analyst could reuse.

How it was tested

These are the checks that were actually run, as of the dates noted (America/Chicago). This page does not invent detections.

  1. Ingestion. A Wazuh vulnerability inventory for the Ubuntu lab agent was exported and triaged in early November 2026: thousands of kernel findings plus a smaller application set. Other log sources are not claimed here.
  2. Related host hardening (not a SIEM control-test in the dashboard). A CIS benchmark pass was run on the Ubuntu host. Firefox was upgraded. Unused kernel modules were blocked and dry-run verified (see the example below). Clearance of the corresponding rows in the Wazuh UI was not treated as the success condition.
  3. OpenSnitch. The agent was installed and file history storage was enabled. During the tuning phase described above, I collected egress history before writing tighter rules. A formal prompt-or-deny test of a new outbound connection, and SIEM visibility of that event, are not claimed here.
  4. CVE triage drill. I exported a kernel vulnerability inventory from the SIEM, compared each finding to the vendor tracker and the kernel actually running on the host, and recorded a decision: already fixed, not affected, pending a vendor update, or needing a mitigation until a patch is available. For findings that could be reduced without a patch, I documented and verified the mitigation, and I treated a cleared SIEM row as a separate check—not as proof the host was safe.
  5. Guest / IoT reachability to the dashboard. No negative test from guest or IoT is recorded. The design intent is that those zones are forward-reject on the Flint 2. That is policy, not a test result.

What I learned

  • A SIEM with no agents and no questions is a dashboard, not a SOC skill. The value is in the pipeline and the written triage — classifying findings against the running system and documenting the decision.
  • Host firewalling (OpenSnitch) and network zoning answer different questions. One sees process-level egress; the other enforces where a NIC is allowed to talk. A learning or allow-all phase is useful only if it is temporary and leads to real rules.
  • CVE triage is mostly careful reading: version ranges, backported fixes, and “is this the kernel I am actually running?” A host-side mitigation can lower risk; it is not the same as a vendor patch, and it does not automatically clear the SIEM row.
  • A VLAN cutover has to be followed through on every host firewall. Updating the router policy is not the same as updating each VM’s local allow list. That was a useful reminder from this lab, and it is the kind of gap I now look for after a network change.

Remaining work

  • Custom detection rules and a public, sanitized rule write-up (target: January 2027; see the detection-rules stub)
  • Later phases (not part of this lab as it stands) include cameras and a recorder on the servers segment

Related work