gpfs配置_加强GPFS安装中使用的SSH配置，使其更安全

最新推荐文章于 2024-05-21 17:54:18 发布

cusi77914

最新推荐文章于 2024-05-21 17:54:18 发布

阅读量916

点赞数

文章标签：网络 python linux java 数据库

原文链接：https://www.ibm.com/developerworks/aix/library/au-aix-modifying-ssh-configuration/index.html

版权

总览

IBM GPFS是一个高性能的企业文件管理平台，广泛用于商业和科学应用程序。作为GPFS配置的一部分，要求启用root用户的远程连接，以便GPFS群集中的节点可以在它们之间进行通信，以运行需要root特权的命令。

不建议将远程根连接作为安全性最佳做法。通常，root登录连接必须专门从控制台完成，或者通过维护对此类连接的个人负责的方法（例如sudo ）完成。

必须采取措施以减轻这种情况对整个环境造成的风险。

本文介绍了可以应用于每个GPFS节点上的Secure Shell（SSH）配置文件的更改，以便只允许从GPFS节点建立与root用户的远程登录操作。

基本的GPFS网络配置

下图显示了基本的GPFS网络配置。它由两个节点组成，每个节点都配置了两个网卡：一个连接到公司网络，另一个已分配用于GPFS。

图1.基本的GPFS网络配置

两个节点都运行Linux®操作系统（本文的建议可以应用于任何类似UNIX®的操作系统），并且节点之间的通信机制被确定为SSH [GPFS支持其他通信机制，例如远程外壳程序（rsh ）]。

sshd_config文件是SSH的配置文件，允许或拒绝根连接的参数称为PermitRootLogin 。对于典型的GPFS安装，此参数的值为yes ，如以下示例所示。

# grep ^PermitRootLogin /etc/ssh/sshd_config
PermitRootLogin yes
#

此值全局适用于所有SSH行为，这意味着在SSH正在侦听的所有网络接口上（通常在所有可用接口上）都允许远程根登录登录连接。

风险情景

记录和维护访问日志有助于将个人对其进行访问在任何计算机系统上执行的操作的责任关联起来。通过允许GPFS要求的root用户远程登录连接，可以为潜在的攻击或未经授权的访问打开一扇门。使用根凭据访问系统的用户的责任感丢失，调查变得更难执行。

以下方案显示了未配置为采取适当措施来减轻允许远程root登录连接的风险的系统上可能发生的某些情况。

方案1：拥有root密码的个人

可以通过批准的方式（例如，具有有效业务需要的系统管理员）或通过未授权的方式（例如，保留此信息的前雇员且新系统管理员未更改）来了解根用户的密码立即输入密码，或在共享文件夹的不受保护的文本文件中找到该密码的人）。

利用用户拥有的这些信息，用户可以使用根身份启动从公司网络到两个GPFS节点的远程连接。

清单1.与节点A的连接

$ ssh -l root 172.19.230.35
root@172.19.230.35's password: **********
Last login: Mon Jul 29 11:14:07 2013 from gpfsnodeb
=== Welcome to GPFS Node A
#

清单2.与节点B的连接

$ ssh -l root 172.19.230.36
root@172.19.230.36's password: **********
Last login: Mon Jul 29 11:30:16 2013 from gpfsnodea
=== Welcome to GPFS Node B
#

可以从节点本身启动具有与前面所述相似特性的SSH连接。用户可以从用户的个人计算机或其他非GPFS服务器使用该用户的个人用户ID（或在被攻击的情况下是被劫持的用户ID）与其中一个节点建立SSH连接，并在获得后不久访问时，用户可以使用根凭据跳到另一个节点。

清单3.连接到节点A，然后跳到节点B

$ ssh -l kath1406 172.19.230.35
kath1406@172.19.230.35's password: **********
Last login: Thu Aug 15 11:30:16 2013 from pc0212
=== Welcome to GPFS Node A
[kath1406@gpfsnodea ~]$
[kath1406@gpfsnodea ~]$ ssh -l root 192.168.10.13
root@192.168.10.13's password: **********
Last login: Mon Jul 29 13:26:19 2013 from gpfsnodea
=== Welcome to GPFS Node B
#

