NodeZero v2.0 is a LAN-only server. The assumed adversary is not an internet attacker (there is no inbound exposure: no port forwarding, no VPN, no tunnel) but:
- A compromised or untrusted device on the home LAN.
- Malicious content fetched by the server itself (media automation pipelines pulling from indexers).
- Physical access to the machine or theft of the HDD.
| Layer | Control |
|---|---|
| Network | LAN-only. No inbound router forwarding. DNS filtered through Pi-hole; recursive resolution via Unbound with DNSSEC validation (verified against dnssec-failed.org). |
| Transport | Internal TLS for all web UIs via Caddy with a self-hosted root CA; admin APIs bound to container network, not the host (Caddy admin :2019 is deliberately not published). |
| Authentication | SSH public-key only by default, plus optional YubiKey FIDO2 (ed25519-sk) key — the private key never leaves the hardware token. Password authentication available as a fallback method, each method standing alone (any one factor grants access). |
| Storage | HDD is ext4 (Linux permission model enforced on bind mounts; v1's exFAT plan was rejected for this reason). |
| Services | qBittorrent and the ARR stack isolated on a dedicated Docker bridge network; Pi-hole admin separated onto port 8083 to avoid collision with Traccar on 8082. |
| Host | Minimal Ubuntu Server install; smartmontools monitors both drives. |
These are accepted trade-offs, documented so a reviewer knows the operator knows:
- No backups, by decision. Media is re-acquirable; configs are reconstructible from this repo. The risk is accepted, not missed.
- Self-signed internal CA. Trust is bootstrapped by manually installing
root.crton each client. Anyone with LAN access could in theory present their own CA; mitigated by the LAN-only threat model. - Password SSH fallback coexists with key-only auth; it exists for recovery convenience and is the weakest link.
- No host firewall (UFW disabled). v1 applied UFW; stale nftables rules caused real outages and were removed with the VPN stack. On a trusted LAN this is accepted; if the threat model changes (untrusted devices, IoT VLAN), re-enabling UFW is the first control to restore.
- Internal DNS is unencrypted UDP between Pi-hole and Unbound — fine on one host, noted for completeness.
This is a personal homelab, not a product. If you spot something genuinely wrong in the public documentation (e.g. an accidentally committed secret), open an issue or contact the author privately.