一种基于SSH2协议的数据采集方法与流程

本发明涉及网络安全技术领域，具体涉及一种基于ssh2协议的数据采集方法。

背景技术：

随着网络与信息技术的飞速发展，网络安全问题也日益突出。传统的网络服务程序如ftp、pop和telnet等都是以明文的方式在网络传送口令、数据等，容易受到攻击，存在着安全隐患，ssh协议是为了克服这种问题而提出的。ssh是secureshell的缩写，它将所传输的数据进行加密，可以在不安全的网络上提供安全的数据传输。ssh2协议是ssh协议的2.x版本，是为了客服ssh协议的1.x版本存在的一些缺陷而提出的升级版本。ssh2协议从几个不同的角度强化其通信的完整性，主要由3个组件组成，即ssh连接协议(connectionprotocol)、ssh用户认证协议(userauthenticationprotocol)、ssh传输层协议(transportlayerprotocol)。三层一起在底层tcp(或者其他类型)连接的基础上为上层提供一条安全的通信链路，如图1所示，其中ssh连接层通过多个信道多路复用一个单一的加密隧道来提供交换式会话、tcp/ip连接端口转发等。

ssh2协议的tcp/ip连接端口转发可以分为三种，正向端口转发、反向端口转发和动态端口转发。

ssh2本地端口(正向端口)转发是将本地端口上的连接转发至远程，通过监听本地的端口，一旦有数据传向这个端口，那么将这个端口上的数据通过ssh2的加密通道转发至目标主机。图2为ssh2本地tcp/ip端口转发的示意图，将主机a(ssh2客户端)端口xxxx上的连接通过主机b(ssh2服务端)转发到主机c的yyyy端口上。主机a想访问主机c上的服务，但是有些情况下主机a和主机c无法联通，而主机a和主机b可以连通，同时主机b可以和主机c连通，这时主机a(ssh2客户端)就可以用ssh2隧道先连上主机b(ssh2服务端)再通过其转发，这样就可以在无法连上主机c的情况下可以访问主机c上的服务。因此，这种情况下主机a和主机b之间就形成了一条ssh隧道，在这条隧道中数据传输为时时加密的，所以不用担心传输内容被诸如防火墙之类的软件屏蔽。因此，本地端口转发的一大用处就是在局域网内部通过建立一条至外网主机的ssh隧道，以此来访问被局域网网管屏蔽的外部服务。

与ssh2本地端口转发不同，ssh2远程端口转发(反向端口转发)是要将另一方的端口连接转发至本地，通过监听远程主机(ssh2服务端)上的端口，将这个端口上的数据通过ssh2的加密通道经由本地主机(ssh2客户端)转发至目的主机。ssh2远程tcp/ip端口转发如图3所示，将主机b(ssh2服务端)端口xxxx上的连接通过主机a(ssh2客户端)转发到主机c的yyyy端口上。主机a和主机b建立了ssh2连接，这时主机b(ssh2服务端)不能连通主机c，但是主机a可以连通主机c，那么主机b可以通过主机a间接访问主机c。ssh2远程端口转发可以用来实现从外网访问局域网内部的服务。

ssh2本地端口转发和ssh2远程端口转发都需要指定监听端口上数据的目标主机，与这两种端口转发不同，动态端口转发不需要指定数据的目标主机，而是根据应用协议本身决定数据的目的地址。ssh2动态端口转发实际上是在指定端口上创建了一个socks代理服务，对于这个端口的连接首先根据socks代理协议，获取连接的最终目的主机，然后通过ssh2打开信道请求打开一个“direct-tcpip”(本地端口转发)信道。ssh2本地端口转发和动态端口转发打开的都是“direct-tcpip”(本地端口转发)信道，而ssh2远程端口转发打开的是“forwarded-tcpip”(远程端口转发)信道。