清单4.连接到节点B，然后跳到节点A

$ ssh -l kath1406 172.19.230.36
kath1406@172.19.230.35's password: **********
Last login: Thu Aug 15 11:03:10 2013 from pc0212
=== Welcome to GPFS Node B
[kath1406@gpfsnodeb ~]$
[kath1406@gpfsnodeb ~]$ ssh -l root 192.168.10.12
root@192.168.10.12's password: **********
Last login: Mon Jul 29 14:02:02 2013 from gpfsnodeb
=== Welcome to GPFS Node A
#

可以看出，无论远程根登录连接来自何处（公司网络或专用GPFS子网），都可以接受，不存在任何限制，并且潜在地存在获得未授权的根访问的风险。

图2.不受限制的SSH连接可以从网络中的任何点启动

方案2：使用被盗的根SSH加密密钥

为了使GPFS能够使用SSH在节点之间执行自动化管理任务，将创建加密密钥并在节点之间交换。但是，在GPFS安装中，这些加密密钥通常是在没有密码的情况下创建的，因此自动化的重要性超过了安全性。

先前具有对GPFS节点的根访问权限的个人可以复制根的加密密钥，然后进一步使用它们来获得未经授权的根访问权限。

由于加密密钥的更改频率不如密码高，因此固有的风险是，即使更改了root密码，拥有密钥的用户也将能够继续访问节点。

加密密钥通常位于密钥所属用户的主目录下的.ssh子目录中。对于root用户，他们可以位于/root/.ssh文件夹中。默认情况下，用于创建密钥的ssh-keygen命令使用Rivest-Shamir-Adleman（RSA）算法。然后，可以制作id_rsa和id_rsa.pub文件的副本（分别包含私钥和公钥）以供进一步使用。

复制密钥后，可以使用根私钥从用户的计算机登录到服务器。

清单5.使用被盗的根SSH加密密钥连接到节点A

$ eval `ssh-agent`
Agent pid 22047
$ ssh-add gpfsnodea_id_rsa
Identity added: gpfsnodea_id_rsa (gpfsnodea_id_rsa)
$ ssh -l root 172.19.230.35
Last login: Thu Aug 15 13:27:35 2013 from gpfsnodeb
=== Welcome to GPFS Node A
#

清单6.使用被盗的根SSH加密密钥连接到节点B

$ eval `ssh-agent`
Agent pid 24040
$ ssh-add gpfsnodeb_id_rsa
Identity added: gpfsnodeb_id_rsa (gpfsnodeb_id_rsa)
$ ssh -l root 172.19.230.36
Last login: Thu Aug 15 13:30:12 2013 from gpfsnodea
=== Welcome to GPFS Node B
#

可以看出，通过使用被盗的根SSH加密密钥，甚至不需要密码来访问节点。节点之间SSH加密密钥的互换定义了信任关系。因此，即使更改了root密码，无论root密码是什么，连接都将继续建立。

方案3：注入恶意SSH加密密钥

在以前的场景中，展示了如何通过为根用户使用先前创建的SSH加密密钥来使用它们来实现未经授权的特权访问。假定已将使用加密密钥进行远程连接所需的SSH配置作为GPFS安装先决条件的一部分已准备就绪。

此方案涵盖了恶意用户注入用户自己创建的加密密钥以获取对GPFS节点的根访问权限的情况。假定该用户以前具有root用户权限才能访问节点，才能执行此任务。

第一步是创建一对加密密钥。密钥可以在GPFS节点之一上的用户个人计算机上创建，也可以从其他非GPFS服务器上创建。 ssh-keygen命令必须按照以下清单所示运行（此示例使用默认GPFS安装所要求的空密码）：

