[实验文]利用ssh服务突破业务堡垒机的统一入口限制.docx

[实验文]利用SSH服务突破业务堡垒机的统一入口限制
Writer: demonalex[at]dark2s[dot]org

随着经济全球化进程的日益加剧，国内的上市公司企业数量也与日俱增，SOX（萨班斯）法案也随之成为各大企业与机构的主要内审依据之一，为了有效实现SOX法案中针对IT审计的技术支撑手段，各大安全厂家均推出了自己的4A解决方案，从一开始的旁路审计系统，到后来的业务堡垒机、综合审计平台等等，且各自具备特殊亮点。在此番如火如荼的激烈战斗中，让我们切身地了解到了业务堡垒机这种IT安全审计中坚产品的份量。
本来设计业务堡垒机的初衷是为了营造出一个唯一的安全登陆入口，实现对维护通讯进行统一的帐号管理、认证、授权与审计工作，同时为保障自然人与这个唯一入口间的通讯链路是安全的，因此大家都会用SSH作为通讯手段。但不要忘记SSH除了是个加密的telnet替代品外，还提供大量特殊功能，如SCP以及本次实验所使用到的TCP Forward功能（类似于TCP端口映射技术），通过这项功能我们可以轻易绕过大部分的业务堡垒机产品。
针对上述论点我们进行下面的实验，首先部署一个模拟企业内部通讯网络，其架构主要包含一个OA区（维护终端区域）、服务器区以及一台用于隔离用的核心路由器。具体示意图如下：

正常的情况下，处于OA区域的远程维护终端内直接访问服务器区域的所有服务器应用，但这样有违业务堡垒机部署的初衷，因此我们需要在核心路由器上加入相应的ACL安全策略，实现远程维护操作必须“以业务堡垒机作为唯一安全入口”的最终目的。以下为核心路由器（CISCO C2600 Version 12.2）主要配置：
!
interface FastEthernet0/0.1
description link to server
encapsulation dot1Q 1 native
ip address 192.168.10.10 255.255.255.0
ip access-group passall in
ip access-group passall out
!
interface FastEthernet0/0.2
description link to OA
encapsulation dot1Q 2
ip address 192.168.20.1 255.255.255.0
ip access-group untrust in
ip access-group passall out
!
ip access-list extended untrust
permit tcp any host 192.168.100.4 eq 22
deny ip any 192.168.100.0 0.0.0.255
permit ip any any
!
通过上述配置可以确认：透过配置名为“untrust”的ACL实现用户不能访问192.168.100.0/24这个网段，仅仅只能访问业务堡垒机192.168.100.4的SSH服务（TCP22）的效果。原则上，通过上述配置我们可以认为这个环境已经满足‘业务堡垒机对远程维护操作进行统一帐号管理、认证、授权与审计’的目的了，且只有业务堡垒机（IP地址为192.168.100.4）是服务器区域的唯一入口。
现阶段正常情况下，处于OA区域的维护终端若要对处于服务器区的服务器进行维护操作，必须先利用SSH客户端（SecureCRT、Putty、…）登陆业务堡垒机，由业务堡垒机对客户端的自然人身份、权限进行鉴别，并对整个过程进行审计。但这里忽略上文所谈到的SSH特性—TCP Forward功能，下面我们通过实操确认一下该功能可实现的效果：
1） 第一步，我们在维护终端机器（192.168.20.197/24）上通过PING与SSH客户端连接服务器（192.168.100.2/24），可以确认“ACL策略已隔离OA区与服务器区的直接访问”；
2） 第二步，在维护终端机器（192.168.20.197/24）上打开SSH客户端Putty（本例用的是Putty，其实其它客户端程序也能完成该功能，只是操作过程存在差异而已），选择“Connection”->“SSH”->“Tunnels”分页：

在上图红色框框部分填入：
Source port（映射后的本机监听TCP端口，注意：该端口目前不能被其它程序所占用）；
Destination（被映射的TCP套接字，格式为“IP地址:TCP端口”）。
然后点击“Add”按钮，再回到“Session”分页，在“Host Name (or IP address)”输入栏输入业务堡垒机的IP地址，然后点击“Open”按钮进行连接。
3） SSH登陆成功后再启动Putty并连接本机的TCP5545端口即可直接连接192.168.100.2的SSH服务，且由于其通讯是基于SSH隧道的，因此业务堡垒机无法对其通讯内容进行审计。除本例所映射的SSH应用外，其它应用亦可使用相同的方法进行映射，从而绕过ACL。
在TCP Forward实验过程中发现以下问题：
ü 启动SSH客户端对业务堡垒机进行SSH连接，若处于登陆状态（即未登陆成功）或登陆失败皆无法进入TCP Forward状态；
ü 启动SSH客户端对业务堡垒机进行SSH登陆时可以使用任何权限的帐号，只有登陆成功即可进入TCP Forward状态；
ü 若SSH登陆成功但本地映射端口没有开启，则说明远端的被映射端口没有开启。
本文所利用的漏洞主要是由业务堡垒机SSH服务的TCP Forward功能引起的，因此最佳的杜绝手段是在业务堡垒机的SSH服务中停用并禁用TCP Forward功能，具体办法（本方法主要针对Openssh应用）是在/etc/ssh/sshd_config中加入以下语句：
AllowTcpForwarding no
并重新启动ssh服务。完成上述操作后其现象表现为，当用户通过自然人身份登陆业务堡垒机后，本地依然会开启相应的映射端口，但使用对应的客户端进行连接时却无法建立三次握手，下面重复上一个例子的操作（将远端的192.168.100.2:22映射至本地的TCP5545），再进行连接时将出现以下错误：

通过本文我们可以了解到：时下的安全产品无论是在设计上还有在功能上都已成熟，但只要存在一个大家可能忽略的小细节就可能导致其最终实现的成果遭到根本性的破坏。