ssh2提供的tcp/ip端口转发功能通常被称为ssh隧道，这种隧道功能自动提供了相应的加解密服务，在一定程度上保护了用户的隐私。但另一方面，它也允许一些被拦截的协议或应用封装在隧道内，以安全可靠的ssh2协议的形态在网络上传输。这种对其他未知应用的封装和隐藏无疑对网络安全产生了一定程度的影响，因此需要对其进行及时有效的识别。但是由于ssh2的加密特点，难以对封装在隧道内的应用进行有效的检测和识别，虽然现有技术也可以对ssh2协议数据进行采集，但往往都是通过ssh2代理服务器实现的(如图4所示)，客户端设备不能直接与服务端设备建立连接，而是客户端设备首先和代理服务器建立连接，然后由代理服务器和目标服务器建立连接，使得客户端设备和服务端设备通过代理服务器间接通信，代理服务器需要同时维护两个ssh2连接，此时需要完成二次登录操作，即先由客户端设备向代理服务器发起ssh连接和登录，然后由代理向服务端设备发起ssh连接并登录，根据获得的完整的ssh消息进行解密，以便将采集到的ssh2协议数据由密文数据转换为明文数据。这种采集方法中代理服务器显式地存在于网络中，拥有自己的ip地址，容易暴露代理服务器的网络位置，从而遭到针对性攻击。

技术实现要素：

本发明的目的在于，为了克服现有技术中采用代理服务器对ssh2协议数据进行采集时易暴露其网络位置，从而产生安全隐患的技术问题，提出了一种对封装在ssh2隧道内的应用会话能够进行实时采集的数据采集方法，能够使ssh2客户端设备直接与ssh2服务端建立会话连接，不需要二次登录，使数据采集设备不易遭到针对性攻击。

为实现上述目的，本发明提供的一种基于ssh2协议的数据采集方法，该方法包括：

步骤1)获取发送端与接收端之间在ssh2握手阶段传输的ssh2数据包，记录并修改该数据包信息，在ssh2握手阶段数据包传输结束后，以该ssh2数据包推导出一对传输密钥；

步骤2)截取发送端输出的含有请求打开信道消息的ssh2数据包，利用步骤1)推导出的发送端一侧的传输密钥，将含有请求打开信道消息的ssh2数据包解密成明文数据，检查其请求打开的信道类型，如果请求打开的信道类型不是为“forwarded-tcpip”或者“direct-tcpip”，则直接用接收端一侧的传输秘钥对将解密出的明文数据进行加密后让送给接收端，否则，执行步骤3)；

步骤3)从“forwarded-tcpip”或者“direct-tcpip”类型的请求打开信道消息中记录tcp/ip端口转发信道的相关信息，利用接收端一侧的传输密钥对含有该请求打开信道消息的明文数据进行加密后让送给接收端；

步骤4)当接收端收到请求打开信道消息之后，反馈决定是否打开该信道的执行消息，如果该执行消息为打开信道命令，则保留步骤3)中记录的tcp/ip端口转发信道的相关信息，同时还要添加记录这个tcp/ip端口转发信道所对应的接收端的本地编号，然后执行步骤5)；如果该执行消息为不打开信道命令，则删除步骤3)中记录的tcp/ip端口转发信道的相关信息；

步骤5)截取任一已打开的ssh2信道中传输的数据包，从其解密出的明文数据中获取接收端的本地编号，以该本地编号判定所述的ssh2信道是不是之前记录的需要采集分析的tcp/ip端口转发信道，如果不是，则直接将明文数据用接收端一侧的传输密钥加密后发送给接收端；如果是之前记录的需要采集分析的tcp/ip端口转发信道，则执行步骤6)；

步骤6)从步骤5)所解密的明文数据中提取出tcp/ip连接的有效数据，然后根据ssh2信道所对应的协议解析该有效数据，并将解析结果作为采集结果进行输出。

