Learn NAS - Vulnerability & Patch Management

#Introduction

A secure NAS isn't one that's configured once and forgotten. Episode 15 covers vulnerability and patch management: how to track CVEs, keep the system updated, and continuously reduce the attack surface.

Samba, OpenSSH, and supporting libraries are the most commonly targeted components. New CVEs appear every week, and an unpatched NAS is an easy target. Routine update habits and periodic audits are the difference between a healthy NAS and an infected one.

By the end of this episode you'll be able to monitor CVEs, run routine updates safely, isolate apps and services, run services as non-root, minimize the attack surface, and perform basic security audits.

#CVE Awareness

#Tracking CVEs for NAS Components

CVE (Common Vulnerabilities and Exposures) is the public vulnerability database. For a NAS, the components to monitor include Samba, OpenSSH, the kernel, and related libraries. Information sources: official project sites, mailing lists, and security feeds.

samba --version
sshd -V
uname -r

The commands above show the Samba, OpenSSH, and kernel versions. Note these versions and compare them with the latest security advisories to determine whether a patch is needed.

#Samba and SMB Vulnerabilities

Samba has a history of serious CVEs, including ones enabling remote code execution and privilege escalation. Every Samba CVE usually ships a fix in the latest minor release. The key: always run a supported version and upgrade promptly when an advisory is released.

curl -s https://www.samba.org/samba/security/ | grep -i "CVE" | head

The curl command fetches the Samba security advisory page. Getting into the habit of checking official sources is far more accurate than relying on rumors.

#Routine Update Habits

#A Regular Update Schedule

Updating is a habit, not an event. Set a schedule: for example, weekly for security patches and monthly for major updates. On TrueNAS SCALE, system updates can be scheduled and leverage boot environments, making rollbacks safe.

apt update
apt upgrade
apt autoremove

The apt update and apt upgrade commands keep the Debian base up to date, and apt autoremove cleans up packages that are no longer needed.

#Updating with Boot Environments

TrueNAS SCALE uses boot environments: before an update, the system snapshots the boot environment. If an update goes wrong, boot into the previous environment within seconds.

beadm list

The beadm list command lists the boot environments. Having an older environment is a safety net that makes updates much more confident.

#Isolating Apps and Services

#Apps in Isolation

Additional applications should run in isolation — containers or jails — so that a vulnerability in one app doesn't immediately grant access to the main system. TrueNAS SCALE runs apps in containers; OpenMediaVault uses Docker through a plugin.

docker ps

The docker ps output shows active containers. Make sure each container is pulled from a trusted source and its image versions are kept current.

#Restricting Container Access

Containers should only access the datasets they actually need, not the entire pool. When creating an app, mount only the specific datasets and avoid access to system directories.

#Non-Root Services

#Running Services as a Dedicated User

Every service should run with a non-privileged user. If a service is compromised, the attacker doesn't immediately get root access. This is standard practice for databases, web servers, and container applications.

sudo -u nas-app /usr/local/bin/nas-app

The sudo -u nas-app command runs a process as the nas-app user. In containers, set user on the image or compose for the same purpose.

services:
  app:
    image: example/app:1.0
    user: "1000:1000"

The manifest above runs the container with UID 1000 instead of root. The user: "1000:1000" pattern is a must-consider for every container you deploy.

#Minimizing the Attack Surface

#Reducing Running Services

The fewer ports and services that are open, the smaller the attack surface. Turn off unused services: plain FTP, telnet, or old protocols. Every active service must have a reason to exist.

ss -tlnp

The ss -tlnp command lists all listening ports. Compare them with the list of services you actually need, then shut down the rest.

#Supporting Principles

• Change the SSH port? Not required; what's required is strong keys and a firewall.
• Disable unused accounts.
• Enable a strong password policy.
• Restrict SSH access to keys only, not passwords.

#Periodic Security Audits

#Performing a Basic Audit

Security audits don't have to be expensive. A few simple steps done routinely:

zpool status
ss -tlnp
last -n 20
journalctl -u ssh -n 20 --no-pager

The last command shows login history, and journalctl -u ssh shows SSH logs. Both are starting points for detecting suspicious access.

#Creating an Audit Checklist

Schedule periodic audits (for example, monthly) with a checklist: updates have run, open ports match the list, no strange logins, backups succeeded, and certificates aren't expired. This checklist is a practice that will be strengthened in episodes 16 and 22.

#Closing

In this episode 15 you built continuous security: monitoring CVEs for Samba and OpenSSH, running routine updates with boot environments, isolating apps and containers, running non-root services, minimizing the attack surface, and performing periodic audits.

Key takeaways:

• Monitor CVEs for critical components and patch promptly.
• Set an update schedule; boot environments make it safe.
• Isolate apps in containers with minimal data access.
• Run services as non-root.
• Audit periodically: ports, logins, logs, and backup status.

In the next episode, episode 16, we'll cover monitoring and health checks — from SMART monitoring, scrub and ZFS status, email alerts, to TrueNAS Reporting, TrueCommand, OMV monitoring, Prometheus with node_exporter, and automatic shutdown via a UPS with NUT. The system is healthy now; it's time to keep it healthy.