Security

Posture and practices. No enumerated weaknesses or specific control parameters here — those live in the private repo where they belong.

Threat model

Operating assumption: this is a one-person homelab on a residential connection, running a mix of services I rely on (password manager, calendar, photos) and a few that are reachable from the internet (portfolio, self-hosted Git). The realistic threat is opportunistic — bots scanning my public IP, automated exploitation of known CVEs in exposed services, credential stuffing against any public login.

A targeted, well-resourced adversary is out of scope. The defenses are designed to make the cost of opportunistic attacks high enough that automation gives up and moves on.

Layered controls

The defenses are intentionally redundant. Any single layer failing should leave the next one intact.

Network segmentation. Trust-tier VLANs with default-deny inter-tier policy. A compromise on one VLAN doesn't get lateral movement to another without crossing an explicit firewall rule.
Public surface stays small. Only a handful of services are reachable from the internet, all proxied through a DMZ-isolated host with a tight firewall-enforced allowlist into internal.
TLS at the edge, properly. ACME-automated certs via Cloudflare DNS-01. Public hostnames carry HSTS preload-eligible headers.
Identity in front of everything internal. Authentik handles SSO. OIDC where the app supports it; reverse-proxy forward auth where it doesn't. There's no "log in with the app's local account" bypass.
Admin is VPN-only. Hypervisor, firewall, backup server, switches, APs — none of them reachable from the internet. WireGuard is the only remote admin path, and it has its own keypair-based auth.
Secrets aren't in git. Configs reference secrets by name; values live in a password manager.

Update cadence

Edge components (firewall, reverse proxies, identity provider) — patched promptly when CVEs land. Highest blast radius if compromised.
Hypervisor and backup server — quarterly review, with security patches applied out-of-cycle when needed.
Application LXCs — rolling updates on a regular schedule, with the sensitive ones (password manager, photos, identity) bumped ahead of less-sensitive ones.
Container images — re-pulled on the same rolling schedule.

A version tracker in the private repo records what's running where, so drift is visible at a glance.

Backups

Hypervisor-level backups to a dedicated backup server on a separate VLAN.
Conservative retention, with the most recent backups always preserved no matter what gets pruned.
Backups verified periodically; restores exercised on a non-production host so I find out if something is broken before I need it.
A documented rebuild order means the lab can come back from cold in a few hours, assuming I have physical access to the firewall.

Credentials & rotation

Identity provider passwords: in a password manager, used through it.
Service-to-service secrets (API tokens, DB passwords): rotated when there's a reason to (component change, suspected exposure), not on a fixed calendar.
VPN credentials: per-device. Each remote client has its own keypair.

Honest limitations

This is a learning environment, not a hardened production estate. A couple of things I'd rather be upfront about:

No HA. One hypervisor, one firewall. The mitigation isn't redundancy, it's a tested rebuild path and conservative backups.
One-person ops. Everything runs as it would in a prod environment with on-call staff, except there's only me. The choice of tooling reflects that — anything that needs constant attention has been swapped out for something simpler.

Neither of those is unmanaged risk. They're scoped accepted risks, reviewed quarterly in the private repo.

Security contact

Found something concerning about a public-facing endpoint? admin@lerkolabs.com. I'll respond.

3.9 KiB Raw Blame History