对于一个tcp/ip端口转发信道而言，需要根据这个信道对应的tcp/ip连接来判定这路连接对应的协议。具体而言，对于本地tcp/ip端口转发而言，用tcp/ip 连接的目的端口来判定这路端口转发所对应的协议，这里需要预先定义需要采集分析的协议和端口之间的对应关系；而对于远程tcp/ip端口转发而言，用ssh2客户端要求ssh2服务端进行端口转发的端口来判定这路tcp/ip连接所对应的协议。

作为上述技术方案的进一步改进，如果请求打开的信道类型是“direct-tcpip”，即本地tcp/ip端口转发信道类型，那么所述“direct-tcpip”类型的请求打开信道消息中记录tcp/ip端口转发信道的相关信息包括：创建连接请求的主机ip地址和端口，tcp/ip连接目的ip地址和目的端口，以及tcp/ip端口转发信道所对应的ssh2客户端的本地编号。因为是由ssh2客户端发送请求打开”direct-tcpip”信道消息，在记录相应的消息后，需要用ssh2服务端一侧的传输密钥对明文数据进行加密后让送给ssh2服务端。

作为上述技术方案的进一步改进，如果请求打开的信道类型是“forwarded-tcpip”，即远程tcp/ip端口转发信道类型，那么所述“forwarded-tcpip”类型的请求打开信道消息中记录tcp/ip端口转发信道的相关信息包括：创建连接请求的主机ip地址和端口，ssh2客户端在请求打开信道消息之前要求ssh2服务端进行端口转发的ip地址和端口，和tcp/ip端口转发信道所对应的ssh2服务端的本地编号。与本地tcp/ip端口转发信道不同，远程tcp/ip端口转发信道是由ssh2服务端发送请求打开“forwarded-tcpip”信道消息，在记录相应的消息后，需要用ssh2客户端一侧的传输秘钥对明文数据进行加密后让送给ssh2客户端。

作为上述技术方案的进一步改进，该数据采集方法还包括更新步骤4)中所保留的tcp/ip端口转发信道的相关信息的步骤，具体包括：

步骤101)当所述的发送端和接收端之间的数据传输结束之后，发送端和接收端都会发送请求关闭信道消息，来关闭信道。对此，截取发送端和接收端分别输出的含有请求关闭信道消息的ssh2数据包，从其解密出的明文数据中获取接收端的本地编号，根据该接收端的本地编号判定当前信道，如果是之前记录的需要采集分析的某一tcp/ip端口转发信道，且分别收到了发送端和接收端请求关闭信道消息后，则执行步骤102)，否则，直接用接收端一侧的传输密钥对明文数据进行加密后让送给接收端；

步骤102)删除步骤101)中所述的某一tcp/ip端口转发信道的相关信息，以便ssh2客户端和ssh2服务端可以重用相应的信道编码，并且用接收端一侧的传输密钥对含有该请求关闭信道消息的明文数据进行加密后发送给接收端。

本发明的一种基于ssh2协议的数据采集器及方法的优点在于：

利用本发明所提供的数据采集方法，对ssh2信道内的tcp/ip连接端口转发的数据进行采集分析，使得ssh2客户端设备能够直接地与ssh2服务端设备建立连接，不需要二次登录，在避免数据采集设备遭到针对性攻击的情况下，实现对封装在ssh2会话内的不同应用的数据根据相应协议进行解析，输出解析结果。

附图说明

图1为ssh2协议隧道的结构示意图。

图2为ssh2本地tcp/ip端口转发的结构示意图。

图3为ssh2远程tcp/ip端口转发的结构示意图。

图4为利用现有技术中基于ssh2协议的数据采集方法应用示意图。

图5为本发明实施例中的一种基于ssh2协议的数据采集方法流程图。

图6为利用本发明实施例中的基于ssh2协议的数据采集方法应用示意图。

具体实施方式

下面结合附图和实施例对本发明所述的一种基于ssh2协议的数据采集方法进行详细说明。

如图5所示，本发明提供的一种基于ssh2协议的数据采集方法，该方法具体包括如下步骤：