清单7.创建恶意SSH加密密钥

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/left173/.ssh/id_rsa): ./rogue_rsa
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in ./rogue_rsa
Your public key has been saved in ./rogue_rsa.pub
The key fingerprint is:
c2:ae:ac:af:dd:71:35:35:39:c1:07:b2:f8:cc:71:82 left173@pc2604
The key's randomart image is:
+--[RSA 2048]----+
|         ..o.   |
|        o o.o.  |
|       E + *.   |
|     .  + = o   |
|      o S *     |
|     . . . .    |
|      o .       |
|   o o o        |
|  o+= .         |
+----------------+
$

下一步是在每个GPFS节点上安装流氓公共加密密钥rogue_rsa.pub 。必须将其传输或复制到每个GPFS节点上的/root/.ssh目录中。然后，必须将其附加到authorized_keys文件的末尾，如下面的清单所示。

清单8.在GPFS节点上注入流氓SSH公钥

# pwd
/home/root/.ssh
# cat rogue_id_rsa.pub >> authorized_keys
# rm rogue_id_rsa.pub
#

authorized_keys文件维护允许用于连接到服务器的公共加密密钥的列表。在这里，GPFS节点之间以及通常与尝试连接到服务器的任何人之间都建立了信任关系。

完成这些步骤之后，恶意用户将准备好以root用户身份登录，如下面的清单所示。

清单9.使用流氓加密密钥连接到节点A

$ eval `ssh-agent`
Agent pid 25036
$ ssh-add rogue_id_rsa
Identity added: rogue_id_rsa (rogue_id_rsa)
$ ssh -l root 172.19.230.35
Last login: Thu Aug 15 14:15:00 2013 from gpfsnodeb
=== Welcome to GPFS Node A
#

清单10.使用流氓加密密钥连接到节点B

$ eval `ssh-agent`
Agent pid 25140
$ ssh-add rogue_id_rsa
Identity added: rogue_id_rsa (rogue_id_rsa)
$ ssh -l root 172.19.230.36
Last login: Thu Aug 15 14:15:00 2013 from gpfsnodea
=== Welcome to GPFS Node B
#

通过使用这对新的恶意密钥，根密码是否更改或加密密钥都没有关系，现在，恶意用户可以通过一种方法进入服务器，而无需更改根用户的访问凭据。

通过加强SSH配置降低风险

前面描述的三种情况只是恶意用户可以通过滥用GPFS正常工作所需的配置而执行的行为的示例。

可以利用此后门的更复杂的替代方案可以存在，也可以在将来开发。我们的目标是为当前和将来未知的恶意技术做好准备，并在合理范围内减少暴露。

遵循的理由是，对于GPFS安装（自2013年8月起）来说，必须允许远程root登录才能正常工作，因此，必须保留此配置。但是，也可以通过SSH配置对其进行限制，指定允许哪些IP地址直接与root连接，哪些不允许。那些属于专用GPFS子网的IP地址（请参见图1 ）将被允许直接与root连接，而其他IP将继续能够连接SSH服务，但不能直接与root连接。

OpenSSH和Match指令

Match指令仅可用于4.3p2之后的OpenSSH版本。

有条件地控制远程root登录连接

Match指令允许包含条件验证。如果满足建立的条件，则可以在此处更改已经定义为具有特定值的参数。

该指令可以通过多种方式配置，并且可以接收不同的参数，但是由于目标是限制来自某些IP的连接，因此将重点放在Address参数上。

使用Match指令

根据图1 ，GPFS专用子网的IP地址为192.168.10.12（节点A）和192.168.10.13（节点B），因此，从这些IP地址启动连接的用户将能够使用root远程登录。用户身份。重要的是要考虑到，必须在sshd_config配置文件的末尾包含任何Match指令。

清单11和清单12中显示了Node A和Node B的SSH配置。

清单11.节点A的SSH配置

# egrep -n "^PermitRootLogin|Match" sshd_config
38:PermitRootLogin no
114:Match Address 192.168.10.13
115:PermitRootLogin yes
#

清单12.节点B的SSH配置

