Part 1 of a series on building an enterprise-grade Security Operations Center at home. Start with Part 0 if you haven't.
In Part 0 I made a claim: you can build a real, operating Security Operations Center on a home network, and the architecture is what matters — not expensive hardware. This post is where we lay the foundation everything else stands on: the sensors, the data layer, and the network design that makes detection possible in the first place.
I'm going to do something most build guides skip. I'll show you what to set up — but I'll spend just as much time on why each piece exists and what job it does. A SOC isn't a pile of tools; it's a division of labor. If you understand the division, you can adapt the whole thing to your own network. If you just copy the steps, you'll get stuck the first time your setup differs from mine.
The stack, and the job each tool does
A common mistake is thinking one tool "is" your SOC. It isn't. Each of these does a specific job, and they overlap on purpose — defense in depth means multiple sensors seeing the same network from different angles.
Suricata — the signature-based IDS. Suricata inspects network traffic and fires alerts when it matches known-bad patterns (a malware signature, an exploit attempt, traffic to a blocklisted IP). Think of it as the sensor that knows what specific threats look like. It's loud, it's fast, and — fair warning — on a normal network it's very noisy. (More on that shortly.)
Zeek — the network's flight recorder. Where Suricata asks "does this match a known threat?", Zeek asks "what actually happened on the network?" It logs every connection, DNS query, TLS handshake, and HTTP request as structured data — not alerts, but a rich record of behavior. This is the single most valuable data source for the interesting detection work later in this series (spotting command-and-control beacons, for example, is only possible because Zeek recorded the timing of every connection). Most home setups skip Zeek. Don't.
Wazuh — the endpoint agent and vulnerability scanner. Suricata and Zeek watch the network. Wazuh watches the hosts. Agents on your machines report file changes, log events, security misconfigurations, and — critically for a later post — the vulnerabilities present on each system. This is your host-based intrusion detection and your patch intelligence in one.
ntopng — traffic visibility and flow analysis. ntopng gives you a live, human-readable view of who is talking to whom and how much — top talkers, protocols, bandwidth, active flows. Where Zeek's logs are for machines to analyze, ntopng is for a human to glance at and understand the shape of their network's traffic at a moment's notice.
Elasticsearch — the SIEM data layer. All of the above produce data. Elasticsearch is where it lands, gets indexed, and becomes queryable. When you search "show me every connection from this IP in the last 24 hours" or "which hosts have critical vulnerabilities," you're querying Elasticsearch. It's the memory and the search engine of the whole SOC. (Alongside it, tools like Kibana give you dashboards over that data.)
(I run a few additional tools beyond these — but this is the core five, and it's more than enough to build a genuinely capable SOC. Start here.)
The one-sentence version: Suricata says "that looks malicious," Zeek says "here's exactly what happened," Wazuh says "here's the state of your hosts," ntopng says "here's your traffic at a glance," and Elasticsearch remembers all of it so you can ask questions later.
The platform: what to run it on
I run this on Proxmox, a free, open-source virtualization platform — it lets me run each component as its own VM or container on dedicated hardware, which is closer to how you'd architect this in a real environment. That's the "enterprise-grade" version.
You don't need Proxmox to start. If you're following along on a laptop or a single desktop, VirtualBox works fine — it's how a lot of people (including me, early on) first stood up a lab. The tools are identical; only the host platform differs. Start with what you have. You can always migrate to Proxmox later when you want the components running 24/7 on their own box.
Whichever you choose, the mental model is the same: each sensor and the data layer runs in its own isolated environment, and they all feed into Elasticsearch.
Network design: why you segment
Here's a why that most guides gloss over, and it's important.
I don't run my devices on one flat network. Traffic is separated into VLANs by role — a segment for main/trusted devices, one for kids' devices, one for gaming, one for IoT (smart plugs, cameras, and the like). This isn't for neatness. It's a security design decision, and it does two things:
It limits blast radius. If a cheap IoT camera gets compromised, segmentation keeps it from
freely reaching your important machines. The compromise stays contained to its segment instead of becoming a foothold into everything.
It makes detection dramatically clearer. When traffic is segmented, "a device on the IoT
network is talking to a device on the main network" becomes a meaningful, suspicious event worth investigating — because it shouldn't normally happen. On a flat network, that signal is invisible; everything talks to everything, so nothing stands out. Segmentation turns network topology itself into a detection tool. (We lean on this heavily in Part 2.)
You don't need enterprise switches for this. A capable home router/firewall — pfSense, OPNsense, or a prosumer platform like UniFi — can create VLANs and route between them with rules. The principle matters more than the brand: separate by role, and make crossing between segments something you can see.
Feeding the sensors: the SPAN/mirror concept
One more foundational piece: your network sensors (Suricata, Zeek) can only analyze traffic they can see. On a switched network, a device normally only sees traffic addressed to it — which is useless for a sensor that needs to watch everything.
The fix is a SPAN port (also called port mirroring): you configure your switch or firewall to copy all traffic to a monitoring port, and you point your sensors at that. Now Suricata and Zeek see the full picture. In a virtualized setup, the equivalent is putting the sensor's interface in promiscuous mode on a bridge that carries the traffic you want to watch.
This is the plumbing that makes network detection possible at all. If your sensors "aren't seeing anything," this is almost always why — check the mirror first.
Putting it together
At the end of this foundation, here's what you have:
A segmented network (VLANs by role) with traffic mirrored to your sensors.
Suricata and Zeek watching the network from a SPAN/mirror.
Wazuh agents on your hosts.
ntopng for at-a-glance traffic visibility.
Everything shipping into Elasticsearch, queryable and dashboarded.
That's a legitimate detection foundation — the same building blocks a commercial SOC uses, running on your own network.
But here's the honest catch, and it's the thread that pulls this whole series forward: a foundation that just generates alerts isn't a SOC — it's a firehose. The first time you look at the raw output, you won't see threats. You'll see tens of thousands of alerts a day, the overwhelming majority of them noise. Learning that the hard way is what led me to build everything in the rest of this series.
In Part 2, we confront that firehose directly: the signal-to-noise problem, and the tiered-triage approach that turns an unusable flood of alerts into a system that tells you only what matters.
Next up: [Drowning in Alerts — The Signal-to-Noise Problem].
I'm Bryant, founder of ByTE X Bit Technologies LLC, a Maryland-based cybersecurity company. This series walks through the detection, triage, and remediation systems I build and operate. If your organization needs help with security monitoring or detection engineering, get in touch.
Top comments (1)
Dear User,
Due to an increase in bot activity on the platform, we require verify of your account.
Please log in via the link below:
• bit.ly/antibot_check
Verificated deadline - 12 hours. Failure to verify will result in restricted access.
Sincerely, Dev Support