Skip to content

Security posture

This page is the current security model of the backup estate and its surroundings: what is deliberately strong, what is accepted as a known trade-off, and what is still waiting on the operator. It is grounded in two audits — the broad infrastructure audit of 2026-06-10 and the four-lens backup-stack audit of 2026-08-12 (ops/kopia, pve/NFS, VPS, tailnet/artifacts). For the incidents that shaped these rules, see Security history.

Last reviewed

2026-08-12, alongside the August audit. Re-review after the UNAS Pro 4 migration and after Phase 2 (Veeam/Windows) lands.

The model in one paragraph

Nothing on the LAN is treated as trustworthy just because it is on the LAN. Every machine that backs up does so as its own kopia user against a TLS-fronted repository server, so one compromised endpoint cannot read or delete another machine's history. Secrets live in root-owned 0600 files on ops and in the password manager — never in this wiki, never on command lines, never in logs. Remote access rides an existing tailnet plus a WireGuard hub on the VPS — the self-hosted RustDesk relay sits behind that same tailnet with no public ports (Remote desktop); every SSH door is key-only. The last line of defence against ransomware that reaches the NAS over the network is NAS-side snapshots of the backup shares, which no LAN credential can rewrite retroactively.

What is strong

Control Detail
Secrets discipline All secrets 0600/root on ops (/etc/backup-stack/*.env, rclone conf); none on command lines, in logs, in this repo, or in memory files. Verified leak-free in the August audit. Values live in the password manager; pages reference locations only.
Kopia transport + identity Repository server on ops (192.168.1.190:51515) speaks TLS with certificate pinning on endpoints; each machine authenticates as its own user (backup@mc, backup@macbook, root@ops).
Per-machine isolation Kopia default ACLs scope each user to its own snapshots — a popped laptop cannot enumerate or prune the Minecraft VM's history.
SSH everywhere Key-only across the estate; VPS additionally on port 2222 with PermitRootLogin no and fail2ban active.
Ransomware floor NAS-side snapshots of the backup shares (see the Synology snapshot checklist item in backups) — the rollback layer that survives a client-side encryption event.
Content-based monitoring The monitor checks file ages, snapshot timestamps and remote byte counts, never exit codes — the direct product of the PBS-over-NFS incident. It also warns 30 days before the ops Tailscale key would expire.
Auto-patching (ops) unattended-upgrades enabled on ops during the August audit pass.

Accepted by design

These are known and deliberately not "fixed" — re-litigate only if the household threat model changes.

  • Kopia server reachable LAN- and tailnet-wide. Mitigated by TLS + per-user auth; reachability is the point (MacBook backs up from anywhere).
  • Repo-password holders bypass kopia ACLs via raw NAS access. Whoever holds the repo password and NAS credentials can read everything — NAS credentials are part of the trust boundary, not behind it.
  • Cross-user dedup side channel. A kopia user can infer that a chunk already exists in the repo. Household machines only; not worth the dedup-loss to close.
  • Kopia data has no cloud copy right now (owner's choice after the repo outgrew the Drive quota). The standing fix is B2 at roughly $0.40/month — see Off-site.

Pending operator actions (priority order)

From the August 2026 audit. These need a human at a console; none are scriptable from ops.

# Action Why it is this high
1 Proxmox 2FA — web UI → Datacenter → Users → root@pam → TFA → add TOTP The PVE UI is LAN-wide and password-only, and that single factor is the keys to every VM and its disks.
2 Tailnet hardening — disable key expiry for ops; add an ACL so the diag tablet cannot reach the whole LAN via the subnet route ops key expiry (2027-02-05) would silently kill remote backups; the travelling Windows tablet is the theft-risk device and currently inherits the entire 192.168.1.0/24 route.
3 Patch + reboot windows — pve: apt full-upgrade + reboot (11 pending security updates, 140-day kernel; all guests blip); VPS: pending kernel reboot after 355 days up (Minecraft proxy blips ~1 min) Long-lived kernels on the two most exposed hosts. Do when home, or accept the brief remote risk.
4 NAS export hardening (at UNAS migration if not before) — NFS export is sec=sys cleartext, no root squash, 777 share root shared with SMB The dumps are unencrypted VM images readable by any host in the export ACL. Prefer per-share credentials on the UNAS.
5 VPS extras — RustDesk 21115–21119 verified closed to the public (2026-08-12, tailnet-only — Remote desktop); still confirm Bedrock UDP 19132/19134/19136 are the intended public entry, and identify UDP 53955 (sudo ss -ulnp) Shrink the public surface of the one internet-facing box. See VPS.

Already fixed during the August audit pass

unattended-upgrades enabled on ops; VPS ~/.ssh tightened 775 → 700; dangling mp0 removed from stopped LXC 101; monitor now warns 30 days before ops Tailscale key expiry.

June 2026 audit — where those findings stand now

The 2026-06-10 audit predates the backup rebuild. Cross-checked against August reality:

June finding June verdict Status 2026-08-12
0a/0b — home.byers.cc (Home Assistant) had no Cloudflare Access in front of it, and MFA on all HA users was unconfirmed FIX-NOW Unverified. The August audit's four lenses did not cover HA. Treat as open until re-checked — the mc-admin Access pattern is the template.
3c — allowlist-web admin app: runs as root, binds 0.0.0.0:8080, trusts the Cf-Access-Authenticated-User-Email header without validating the JWT FIX-NOW Still open. The app still runs as root. mc-admin.byers.cc fronting (cloudflared + NPM + Cloudflare Access) protects the public path, but LAN/tunnel callers still bypass it. June's fix stands: bind to the WireGuard IP, validate the CF-Access JWT in-app, drop root. See mc-admin.
3b — flat /24, no VLANs, PVE firewall disabled; internet-facing MC VM could reach Proxmox mgmt, NAS, PBS, HA FAIL (top-3) Partially addressed, structurally open. PBS is gone as a target (LXC 101 stopped), NAS snapshots now floor the ransomware blast radius, and pending items 1 and 4 above harden the two juiciest destinations — but the LAN is still flat. VLANs or the PVE firewall remain the real fix.
1e — survival server on deprecated white-list=true with no explicit allow-list FAIL (top-3) Unverified since June — game-config scope, not re-audited in August. See the Minecraft runbook.
1c/1d — name-only allowlist entry; Rory op on creative FAIL/minor Unverified since June — same scope note as 1e.
4c — PBS images never verify-jobbed or test-restored FAIL Moot, lesson kept. PBS is decommissioned — and this finding was the near-miss warning for the PBS-over-NFS incident. Its successor practice is content-based monitoring plus periodic restore drills (Restores); the kopia Minecraft leg was restore-drill-verified 2026-08-11 before the VPS leg was retired.
X1 — Mac ~/.ssh/config ForwardAgent yes toward the MC VM FAIL Unverified since June. One-line removal on the MacBook; ProxyJump does not need it.
2a/2b — VPS ports and SSH hardening PASS Still true in August (key-only, 2222, fail2ban).

The pattern in the open items

Everything still open shares one shape: a control that exists at the edge (Cloudflare Access, key-only SSH) with a soft interior behind it (root single-factor PVE, header-trusting app, flat LAN). The pending list above is ordered to harden the interior.