对于NFS 服务器，通过一些快速更改可以使它们更加安全和安全。
NFS导出的基本选项可以包括：
- no_all_squash ：此选项禁用所有挤压。
- rw ：此选项使 NFS 服务器能够在 NFS 卷上使用读取和写入请求。
- ro ：此选项使 NFS 服务器能够在 NFS 卷上使用只读请求。
- sync ：此选项使 NFS 服务器仅在将更改提交到稳定存储后才回复请求。
- async ：此选项使 NFS 服务器能够违反 NFS 协议并在任何更改提交到稳定存储之前回复请求。
- 安全 ：此选项要求请求源自 Internet 端口。
- 不安全：此选项接受任何或者所有端口。
- wdelay ：如果 NFS 服务器怀疑另一个相关的写入请求可能正在进行或者可能很快到达，则该选项使 NFS 服务器能够延迟向磁盘提交写入请求。
- no_wdelay ：此选项使 NFS 服务器允许在单个操作中将多个写入请求提交到磁盘。此功能可以提高性能，但如果 NFS 服务器收到许多小请求，则此行为可能会降低性能。我们应该知道，如果还设置了 async，则此选项无效。
- subtree_check ：此选项启用子树检查。
- no_subtree_check ：此选项禁用子树检查，这有一些隐含的安全问题，但可以提高可靠性。
- anonuid=UID ：这些选项明确设置匿名帐户的 uid 和 gid；当我们希望所有请求都显示为来自单个用户时，这会很有用。
- anongid=GID ：此选项将禁用 anonuid=UID。
什么是 root_squash？
root_squash 将允许客户端上的 root 用户以 root 身份访问和创建 NFS 服务器上的文件。
从技术上讲，此选项将强制 NFS 将客户端的 root 更改为匿名 ID，实际上，这将通过防止一个系统上的 root 帐户的所有权迁移到另一个系统来提高安全性。
如果我们在 NFS 服务器上托管根文件系统（尤其是对于无盘客户端），则需要这样做；考虑到这一点，它可以（谨慎地）用于选定的主机，但除非我们知道后果，否则不应使用 no_root_squash。
如何避免这种情况？
1.首先从导出目录中删除vi文件:)，然后在nfs导出上启用root_squash。
在服务器上再次编辑 /etc/exports 将 no_root_squash 修改为 root_squash：
server# vi /etc/exports /export/test 192.168.1.0/255.255.255.0(root_squash,insecure,rw)
- 重启nfs服务器，在客户端重新挂载文件系统：
server# systemctl restart nfs
client# umount /mnt/test client# mount -t nfs server:/export/test /mnt/nfstest
- 从客户端，以 root 身份在 NFS 挂载上创建一些文件，检查权限：
client# touch /mnt/nfstest/{test1,test2,test3}
根据 /export/test 上设置的权限，我们将获得权限被拒绝，或者如果目录是全局可写的，则文件的权限将类似于：
-rw-r--r-- 1 65534 65534 0 Nov 6 2015 test1 -rw-r--r-- 1 65534 65534 0 Nov 6 2015 test2 -rw-r--r-- 1 65534 65534 0 Nov 6 2015 test3
root_squash 正在将根 UID 重新映射为匿名用户的 uid。
此 uid 可在导出文件 man /etc/exports 中配置以获取更多信息。
在客户端以 root 身份再次复制 vi 命令（如果允许）到 nfs 卷并重复上述步骤（ssh 到服务器在 /etc/passwd 上运行 vi）。
这次我们将没有权限保存文件，权限被提升到非特权帐户。
这更安全一点，但是我们还没有完成。
我们可以采取的另一个步骤是使用 nosuid 选项将导出的文件系统挂载到 NFS 服务器上。
server# vi /etc/fstab
- 找到/export/的挂载点，修改options列默认为。
/dev/mapper/sys_vg-export_lv /export ext3 defaults 0 0 /dev/mapper/sys_vg-export_lv /export ext3 nosuid 0 0
- 重新挂载：
server# mount -o remount /export
- 将vi文件转储到mount上，设置suid位，切换到非特权账户再试一次：
server# cp /usr/bin/vi /export/test; chmod u+s /export/test/vi
server# su - someuser server$ /export/test/vi /etc/passwd
对传递的文件进行更改后，将不允许我们保存更改。
- 以非特权用户身份跳转到客户端并尝试相同的操作：
client$ /export/test/vi /etc/passwd
它仍然有效，客户端还需要使用 nosuid 选项重新安装：
client# mount -t nfs -o nosuid server:/export/test /mnt/nfstest
使用非特权帐户再次测试，它应该会失败。
可以在挂载点上指定几个其他选项以进一步限制可以从它们运行的内容，请查看 noexec（无可执行文件）、nodev（无设备文件）。
如果需要进一步的安全性，请查看 Kerberos 和 NFSv4.
SUID 和 NFS
suid 是用户在执行文件时承担文件所有者权限的一种方法。
我为什么要关心这个？
想象一下，如果用户能够将文件复制到 NFS 卷上，启用对文件的 suid 位，然后在 NFS 服务器或者客户端上运行它，从而在此过程中有效地将自己提升为 root？
这是一个说明风险的示例。
NFS 服务器主机名是服务器，NFS 客户端主机名是客户端。
示例网络上的子网是 192.168.1.0/24.
此示例还假设两个系统都运行相同的操作系统版本（即，两者都是 RHEL 7，或者都是 SLES 12），只要操作系统的主要版本匹配即可。
- 在 NFS 服务器上创建一个临时目录 (/export/test) 并使用以下选项导出（用我们自己的网络/网络掩码替换 192.168.1.0/255.255.255.0）：
server# vi /etc/exports /export/test 192.168.1.0/255.255.255.0(no_root_squash,insecure,rw)
- 重启 nfs 服务器。
这取决于linux的风格..
RHEL：
server# systemctl restart nfs
使用：
server# systemctl restart nfsserver
- 在客户端机器上，挂载导出：
client# mkdir /mnt/nfstest client# mount -t nfs server:/export/test /mnt/nfstest
- 在客户端上，以 root 用户身份，将 vi 二进制文件复制到 NFS 挂载。
client# which vi —— output ——— /usr/bin/vi
client# cp /usr/bin/vi /mnt/nfstest
- 在复制的二进制文件上设置 suid 位。
client# chmod u+s /mnt/nfstest/vi
- 以非特权用户身份通过 SSH 连接到 nfs 服务器。
作为非特权用户运行位于服务器上导出的安装中的 vi：
server$ /export/test/vi /etc/passwd
- 在密码文件中找到非特权账户，将UID改为0，保存，注销然后以非特权用户身份重新登录。
用户现在是 root。
这同样适用于客户端，如果我们以普通用户身份从 NFS 挂载执行 vi，我们可以将其指向主机上的任何文件，并且能够以 root 身份进行编辑。
它适用于我们能想到的任何二进制文件。