This document describes different levels of security which can be implemented on the NFS share(s) inside SoftNAS to ensure that only authorized resources can access the NFS share(s).
1. HOST LEVEL SECURITY
This level specifies the hosts that will have access to the exported directory.
Six ways of specifying which hosts are allowed to mount the directory are available:
a. Everyone : Any host capable of contacting your system is allowed access. This option should be used with care, especially if your system is connected to the Internet.
b. Host(s): This can either be a single IP address, a single hostname, or a regular expression like *.foo.com. In the last case, any host whose reverse DNS lookup by IP address matches the expression will be allowed access.
c. WebNFS clients: Allows clients using Sun's WebNFS protocol to access this directory.
d. NIS Netgroup: Allows all members of the specified NIS netgroup to access this export.
e. IPv4 Network and Netmask: Any host in the specified subnet is allowed access. For example, if the network was 10.1.2.0 and the netmask 255.255.255.0, all hosts with IP addresses from 10.1.2.0 to 10.1.2.255 would be allowed.
f. IPv6 Address and Prefix: Any host in the specified subnet is allowed access.
Example of my /etc/exports file for your reference. I used option (e) to lock down my share to only 2 specific IP CIDR ranges on my network. So all the systems within that CIDR range will be able to mount and access the NFS share and no one else.
/export 10.10.1.0/24(ro,fsid=0) 10.10.20.0/24(ro,fsid=0)
/export/pool1/cifs1 10.10.1.0/24(async,no_subtree_check,no_root_squash,insecure,rw,nohide) 10.10.20.0/24(async,no_subtree_check,no_root_squash,insecure,rw,nohide)
2. ACLs LEVEL SECURITY
This type of Security is only ideal for small scale NFS users (around 5 users). With this type of security the below commands can be used to control access authorization to the NFS share by creating the users from SoftNAS first and making sure that their UID/GID are the same on the linux Client(s) mounting the share. Then ACLs per user/group bases could be configured.
Examples of the commands to run:
# useradd user1
# chmod -R 770 /pool-name/volume-name
# setfacl -m u:user1:rwx /pool-name/volume-name :- To set the ACLs for user1 on the share
# setfacl -m d:u:user1:rwx /pool-name/volume-name :- To make it the default behavior for all future directories created under the root share (/pool-name/volume-name)
3. KERBEROS LEVEL SECURITY
This one is more secure and more complex to setup and it's ideal for used with centralized authentication systems like (AD or LDAP). With the setup once the share is mounted only the authorized users/groups are allowed access to the share and no one else.