# egrep -n "^PermitRootLogin|Match" sshd_config
38:PermitRootLogin no
114:Match Address 192.168.10.12
115:PermitRootLogin yes
#

注意，未显示sshd_config文件的全部内容，而是使用egrep命令在文件内查找字符串PermitRootLogin和Match 。（ -n标志用于显示找到字符串的行号，而egrep返回的数字不属于文件内容的一部分）。

在两个节点的配置文件的第38行上，请注意， PermitRootLogin参数已设置为no 。因为此配置实际上出现在文件的开头，所以将其视为全局设置。因此， 该值适用于所有连接 ，这意味着默认情况下将拒绝任何远程根登录登录连接。这是建议的值。

激活SSH配置

必须考虑必须重新启动SSH服务器（例如，在Linux中，通过运行service sshd restart命令），才能激活对配置文件所做的更改。

无论如何，在第114行（两个文件的末尾），都会出现Match伪指令，并在其专用GPFS子网中为它们的每个对等群集节点接收字符串Address和IP地址作为参数。

如果在“ Match Address指令中列出了尝试直接使用根ID登录的连接的IP地址，则PermitRootLogin值为yes （如在第115行中定义），它将覆盖第38行中定义的全局值。并允许来自授权IP地址的连接使用根ID登录。

如果GPFS集群由两个以上的节点组成，则可以声明Match Address指令的多个节，每个节都包含集群的每个节点的IP地址。

仅使用加密密钥身份验证

如果将PermitRootLogin参数配置为值yes ，则可以通过提供根密码或使用其SSH加密密钥来使用两种身份验证方法来连接到SSH服务器。

由于GPFS要求运行一些自动化进程并使用根身份将其连接到其他节点，因此通常选择和配置加密密钥身份验证。 GPFS不需要使用root密码来启动连接，因此，可以将PermitRootLogin配置为without-password值。

乍一看，配置此值似乎会引起混乱，但是实际上，它是一个更严格的值，因为它禁用了根ID的密码身份验证，而加密密钥身份验证方法是root唯一允许的选项。 SSH配置文件将包含清单13中的代码。

清单13.限制根连接以仅使用加密密钥

# egrep -n "^PermitRootLogin|Match" sshd_config
38:PermitRootLogin no
114:Match Address 192.168.10.12
115:PermitRootLogin without-password
#

图3.远程root登录连接被限制为仅可用于专用GPFS IP地址

GPFS `adminMode`配置参数

在GPFS 3.3或更高版本中，引入adminMode配置参数是为了控制和限制可以运行管理命令的节点数，因此需要直接远程访问root用户。

adminMode参数有两个可能的值： allToall和central 。

当adminMode设置为allToall ，GPFS会理解所有节点之间都具有访问权限，因此，所有节点都可以在其集群对应节点上运行管理命令。

当adminMode设置为central值时，GPFS就像在其上运行命令的节点是唯一具有根访问所有其他节点的节点一样。这允许对哪些GPFS节点可以运行管理命令进行附加控制。

请注意，通过将adminMode设置为central ，可以进一步增强安全性， 但是此参数本身不会影响 SSH服务的行为，因此，两种配置（GPFS端的adminMode参数和SSH端的Match指令）都应结合使用。

结论与建议

通过在PermitRootLogin通过Match指令实现PermitRootLogin参数的条件配置，可以降低允许来自非授权或非GPFS群集服务器或网络的远程根登录连接的风险，并且仅将访问权限授予严格需要它的用户。来自非授权位置的恶意用户尝试先前描述的任何情况都将无法直接与root连接。

请注意，控制对root用户的登录访问权限不是可以与SSH Match指令一起使用的唯一条件控件。另外，本文介绍的解决方案也不是GPFS独有的。任何需要对SSH远程访问进行这种粒度控制的系统或安装都可以从其实施中受益。

最终目标是平衡必须与之相关的生产力，自动化和安全性。他们不能被看作是分开面对的立场。本文显示，与安装默认配置的环境相比，拥有一个高效且更安全的GPFS环境是完全可以实现的。