SSH ForceCommand在跳转主机上的安全性如何?


8

我的网络中具有以下设置:

Internet <--> Bastion <--> Local Network

我有几个用户,每个用户都分配给一台特定的计算机。换句话说:每个用户只能访问这些服务器之一。例如:User1-> Machine1,User2-> Machine2,依此类推。

这些用户将从我的网络外部进行连接,我已经考虑了很多选择,如何通过我的堡垒主机将其连接转发到我的网络。

最终我选择了Match Blocks和forcecommand。

因此,我在堡垒上的/ etc / ssh / sshd_config看起来像这样:

Match User User1
        ForceCommand ssh User1@Machine1 $SSH_ORIGINAL_COMMAND

User1连接到堡垒主机,堡垒主机自动与Machine1建立连接。

据我了解的ForceCommand,User1对堡垒主机没有任何实际访问权限,因为他的所有操作都将首先由match块处理,因此被重新路由到Machine1。但是,这是真的吗?这是否已经足够安全设置?无论如何,该用户在Machine1上被监禁,因此他在那里的可能性不大。


2
请记住要获取IPv6,因此您将不再需要跳转框。
迈克尔·汉普顿

Answers:


6

我使用堡垒主机的方式是使用ProxyCommand-W标志,如本例所示:

ssh -o ProxyCommand='ssh -W %h:%p user@bastion' user@machine

出于安全原因,我使用此方法。客户端与目标计算机之间的通信经过加密和端到端身份验证,这意味着即使堡垒遭到破坏,它也保持安全。遭到破坏的堡垒主机提供的安全性不亚于没有堡垒时使用ssh端到端。

它还消除了使用任何代理转发的需要。客户端可以首先使用基于密钥的身份验证来访问堡垒,然后再使用它来访问目标主机,而没有为这些主机提供代理连接,该代理连接可用于滥用客户端上存在的私钥。

它还限制了我依赖于堡垒主机的代码。我根本不需要在堡垒上执行任何命令。-W暗示着no命令标志以及一个端口转发,堡垒主机需要允许的所有端口转发。

考虑到这种方法,我的建议是尽可能地锁定堡垒主机,仅允许使用上述结构的命令。

~/.ssh/authorized_keys对堡垒文件可以由root拥有(如均能从文件系统到它的根路径上的目录),这样可减少即使有人设法在突破作为非特权用户可能被修改的风险堡垒主机。

authorized_keys客户端的权限可以通过选项进行限制commandno-agent-forwardingno-ptyno-user-rcno-X11-forwarding,以及使用permitopen到极限的端口转发,只允许该用户被允许访问的主机上的端口22。

原则上,即使多个用户在该堡垒上共享一个用户名,此方法也将是安全的。但是,通过在堡垒上使用单独的用户名,您可以获得更多的分隔。


看来您是在堡垒本身上调用ssh二进制文件。在这种情况下,如果堡垒遭到破坏,攻击者可以用一个ssh二进制文件替换该ssh二进制文件,该二进制文件将转储您的通信。由于您没有在命令行中使用路径(例如/ usr / bin / ssh),因此即使没有在堡垒上的超级用户访问权限,攻击者也可以这样做,方法是将其放入主目录并更改PATH(或使用别名) ssh)。只是我的2美分。
乔治Y.

1
@乔治 你错了。这两个ssh命令都在客户端上运行。这正是我建议的方法。问题中提到的方法将ssh在堡垒上运行,这会打开各种可能的攻击媒介。
kasperd '16

2

您可以轻松地规避ForceCommand,因为它在外壳启动时会启动。从本质上讲,这意味着您的外壳rc文件首先得到处理,然后如果允许,则执行ForceCommand。exec sh在shell rc文件中简单将生成另一个shell,并让ForceCommand等待直到退出该shell。

所以底线; 如果用户可以通过ftp,sftp,scp或其他方式以某种方式编辑其shell rc(例如.bashrc),则ForceCommand并不是真正值得依赖的东西。


好的,我会尝试的。这些用户都没有访问堡垒主机的权限来进行任何文件更改。他们只能访问可以更改.bashrc的目标主机。但是,我希望我理解的正确,您与堡垒主机有关?
Elch博士2014年

1
如果用户能够登录系统以更改bashrc文件,那么这只是一个问题。如果不打算正常使用这些帐户,则它们可以由root拥有,目录和几乎所有文件都由root拥有。检查有关.ssh文件所有权的规则,但是当然.bashrc之类的东西不一定是可写的。
mc0e 2014年

是的,确实是@Elch博士,我指的是堡垒主机上的安全性。您也可以考虑;chattr + i将shell rc设置为不可变,并禁止用户自行更改shell。
HrvojeŠpoljar2014年

1

我想这在大多数时候都可以,但是安全性的问题是尚未有人考虑的事情。没有任何保证。

例如,很长一段时间以来,没有人对使用bash中的环境变量创建函数的方式进行过认真的思考,但是最近人们意识到这可以被颠覆,其结果之一就是可以克服ForceCommand(在如果用户的shell是bash,则至少要在authorized_keys文件中实现)。Bash已修复,希望您的版本是最新的,但是这种事情会发生。

我不能完全确定定义ForceCommand是否与在authorized_keys文件中定义这些命令有效。我没那么仔细看。


0

在用户登录时运行的sshd 使其.bashrc拥有root:usergrp但仍可被sshd读取。在$ HOME上设置perms / owner不允许用户创建新文件。这样一来,root用户可以控制的内容.bashrc,让它做所需的事情,但是用户本身无法更改这些设置或对文件/目录的权限,而这些权限将间接允许他们更改的内容.bashrc


不向堡垒服务器上的用户分配任何主目录怎么办?
Elch博士2014年

您要在哪里存储.bashrc要运行的命令?
Marcin 2014年

在堡垒服务器上,将连接转发到真实主机的forcecommand在sshd_config中定义。因此,我不需要在该堡垒主机上指定其他命令,对吗?
Elch博士2014年

0

我有另一个主意。对于堡垒服务器上的每个用户,您可以在/ etc / passwd中将其shell定义为仅运行ssh user1 @ machine1,user2 @ machine2等的bash脚本。这样,您可以确保他们没有任何有效的密码。在服务器本身的外壳上,它们只是连接到应该连接的计算机上。


你有尝试过吗?这个想法发生在我身上,我想知道它的效果如何。
William Pietri
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.