通过加强 SSH 配置来降低风险 前面描述的三个场景只是恶意用户通过滥用 GPFS 正常工作所需的配置而执行的行为的示例。
以后可能存在或者开发出可以利用此后门的更先进的替代品。我们的目标是针对当前和未来的未知恶意技术做好准备，将风险减轻到一个合理的范围内。
这里遵循的基本原理是，为了让 GPFS 安装能够正常工作，允许让 root 用户远程登录成为强制性的（截至 2013 年 8 月），因此，必须保持此配置。但是，也可以通过 SSH 配置对此进行限制，指定哪些 IP 地址允许直接使用 root 用户连接，哪些不允许直接使用。属于专用 GPFS 子网的那些 IP 地址（参见 图 1）将被允许直接使用 root 用户连接，其他 IP 可以继续连接到 SSH 服务，但不能直接使用 root 用户连接。
OpenSSH 和 Match 指令Match 指令只可在 4.3p2 之后的 OpenSSH 版本上使用。
有条件地控制 root 用户远程登录连接Match 指令允许包括一个条件验证。如果满足所建立的条件，那么可以在这里修改已被定义为特定值的参数。
该指令可以通过多种方式进行配置，也可以接收不同的参数，但是，因为目标是限制来自特定 IP 的连接，所以我们将重点关注 Address 参数。
使用 Match 指令根据 ，GPFS 专用子网的 IP 地址是 192.168.10.12（节点 A）和 192.168.10.13（节点 B），因此，从这些 IP 地址发起连接的用户能够使用 root 用户 ID 进行远程登录。需要重点考虑的是，所有 Match 指令都必须包含在 sshd_config 配置文件的末尾处。
节点 A 和节点 B 的 SSH 配置如清单 11 和清单 12 所示。
清单 11. 节点 A 的 SSH 配置1
2
3
4
5
| # egrep -n "^PermitRootLogin|Match" sshd_config
38 ermitRootLogin no
114:Match Address 192.168.10.13
115ermitRootLogin yes
#
|
清单 12. 节点 B 的 SSH 配置1
2
3
4
5
| # egrep -n "^PermitRootLogin|Match" sshd_config
38ermitRootLogin no
114:Match Address 192.168.10.12
115ermitRootLogin yes
#
|
请注意，这里并没有显示 sshd_config 文件的完整内容，而是使用了 egrep 命令来查找文件中的字符串 PermitRootLogin 和 Match。（使用 -n 标志显示字符串所在的行的编号，以及 egrep 所返回的编号，这些编号不属于该文件的内容）。
在两个节点的配置文件的第 38 行上，请注意，PermitRootLogin 参数的值已被设置为 no。由于此配置实际上出现在文件的开头处，所以被认为是一个全局设置。因此，该值适用于所有连接，这意味着在默认情况下，任何 root 用户远程登录连接都被拒绝。这是推荐的值。
激活 SSH 配置值得重点考虑的是，必须重新启动 SSH 服务器（例如，在 Linux 中运行 service sshd restart 命令），以激活在配置文件上所做的更改。
然而，在第 114 行（在这两个文件的结尾）中，Match 指令出现了，并接收作为参数的字符串 Address 和各自对口集群节点专用 GPFS 子网上的 IP 地址。
如果 Match Address 指令中列出了试图直接使用 root 用户 ID 登录的连接的源 IP 地址，那么 PermitRootLogin 值是 yes（如第 115 行中所定义的那样），它覆盖在第 38 行中定义的全局值，并允许来自授权 IP 地址的连接使用 root 用户 ID 登录。
如果 GPFS 集群包含两个以上的节点，那么可以声明 Match Address 指令的多个段落，每一个段落包含集群的每一个节点的 IP 地址。
使用专门的加密密钥身份认证 当 PermitRootLogin 参数的值被配置为 yes 时，通过提供 root 用户 密码或使用 SSH 加密密钥，两种身份验证方法都可以用来连接到 SSH 服务器。
因为 GPFS 需要使用一些自动化的进程来运行和连接到其他节点（以 root 用户身份），所以加密密钥身份验证通常是替代选择方案，并且可以对其进行配置。GPFS 不需要使用 root 用户密码来启动连接，因此，可以将 PermitRootLogin 配置为 without-password 值。
乍一看，配置这个值似乎会造成混乱，但相反，它实际上是一个更严格的值，因为它会禁用 root 用户 ID 的密码身份认证，让加密密钥身份验证方法成为 root 用户的惟一可用选项。SSH 配置文件将会包含清单 13 中的代码。
清单 13. 限制 root 用户连接只使用加密密钥1
2
3
4
5
| # egrep -n "^PermitRootLogin|Match" sshd_config
38ermitRootLogin no
114:Match Address 192.168.10.12
115ermitRootLogin without-password
#
|
图 3. root 用户远程登录连接被限制为 GPFS IP 地址专用 GPFS adminMode 配置参数 在 GPFS 版本 3.3 或更高版本中，已经引入了 adminMode 配置参数，以控制和限制可以运行管理命令的节点数量，以及因此需要能够直接远程访问 root 用户的节点数量。
adminMode 参数有两个可能的值： allToall 和 central。
当 adminMode 被设置为 allToall 时，GPFS 就会明白，所有节点都有访问权限，因此，所有节点都可以在其集群同伴上运行管理命令。
当 adminMode 的值被设置为 central 时，GPFS 的行为就像是运行命令的节点是能够以 root 用户身份访问其他所有节点的惟一一个节点。这使得对哪些 GPFS 节点可以运行管理命令有了更多的控制。
请注意，通过将 adminMode 设置为 central，安全性甚至得到了更大的强化，但这个参数本身不干涉 SSH 服务的行为，因此，应该一起使用这两个配置（来自 GPFS 方的 adminMode 参数和来自 SSH 方的 Match 指令）。
结束语和建议通过 SSH 中的 Match 指令实现 PermitRootLogin 参数的有条件配置，允许从非授权或者非 GPFS 集群服务器或网络进行 root 用户远程登录连接而造成的风险得到了缓解，并且只将访问权授予那些绝对需要它们的人。来自非授权位置的恶意用户如果尝试任何 ，那么他们不能直接以 root 用户身份建立连接。
请注意， root 用户登录访问控制并不是 SSH Match 指令的惟一可用条件控制。此外，在本文中描述的解决方案并非只适用于 GPFS。需要对 SSH 远程访问进行这种细粒度控制的任何系统或安装都可以从这个实现中获益。
最终的目标是平衡必须与它们有关联的生产力、自动化和安全性。不能从独立和对立的立场来看待它们。本文已展示，拥有比使用默认配置的安装更高效更安全的 GPFS 环境是完全可行的。
建议- 如果可能的话，划分一个专用于 GPFS 通信的特定子网。
- 这有助于控制和限制可以使用 root 用户远程登录配置的 IP 地址。
- 。如果网络性能是一个问题，那么确保通过相应的 Match 指令在每个集群节点上的 sshd_config 配置文件中只配置了获得授权的 GPFS 节点的 IP 地址。
- 来限制可以在集群的其他所有节点上运行管理命令的节点。这为 GPFS 安装增加另一个安全层。
- ，通过实现 Match 指令获得所需的严格限制的连接。
- 如果您的 OpenSSH 服务器版本低于或等于 4.3p2，请对其进行升级，以便能够使用 Match 指令。
- 为每个 GPFS 节点生成不同的 root 用户 SSH 加密密钥对。
- 将加密密钥视为密码：每个系统的加密密钥都必须是不同的。
- 这降低了使用相同的凭据对多个系统进行未经授权的访问的风险。
- 确保 root 用户的加密密钥只有 root 用户 ID 可以访问。
- 确保 root 用户的私钥的权限是 700，或更严格。
- 定期创建新的 SSH root 用户加密密钥，并丢弃旧的加密密码。
- 和密码的建议一样，用于自动化流程的加密密钥也应该定期修改，以减少出现类似 中所述情况的可能性。
- 定期检查 authorized_keys 文件的内容。
- 必须删除在文件中找到的未经授权的密钥，同时必须启动有关配置文件内容的变更的调查。
- 减少发生类似于 中所述情况的可能性。
- 定期检查 sshd_config 文件的内容。
- 检查 Match 指令是否存在未经授权的更改。
- 检查是否添加了允许 root 用户远程登录连接的新 IP 地址，或者全局 PermitRootLogin 参数是否从 no 更改为 yes。
- 通过在每一个 GPFS 节点上实现（其中任意一个或两个方法） 或本地防火墙（比如 iptables）访问控制，就可以对那些已通过 Match 指令在 SSH 服务上进行配置的连接实现更多的网络访问限制。
- 实现 sudo 等特权访问控制，以避免 root 用户密码在几个人之间的随意披露。这有助于减少发生类似于 中所述情况的可能性。
- 可以保存针对所执行的特权活动的日志记录，并且可以跟踪某个人的责任。
- Sudo 事件可以被发送到系统日志服务器，因此，在任何 GPFS 节点上的本地安全性受到损害时，活动日志会存放在外部的独立服务器上，以便进行进一步的分析和事故调查。
|
