Security on RevoluGame

Backing Up the One Credential That Can't Be Wrong

Mon, 15 Jun 2026 10:00:00 +0100

Most things in my homelab can fail and I shrug. A container restarts, a dashboard is stale for an hour, a media file gets deleted by mistake: annoying, recoverable, fine. The password vault is not in that category. If it’s wrong, or gone, or merely unreachable at the wrong moment, I lose access to everything else at once. It’s the one piece of infrastructure that earns the extra paranoia.

So instead of “back it up somewhere,” I sat down and asked the question I’d ask at work for any single point of failure: which specific failure does each copy need to survive? That question is what actually shaped the design. Not “more backups.”

Three copies, three different failure modes

The vault lives day-to-day in Dashlane. Around it, a script keeps two more copies current:

A dated, offline KeePass .kdbx archive. The script exports the vault, converts it to KeePass format, and syncs the file to NAS over rsync. This file needs nothing else to be true. No Dashlane account, no Vaultwarden instance, no network to be opened. KeePassXC plus a master passphrase is the entire recovery path.
A live Vaultwarden mirror. The script wipes and re-imports a self-hosted Vaultwarden instance on every run, so it never drifts and never accumulates stale duplicates. Unlike the .kdbx, this one behaves like a normal vault app day-to-day. Useful if Dashlane itself is the thing that’s unavailable.
The original, in Dashlane. Still the primary, still the one I actually use day to day.

Each of these answers a different question. If Dashlane has an outage or I get locked out of the account, Vaultwarden keeps working normally. If my entire home network and every service on it is down, or I’m on a borrowed machine with nothing installed, the .kdbx file plus a passphrase I’ve memorized is the whole recovery procedure. No SSH keys, no app, no account, no network. If the NAS itself dies, the live Vaultwarden mirror (running elsewhere) and Dashlane are both still fine.

That’s the test I’d apply to any redundancy claim: two backups that die from the same root cause aren’t two backups, they’re one backup with extra steps. These three don’t share a single point of failure with each other.

The part that matters more than the architecture

Diagrams of “three copies in three places” are easy to draw and easy to get wrong in the implementation details, and the details are where a vault backup script can quietly turn into a liability instead of a safety net.

The script exports the raw vault to CSV in plaintext before converting it. There’s no way around that, the conversion tool needs plaintext input. So the entire design constraint became: that plaintext must never outlive the script’s own execution. It’s written to a private temp directory, and a shell trap deletes it on every exit path. Success, failure, or interruption, not just the happy path. The master passphrase that protects the .kdbx is treated as its own tier-zero secret: it lives outside the repo, outside the backup, memorized or written down somewhere physically safe, because it’s the one credential that unlocks the credential store.

It’s a small thing, a trap ... EXIT instead of cleanup code only at the bottom of the script. But it’s exactly the kind of detail that’s invisible when it works and catastrophic when it doesn’t. I’d rather the script crash and still clean up after itself than ship a feature and leave a plaintext export sitting in a temp folder because someone hit Ctrl-C at the wrong moment.

Threat-model your one credential that can’t be wrong

Every system has at least one of these. The credential, the key, the record that everything else assumes is correct and available. For most of us it’s a password vault; for some it might be a signing key or a recovery seed.

The exercise worth doing isn’t “add more backups.” It’s listing the ways that one thing could become unavailable or wrong, and checking that your copies don’t all fail for the same reason. If they do, you’ve built redundancy theater, not redundancy.

Running a Personal SOC: Bringing Production Security Practices Home

Fri, 12 Jun 2026 10:00:00 +0100

At work, nobody questions why we have logging, alerting, and a daily look at what changed overnight. At home, the same network runs a NAS, a media stack, Home Assistant, and a handful of containers. And for years my only “security monitoring” was noticing something was broken.

So I built myself a small, read-only security operations setup for the homelab: a daily audit script and a cross-domain digest agent that correlates it with everything else running on the network. Nothing here is novel security research. The interesting part is which production habits turned out to be worth carrying home, and which ones I deliberately left at the office.

Two layers, not one

The setup is split into two pieces with different jobs.

The daily audit is the boring, deterministic layer. Once a day it collects, locally and read-only:

listening sockets, flagging anything bound to a wildcard interface
Docker/container posture: privileged containers, dangerous bind mounts, host network mode, dangerous capabilities
systemd service drift against an expected allowlist
a local secrets/config hygiene scan (path, line, and pattern only - never the matched value)
cached apt list --upgradable, optionally enriched with a trivy fs scan
whether the monitoring artifacts and timers it depends on are actually present

It writes a deterministic Markdown digest and a JSON report to a local outbox. That’s it. No remediation, no service restarts, no firewall changes. The rule I gave it was “assume breach, trust no single signal, change nothing during observation.”

The SOC agent is the correlation layer on top. It runs once a day and pulls together SSH auth logs (brute-force detection, unexpected successful logins, elevated sudo activity), Docker security posture, UniFi network signals (unknown MAC addresses, active IPS/DPI/flood/scan/rogue alarms), and re-surfaces anything security-relevant the daily audit already found. Everything gets a severity from ok up through critical, and the result is written as an Obsidian note with YAML frontmatter. So a year of these becomes a searchable, taggable incident timeline instead of a folder of text files nobody opens.

Where the LLM fits - and where it doesn’t

Both agents can optionally hand their findings to a local Ollama model to write a short narrative summary on top of the facts. This is the part I was most careful about, because it’s the part most people get backwards.

The model never sees raw logs, full inventories, or matched secrets. It only compact finding titles, IDs, severities, and evidence keys. It doesn’t decide what’s a finding; the deterministic analyzers do that. And if Ollama is unreachable or returns something unusable, the deterministic digest ships as-is. The LLM is a narrator, never the source of truth.

That’s the same boundary I’d want on a production alerting pipeline: detection logic stays deterministic and testable, and generative summarization sits strictly downstream of it, never upstream.

The part that’s just operational discipline

A few choices here have nothing to do with security theory and everything to do with habits from running things in production:

Output paths are permissioned, not just “private by convention.” Reports get 0600, runtime directories 0700.
Stale data is treated as a finding, not silently trusted. Upstream reports older than a configured threshold are flagged rather than quietly re-surfaced as current.
Notifications are a tap-through, not the whole story. A push notification carries the headline and a link into the actual note - useful at a glance, but the record of truth lives in the note, not in a chat history that scrolls away.
Everything is replayable offline. Both agents accept a fixture file in place of live collection, so I can test a new analyzer rule against a known input before it ever touches my real network.

What it actually buys me

Mostly, it buys me the same thing it buys at work: I notice drift before it becomes an incident, instead of after. A container that quietly picked up a privileged flag, a port that got published wider than intended, an unfamiliar MAC address on the network. These are exactly the kind of small, boring facts that are easy to miss and easy to detect deterministically.

It’s not a real SOC. There’s no 24/7 coverage, no incident response retainer, and the threat model is “don’t get owned by something dumb,” not “defend against a motivated attacker.” But the muscle is the same one I use at work: write the check once, make it boring and deterministic, let a model help you read the output, and keep a record you can actually search six months later.

If you’re already doing this professionally, the homelab version costs you an evening and pays you back the first time you catch something you would have otherwise missed entirely.