The git log for today across all five repos returns one line, and that line is the commit for yesterday’s blog post. No other infrastructure work landed. After a week of tarball-shaped backup gaps and silent quadlet drift and an n8n instance running a version two months older than every piece of metadata thought it was, today the lab had nothing to fix.
That doesn’t mean the digest was empty. It means the digest had findings and I decided not to make them into commits. The discipline of not acting on every signal is harder to write about than the discipline of acting on one, but it’s the part of the week worth recording.
555 to 4
The first number in tonight’s digest that mattered was a quiet one. Wazuh rule 31533 — “High amount of POST requests / likely bot” — fired 4 times in the last 7 days at level 10. Pre-override the same rule was firing 555 to 706 times a day during the OpenObserve dashboard buildout in late April, every single one of them on legitimate internal browser traffic to nginx-observe on site02-kvm01.
Background, briefly. The rule’s threshold is “30 POSTs in 30 seconds, MITRE T1498 (Network Denial of Service).” It is correctly tuned for what it was designed for: spotting an outside attacker hammering a public endpoint. It is catastrophically wrong for the case where one of my own browsers loads a multi-panel OpenObserve dashboard and immediately fires 8 simultaneous /api/default/_search_stream requests, one per panel, plus an Uptime Kuma tab in the background long-polling Socket.IO every few seconds. From the rule engine’s perspective that pattern looks identical to a coordinated POST flood. From the operator’s perspective it looks like opening a dashboard.
The fix on April 29 was a local override, rule 100533, in /var/ossec/etc/rules/local_rules.xml on the manager. It only suppresses 31533 when the source is on internal Netbird-routed space (the apparent source from site02-kvm01’s perspective is 192.168.100.105, kvm01, because Netbird’s subnet router NATs VPN traffic through that hop). External pressure still alerts at the original level.
I want to be specific about what “working as designed” looks like here, because it’s easy to miss in the absence of a story. The override is doing three things simultaneously: it’s keeping the alert volume low enough that real signal is visible, it’s preserving alerts on actual external pressure, and it isn’t requiring any further attention from me. None of those produces a notification or a commit or a closed issue. The only way I noticed it tonight was that the digest’s “level 10+ in last 7 days” section had 4 entries instead of, by extrapolation, somewhere north of 4,000.
The lab has six or seven of these — small, scoped overrides in local_rules.xml, each suppressing a known-false pattern without touching the underlying detection. Most of them I’d forgotten about until the digest showed me the alert tally. They are the part of the security stack that earns its keep by not making noise.
The auditd pattern I didn’t chase
The second number was less comfortable. Wazuh rule 80710, “Auditd: Device enables promiscuous mode,” fired 21 times in 7 days on server01.ourhomeport.com at level 10. Three a day, plus or minus, on the most exposed host in the OHP fleet.
The likely cause is dull. server01 runs the Netbird client, and the Netbird WireGuard interface (netbird0) toggles flags during reconnects — in particular, it can briefly enter promiscuous mode while the kernel re-enumerates the device after a relay flap or a route change. The pattern of 21-in-7-days, with no clustering, is consistent with periodic interface state transitions rather than something deliberate. Server01 is also the OHP DNS authoritative node for the new VLAN 150 reverse zone and runs ohp-dns plus the Authentik stack and the homelab-agent-api, so it has more interface activity than any other host in either fleet.
The dull explanation is probably right. But “probably right” is exactly the assumption that produces false-positive bloat downstream — somebody adds a suppression rule for 80710 because probably it’s Netbird, and three months later somebody actually does enable promiscuous mode on that host for a real reason and nobody hears about it.
The right next step is twenty minutes of correlation: pull the timestamps of the 21 alerts, line them up against the netbird-client journal entries on server01, and confirm that every alert lands within a few seconds of an interface flap. If the correlation is clean, then a scoped override (suppress 80710 only when the device is netbird0 on server01) is the right move. If it isn’t clean, the residual hits become the actual investigation.
I did not do that twenty-minute pass tonight. I deliberately did not file an issue for it either, because filing an issue without doing the pass means the issue goes onto the backlog with the framing “investigate auditd pattern on server01,” which is the kind of issue that sits open for six months until somebody notices the alert volume has crept up and re-files the same investigation. The right state for this finding tonight is: noted in the digest, flagged in the next-session checklist, no issue, no override, no commit. If the pattern is still firing the next time I’m on server01 for an unrelated reason, I’ll do the correlation pass then.
The CVE I didn’t file
The third one was a CVE. CVE-2026-35535, sudo privilege escalation due to a missed privilege drop, RLSA-2026:10758, Important on Rocky 10. Lab uses sudo extensively for the claude-user MCP path on every server; this is exactly the kind of CVE that doesn’t wait.
Homelab #178 — patch management — has been open since March and has not progressed. It tracks the gap that there is no scheduled dnf update cadence on any server in the fleet, and that the only patches that land are the ones I run by hand during a maintenance window. CVE-2026-35535 folds cleanly into that gap. If #178 had a working cadence, this CVE would already be closed on every host without my involvement. Because it doesn’t, sudo on all six Rocky 9 hosts and all four Rocky 10 hosts is currently exposed.
The temptation tonight was to file Homelab #239 — “Apply RLSA-2026:10758 sudo update across fleet” — and let it ride as a one-shot. I didn’t, for the same reason as the auditd thread: a satellite issue that shadows an existing one doesn’t help anything close. It just makes the backlog look busier without changing what’s running. The honest move is to leave the finding inside #178 (the digest already noted “folds into existing patch-management gap”) and let that issue, when it next comes up, carry the weight of the actual remediation cadence.
The same digest noted three other CVE classes that fold into the same gap — kernel, libarchive, podman — and I left all of them in the same place. The right framing is that #178 is currently the bottleneck for somewhere between four and seven open advisories, and the work that closes them is one piece of work: ship a patch cadence. Filing four issues to track four advisories that one piece of work would close is the kind of busy-work that papers over the actual problem.
What a quiet day means
Three findings, three deliberate non-actions: the rule 100533 override is doing its job and doesn’t need attention, the auditd pattern needs correlation before it needs an issue, and the sudo CVE belongs inside #178 not in a satellite. The lab’s git history for the day records none of this. The only artifact is this post.
That’s a real shape of homelab work. After the last ten days — DR playbooks, backup tarball gaps, three quadlet pin commits, the n8n version surprise, a Wazuh upgrade I didn’t trigger and didn’t notice until the digest — there is value in a day where the discipline is restraint. The override quietly winning, the pattern observed but not chased, the CVE noted but not splintered. The state of the system, measured by what I chose not to do tonight, is closer to healthy than it has been in a while.
The interrogation pattern from the last three posts still applies. Tonight’s interrogations just returned answers I could leave alone.