步骤1)获取发送端与接收端之间在ssh2握手阶段传输的ssh2数据包，记录并修改该数据包信息，并以该ssh2数据包推导出一对传输密钥；

步骤2)截取发送端输出的含有请求打开信道消息的ssh2数据包，利用步骤1)推导出的发送端一侧的传输密钥，将含有请求打开信道消息的ssh2数据包解密成明文数据，判断其请求打开的信道类型，如果不是“forwarded-tcpip”或者“direct-tcpip”类型，则直接用接收端一侧的传输密钥对明文数据进行加密后让送给接收端，否则，执行步骤3)；

步骤3)从“forwarded-tcpip”或者“direct-tcpip”类型的请求打开信道消息中记录tcp/ip端口转发信道的相关信息，利用接收端一侧的传输密钥对含有该请求打开信道消息的明文数据进行加密后让送给接收端；

步骤4)判断接收端以请求打开信道消息所反馈的执行消息，如果该执行消息为不打开信道命令，则删除步骤3)中记录的tcp/ip端口转发信道的相关信息，如果该执行消息为打开信道命令，则保留步骤3)中记录的tcp/ip端口转发信道的相关 信息，同时记录该tcp/ip端口转发信道的接收端的本地编号后，执行步骤5)；

步骤5)截取任一已打开的ssh2信道中传输的数据包，从其解密出的明文数据中获取接收端的本地编号，以该本地编号判定所述的ssh2信道，如果是之前记录的某一tcp/ip端口转发信道，则执行步骤6)，否则，直接用接收端一侧的传输密钥对明文数据进行加密后让送给接收端；

步骤6)从步骤5)所解密的明文数据中提取出tcp/ip连接的有效数据，然后根据ssh2信道所对应的协议解析该有效数据，并将解析结果作为采集结果进行输出。

实施例一

参考图5-6，在本实施例中，利用上述的数据采集方法对实时传输数据的ssh2信道进行操作的具体过程为：

首先，获取各ssh2信道所连接的发送端和接收端的两个方向的ssh2数据包。

其次，根据截获的ssh2数据包的不同类型进行中间处理：

如果ssh2数据包为ssh2握手阶段的数据包，则记录该数据包信息，并需要对相应的信息进行修改，替换为新的数据包信息。即当收到ssh2客户端或者ssh2服务端的消息时，为了之后能推导出传输密钥或者完成对ssh2服务端的验证等，不能直接转发给另一方，而需要对这些消息进行修改，同时因为这些原数据包消息还要用来推导出传输密钥，所以还要记录下来。在ssh2握手阶段数据包结束传输后，推导出一对传输密钥。即在握手阶段协商出一对传输密钥，其中一个是发送端一侧的密钥，另一个是接收端一侧的密钥。

如果ssh2数据包为密文阶段传输的数据包，利用上述推导出的发送端一侧的传输密钥解密成明文数据，然后根据ssh2协议内容，判断该ssh2数据包是何种消息，做出相应处理，判断得出的具体分类结果包括：

如果ssh2数据包是请求打开信道消息，即消息码是90，则检查打开信道类型。其中请求打开信道消息格式如下：

bytessh_msg_channel_open

stringchanneltype，us-ascii编码

uint32senderchannel

uint32initialwindowsize

uint32maximumpacketsize

……信道特定数据

其中，‘channeltype’表明请求打开信道的类型，‘senderchannel’是本 消息发送方使用的信道的一个本地标识。根据上面所述请求打开信道消息格式，我们从中提取出请求打开信道的类型‘channeltype’，此时如果请求打开的信道类型不是“forwarded-tcpip”或者“direct-tcpip”，然后用接收端一侧的传输秘钥对将解密出的明文数据再次进行加密后让送给接收端。

