The fourth in a series on what you actually get when you buy the book. Earlier entries: Two Books for the Price of One, Foundations Before Firepower, and Many Calculations Before the Battle.
Before we get into the core article — a quick, time-bound note. As a thank you to this amazing community, I have partnered with Packt to giveaway 2 copies of my newly released Cybersecurity Architect's Handbook, Second Edition on my LinkedIn channel. running through July 1, 2026. Two winners will get a copy of my book - Cybersecurity Architect's Handbook, Second Edition -Two winners will each take home either a print or e-book version. See details at the end of this post for details!
If you've been on the fence about grabbing the book, this is the cheap way in — it costs you three or four clicks and a comment. More at the bottom, but the clock's already running, so don't sit on it.
Category 1 was about knowing yourself and your enemy before contact — the thinking that decides what's worth defending and what's likely to come at it. This post moves to the first place that thinking touches wire: Category 2, Network Security Controls. If threat modeling is studying the map, this category is learning the ground itself — the traffic, the boundaries, and the chokepoints where you can actually see and shape what's moving.
The lab opens with two deceptively simple questions that every security architecture eventually circles back to: do you know what's happening on your network, and can you stop the things you don't want to happen? Firewalls, intrusion detection and prevention, traffic monitors, and the DNS resolver itself exist to answer those two questions. Together they form the visibility-and-control backbone the rest of a security program leans on.
The throughline is layering
The one idea that runs through the entire category is that no single tool catches everything, and no single capability is sufficient on its own. A real defensive architecture combines preventive controls with detective ones, and detective ones with response and forensics, each reinforcing the others. Threats get blocked when possible, detected quickly when they aren't, and investigated thoroughly when they make it through. That layering is the lesson; the individual tools are just where you practice it.
And, consistent with the rest of the supplement, the whole category is built to prove that a meaningful defensive stack doesn't require an enterprise budget. Every lab runs free, open-source tooling on commodity hardware or a VM — the same concepts you'll meet behind six-figure commercial platforms, minus the licensing.
Detection: Snort, Suricata, and Zeek
The category starts where network defense historically started — with the intrusion detection engine, Snort. It's worth knowing the lineage: Martin Roesch wrote it in 1998, Cisco picked it up via the Sourcefire acquisition, and it's now maintained by Talos as the most widely deployed open-source IDS in the world. The lab uses Snort 3, which is a genuine redesign rather than a version bump — Lua-based config, multi-threaded processing, and a flow-based inspection model that reconstructs whole sessions instead of judging one packet at a time. That last part matters, because most modern evasion is precisely the trick of spreading an attack across packets to slip past packet-by-packet inspection. There's also SnortML, a machine-learning detection engine Talos open-sourced in 2024, aimed squarely at the oldest weakness of signature-based detection: the inability to catch the threat nobody has written a rule for yet.
Then comes my favorite pairing in the category — a single lab that runs Suricata and Zeek against the same packet capture. They're deliberately different animals. Suricata is a signature engine: it compares traffic to rules and alerts when something matches a known-bad pattern. Zeek (formerly Bro — named, with some irony, after Orwell's Big Brother) doesn't judge good or bad at all; it records the detail of every connection, DNS lookup, and TLS handshake into structured logs you can search and pivot through. One tells you when known-bad traffic shows up; the other tells you, in forensic detail, what actually happened — so you can investigate the alert or hunt for the activity no rule anticipated.
Running both over the same traffic teaches the cross-referencing habit better than any diagram could. In the lab, Suricata fires on a suspicious DNS query, but Zeek's dns.log comes back blank for the matching AAAA lookups — and it's Zeek's TLS metadata, the SNI in the handshake, that confirms the destination anyway. That's the moment it clicks why analysts run these side by side instead of picking a favorite.
A different model: centralized ClamAV
Tucked into the category is a small lab that's really a lesson in architectural thinking applied to a boring operational chore. Most shops deploy antivirus by installing an agent on every host and then managing signatures, schedules, and version drift across hundreds of installs. The lab builds the alternative: one Debian host running ClamAV's clamd daemon, listening on a socket, kept current by an automatic updater, scanning files that other machines stream to it over TCP — no engine installed on the clients at all.
The payoff is the architect's payoff: one signature database to keep current, one service to monitor, one place to audit. Endpoints stay light, new systems onboard by pointing at the scanner instead of installing a stack, and when Talos ships an urgent signature, everyone is covered the moment the central host updates. Same protection, dramatically less to operate.
Prevention: the firewall, hands-on
From detection the category turns to prevention, and it does the thing I wish more material did — it lays out the full firewall taxonomy before touching a config. Eight types, each with real examples and a clear "best for": packet filters, stateful inspection (the foundation of modern firewalling), proxy/application-layer, next-generation firewalls, web application firewalls, cloud and Firewall-as-a-Service, host-based, and UTM. Understanding where each fits is what lets you make a grounded selection instead of buying whatever the analyst quadrant rewarded this year.
Then you build one. The lab walks through installing OPNsense 26.1 — free, open source, runs fine as a VM, and ships features comparable to many commercial NGFWs — and lands on a working firewall in front of a small lab network. On top of that, it layers Zenarmor to add application-aware Layer 7 inspection and the identity-driven, cloud-managed, follow-the-device enforcement that defines SASE. The key takeaway is exactly the one the whole supplement keeps making: next-generation, application-aware security is not the exclusive property of six-figure platforms. The vendor and the UI change; the underlying concepts — zone-based rules, application identification, IDS/IPS inline, segmentation — don't.
The capstone of the category: DNS
The category saves its best argument for last, and it's one a lot of programs miss entirely: treat the resolver as a security control, not as plumbing. Almost every action on a network begins with a DNS lookup the user never sees, which makes the resolver both one of the most load-bearing services on the network and one of the most overlooked. The lab gives it real history — BIND, cache poisoning, the DNSSEC response, and the encrypted transports (DoT/DoH) that are now standard — then compares Pi-hole, AdGuard Home, and Technitium before building two resolvers: a privacy-first Pi-hole + Unbound setup, and a resilient three-node Technitium cluster.
Here's the turn that makes this the capstone of the whole category. By filtering, validating, and encrypting name resolution, you turn the resolver into one of the highest-leverage preventive controls on the network. But in doing so you also build the best-positioned sensor you have. Every query a device makes is a statement of intent — what it wanted to reach, when, and how often. The per-client query logs you stood up as a byproduct of filtering aren't just an audit trail; they're a live behavioral feed in which a beaconing implant or a misconfigured device very often reveals itself first.
Where prevention hands off to detection
That's the bridge out of the category. Having spent Category 2 learning to block what we can recognize as bad, the natural next problem is making sense of everything else — collecting, correlating, and interrogating the signals our infrastructure already produces. That's Category 3, Security Monitoring and Analytics, and it's where this series goes next.
The full Category 2 lab — Snort, the Suricata/Zeek pairing, centralized ClamAV, the firewall taxonomy and the OPNsense/Zenarmor build, and the DNS resolver labs — is in the supplemental download on the book's GitHub repository, alongside the other seven categories and the AI-powered SOC capstone they build toward.
Win a copy — before July 1
One more time, because the window is short: Packt is sponsoring a giveaway on my LinkedIn channel, running through July 1, 2026. Two winners will get a copy of my book - Cybersecurity Architect's Handbook, Second Edition :
- 1 winner will receive an eBook.
- 1 winner will receive a print book.
To enter:
- Follow me on LinkedIn: https://www.linkedin.com/in/lnichols/
- Share this and the LinkedIn post
- Comment "Print" or "eBook" to indicate which one you want to win on LinkedIn
- Follow the SecPro from Packt page: https://www.linkedin.com/showcase/secpro-from-packt/
That's the whole entry. If you'd rather not leave it to a drawing, grab the Cybersecurity Architect's Handbook, Second Edition here: Amazon.
Either way — stand up a resolver you control, point a couple of clients at it, and watch what your own network is actually asking for. It's a quietly eye-opening evening. If you build something with it, I'd like to hear about it — you'll find me at secdoc.tech.
