☰

保护 NFS 免受 SSH 隧道攻击

tag-icon • tag-icon ssh ssh-tunnel nfs
保护 NFS 免受 SSH 隧道攻击

我闲闲地读着http://nfs.sourceforge.net/nfs-howto/ar01s06.html当我看到“6.4. 通过 SSH 隧道传输 NFS”一节时，我试图理解为什么 localhost 导出不好。该节中关于导出 localhost 可能存在安全漏洞的所有内容都是有道理的，因为它允许其他人通过 ssh 端口转发进入并访问共享。

我的问题是，如果用户可以 ssh 进入可以连接到 NFS 服务器的计算机，那么如何防止 ssh 隧道破坏系统的安全性？例如，假设计算机 A( 192.168.1.1)、B( 192.168.1.2) 和 C( 192.168.1.3)。假设 A 是具有以下导出文件的服务器：

/home 192.168.1.2(rw)

如您所见，A 授予 B 使用 /home 共享的权限。现在，让 C 使用以下命令 ssh 进入 B：

$ ssh 192.168.1.2 -L 250:192.168.1.1:2049  -f sleep 60m
$ ssh 192.168.1.2 -L 251:192.168.1.1:32767 -f sleep 60m

似乎 A 导出到 B 的共享对于任何可以 ssh 进入 B 的人来说都是脆弱的。是这样吗？除了确保任何可以登录 B 的人都是非常受信任的用户之外，还有其他方法可以防止这种情况发生吗？

答案1

你看到的是一份非常古老的文档，它讨论了 2001 年发布的内核版本 2.4，在过去的 12 年里发生了很多变化。尽管有些东西保持不变。

我只有 CentOS 6.x 机器可以玩，默认情况下它使用 nfsv4。为了允许通过中间机器进行连接，我必须使用insecureset 导出文件系统。

因此，要回答您的问题，请使用 nfsv4 并使用默认secure模式。如果您在 B 上拥有足够的权限，您还可以设置

AllowTcpForwarding no

在它的 /etc/ssh/sshd_config 中。

与安全一样，如果你赋予人们特权，你就必须信任他们。

答案2

您所强调的问题不是缺陷，而是一项功能！是的，这是 SSH 协议的功能，并且配置不当的 SSH 服务可用于各种漏洞，例如：

  • 绕过主机防火墙
  • 绕过 IP 限制
  • 远程访问仅监听“localhost”接口的服务 [ mysql?]

作为常见配置错误和安全问题的一个示例，将/sbin/nologinshell 设置为用户，并不能阻止它使用 OpenSSH 守护进程的大多数默认配置生成 ssh 隧道！

根据您的问题，您应该避免使用 NFSv2/NFSv3，而使用更安全的 NFSv4，它转向不同的安全模型，对单个用户而不是主机进行身份验证。或者，通过正确配置 OpenSSH 服务，禁止普通用户使用 SSH 隧道。

答案3

该文档相当老旧（2006 年！）。在没有更好的安全机制（即 NFSv4 + GSS）的情况下，将主机添加到导出意味着您隐含地信任该主机、其用户和进程。

SSH 端口转发不是你唯一的问题，你可以禁止它（sshd AllowTcpForwarding no），但正如sshd_config(5)所说

请注意，禁用 TCP 转发不会提高安全性，除非用户也被拒绝 shell 访问，因为他们始终可以安装自己的转发器。

因此，将socat、、netcatSOCKS（OpenSSH 也支持，尽管仅支持 TCP）、OpenSSHtun隧道支持以及甚至bash在有其/dev/tcp支持的情况下您就会发现问题...太多了，无法一一列出。

如果 B 具有允许每个用户规则的主机防火墙（即 Linux /iptables --uid-owner），您可能能够锁定 B，以便 A 可以更加信任它。否则，请尝试使用 GSS 和 Kerberos 的 NFSv4，这将为您提供每个用户的信任。

答案4

这很容易被击败

  1. 确保您的出口商品有标记secure
  2. 不允许计算机 C 对计算机 B 进行 root 访问

的手册页exports(5)显示：

secure
This option requires that requests originate on an internet port
less than IPPORT_RESERVED (1024). This option is on by default. 
To turn it off, specify insecure.

请注意，此功能默认处于开启状态。

从计算机 C 连接到计算机 B 的任何用户都将以普通用户的身份进行连接。如您所述，通过 SSH 转发的 NFS 连接看起来像是以该用户身份在 B 上运行的进程发起的。这意味着该连接受 B 上的常规安全控制，特别是普通用户不能从低于 1024 的端口发起连接。

在我的一个系统上进行测试，我发现以下内容：

djs@tuonela:~$ sudo mount -o port=250,mountport=251,tcp localhost:/srv/users /mnt/x -t nfs
mount.nfs: access denied by server while mounting localhost:/srv/users

当然，任何能够在计算机 B 上将其帐户提升为 root 权限的人都可以击败这种保护，因此您需要充分锁定 NFS 客户端计算机。

相关内容