Learn NAS - Access Control & Firewall

#Introduction

A NAS holds the most valuable data on your network, and it has to be reachable through network protocols. Episode 13 covers access control and firewalls: how to restrict who can reach the management UI, how to filter traffic with subnet whitelists, and how to prevent the NAS from being exposed to the public internet.

Many NAS security incidents happen not because of sophisticated attacks, but because the management UI or SMB was left open to the public. The basic principle is simple: only services that genuinely must be visible may be open, and only to the networks that should see them.

By the end of this episode you'll be able to restrict the management UI, configure a whitelist-based firewall, check for public exposure, apply correct SMB and NFS ACLs, and apply least privilege across all layers.

#Restricting Management UI Access

#Why the Management UI Is Sensitive

The management UI gives full control over the NAS — creating users, deleting datasets, changing the firewall. If this UI is reachable by everyone on the network, one leaked credential could destroy everything. The UI should only be reachable from an administrative subnet.

ss -tlnp

The ss -tlnp command lists all listening ports. TrueNAS SCALE uses port 443 for HTTPS and port 6000 for WebSocket; OpenMediaVault uses 443 once TLS is enabled. Make sure these ports are only open to specific subnets.

#Restricting the UI to an Admin Subnet

The best approach is to block the management UI ports in the firewall for all IPs except the admin subnet. This drastically reduces the attack surface, because attackers can't reach the UI at all.

#Firewalls and Subnet Whitelists

#NAS Firewall Basics

TrueNAS SCALE has a built-in firewall configurable through the Network > Firewall menu or pfctl. OpenMediaVault uses standard Debian nftables/iptables. Start with a default-deny policy for non-essential services.

pfctl -s rules

The pfctl -s rules command shows PF rules on TrueNAS SCALE. Make sure there's an allow rule limiting access sources to the needed subnets, and a deny for everything else.

#IP-Based Whitelists

Flip the approach from opening ports to everyone to a whitelist: only specific subnets may reach specific ports. Example pattern:

• SMB and NFS: only the client and hypervisor subnets.
• SSH: only the admin subnet.
• Management UI: only the admin subnet.
• iSCSI: only the hypervisor subnet.

The fewer networks that can reach a service, the smaller the risk.

#Preventing Public Exposure

#Checking Port Forwarding

A common cause of exposure is port forwarding on the router, whether deliberate or accidental. A NAS should not have any ports forwarded to the internet except through strict security layers like a VPN.

nmap -Pn -p 445,443,22 <IP-PUBLIK>

Running nmap from an outside network (for example, via a VPS or cloud) shows which ports are open to the public. If SMB or management UI ports appear open, immediately close the port forwarding on the router.

#Testing from Outside Periodically

Public exposure changes with configuration. Schedule periodic tests using an internet monitoring service or nmap from an external connection. The ideal result: no ports open to the internet, or only a VPN gateway open.

#ACLs on SMB and NFS

#Enforcing Permissions at the Protocol Layer

The ACLs created in episode 7 need to be enforced when shares are accessed. On SMB, permissions are set per share and per user; on NFS, options like ro, rw, and root_squash control access at the protocol level.

/tank/data   192.168.1.0/24(rw,root_squash)
/tank/arsip  192.168.1.0/24(ro)

The second export above restricts /tank/arsip to read-only, so clients can't modify the archive even if their local user has write rights. This is an example of layered access control at the protocol level.

#Verifying ACLs

Verify ACLs work correctly by logging who accesses what, and testing as different users.

zfs get acltype tank/data
ls -l /tank/data/dokumen

The ls -l output shows the owner and group, while zfs get acltype shows the ACL type. Together they confirm the permissions you designed are actually active.

#IP Allowlists on Shares

#Restricting Access per Share

Besides per-user ACLs, shares can be restricted by source IP. On NFS this is done in /etc/exports; on SMB, through host allow. This feature is very useful for shares that should only be reachable by specific machines.

/tank/vm    192.168.1.50(rw,no_root_squash)
/tank/vm    192.168.1.51(rw,no_root_squash)

The configuration above restricts /tank/vm to only two hypervisor hosts. Other source IPs are rejected even if they know the path and credentials.

#The Principle of Least Privilege

#Giving the Smallest Rights Needed

Least privilege means every user, service, and share gets the minimum rights necessary. Examples:

• The backup user only needs read access on the source dataset.
• The archive share is read-only for everyone except admins.
• Container services run as a non-root user.
• Admin accounts are only for administrative tasks.

ps aux | grep -E "^root" | wc -l

The command above counts processes running as root. The fewer, the better. This pattern will be deepened in episode 15 when we discuss non-root services.

#Closing

In this episode 13 you locked down NAS access: restricting the management UI, applying a subnet whitelist firewall, preventing public exposure, enforcing SMB and NFS ACLs, restricting shares with IP allowlists, and applying least privilege.

Key takeaways:

• The management UI should only be reachable from the admin subnet.
• Use a default-deny policy and subnet whitelists.
• Never forward SMB or UI ports to the internet.
• Enforce ACLs at the share level, not just the filesystem level.
• Give every entity the smallest rights possible.

In the next episode, episode 14, we'll cover encryption and secure transport — from native ZFS disk encryption with aes-256-gcm, GELI and LUKS, key management, to TLS for the management UI, SFTP/FTPS, and VPNs for remote access with Tailscale and WireGuard. Access is locked; now it's time to protect the data from intruders.