Suricata IDS: Out-of-Band Deployment Notes

A firewall is a control point; an IDS is an observation point. In February I set up SPAN on the core switch and mirrored the traffic to a small box running Suricata. No inline, no blocking — first, find out what "normal" looks like at home. These are notes from that out-of-band experiment, ordered by the actual sequence — wiring, baseline, noise, handoff — not a full install guide.

Why start out-of-band

An inline IPS that false-positives cuts your network outright, and at home that's expensive: a spouse's video call, a kid's online class, every IoT device reconnecting at once. Out-of-band has clear upsides — Suricata can die and the network doesn't care; a false-positive rule doesn't cut anything by default; and it's the right way to build a baseline before you talk about blocking. The cost is just as clear: you can see, but by default you can't stop. When you do need to block, bake the finding into the firewall — don't let the IDS act on a whim.

Wiring and mirror-port reality

On the core switch, pick a mirror source (the uplink or the LAN aggregation, for example) and point the destination port at a dedicated NIC on the Suricata box. That NIC goes promiscuous and doesn't even need a business IP — it just eats the mirror. Sanity check:

ip link set eth1 promisc on
suricata -T -c /etc/suricata/suricata.yaml

HOME_NET has to be right, or every alert is either noise or nothing. Decide up front what counts as home: the LAN subnet, the VPN subnet, the guest network. Skip the VPN range and your normal commute-home traffic gets flagged as "external"; overreach into public ranges and you'll miss real lateral scanning. Enable a ruleset like Emerging Threats and keep it updated. EVE JSON logs slot into your analysis stack later, but watch the disk — rotate them daily.

The notes also need an honest limitations section. SPAN can drop packets, so don't treat a passive IDS as billing-grade traffic accounting; mirror quality degrades when the switch CPU is busy; and cross-check important alerts against host logs instead of trusting the network side alone. The little box's CPU and NIC also have to keep up with the mirror bandwidth — feed it a saturated gigabit mirror and Suricata will silently drop detections too.

Week one: watch, don't convict

With all rules enabled, the first week at home produces a lot of noise: device discovery, P2P, games, NAS sync, odd probes from the printer. The discipline for the experiment: don't ban IPs immediately, just classify. What's known home traffic, what's genuinely suspicious outbound, what's an overbroad rule. Suppress the rules you've confirmed harmless, and record the SID plus the reason — otherwise in three months you'll have no idea why it's suppressed.

Only high-priority alerts go to your phone; low priority lands in a log you flip through on weekends. Grab raw pcap on demand, don't store everything and blow up your disk — mirror traffic is line-rate times uptime, and storage exhaustion arrives before any attacker does.

Converging alerts into something actionable

The processing order that worked best in practice: look at the five-tuple and the timestamp → check whether a home device was online during that window → check host logs or firewall conntrack → then decide suppress, allowlist, or a firewall rule. Encrypted traffic dominates, so an IDS mostly sees metadata and known signatures; you can't see inside TLS, and that's not a config failure, it's reality.

Sometimes the biggest win isn't catching an external attack — it's finding a service that shouldn't be talking to the public internet at all: a debug port left open, a container port mapping that's too wide, an old device still phoning home. An out-of-band IDS is an extra mirror showing you what actually flows across the boundary.

Handoff to the firewall: human-confirmed, never mindless

After a human confirms an alert, it can be distilled into a firewall or fail2ban rule. Don't auto-ban large IP ranges — home egress IPs change, CDN nodes are shared, and collateral damage is real. My handoff experiment stopped at "alert-to-ticket": when one source hits high-risk rules repeatedly, I add a manual temporary DROP with an expiry. Permanent rules need stronger evidence.

Conclusion and the not-done list

The out-of-band deployment proved the point: separating observation from control keeps a home network steadier, and talking about automatic bans before a baseline exists is just an amplifier for noise. Rule updates belong in the experiment rhythm too — after an Emerging Threats ruleset upgrade, watch for twenty-four hours before deciding whether to inherit the old suppressions; the new rules may flag that printer as high-risk again a week after it finally quieted down.

Not done: inline, a full ELK dashboard, automatic blocking from external threat intel. Those wait until the false-positive rate comes down. The limitations go at the end of the notes: an IDS doesn't replace host hardening and backups; stay humble when the mirror drops packets; and in an encrypted-traffic era, metadata and known malicious signatures still earn their keep — but don't expect an out-of-band box to see inside every HTTPS flow. See clearly first, then talk about control — that phrase lands better at home than it does on a data-center poster.