CN107453861A - 一种基于ssh2协议的数据采集方法 - Google Patents

一种基于ssh2协议的数据采集方法 Download PDF

Info

Publication number
CN107453861A
CN107453861A CN201610371528.9A CN201610371528A CN107453861A CN 107453861 A CN107453861 A CN 107453861A CN 201610371528 A CN201610371528 A CN 201610371528A CN 107453861 A CN107453861 A CN 107453861A
Authority
CN
China
Prior art keywords
ssh2
channel
tcp
receiving terminal
ports
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201610371528.9A
Other languages
English (en)
Other versions
CN107453861B (zh
Inventor
宋磊
田娟娟
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Institute of Acoustics CAS
Beijing Intellix Technologies Co Ltd
Original Assignee
Institute of Acoustics CAS
Beijing Intellix Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Institute of Acoustics CAS, Beijing Intellix Technologies Co Ltd filed Critical Institute of Acoustics CAS
Priority to CN201610371528.9A priority Critical patent/CN107453861B/zh
Publication of CN107453861A publication Critical patent/CN107453861A/zh
Application granted granted Critical
Publication of CN107453861B publication Critical patent/CN107453861B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4633Interconnection of networks using encapsulation techniques, e.g. tunneling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • H04L67/141Setup of application sessions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • H04L67/147Signalling methods or messages providing extensions to protocols defined by standardisation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/26Special purpose or proprietary protocols or architectures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0863Generation of secret information including derivation or calculation of cryptographic keys or passwords involving passwords or one-time passwords

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

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

Description

一种基于SSH2协议的数据采集方法
技术领域
本发明涉及网络安全技术领域,具体涉及一种基于SSH2协议的数据采集方法。
背景技术
随着网络与信息技术的飞速发展,网络安全问题也日益突出。传统的网络服务程序如ftp、pop和telnet等都是以明文的方式在网络传送口令、数据等,容易受到攻击,存在着安全隐患,SSH协议是为了克服这种问题而提出的。SSH是SecureShell的缩写,它将所传输的数据进行加密,可以在不安全的网络上提供安全的数据传输。SSH2协议是SSH协议的2.x版本,是为了客服SSH协议的1.x版本存在的一些缺陷而提出的升级版本。SSH2协议从几个不同的角度强化其通信的完整性,主要由3个组件组成,即SSH连接协议(Connection Protocol)、SSH用户认证协议(UserAuthentication Protocol)、SSH传输层协议(Transport Layer Protocol)。三层一起在底层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,则检查打开信道类型。其中请求打开信道消息格式如下:
byte SSH_MSG_CHANNEL_OPEN
string channel type,US-ASCII编码
uint32 sender channel
uint32 initial window size
uint32 maximum packet size
……信道特定数据
其中,‘channel type’表明请求打开信道的类型,‘sender channel’是本消息发送方使用的信道的一个本地标识。根据上面所述请求打开信道消息格式,我们从中提取出请求打开信道的类型‘channel type’,此时如果请求打开的信道类型不是“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端口转发而言,其请求打开信道消息的格式如下:
byte SSH_MSG_CHANNEL_OPEN
string“direct-tcpip”
uint32 sender channel
uint32 initial window size
uint32 maximum packet size
string host to connect
uint32 port to connect
string originator IP address
uint32 originator port
根据上述消息格式记录TCP/IP端口转达的目的IP地址address to connect和目的端口port to connect,创建连接请求的主机IP地址originator IP address和端口originator port,这个信道所对应的SSH2客户端的本地编号sender channel,以及这个TCP/IP端口转发信道的方向,即内层会话是从SSH2客户端到SSH2服务器还是从SSH2服务器到SSH2客户端,对于本地TCP/IP端口转发而言,内层会话的方向是从SSH2客户端到SSH2服务端,与外层SSH会话的方向相同,对于这种情况,用SSH2客户端的本地编号sender channel作为这个内层会话的客户端的编号。
我们根据目的端口判定这个TCP/IP端口转发信道所对应的协议,根据这个协议来解析这个信道之后所传输的数据。端口和协议之间的对应关系是可以自己定义的,比如80是http/https协议,27017对应的是MongoDB协议等。
对于远程TCP/IP端口转发而言,是希望将到另一方的端口连接转发至本地,SSH2客户端需要显示请求远程TCP/IP端口转发,具体的消息格式如下:
表示SSH2客户端请求SSH2服务端将IP为address to bind,端口为port num tobind上的连接转发至本地。当SSH2服务端接收到这个请求消息后,监听这个端口上的连接。
当SSH2服务端监听到这个端口的连接时,SSH2服务端向SSH2客户端发送请求打开信道消息,这个消息的格式如下:
byte SSH_MSG_CHANNEL_OPEN
string“forwarded-tcpip”
uint32 sender channel
uint32 initial window size
uint32 maximum packet size
string address that was connected
uint32 port that was connected
string originator IP address
uint32 originator port
根据上述消息格式记录SSH2客户端要求SSH2服务端进行端口转发的IP地址address that was connected(SSH_MSG_GLOBAL_REQUEST消息中的address to bind)和端口port that was connect,以及创建连接请求的主机IP地址originator IPaddress和创建连接请求的主机的端口originator port,和这个信道所对应的SSH2服务端的本地编号,以及这个TCP/IP端口转发信道的方向。对于远程TCP/IP端口转发而言,内层会话的方向是从SSH2服务端到SSH2客户端,与外层SSH会话的方向相反,此时用SSH2服务端的本地编号sender channel作为这个内层会话的客户端的编号。与本地TCP/IP端口转发不同,我们无法从打开信道请求消息以及之前其他的消息中获得这个TCP/IP连接会话的目的地址,而创建连接请求的主机的端口originator port又通常是随机的,因此使用SSH2客户端要求SSH2服务端进行端口转发的port that was connect来判定这路TCP/IP端口转发信道所对应的协议,根据这个协议来解析这个信道之后所传输的数据。同理,端口和协议之间的对应关系是预先定义的。
记录完信息后,用接收端一侧的传输秘钥对明文数据进行加密后让送给接收端。SSH2接收端收到打开信道请求之后,决定是否打开该信道。如果成功打开此信道,则保留之前已记录的这个TCP/IP端口转发信道的相关信息,同时还要添加记录这个TCP/IP端口转发信道所对应的接收端的本地编号。具体来说,当接收端发送SSH_MSG_OPEN_CONFIRMATION消息,消息码91,表示能够打开此信道,这个消息的消息格式如下:
byte SSH_MSG_CHANNEL_OPEN_CONFIRMATION
uint32 recipient channel
uint32 sender channel
uint32 initial window size
uint32 maximum packet size
其中,‘recipient channel’是原打开信道请求中给出的信道编号,‘senderchannel’是接收端分配的信道编号。对于本地TCP/IP端口转发而言,是由SSH2服务端发送此消息,因此用SSH2服务端的本地编号,即这个消息中sender channel作为这个内层会话的服务端的编号,对于远程TCP/IP端口转发而言,由SSH2客户端发送此消息,因此用SSH2客户端的本地编号,即sender channel作为这个内层会话的服务端的编号。需要说明的是,SSH2客户端发送请求打开‘tcpip-forward’信道消息,SSH2服务端对这个消息应答;SSH2服务端发送请求打开‘forwarded-tcpip’信道消息,SSH2客户端对这个消息应答。
同时,如果SSH_MSG_CHANNEL_OPEN消息的接收方不支持指定的‘channeltype’,则接收方以SSH_MSG_CHANNEL_OPEN_FAILURE进行应答,当收到这个消息后删除之前记录的这个TCP/IP端口转发信道的信息,之后用接收端侧的密钥将此消息加密后,发送到对端。
当一个TCP/IP端口转发信道打开之后,收到这个信道所传输的数据时,首先用发送端一侧的传输密钥将数据包解密成明文数据。数据传输通过以下类型的消息实现。
byte SSH_MSG_CHANNEL_DATA
uint32 recipient channel
string data
这里需要从recipient channel判断这个数据包是否为之前记录的某个TCP/IP端口转发信道中的数据。具体来说:首先检查这个消息的方向,即是从SSH2客户端发向SSH2服务端还是从SSH2服务端发向SSH2客户端,然后遍历这个SSH2会话中记录的所有TCP/IP端口转发信道的相关信息。如果这个消息的方向和某个内层的TCP/IP连接信道会话的方向相同,且recipient channel和这个内层会话的服务端编号相同,或者如果这个消息的方向和某个内层的TCP/IP端口转发信道会话的方向相反,且recipient channel和这个内层会话的客户端编号相同,则这个数据包是该TCP/IP端口转发信道中的数据,然后从这个消息中提取这个信道所对应的TCP/IP连接的有效数据string data,根据这个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服务端能够重用相应的信道编码,同时也要用另一端的密钥将明文加密成密文,发送到此端口。
最后所应说明的是,以上实施例仅用以说明本发明的技术方案而非限制。尽管参照实施例对本发明进行了详细说明,本领域的普通技术人员应当理解,对本发明的技术方案进行修改或者等同替换,都不脱离本发明技术方案的精神和范围,其均应涵盖在本发明的权利要求范围当中。

Claims (4)

1.一种基于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信道所对应的协议解析该有效数据,并将解析结果作为采集结果进行输出。
2.根据权利要求1所述的基于SSH2协议的数据采集方法,其特征在于,所述“direct-tcpip”类型的请求打开信道消息中记录TCP/IP端口转发信道的相关信息包括:创建连接请求的主机IP地址和端口、TCP/IP连接目的IP地址和目的端口、TCP/IP端口转发信道所对应的SSH2客户端的本地编号。
3.根据权利要求1所述的基于SSH2协议的数据采集方法,其特征在于,所述“forwarded-tcpip”类型的请求打开信道消息中记录TCP/IP端口转发信道的相关信息包括:创建连接请求的主机IP地址和端口、SSH2客户端在请求打开信道消息之前要求SSH2服务端进行端口转发的IP地址和端口、TCP/IP端口转发信道所对应的SSH2服务端的本地编号。
4.根据权利要求1所述的基于SSH2协议的数据采集方法,其特征在于,当所述的发送端和接收端之间的数据传输结束后,该数据采集方法还包括更新步骤4)中所保留的TCP/IP端口转发信道的相关信息的步骤,具体包括:
步骤101)截取发送端和接收端分别输出的含有请求关闭信道消息的SSH2数据包,从其解密出的明文数据中获取接收端的本地编号,以该本地编号判定当前信道,如果是步骤4)中所保留的某一TCP/IP端口转发信道,则执行步骤102),否则,直接用接收端一侧的传输密钥对明文数据进行加密后让送给接收端;
步骤102)删除步骤101)中所述的某一TCP/IP端口转发信道的相关信息,并利用接收端一侧的传输密钥对含有该请求关闭信道消息的明文数据进行加密后让送给接收端。
CN201610371528.9A 2016-05-30 2016-05-30 一种基于ssh2协议的数据采集方法 Active CN107453861B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610371528.9A CN107453861B (zh) 2016-05-30 2016-05-30 一种基于ssh2协议的数据采集方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610371528.9A CN107453861B (zh) 2016-05-30 2016-05-30 一种基于ssh2协议的数据采集方法

