Skip to content

Security Audit — Oak Techx Homelab

Date: 2026-06-07 (post-Session-10 marathon, performed while Kay slept) Auditor: Claude Opus 4.7 Scope: All deployed services + PVE host + iLO + network + TLS + secrets + backups + updates Method: Read-only probing across PVE, all LXCs, network paths, container configs. No state changes made during the audit.

Severity scale

Symbol Meaning
🔴 CRITICAL Fix before next session — unauth-access or data-loss risk
🟠 HIGH Fix this week — exploitable under specific conditions
🟡 MEDIUM Fix this month — hardening gap, defense-in-depth
🔵 LOW / HYGIENE Track and clean opportunistically
✅ GOOD Already secure, noted for completeness

Executive summary

Overall posture: Solid foundation, weak host-level hardening. The application layer (Authelia SSO+MFA, Vaultwarden signups locked, Nextcloud + GitLab behind Traefik + LE certs, Cloudflare Tunnel for the single external surface) is well above homelab average. The exposure surface to the public internet is correctly limited to ONE hostname (cloud.iamkay.eu) via Cloudflare Tunnel. The weakness is on PVE host hardening and the unpatched PVE 8.1.5 running stale.

Top 5 fixes to prioritize:

  1. 🔴 PVE 8.1.5 needs to update to 8.3+ (5+ months of security patches missing)
  2. 🔴 SSH allows root password auth on PVE host + no fail2ban → brute-forceable if VLAN 10 ever leaks
  3. 🔴 No off-site backup → single-site failure (theft, fire, ransomware) destroys homelab
  4. 🟠 GitLab + Nextcloud admin users have no enforced 2FA (Kay personally has it; not enforced for future users)
  5. 🟠 PVE root has no 2FA in pveum

1. PVE host (arochukwu, 10.0.10.5)

1.1 🔴 CRITICAL — PVE 5+ months behind, kernel stale

Item Current Latest as of 2026-06-07
pve-manager 8.1.5 (Jan 2024) 8.3.x (May 2026)
kernel 6.5.13-3-pve 6.8.x-pve

Risk: Multiple CVEs in PVE 8.1 → 8.3 windows include LXC escape, container privilege escalation, web UI XSS. Currently exploitable only with PVE auth (PAM root), but reduces defense-in-depth.

Remediation: 

# On PVE host, before next maintenance window:
apt update
apt full-upgrade -y
# Read changelog before reboot
reboot
Time: 20-30 min including kernel reboot. Schedule during a low-use window (Sunday morning is fine).

1.2 🔴 CRITICAL — SSH root password auth + no fail2ban

PermitRootLogin yes
PasswordAuthentication (not explicitly set → defaults yes)
fail2ban NOT installed

Risk: If VLAN 10 ever leaks (compromised LXC, misconfigured switch, future Tailscale routing change), root SSH is brute-forceable. There's no rate limiting.

Remediation (do in this order on PVE host): 

# 1. Install fail2ban first (so even if SSH config has issues, you have backup protection)
apt install fail2ban
# Default jail.local for sshd is sane; enable + start:
systemctl enable --now fail2ban

# 2. Tighten SSH config — these lines in /etc/ssh/sshd_config:
PermitRootLogin prohibit-password    # only key auth as root
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
X11Forwarding no
MaxAuthTries 3

# 3. Before restarting sshd, ensure your key still works:
# Open a SECOND ssh session and keep it alive — if the new config locks you out,
# the second session can fix it. Then:
systemctl restart sshd
# Verify second session still works before closing first session.
Time: 10 min including verification. Keep a second SSH session alive during the change.

1.3 🔴 CRITICAL — pve-firewall disabled, no unattended-upgrades

pve-firewall status: disabled/running
unattended-upgrades: NOT configured

Risk: No host-level filtering of ingress to PVE; no automated patching.

Remediation: 

# 1. Enable unattended-upgrades for security patches only
apt install unattended-upgrades apt-listchanges
dpkg-reconfigure -plow unattended-upgrades
# Edit /etc/apt/apt.conf.d/50unattended-upgrades to include "Debian-Security" updates

# 2. pve-firewall — leave OFF until you write rules first;
# turning it ON with empty rules will work fine (defaults allow), but
# for actual hardening:
# /etc/pve/firewall/cluster.fw — enable + REJECT default IN
# /etc/pve/nodes/arochukwu/host.fw — allow VLAN 10 + VLAN 40
# Document rules before enabling. Deferred until you have time to test.

1.4 🟠 HIGH — rpcbind exposed on 0.0.0.0:111 (DDoS amplification vector)

PVE host doesn't run an NFS server. rpcbind is listening on all interfaces.

Remediation: 

# Bind rpcbind to localhost only via /etc/default/rpcbind:
echo 'OPTIONS="-w -h 127.0.0.1"' > /etc/default/rpcbind
systemctl restart rpcbind

1.5 🟠 HIGH — node_exporter on 0.0.0.0:9100 (system metrics exposed)

Prometheus exporter for PVE host metrics is listening on all interfaces. Exposes kernel version, hardware, mountpoints, etc. — useful for fingerprinting attackers.

Remediation: Bind to VLAN 10 only via --web.listen-address=10.0.10.5:9100 in /etc/default/prometheus-node-exporter, then restart.

1.6 🟠 HIGH — PVE root user has no 2FA

pveum user list shows root@pam, tfa-locked-until empty. PVE web UI accepts root login with only the PAM (Linux root) password. Even though you have a strong password, there's no second factor.

Remediation: Web UI → Datacenter → Permissions → Two Factor → Add for root@pam (TOTP). Use the same authenticator app that has your Authelia + Nextcloud entries.

1.7 🟡 MEDIUM — Stale apt sources file

pve-enterprise.list.dpkg-old exists — dangling old apt config file. Harmless but clutter.

Remediation: rm /etc/apt/sources.list.d/pve-enterprise.list.dpkg-old (after confirming nothing references it).

1.8 🟡 MEDIUM — RSA SSH key in authorized_keys

/root/.ssh/authorized_keys has 3 keys; one is ssh-rsa. ed25519 is preferred.

Remediation: Identify the ssh-rsa key (probably win11 comment), regenerate as ed25519, replace.

1.9 ✅ GOOD on PVE host

  • Only root@pam user (no leftover defaults)
  • /etc/pve/storage.cfg, datacenter.cfg, user.cfg have correct perms (-rw-r----- root:www-data)
  • chrony NTP active, system time accurate
  • Postfix bound to loopback only (127.0.0.1:25)
  • prometheus-node-exporter behind pve-firewall policy when enabled
  • PVE web UI requires authentication

2. iLO 3 (172.16.1.3)

(Limited probing — most checks require iLO console; reusing findings from reference_ilo3_v194_quirks.md)

2.1 🔴 CRITICAL — TLS 1.0 only (iLO 3 firmware ceiling)

iLO 3 v1.94 (final firmware, 2020-12-06) supports only TLS 1.0. Browsers, OpenSSL 3.0, Windows Schannel all reject it by default. Firefox requires manual about:config toggle.

Risk: Active MITM on VLAN 40 can downgrade and observe iLO admin sessions. Practical risk is low (VLAN 40 is restricted), but the protocol itself is broken.

Remediation: There is no fix — HP discontinued iLO 3 firmware support. Mitigation: ensure iLO is on isolated VLAN 40 (✓ done Session 7), require MGMT VPN to access iLO from outside, and treat any iLO web UI session as untrusted.

2.2 🟠 HIGH — DSA-1024 SSH key for iLO kay user

iLO 3 only accepts DSA keys (RSA paste fails). DSA-1024 is cryptographically weak by modern standards.

Risk: Theoretical key recovery via accumulated TLS observations. Practical risk: very low on isolated VLAN 40.

Remediation: Same as 2.1 — accept the firmware ceiling. Track for replacement at iLO swap (would require new hardware).

2.3 🟠 HIGH — IPMI/UDP 623 open on VLAN 40

IPMI-over-LAN was enabled in Session 3 for ipmitool access. Anyone on VLAN 40 (currently: laptop, iLO itself, PVE vmbr0.40) can attempt RMCP+ auth. Brute-force protected by iLO's own throttle, but the protocol family has had historical vulnerabilities.

Risk: If VLAN 40 ever has untrusted devices, iLO can be probed.

Remediation: Add pfSense rule: drop UDP/623 ingress from anything NOT in {laptop static IP, PVE 172.16.1.5}. Allow MGMT laptop + PVE only. Test ipmitool still works after rule.

2.4 ✅ GOOD on iLO

  • iLO Advanced license active
  • kay admin user, default Administrator slot renamed
  • FIPS Mode NOT enabled (per CLAUDE.md §0 rule — would wipe config)
  • iLO on isolated VLAN 40 since Session 7
  • pfSense blocks VLAN 10 → MGMT (Session 7)

3. Network & firewall

3.1 🟠 HIGH — pfSense rules not audited

Only pfSense itself can show the full rule table; I can't probe it from PVE. Recommendation: log into pfSense, export full rule set, review for: - WAN exposure (anything other than CF Tunnel egress?) - Default-deny on all LAN→WAN paths except whitelisted ports - Block bogons enabled - pfBlockerNG / IDS configured

3.2 ✅ GOOD — Cross-VLAN segregation enforced

  • VLAN 10 (SERVERS) → VLAN 40 (MGMT): blocked by pfSense rule (Session 7, verified six ways)
  • VLAN 10 → VLAN 1: blocked
  • VLAN 10 → internet: allowed (egress)
  • VLAN 40 ↔ VLAN 40 intra-VLAN: open (laptop ↔ iLO ↔ host vmbr0.40, no pfSense in path)

3.3 ✅ GOOD — Per-LXC port exposure mapped

Each LXC's listening ports identified — no surprises. All services on intended ports (e.g. Authelia 9091, Pi-hole 53+8081, Traefik 80+443).

3.4 ✅ GOOD — Cloudflare Tunnel egress is exclusively to Cloudflare-owned IPs

cloudflared talks only to 198.41.* (Cloudflare's Argo Tunnel IP block). No unexpected egress.

3.5 🟡 MEDIUM — Public DNS leaks domain structure

hm.iamkay.eu apex resolves publicly to Cloudflare IPs (no hostname configured on the tunnel for the apex, so requests would 1014). Reveals that hm.iamkay.eu is the internal domain. Minor info disclosure — attackers know your naming scheme. Not directly exploitable.

Remediation: Optional — use a different internal-only TLD (e.g. .lan or unregistered). Defer; reorganizing DNS naming is high-effort, low-impact.

4. TLS posture

4.1 ✅ GOOD — All certs valid LE, auto-renewing

13 hostnames covered by 2 certs (*.hm.iamkay.eu wildcard + cloud.iamkay.eu apex sibling). Expiries 2026-08-13 (cloud.iamkay.eu) and 2026-09-03 (wildcard). DNS-01 via Cloudflare token, auto-renews ~30 days before expiry.

4.2 ✅ GOOD — TLS 1.0 rejected at Traefik

openssl s_client -tls1 is rejected with protocol version alert. Minimum TLS 1.2 enforced (Traefik defaults).

4.3 ✅ GOOD — TLS 1.3 active on Cloudflare-fronted endpoint

cloud.iamkay.eu negotiates TLSv1.3 with TLS_AES_256_GCM_SHA384. Browser-trusted cert chain.

4.4 🟠 HIGH — vault.hm.iamkay.eu missing HSTS header

cloud.iamkay.eu      HSTS: max-age=15552000; includeSubDomains ✓
cloud.hm.iamkay.eu   HSTS: max-age=15552000; includeSubDomains ✓
vault.hm.iamkay.eu   HSTS: NOT SET ✗

Risk: Initial HTTPS connection vulnerable to TLS-stripping if attacker has on-path access. For Vaultwarden — your password vault — HSTS is essential.

Remediation: Add HSTS middleware to Traefik's vault.yml dynamic config. Same pattern as Nextcloud's nextcloud-headers. Will set on next session.

4.5 🟡 MEDIUM — Other internal services may also lack HSTS

Same audit could apply to traefik dashboard, grafana, kuma, gitlab, pbs, homenas, dns, home, arochukwu, pi-hole admin. Most rely on Authelia gating which mitigates but doesn't fix HSTS specifically.

Remediation: Create a global Traefik middleware security-headers@file with HSTS + standard security headers, attach to every router. One-time write of ~20 lines.

5. Application services

5.1 ✅ GOOD — Vaultwarden (LXC 252)

  • ✅ Signups disabled (signups_allowed: false)
  • ✅ Invitations disabled
  • ✅ Admin token argon2id-hashed (m=65536, t=3, p=4)
  • ✅ Domain config matches Traefik route
  • ✅ Daily PBS backup of /opt/vaultwarden/data/

5.2 🟠 HIGH — Vaultwarden emergency access enabled

emergency_access_allowed: true — feature lets designated contacts request access to your vault after a delay (in case of incapacitation). Without contacts configured, the setting is moot. Worth disabling if not using.

Remediation: Vaultwarden admin panel (vault.hm.iamkay.eu/admin) → Settings → Domain → toggle off emergency_access_allowed (unless setting up an emergency contact).

5.3 🟡 MEDIUM — Vaultwarden require_device_email: false

Anyone with valid credentials can log in from a new device without email verification of the new device. Slightly weakens device-binding.

Remediation: Enable require_device_email in admin panel — but requires SMTP first. Defer until family-cloud SMTP setup.

5.4 ✅ GOOD — Authelia (LXC 254)

  • ✅ Default policy deny
  • ✅ Regulation: 3 retries / 2 min find / 5 min ban — production-tight
  • ✅ Session: 5 min inactive / 1 h max / 1 month remember
  • ✅ TOTP enforced for protected routes
  • ✅ Argon2id password hashing
  • ✅ File-based user DB (small N — appropriate for 1-5 users)
  • 🟡 SMTP deferred — bypasses email verification today

5.5 🟠 HIGH — Nextcloud 2FA not enforced for any group

occ twofactorauth:enforce returns "Two-factor authentication is not enforced". Kay personally enabled TOTP tonight, but it's not required.

Risk: When family users are added, they'll skip 2FA by default. Family-cloud security depends on every user having MFA.

Remediation: Once family users are onboarded: 

pct exec 258 -- docker exec -u www-data nextcloud-app php occ twofactorauth:enforce --on --group=admin --group=family

5.6 ✅ GOOD — Nextcloud baseline

  • ✅ overwriteprotocol: https
  • ✅ trusted_proxies set to 10.0.10.10/32 (Traefik)
  • ✅ Brute-force protection enabled (Nextcloud default)
  • ✅ App passwords required for sync clients
  • ✅ External Storage configured for NFS — keeps data off LXC rootfs
  • ✅ Not behind Authelia (correct — sync clients break with ForwardAuth)

5.7 ✅ GOOD — GitLab (LXC 257)

  • ✅ Signup disabled (signup_enabled: false)
  • ✅ Only 2 users (admin root + kay)
  • ✅ Password auth for web UI enabled (with PAT for API)

5.8 🟠 HIGH — GitLab 2FA not required

require_two_factor_authentication: false. Same risk pattern as Nextcloud — admin actions don't require second factor.

Remediation: GitLab Admin → Settings → General → Sign-in restrictions → enable "Two-factor authentication" for "All users" (after kay enrolls his own TOTP). Allow grace period (e.g. 1 day). Apply.

5.9 ✅ GOOD — Pi-hole (LXC 253)

  • ✅ DNSSEC validation enabled
  • ✅ Admin UI behind Authelia (verified middleware in pihole.yml)
  • ✅ Adlist active (StevenBlack, 83,600 domains)
  • ✅ Only DNS port 53 exposed to VLAN 10

5.10 🟡 MEDIUM — cloudflared tunnel token in Docker env

LXC 259's docker inspect shows TUNNEL_TOKEN=eyJh... in container Config.Env. Anyone with root on LXC 259 can read it. Acceptable for the threat model (root on LXC 259 = total compromise anyway), but Docker secret file mount would be hygiene-better.

Remediation: Optional — mount as /run/secrets/cf-tunnel-token via docker-compose secrets: section instead of env. ~5 min change.

5.11 ✅ GOOD — PBS (VM 200) and OMV (VM 189)

  • ✅ PBS web requires auth (returned authentication failed to unauth probe)
  • ✅ OMV SSH requires public key (denied unauth probe)
  • ✅ Both run on isolated VLAN 10
  • ✅ Daily PBS backup job verified (created Session 9)

6. Secrets & credentials posture

6.1 🟠 HIGH — 11 on-disk credential files still in /root/*-build/

(Already flagged in tonight's session.) Tomorrow's cleanup: 

/root/authelia-build/lxc-254-root.password
/root/gitlab-build/gitlab-root.password
/root/gitlab-build/lxc-257-root.password
/root/monitoring-build/grafana-admin.password
/root/monitoring-build/lxc-256-root.password
/root/pihole-build/lxc-253-root.password
/root/tailscale-build/lxc-255-root.password
/root/traefik-build/cloudflare.token
/root/traefik-build/lxc-251-root.password
/root/traefik-build/traefik-dashboard.password
/root/vaultwarden-build/lxc-252-root.password

Risk: Anyone with root on PVE can read these. Currently low risk (only root has the PVE box), but defense-in-depth would be to vault and delete.

Remediation: Verify each is in Vaultwarden, then rm all 11. Tracker entry already in TODO.

6.2 🟠 HIGH — iPhone CalDAV app password not vaulted

The 72-char app password generated via occ user:add-app-password kay was shown in chat but not saved to Vaultwarden as a separate entry. If you ever need to revoke or rotate it, you'll need the original to find which session it backs.

Remediation: Save now as "Nextcloud - iPhone CalDAV app password" in Vaultwarden.

6.3 🟡 MEDIUM — Cloudflare API token has zone-edit scope on the apex

/etc/traefik/cloudflare.token has DNS edit permissions on iamkay.eu. If LXC 251 is compromised, attacker can edit DNS for the entire zone (e.g. point cloud.iamkay.eu at their own server to phish credentials).

Remediation: Cloudflare token can be scoped narrower. Today's scope is broader than necessary. Future cleanup: rotate token with only Zone:DNS:Edit for iamkay.eu + Zone:Zone:Read. Already at this level; verify periodically.

6.4 ✅ GOOD — secrets isolation

  • Vaultwarden admin token: argon2id-hashed in config.json
  • Authelia user password: argon2id-hashed in users_database.yml
  • LXC root passwords: random 32-char base64
  • PostgreSQL password: in .env mode 600, root-only readable
  • Cloudflare API token: 0600 traefik:traefik

7. Backup posture

7.1 🔴 CRITICAL — No off-site backup

Path D family-cloud data is now LIVE. PBS backs up daily to apple-tank datastore on the same physical machine. Single failure (fire, theft, ransomware encrypting the host) destroys both production and backup.

Remediation: Implement Cloudflare R2 or Backblaze B2 cold-storage sync. Already deferred in architecture decisions ("decision deferred to before D.1 ships data" — D.1 just shipped, decision is overdue). Pick one and configure within 1 week: - Cloudflare R2: $0.015/GB/mo storage, free egress to anywhere, S3-compatible - Backblaze B2: $0.006/GB/mo, $0.01/GB egress, simpler

For ~50 GB of family data: ~$0.30-$0.75/mo. Worth it.

7.2 ✅ GOOD — Daily PBS job configured + restore drill passed

  • Schedule 02:00 daily
  • All VMs except 200 (PBS itself) backed up
  • GFS retention: 3 last + 7 daily + 4 weekly + 12 monthly + 2 yearly
  • Restore drill Session 8 succeeded (filesystem inspection)

7.3 🟡 MEDIUM — PBS restore drill caveat unresolved

Session 8 noted PBS web UI hung during restore validation; SSH to PBS started rejecting connections. Workaround: chunk-handler resource tuning on PBS VM. Not blocking — backups + restore both work, just the UI bounce is annoying.

Remediation: Bump PBS VM memory 4 GB → 6 GB; tune chunk-handler concurrency.

7.4 🟡 MEDIUM — apple-tank is removable datastore

When the Apple HDD is unplugged (intentional or by accident), PBS reports the datastore offline. Cron job for backups will fail silently unless email alerts are configured.

Remediation: Configure PBS notification email (already pointed at [email protected] in the job's mailto). Verify email arrives when next backup fails (test by unplugging dock).

8. Update / patch posture

8.1 🔴 CRITICAL — PVE 8.1.5 stale (covered in §1.1)

8.2 🟠 HIGH — Container images may be stale

  • nextcloud:fpm-alpine — was pulled with :latest tag, current 33.0.5.1, may have minor updates
  • vaultwarden/server:latest — 1.36.0
  • pihole/pihole:latest — 6.6.2
  • gitlab/gitlab-ce:latest — 18.x current

:latest tag means next docker-compose pull && up -d brings updates. Untracked when updates land.

Remediation: Set Watchtower or Renovate for container update notifications. For now, monthly manual: cd /opt/<service> && docker-compose pull && docker-compose up -d. Set a reminder.

8.3 🟠 HIGH — P410i firmware 3.66 still pre-update

Blocks BBWC enable (write-through mode active). SPP G7.1.3 + 2017.10.1 ISOs staged at /var/lib/vz/template/iso/. Flash deferred to second chassis-open. Until then: write-back disabled, data integrity not at risk but write performance suboptimal.

Remediation: Already on the queue per CLAUDE.md Section 11 #19. Bundle into next chassis-open (~July with HBA install).

8.4 🟡 MEDIUM — BIOS P67 (2011) on G7 with stale microcode

Spectre/Meltdown microcode missing. Modern kernel mitigations cover most cases.

Remediation: Bundle with the SPP G7.1.3 flash at next chassis-open. Lower priority than firmware.

9. Identity inventory

9.1 Account count per service

Service Admin Users Notes
PVE web root@pam (1) 0 No 2FA
iLO kay (1) 0 Password + DSA key auth
Vaultwarden kay (1) via auth 0 family yet Admin token argon2id
Authelia kay (1) 0 family yet TOTP enrolled
Nextcloud kay admin (1) 0 family yet TOTP enabled (you)
GitLab root, kay (2) 0 Neither has 2FA enforced
Pi-hole admin shared admin password — Behind Authelia
PBS shared admin — Default + auth
OMV root + SMB users — SSH key only
Tailscale captkay.github (1) + Kay's iPhone + laptop already on tailnet

9.2 🟡 MEDIUM — GitLab has a root user separate from kay

GitLab's default root admin account is still present (with the random password from build). When you add family/team members, the gitlab root is an unused attack surface.

Remediation: Either disable gitlab root after promoting kay to admin role, OR keep root for emergency-access and lock with strong + unique password (already random, fine).

10. Operational hygiene

10.1 🟡 MEDIUM — Empty stub dirs on tanks (deferred per CLAUDE.md §0)

r-tank/mac-store/, r-tank/proxmox/vms/, s-tank/proxmox/ct-k8s-datastore/, /windows-store/, /R-tank/, s-tank/recovery/ — cleanup pending per-target confirmation. Not a security issue, cosmetic.

10.2 ✅ GOOD — Audit trail is preserved

  • /root/cleanup-20260606-*.log — OMV cleanup forensic
  • /root/config.xml.backup-pre-cleanup-* — OMV config pre-cleanup
  • /etc/network/interfaces.backup-* — multiple network backups
  • PVE web UI task log — all admin actions logged
  • Authelia auth log retained in SQLite

10.3 🟡 MEDIUM — No SIEM / centralized auth log analysis

Authelia, Nextcloud, GitLab, PVE, OMV all log auth events to local files. Loki ships container logs (Session 9), but auth log analysis isn't automated. A brute-force across multiple services wouldn't be detected today.

Remediation: Phase 3.5 monitoring stack already has Loki. Build Grafana dashboard with auth-event queries across services. Add Uptime Kuma alert on >N auth failures per minute. Defer until you want to spend an evening on it.

11. Cloudflare external surface

11.1 ✅ GOOD — Single external endpoint (cloud.iamkay.eu)

Only cloud.iamkay.eu exposed via Cloudflare Tunnel. Cloudflare provides: - TLS 1.3 edge termination ✓ - HTTP/2 + HTTP/3 ✓ - DDoS protection at edge ✓ - Bot detection (default ON) ✓ - Universal SSL cert ✓ (separate from your LE cert which is for origin) - Country firewall (configurable, not currently restrictive) — see 11.2

11.2 🟡 MEDIUM — No geo / Access policy on cloud.iamkay.eu

Nextcloud is accessible from any country, any IP. Family-cloud users are 3-5 people, mostly NL — could whitelist EU only or set up Cloudflare Access for authenticated-tunnel-only access for admin endpoints.

Remediation: - For end-users (family): leave open — they may travel - For admin endpoints (if exposed externally later — they aren't today): use Cloudflare Access policies (email-based MFA + device cert) instead of direct exposure - Add Cloudflare WAF rules for known attack patterns (free tier includes managed rulesets)

11.3 ✅ GOOD — DNS attack surface

Only cloud.iamkay.eu has a public DNS record (proxied through Cloudflare). All *.hm.iamkay.eu are internal only (resolved by Pi-hole). No DNS leak of internal hostnames.

12. Priority action list

🔴 This weekend (before next session)

  1. PVE 8.1.5 → 8.3 upgrade + reboot (~30 min including reboot)
  2. SSH hardening on PVE host (key-only, fail2ban, MaxAuthTries) (~15 min)
  3. Off-site backup decision (R2 vs B2) + config (~1 hour to spin up R2/B2 + sync job for apple-tank weekly)
  4. Enable PVE root 2FA (~3 min — web UI toggle + scan QR)
  5. Vault iPhone CalDAV app password (~2 min — copy/paste into Vaultwarden)

🟠 This week

  1. Enforce 2FA in Nextcloud + GitLab for all admin users
  2. Add HSTS middleware to Traefik (global security-headers@file, attach to all routers)
  3. Disable Vaultwarden emergency access if not used
  4. Bind rpcbind + node_exporter to specific IPs
  5. Lock down IPMI/623 via pfSense rule (only laptop + PVE)
  6. Verify the 11 leftover credential files are in Vaultwarden, then nuke them

🟡 This month

  1. Enable pve-firewall with rules (after writing them carefully)
  2. Configure unattended-upgrades on PVE + each LXC
  3. Watchtower or monthly manual container update pass
  4. SIEM: Grafana dashboard with Loki-driven auth-event queries
  5. PVE root SSH key audit — replace RSA with ed25519
  6. PBS chunk-handler tuning
  7. Cloudflare WAF managed rules + geo policy review
  8. Stale apt files cleanup

🔵 Hygiene (opportunistic)

  1. Empty stub dir cleanup on tanks (when chassis-open or new build)
  2. Rotate Pi-hole admin password annually
  3. Cloudflare API token rotation cadence (every 6 months)
  4. Bring Vaultwarden + Authelia + Nextcloud client-app passwords into a rotation cadence

13. Summary scoreboard

Category Score Trend
External exposure A Excellent — single endpoint, TLS 1.3, no port forwards
Application-layer auth B+ Authelia SSO+MFA solid, but app-level 2FA not enforced
TLS posture A- LE wildcards renewing; missing HSTS on vault
Network segmentation A- VLANs working; pfSense rules need audit
Host hardening (PVE) C- Stale, no fail2ban, no 2FA
iLO posture D TLS 1.0 only, DSA keys, firmware ceiling — accept and isolate
Backup posture C Daily local works, no off-site (urgent)
Patch posture C- 5+ months behind
Secrets management B+ Vaultwarden + hashed; 11 stash files to clean
Identity inventory B Few accounts, but 2FA not enforced where it should be

Overall: B- — solid where you've focused (application layer, external surface), gaps where time hasn't been spent yet (host hardening, off-site backup, patches). Top 5 list at §12 closes the worst gaps in ~3 hours of focused work.

End of audit. Findings actionable; remediations have concrete commands. Off-site backup is the single most impactful next move — once Path D family data is real (it is, as of tonight), the data needs an off-site copy that survives single-site failure.