📖 Chapter 03 — Security Hardening

The layers that protect against attackers. Defense in depth.

Learning Objectives

• Apply the principle of defense in depth to the home NAS
• Harden the network layer (firewall, port forwarding, Tailscale)
• Harden the OS layer (TrueNAS configuration, SSH keys)
• Harden the app layer (Vaultwarden, MFA, app-level auth)
• Harden the credential layer (passwords, MFA, audit)

Introduction

Security is not a switch; it's a gradient. The home NAS with no security is at one end; the home NAS with every hardening measure is at the other. The right place to be is somewhere in the middle: the practical security that protects against realistic threats without consuming your life.

This chapter covers the layers: the network, the OS, the apps, the credentials, the monitoring. Each layer adds protection; no single layer is enough. Defense in depth.

The threat model

Before you can protect against attackers, you need to know who they are and what they want. The threat model for a home NAS:

• Automated scanners. Bots that scan the internet for open ports, default credentials, known vulnerabilities. They find exposed services within hours of being online.
• Targeted attackers. Someone who specifically wants your data (a stalker, a former partner, a competitor). Less common but more dangerous.
• Insider threats. People who already have access (a family member, a guest) and abuse it.
• Opportunistic attacks. Someone who finds an open port or a weak password and exploits it.

For most home users, the realistic threat is the first and fourth. The defenses below are designed to defeat them. The targeted attacker is harder to defend against but also less common.

Defense in depth

Defense in depth means: no single layer is the only defense. If one layer fails, the next layer catches. For the home NAS, the layers are:

1. Network: don't expose services to the internet. Use Tailscale for remote access.
2. Firewall: block everything by default, allow only what's needed.
3. OS: keep the OS updated, use SSH keys not passwords, disable unnecessary services.
4. Apps: use strong authentication, MFA where possible, follow security advisories.
5. Credentials: unique passwords for every service, a password manager, MFA on critical accounts.
6. Monitoring: know when something is wrong, alert on suspicious activity.
7. Backups: even if the attacker gets in, the data is recoverable.

Each layer is a partial defense. Together, they make the system robust against realistic threats.

Network layer

The most important security measure: don't expose services to the public internet. From Volume 1, Chapter 8: Tailscale is the right way to access the NAS remotely. The NAS doesn't need to be reachable from the open internet.

Specifically:

• No port forwarding on the router. None. SMB, SSH, web UIs — none of them should be reachable from the internet.
• No UPnP on the router. UPnP lets devices open ports without your permission.
• No public DNS records pointing to the NAS. The NAS is reachable only by its local IP and (if used) its Tailscale IP.

If a service needs to be public (a public website, a service for a non-technical friend), use Cloudflare Tunnel or Cloudflare Access, which put Cloudflare between the public internet and your NAS.

Firewall

TrueNAS Scale has a built-in firewall. Configure it:

• Default policy: deny all incoming traffic.
• Allow rules: only the services that need to be reachable from the LAN (SMB, web UIs on specific ports, Tailscale).
• No rules for the public internet. All public access is via Tailscale (which is encrypted and authenticated).

The firewall is a safety net: if a service accidentally opens a public port, the firewall blocks the traffic.

OS layer

For TrueNAS:

• Keep updated. TrueNAS updates are tested; apply them within a month of release.
• SSH keys, not passwords. Disable password-based SSH login. Use SSH keys with a passphrase. (Volume 1, Chapter 6 has the details.)
• Disable services you don't use. FTP, Telnet, NFS for SMB-only setups. If you don't need it, turn it off.
• Use the admin user sparingly. Create a separate user for day-to-day admin work. Reserve the root account for true emergencies.

For Linux VMs and containers:

• Keep updated. apt upgrade weekly.
• Disable root SSH. Use sudo from a regular user.
• Use SSH keys, not passwords.

App layer

For each app, the security basics:

• Strong passwords. Use the password manager. No "admin/admin." No "P@ssw0rd." Random characters, stored in Vaultwarden.
• MFA where possible. Vaultwarden, Nextcloud, the TrueNAS UI: enable TOTP MFA. Immich, Jellyfin, Paperless: enable MFA if they support it.
• Updates. Apply app updates within a month of release. Read the release notes for security fixes.
• Disable default accounts. The "admin" user in many apps has a default password. Change it on first login. Disable the account if you don't need it.
• Audit the users. Every user with admin access is a potential compromise. Audit the list monthly. Remove access that's no longer needed.