如果请求打开的信道类型是“forwarded-tcpip”或者“direct-tcpip”，即远程tcp/ip端口转发或者本地tcp/ip端口转发信道类型，则根据这个请求打开信道消息，记录其tcp/ip端口转发信道的相关信息。这里需要说明的是，虽然ssh2协议的tcp/ip连接端口转发可以分为三种，即正向端口转发、反向端口转发和动态端口转发，但是ssh2动态端口转发实际上是在指定端口上创建了一个socks代理服务，对于这个端口的连接首先根据sockts代理协议，获取连接的最终目的主机，然后通过ssh2的打开信道请求打开一个“direct-tcpip”(本地端口转发)信道。因此收到的tcp/ip端口转发信道只有“forwarded-tcpip”和”direct-tcpip”两种类型。

对于本地tcp/ip端口转发而言，其请求打开信道消息的格式如下：

bytessh_msg_channel_open

string“direct-tcpip”

uint32senderchannel

uint32initialwindowsize

uint32maximumpacketsize

stringhosttoconnect

uint32porttoconnect

stringoriginatoripaddress

uint32originatorport

根据上述消息格式记录tcp/ip端口转达的目的ip地址addresstoconnect和目的端口porttoconnect，创建连接请求的主机ip地址originatoripaddress和端口originatorport，这个信道所对应的ssh2客户端的本地编号senderchannel，以及这个tcp/ip端口转发信道的方向，即内层会话是从ssh2客户端到ssh2服务器还是从ssh2服务器到ssh2客户端，对于本地tcp/ip端口转发而言，内层会话的方向是从ssh2客户端到ssh2服务端，与外层ssh会话的方向相同，对于这种情况，用ssh2客户端的本地编号senderchannel作为这个内层会话的客户端的编号。

我们根据目的端口判定这个tcp/ip端口转发信道所对应的协议，根据这个协议 来解析这个信道之后所传输的数据。端口和协议之间的对应关系是可以自己定义的，比如80是http/https协议，27017对应的是mongodb协议等。

对于远程tcp/ip端口转发而言，是希望将到另一方的端口连接转发至本地，ssh2客户端需要显示请求远程tcp/ip端口转发，具体的消息格式如下：

表示ssh2客户端请求ssh2服务端将ip为addresstobind，端口为portnumtobind上的连接转发至本地。当ssh2服务端接收到这个请求消息后，监听这个端口上的连接。

当ssh2服务端监听到这个端口的连接时，ssh2服务端向ssh2客户端发送请求打开信道消息，这个消息的格式如下：

bytessh_msg_channel_open

string“forwarded-tcpip”

uint32senderchannel

uint32initialwindowsize

uint32maximumpacketsize

stringaddressthatwasconnected

uint32portthatwasconnected

stringoriginatoripaddress

uint32originatorport

根据上述消息格式记录ssh2客户端要求ssh2服务端进行端口转发的ip地址addressthatwasconnected(ssh_msg_global_request消息中的addresstobind)和端口portthatwasconnect，以及创建连接请求的主机ip地址originatoripaddress和创建连接请求的主机的端口originatorport，和这个信道所对应的ssh2服务端的本地编号，以及这个tcp/ip端口转发信道的方向。对于远程tcp/ip端口转发而言，内层会话的方向是从ssh2服务端到ssh2客户端，与外层ssh会话的方向相反，此时用ssh2服务端的本地编号senderchannel作为这个内层会话的客户 端的编号。与本地tcp/ip端口转发不同，我们无法从打开信道请求消息以及之前其他的消息中获得这个tcp/ip连接会话的目的地址，而创建连接请求的主机的端口originatorport又通常是随机的，因此使用ssh2客户端要求ssh2服务端进行端口转发的portthatwasconnect来判定这路tcp/ip端口转发信道所对应的协议，根据这个协议来解析这个信道之后所传输的数据。同理，端口和协议之间的对应关系是预先定义的。

记录完信息后，用接收端一侧的传输秘钥对明文数据进行加密后让送给接收端。ssh2接收端收到打开信道请求之后，决定是否打开该信道。如果成功打开此信道，则保留之前已记录的这个tcp/ip端口转发信道的相关信息，同时还要添加记录这个tcp/ip端口转发信道所对应的接收端的本地编号。具体来说，当接收端发送ssh_msg_open_confirmation消息，消息码91，表示能够打开此信道，这个消息的消息格式如下：

bytessh_msg_channel_open_confirmation

uint32recipientchannel

uint32senderchannel

uint32initialwindowsize

uint32maximumpacketsize

其中，‘recipientchannel’是原打开信道请求中给出的信道编号，‘senderchannel’是接收端分配的信道编号。对于本地tcp/ip端口转发而言，是由ssh2服务端发送此消息，因此用ssh2服务端的本地编号，即这个消息中senderchannel作为这个内层会话的服务端的编号，对于远程tcp/ip端口转发而言，由ssh2客户端发送此消息，因此用ssh2客户端的本地编号，即senderchannel作为这个内层会话的服务端的编号。需要说明的是，ssh2客户端发送请求打开‘tcpip-forward’信道消息，ssh2服务端对这个消息应答；ssh2服务端发送请求打开‘forwarded-tcpip’信道消息，ssh2客户端对这个消息应答。

同时，如果ssh_msg_channel_open消息的接收方不支持指定的‘channeltype’，则接收方以ssh_msg_channel_open_failure进行应答，当收到这个消息后删除之前记录的这个tcp/ip端口转发信道的信息，之后用接收端侧的密钥将此消息加密后，发送到对端。

当一个tcp/ip端口转发信道打开之后，收到这个信道所传输的数据时，首先用 发送端一侧的传输密钥将数据包解密成明文数据。数据传输通过以下类型的消息实现。

bytessh_msg_channel_data

uint32recipientchannel

stringdata

这里需要从recipientchannel判断这个数据包是否为之前记录的某个tcp/ip端口转发信道中的数据。具体来说：首先检查这个消息的方向，即是从ssh2客户端发向ssh2服务端还是从ssh2服务端发向ssh2客户端，然后遍历这个ssh2会话中记录的所有tcp/ip端口转发信道的相关信息。如果这个消息的方向和某个内层的tcp/ip连接信道会话的方向相同，且recipientchannel和这个内层会话的服务端编号相同，或者如果这个消息的方向和某个内层的tcp/ip端口转发信道会话的方向相反，且recipientchannel和这个内层会话的客户端编号相同，则这个数据包是该tcp/ip端口转发信道中的数据，然后从这个消息中提取这个信道所对应的tcp/ip连接的有效数据stringdata，根据这个tcp/ip连接所对应的协议对有效数据进行解析，解析结果作为采集结果进行输出。同时也要用接收端一侧的密钥将明文加密成密文后，发送到接收端。

如果遍历完这个ssh2会话中记录的所有tcp/ip端口转发信道的相关信息后，都不满足上述条件，则判定这个数据包不是之前记录的tcp/ip端口转发信道中所传输的数据，此时直接用接收端一侧的密钥将明文加密成密文后，发送到接收端。

当一个信道的数据传输结束时，ssh2客户端和ssh2服务端都会发送ssh_msg_channel_close消息，即消息码96，来关闭这个信道。当收到一个ssh_msg_channel_close消息时，首先判断要关闭的信道是否为之前记录的tcp/ip端口转发信道，如果不是，则直接用另一端的密钥将明文加密成密文后，发送到此端口。如果是，则改变信道的状态为半关闭状态，当既收到了ssh2客户端发送的终止信道消息，同时又收到了ssh2服务端发送的终止信道消息后，删除所记录的这个tcp/ip端口转发信道的信息，以便ssh2客户端和ssh2服务端能够重用相应的信道编码，同时也要用另一端的密钥将明文加密成密文，发送到此端口。

最后所应说明的是，以上实施例仅用以说明本发明的技术方案而非限制。尽管参照实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，对本发明的技术方案进行修改或者等同替换，都不脱离本发明技术方案的精神和范围，其均 应涵盖在本发明的权利要求范围当中。