Security & Hardening

Security is a posture, not a feature. The work here splits into three categories: things the project removed because they were doing something we did not want; things the project added or restructured to reduce attack surface; and things the operator still needs to do because no software can do them on their behalf.

---

What was removed

RealNAS inherits a code base that historically called out to several third-party services. Those calls have been removed, not merely disabled. There is no compile-time flag, no environment variable, and no UI toggle that re-enables them.

Crash and error reporting

The third-party crash-reporting client has been excised. Tracebacks remain visible in local logs where the operator can read them; they are not transmitted off the host.

Anonymous usage statistics

The periodic POST of pool layouts, feature usage, and hardware information to a vendor-controlled endpoint has been removed. The endpoint was previously reachable from any installed system; now nothing reaches it.

Proactive support form

The “send diagnostic information” flow has been removed from the UI and from the middleware. There is no inbox to send diagnostic information to.

Commercial-support registration

The forms and endpoints that registered an appliance with a commercial support relationship have been removed.

Vendor-tied update train

Updates flow through freebsd-update and pkg instead of a signed image manifest pinned to a single vendor’s release pipeline.

What was changed

Offline package installation by default

RealNAS packages bundle their Python dependencies as a wheelhouse rather than expecting the installation host to reach PyPI. The installer can be run on a host with no outbound network access at all.

State ownership enforcement

The middleware’s ability to write outside its declared directories is audited at the source level. Code that previously poked /etc, /usr/local/etc, or /boot directly has been refactored to use templated includes or to go through a single etc.generate path that is reviewed for safety.

Drop-in configuration files

SMB and NFS configuration is emitted to include files, leaving the base configuration files editable by the operator. This is both a usability change and a security change: it makes it auditable what RealNAS has written.

Reduced default service surface

The set of services started on a fresh install is small: the middleware, the proxy, sshd, syslogd, and what the operator enables. Plugins, jails, and remote management surfaces are off by default.

Authentication is local by default

There is no implicit external authentication source. Joining the system to AD or LDAP is a deliberate, documented step the operator chooses to take.

What is on the roadmap

These are not done yet. They are work the project considers worth doing.

• Signed pkg repository. A dedicated, signed mirror for RealNAS-built packages so the integrity of an upgrade is verifiable end to end with pkg’s native signature mechanism.
• Capsicum sandboxing for daemons. Where a subsystem does a small, well-defined set of operations, sandbox the worker process under Capsicum so the blast radius of a parse bug is contained.
• Per-subsystem jails. Optional, opt-in, off by default: run Samba, NFS, or the proxy inside a FreeBSD jail with its own resource limits. Useful on hosts that are doing more than one thing.
• Auditd-style event log. A first-class audit trail that records configuration changes and authentication events to local storage with a documented format.
• Secret material at rest. Move any persisted secret material (SMTP credentials, replication SSH keys, etc.) into a single keyfile with an explicit unlock mechanism.

---

What the operator still has to do

The hardening below is the operator’s job. No software can do it for them, because the choices are environment-specific.

Restrict shell access

Disable password SSH and require keys. sysrc sshd_enable=YES, then edit /etc/ssh/sshd_config to set PasswordAuthentication no and PermitRootLogin prohibit-password. Add your administrative key to ~/.ssh/authorized_keys first, of course.

Encrypt sensitive datasets

Native ZFS encryption is available. Use it on datasets that hold material you would not want to read off the drives if they walked out: financial records, household documents, anything subject to regulation. Pick a passphrase that you can recover; keep it somewhere not on the array.

Segment management from data

The webui and SSH should not be reachable from the same network as your guest Wi-Fi. Bind the proxy to a management interface; bind SMB/NFS to the data interface; let the firewall enforce the separation.

Take boot environments before changes

Before any update, take a boot environment: bectl create pre-update-$(date +%Y%m%d). If the change goes wrong, reboot, choose the previous environment from the loader, and the system comes up exactly as it was. This is FreeBSD’s built-in rollback mechanism and it is robust.

Monitor what the system tells you

RealNAS writes alerts to local syslog and (if configured) to email. Read them. /var/log/messages is the first place to look when something seems off. Configure an offsite log target if you want durability beyond the host.

Maintain backups that survive the host

Snapshots are not backups. A snapshot lives on the same pool as the data it protects; if the pool is lost, the snapshots are lost with it. Replicate snapshots to a second pool, ideally in a second physical location. zfs send | ssh remote zfs receive is the canonical mechanism.