Publications (2)

Publication Number Publication Date
CN107453861A true CN107453861A (zh) 2017-12-08
CN107453861B CN107453861B (zh) 2019-09-24

Family

ID=60485452

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610371528.9A Active CN107453861B (zh) 2016-05-30 2016-05-30 一种基于ssh2协议的数据采集方法

Country Status (1)

Country Link
CN (1) CN107453861B (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110493074A (zh) * 2019-07-19 2019-11-22 珠海金山网络游戏科技有限公司 一种服务器与客户端的测试方法及系统
CN111835728A (zh) * 2020-06-15 2020-10-27 广州海颐信息安全技术有限公司 隐匿特权访问真实网络和协议的方法及装置
CN112019563A (zh) * 2020-09-11 2020-12-01 成都运达科技股份有限公司 一种视频数据转发传输系统及方法
CN114338094A (zh) * 2021-12-09 2022-04-12 北京五八信息技术有限公司 请求头信息的采集方法、装置、电子设备及可读介质
CN115550464A (zh) * 2022-12-01 2022-12-30 北京安帝科技有限公司 基于工业互联网云平台的系统监控方法、电子设备与介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009177239A (ja) * 2008-01-21 2009-08-06 Mitsubishi Electric Corp ネットワーク中継装置
CN102801559A (zh) * 2012-08-03 2012-11-28 南京富士通南大软件技术有限公司 智能化局域网数据采集方法
CN104394129A (zh) * 2014-11-05 2015-03-04 中国科学院声学研究所 安全外壳ssh2协议数据的采集方法和装置
CN104683149A (zh) * 2015-02-09 2015-06-03 山东蚁巡网络科技有限公司 一种ssh和snmp无缝切换方法
CN105610983A (zh) * 2016-03-07 2016-05-25 北京荣之联科技股份有限公司 一种分布式的网络监控方法及系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009177239A (ja) * 2008-01-21 2009-08-06 Mitsubishi Electric Corp ネットワーク中継装置
CN102801559A (zh) * 2012-08-03 2012-11-28 南京富士通南大软件技术有限公司 智能化局域网数据采集方法
CN104394129A (zh) * 2014-11-05 2015-03-04 中国科学院声学研究所 安全外壳ssh2协议数据的采集方法和装置
CN104683149A (zh) * 2015-02-09 2015-06-03 山东蚁巡网络科技有限公司 一种ssh和snmp无缝切换方法
CN105610983A (zh) * 2016-03-07 2016-05-25 北京荣之联科技股份有限公司 一种分布式的网络监控方法及系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
张永涛: ""基于SSH2协议的WLAN数据采集分析系统"", 《电信技术》 *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110493074A (zh) * 2019-07-19 2019-11-22 珠海金山网络游戏科技有限公司 一种服务器与客户端的测试方法及系统
CN111835728A (zh) * 2020-06-15 2020-10-27 广州海颐信息安全技术有限公司 隐匿特权访问真实网络和协议的方法及装置
CN111835728B (zh) * 2020-06-15 2023-09-01 广州海颐信息安全技术有限公司 隐匿特权访问真实网络和协议的方法及装置
CN112019563A (zh) * 2020-09-11 2020-12-01 成都运达科技股份有限公司 一种视频数据转发传输系统及方法
CN112019563B (zh) * 2020-09-11 2023-04-07 成都运达科技股份有限公司 一种视频数据转发传输系统及方法
CN114338094A (zh) * 2021-12-09 2022-04-12 北京五八信息技术有限公司 请求头信息的采集方法、装置、电子设备及可读介质
CN115550464A (zh) * 2022-12-01 2022-12-30 北京安帝科技有限公司 基于工业互联网云平台的系统监控方法、电子设备与介质
CN115550464B (zh) * 2022-12-01 2023-03-24 北京安帝科技有限公司 基于工业互联网云平台的系统监控方法、电子设备与介质

Also Published As

Publication number Publication date
CN107453861B (zh) 2019-09-24

Similar Documents

Publication Publication Date Title
CN107018134B (zh) 一种配电终端安全接入平台及其实现方法
CN102347870B (zh) 一种流量安全检测方法、设备和系统
CN106375493B (zh) 一种跨网络通信的方法以及代理服务器
CN107453861A (zh) 一种基于ssh2协议的数据采集方法
CN108521331A (zh) 基于源地址的隐蔽信息发送系统及发送方法
CN114844730A (zh) 一种基于可信隧道技术构建的网络系统
CN111343083B (zh) 即时通信方法、装置、电子设备及可读存储介质
KR20040035902A (ko) 네트워크 주소 변환 상에서의 데이터 전송 방법 및 장치
CN105516062A (zh) 一种实现L2TP over IPsec接入的方法
CN105340242A (zh) 使用http的双向实时通讯系统
CN107124385A (zh) 一种基于镜像流的ssl/tls协议明文数据采集方法
Chavan et al. Secure CoAP using enhanced DTLS for Internet of things
Xu et al. Research on network security of VPN technology
CN108924157B (zh) 一种基于IPSec VPN的报文转发方法及装置
CN113872956A (zh) 一种审查ipsec vpn传输内容的方法及系统
CN107276996A (zh) 一种日志文件的传输方法及系统
CN105635076B (zh) 一种媒体传输方法和设备
CN103888334A (zh) IP分组网中VoIP多层加密方法及系统
CN102932359A (zh) 流媒体服务请求方法、装置和系统
CN102724133A (zh) 一种ip报文传输的方法及装置
CN104601459B (zh) 一种组域虚拟专用网络中报文处理方法和装置
CN108989486B (zh) 一种通信方法及通信系统
CN114629678B (zh) 一种基于tls的内网穿透方法及装置
CN115664738A (zh) 通信方法、装置、电子设备及计算机存储介质
CN106027508A (zh) 一种认证加密的数据传输方法及装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant