The point
The goal of this lab is narrow and specific: prove I can operate a firewall the way a production SOC does: documented policy, a change-management gate in front of every rule modification, and the ability to investigate a blocked-traffic alert from first ping to closed report.
It is deliberately not an attack lab. The value is the defensive process. The lab runs pfSense with five interfaces (WAN, DMZ, and three internal VLANs), with Suricata inline for IDS and syslog-ng collecting every log the network produces. The discipline is real. The blast radius is not.
The stance
Every interface ends in block in log all. There is no implicit allow-outbound: any new flow (user to server, server to internet, DMZ to anywhere) requires a written rule, and every rule’s label carries a change-request ID. Adding a rule means filling out the change-request template first: justification, risk, test plan, rollback. Working alone, that feels excessive. That’s the point. The habit of documenting decisions isn’t for the current moment. It’s for the version of me that comes back six months later and has no idea why a rule exists.
A worked incident
The artifacts include a real investigation from the lab, IR-2026-003: Suricata flagged an outbound SSH scan from a user workstation at 02:11: three servers probed on port 22, all blocked. Log correlation traced it to a backup agent whose software update had silently switched its transport to SSH and was iterating its host list. No breach. Sixty-five minutes from alert to closed report, and one new explicit block rule so the next occurrence is labeled in the audit log instead of falling through to the default deny.
That investigation, from triage through correlation, root cause, and the change request that followed, is the lab working as intended. The incident report, the change-request template, and the complete ruleset are all published as-is.
Honest gaps
Suricata is mostly running default rules and only watches the WAN. Log search is grep over flat files, which doesn’t scale. The change log isn’t version-controlled yet. Each gap is a planned exercise. The goal is not to finish, it’s to keep the process honest. The full writeup covers the topology, the ruleset structure, and the reasoning in detail.