/etc/exports using specific hostnames or IP ranges, enforce strong authentication with sec=krb5p, and disable unnecessary services. This guide details the configuration steps to prevent unauthorized data access and ensure that only trusted clients can mount your shared directories safely within your internal infrastructure.
Configuring Access Control Lists in Exports
The primary defense for any NFS share is the/etc/exports file. By default, many configurations allow broad access, which is a significant security risk even on a local network. You should never use wildcard entries like * unless absolutely necessary and fully understood. Instead, specify individual client IPs or subnets to limit the attack surface.
When editing /etc/exports, use the following structure to define shares:
/srv/nfs4/share1 client_ip(rw,sync,no_subtree_check)
/srv/nfs4/share2 subnet_24bit(rw,sync,no_subtree_check)rw option allows read and write access, while sync ensures that changes are committed to disk before being acknowledged. This prevents data corruption if the server crashes but also adds a slight performance overhead. For better security, consider using no_root_squash with extreme caution; it is generally recommended to keep this disabled so that root users on client machines are mapped to the nobody user on the server, preventing privilege escalation attacks.
After modifying the file, apply the changes by running exportfs -r. This command reloads the exports without restarting the entire service, ensuring minimal disruption to active connections. Always verify the new configuration using exportfs -v to see exactly what the server is advertising to the network.
Implementing Kerberos Authentication
NFS version 4 supports various security flavors, with Kerberos offering the strongest protection against eavesdropping and tampering. While NFSv3 relies heavily on IP-based trust, NFSv4 with Kerberos encrypts both the command stream and the data payload. This is critical even on local networks where malicious actors might have physical access or compromised devices. To enable Kerberos security, install the required packages such askrb5-user and nfs-common. You must configure the /etc/idmapd.conf file to match the domain names of your clients and server. Then, update your /etc/exports entry to include the security flavor:
/srv/nfs4/share1 client_ip(rw,sync,sec=krb5p)krb5p setting provides integrity and privacy. If you only need integrity without encryption, sys or krb5 might suffice, but krb5p is the gold standard for sensitive data. On the client side, users must obtain a valid Kerberos ticket using kinit before attempting to mount the share. This adds a layer of identity verification that IP addresses alone cannot provide.
For environments where full Kerberos deployment is too complex, consider using sec=sys but combine it with strict firewall rules. However, note that sys does not encrypt data, making it vulnerable to packet sniffing tools like Wireshark if the network segment is compromised. As discussed in our guide on Securing an Ubuntu Server for Development Purposes, minimizing exposed services is just as important as hardening individual protocols.
Hardening the Network Layer
Even with proper NFS configuration, network-level controls add a vital second layer of defense. Use your firewall to restrict access to the NFS ports (typically 2049 for NFSv4) only from known client IPs. On Linux systems,iptables or ufw can be configured to drop packets from unauthorized sources.
sudo ufw allow from 192.168.1.0/24 to any port 2049 proto tcprquotad or statd are often unnecessary in modern setups and can be stopped to reduce the number of open ports.
Consider also implementing tcp_wrappers by editing /etc/hosts.allow and /etc/hosts.deny. This legacy system still effectively blocks connection attempts at the socket level before they reach the NFS application. Deny all by default and explicitly allow your trusted clients.
Monitoring and Auditing
Security is not a one-time setup but an ongoing process. Enable logging for NFS operations to detect unusual activity. Check/var/log/syslog or /var/log/messages for repeated mount failures or permission denied errors, which may indicate brute-force attempts or misconfigured clients.
Regularly audit the /etc/exports file to remove stale entries. Unused shares are unnecessary risks. Furthermore, keep your NFS utilities and kernel modules updated to patch known vulnerabilities. Refer to Understanding Ubuntu 22.04 VPS Security for broader context on maintaining a secure server environment beyond just file sharing.
Finally, test your configuration using nfsiostat and nfsstat to monitor performance and error rates. High error counts can signal connectivity issues or security probes. By combining strict export rules, Kerberos encryption, and network filtering, you create a robust defense for your local NFS infrastructure.
Frequently Asked Questions
Can I use NFS over SSH instead of Kerberos?
Yes, mounting an NFS share over an SSH tunnel is a viable alternative for smaller setups. It provides encryption without the complexity of setting up a Kerberos Key Distribution Center. However, it may introduce latency and requires managing SSH keys on each client.
What happens if I forget to restart the NFS service after changing exports?
The changes will not take effect until you run exportfs -r or restart the nfs-server service. Running exportfs -r is preferred because it applies changes dynamically without dropping existing connections. Always verify with exportfs -v to confirm the new settings are active.
Is NFSv3 safe to use on a trusted local network?
NFSv3 lacks native encryption and authentication mechanisms, relying solely on IP addresses for trust. While it is simpler to set up, it is vulnerable to spoofing and eavesdropping. If you must use NFSv3, strictly limit access via firewall rules and avoid storing sensitive data on those shares.
How do I troubleshoot "Permission Denied" errors on the client side?
Check the server's /etc/exports to ensure the client IP is listed correctly. Verify that the client has the necessary permissions on the underlying filesystem directory itself, not just the NFS export. Also, ensure that the root_squash option is configured as expected, as mismatched UID/GID mappings often cause these errors.
Should I disable UDP support for NFS?
It is highly recommended to disable UDP and use TCP exclusively. UDP is unreliable and can lead to data corruption during transfers, especially under high load. Modern NFS implementations prioritize TCP, and disabling UDP reduces the attack surface by closing additional listening ports.