The password manager

The single most important security tool: a password manager. The family uses Vaultwarden (from Volume 1, Chapter 8 and Volume 2, Chapter 6). For the home lab, use Vaultwarden for everything:

• Every service has a unique, randomly generated password.
• The passwords are stored in Vaultwarden; you don't need to remember them.
• MFA is configured for every service that supports it, with the TOTP secret in Vaultwarden (or a separate authenticator app).

Never reuse passwords. If one service is compromised, the attacker doesn't get access to anything else.

MFA: multi-factor authentication

MFA adds a second factor to login: something you know (password) and something you have (phone, hardware key). For critical services, MFA is non-negotiable:

• TrueNAS UI: enable TOTP MFA.
• Vaultwarden: enable TOTP MFA (yes, your password manager needs MFA too).
• Tailscale: enable TOTP MFA.
• Cloudflare: enable TOTP MFA + hardware key if possible.

For other services, enable MFA when available. The friction is real (a few seconds per login); the protection is significant.

The "what if MFA fails" backup

MFA has a downside: if you lose the device, you can't log in. The mitigations:

• Backup codes: most services give you one-time backup codes when you enable MFA. Save these in Vaultwarden (or a separate secure location). They let you log in if you lose your MFA device.
• Multiple devices: configure MFA on your phone AND a tablet (or a spouse's phone). Either can be used to log in.
• Hardware key: a YubiKey or similar. The key is the second factor; if you lose it, you have a backup.

For the TrueNAS admin account, store a backup of the TOTP seed in a secure location (a sealed envelope in a safe, a separate password manager). The cost of being locked out is high.

The "audit trail" pattern

For critical systems, enable audit logging:

• TrueNAS audit log: every login, every share access, every file change.
• App audit logs: where available, configure the app to log user actions.

When something goes wrong ("someone deleted a file they shouldn't have"), the audit log answers the question: who, when, what.

The "incident response" plan

For when the worst happens (a compromised account, a ransomware attack, a stolen device), have a plan:

1. Detect: the monitoring alert fires.
2. Contain: disable the compromised account, change passwords, revoke API tokens.
3. Eradicate: identify the root cause. How did the attacker get in?
4. Recover: restore from backup if needed. Re-enable the affected service.
5. Post-mortem: document what happened, what worked, what didn't, what to change.

The plan is in the runbook (Chapter 7). The discipline: know what to do before the incident. The day of the incident is not the day to figure it out.

What NOT to do

• Don't expose services to the public internet "just for now." "Just for now" becomes "for years." Set up Tailscale, set up Cloudflare Tunnel, do it right.
• Don't use default passwords. "admin/admin" is the first thing an attacker tries.
• Don't share admin credentials. Each person has their own account, with their own permissions.
• Don't trust "security through obscurity." A non-standard port doesn't make a service secure; it just slows down an automated scanner. The protection has to be real (MFA, encryption, Tailscale).

Engineering Note

Summary

Defense in depth: network, firewall, OS, apps, credentials, monitoring, backups. Don't expose services to the public internet (Tailscale or Cloudflare Tunnel). Use SSH keys, MFA, and a password manager. Enable audit logging. Have an incident response plan. Review quarterly. Security is a habit, not a project. The 30 minutes a quarter keeps the system secure over years.

Checklist

• ⬜ Verify no public port forwarding on the router (except Cloudflare Tunnel if used)
• ⬜ Verify the TrueNAS firewall is enabled with deny-by-default
• ⬜ Disable password-based SSH; use SSH keys
• ⬜ Enable MFA on TrueNAS, Vaultwarden, Tailscale, and Cloudflare
• ⬜ Use Vaultwarden for all passwords; never reuse
• ⬜ Enable audit logging on TrueNAS and critical apps
• ⬜ Write an incident response plan in the runbook
• ⬜ Quarterly: review security posture, audit users, check firewall

Looking Ahead

Chapter 04 is capacity planning. Predicting when you'll need more space, more performance, more RAM. The math, the signs, the timing. The chapter that turns "I'm out of space" from a surprise into a planned upgrade.

Ch 03 · v0.1 · drafted from the original ChatGPT conversation, July 2026