WO2016082371A1 - 一种基于ssh协议的会话解析方法及系统 - Google Patents

一种基于ssh协议的会话解析方法及系统 Download PDF

Info

Publication number
WO2016082371A1
WO2016082371A1 PCT/CN2015/074091 CN2015074091W WO2016082371A1 WO 2016082371 A1 WO2016082371 A1 WO 2016082371A1 CN 2015074091 W CN2015074091 W CN 2015074091W WO 2016082371 A1 WO2016082371 A1 WO 2016082371A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
log
data packet
session
length
Prior art date
Application number
PCT/CN2015/074091
Other languages
English (en)
French (fr)
Inventor
宋磊
吴京洪
郑艳伟
叶晓舟
曹作伟
Original Assignee
中国科学院声学研究所
北京中科智网科技有限公司
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 中国科学院声学研究所, 北京中科智网科技有限公司 filed Critical 中国科学院声学研究所
Priority to EP15863662.1A priority Critical patent/EP3211852A4/en
Priority to JP2017528151A priority patent/JP2017539163A/ja
Publication of WO2016082371A1 publication Critical patent/WO2016082371A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/168—Implementing security features at a particular protocol layer above the transport layer

Definitions

  • the invention belongs to the technical field of computer networks, and particularly relates to a session analysis method and system based on the SSH protocol.
  • Protocols are the means of communication between various computer applications and applications. Protocol analysis has become an indispensable technology in network applications.
  • the communication parties encapsulate the communication content in the protocol for transmission, and some protocols also encrypt the transmitted data, such as the SSH protocol, which is a protocol for secure remote login and other secure network services on an insecure network, through the SSH channel.
  • the transmitted data is encrypted data.
  • the monitoring of user behavior is generally implemented by adding a middleman between the server and the client.
  • the data packets intercepted by the middleman are encrypted content, which need to be decrypted into plaintext packets first, and then in plaintext.
  • the data packet is parsed, and the parsing log is generated after parsing.
  • the auditor can reproduce all the operating behaviors of the client by parsing the log, thereby providing security for the business systems of these enterprises or organizations.
  • the purpose of the audit is to monitor the behavior of the client without affecting the normal communication quality between the client and the server.
  • the processing efficiency of the intermediary affects the communication quality between the client and the server, and protocol resolution is an important step for the intermediary to handle. This also puts higher requirements on the efficiency of protocol parsing.
  • the analysis based on the SSH protocol is less, and the existing protocol parsing techniques are often only applicable to some preset fixed scenarios, and the scalability is poor.
  • the current method is mainly based on pure soft parsing, and the performance of concurrency needs to be improved.
  • the object of the present invention is to provide audit support for the business systems of certain enterprises or institutions, thereby A session analysis method and system based on SSH protocol.
  • the present invention provides a session parsing method based on the SSH protocol, and the method includes:
  • Step 101 Receive a data packet based on the SSH protocol session, and perform the following preprocessing on the received data packet:
  • each complete message is sequentially extracted from the data packet
  • the incomplete message included in the current data packet is first cached, then the subsequent data packet is received, and finally the message contained in the subsequent data packet is spliced with the cached message content until Splicing out a complete message;
  • Step 102 Extract the content related to the generated log from the obtained complete messages, and encapsulate the content related to the log according to the set format, thereby obtaining the parsing log to complete the session parsing.
  • the method further includes:
  • Step 103) Send the generated parsing log to the log server in a streaming mode
  • the streaming mode is: writing the generated parsing log to the log cache, and sending the parsing log information to the log server immediately when the cached log length reaches the set sending length.
  • step 101) further includes:
  • Step 101-1) After receiving a data packet based on the SSH protocol session, first check whether there is a cached data packet in the buffer area, and if there is no cache data packet, directly calculate the length of the first message in the received data packet; If there is a cached data packet in the cache, it indicates that the current data packet is a continuation of the content contained in the cache data packet, and then the current data packet content is copied to the cache data packet, and then the incomplete message is spliced, and then the current data is spliced and then calculated. Slow The length of the first message in the stored data packet;
  • Step 101-2 comparing the calculated length of the first message with the length of the received data packet, and performing the following steps for different situations of the decision result:
  • Step 101-2-3 If the length of the first message is greater than the length of the data packet, the data packet is buffered to complete the splicing of several data packets, and finally a complete message is obtained, and the obtained complete message is parsed. .
  • step 102) is specifically:
  • Step 102-1 Identify the message type according to the message code, and determine whether the message is related to the log generation according to the identified type. If the message is irrelevant to the generated log, directly discard the message; otherwise, perform different types of messages related to the generated log. Processing as follows:
  • For the version negotiation message obtain the protocol version number in the message and cache it;
  • the user name is extracted from the message and cached;
  • For the channel request message obtain the requested channel type and cache
  • the message direction is judged to belong to the request or the response, and the message direction is cached; wherein, if the message direction is from the client to the server, it is a request message, and vice versa is a response message;
  • Step 102-2 Generate a parsing log based on the cached content and the response packet, and the generated log includes: a TCP/IP quad, a session ID, a login user name, a login time, a client request command, and a request start time. The response data and response end time returned by the server to the client;
  • the request command of the client and the response data of the server returning the client can occur repeatedly during the lifetime of a session, and each parsed log generated includes only one client request command and one server-side response, that is, different parsing logs. Requests and responses are independent of each other;
  • the TCP/IP quad, session ID, login session username, and login time information remain unchanged during the lifetime of a session.
  • each input of the client is sent to the server in the form of a message, and the input result is presented in the terminal through the echo message returned by the server; by identifying the escaped character in the echo message,
  • the accurate control of the cursor position, combined with the request character recovery request command carried in the message, immediately writes the restored request command to the log buffer when it detects the end of the client request. Only the data returned by the server to the client after the user request ends is used as the response data, and the response data is sequentially written into the log cache.
  • the log segment is sent immediately, for the last log. The transmission of the fragment can be driven by the next request or by a timer.
  • the present invention also provides a session resolution system based on the SSH protocol, the system comprising:
  • the packet processing module is configured to receive the data packet based on the SSH protocol session, and perform the following preprocessing on the received data packet:
  • each complete message is sequentially extracted from the data packet
  • the incomplete message included in the current data packet is first cached, then the subsequent data packet is received, and finally the message contained in the subsequent data packet is spliced with the cached message content until Splicing out a complete message;
  • the parsing module is configured to extract content related to the generated log from the obtained complete messages, and encapsulate the content related to the log according to the set format, thereby obtaining parsing log completion session parsing.
  • the above system further comprises:
  • the log sending module is configured to send the generated parsing log to the log server by using a streaming sending mode, where the streaming sending mode is: writing the generated parsing log into the log buffer, and when the cached log length is set When the length of the transmission is fixed, the log is sent to the log server immediately.
  • FIG. 1-a is a schematic diagram showing the logical structure of each module of the parsing system provided by the present invention.
  • FIG. 1-b is a schematic diagram of an application scenario of the parsing system of the present invention.
  • FIG. 2 is a process flow diagram of a packet processing module in the method of the present invention.
  • FIG. 4 is a schematic diagram of a format of a log segment of a streaming method in the method of the present invention.
  • FIGS. 1-a and 1-b FIGS. 1-a and 1-b
  • FIG. 1-a is a schematic diagram of the logical structure of three modules
  • FIG. 1-b is a schematic diagram of the analysis system.
  • the packet processing module is configured to process the received data packet, and the relationship between the received data packet and the message is a many-to-many mapping, that is, one or more messages may be included in one data packet, or one message may exist in the data packet.
  • the message content is likely to be missed, and the parsing is incomplete. Therefore, before parsing, the data packet needs to be processed first.
  • the message is sequentially extracted from the packet, and a complete message is extracted each time. If the message contained in the packet is incomplete, it will be incomplete. The message is cached.
  • the parsing module After the subsequent data packet is received, the new data and the content of the message in the cache are spliced until a complete message is spliced and submitted to the parsing module for processing. After the module processing, the parsing module is greatly simplified. The processing flow improves the efficiency of the analysis.
  • the parsing module is the core module of the method. It is responsible for identifying, analyzing, and extracting the content related to the generated log from a complete SSH message and processing it, and finally generating a parsing log conforming to the established format.
  • the input to the parsing module is a complete SSH message with the following message format:
  • the parsing module After the parsing module obtains the message, it first obtains the message code from the payload.
  • the message code is a unique identifier of the message type.
  • the message code can be used to know which phase of the SSH protocol the current message corresponds to, and then perform different analysis on the SSH messages of different phases.
  • the processing such as SSH_MSG_USERAUTH_REQUEST, corresponds to the user authentication request phase of the SSH protocol, and the method for parsing the phase message is mainly to obtain the username for requesting authentication. Since the packet processing module does not identify the data packet, the packet processing module processes all the data packets in the SSH session, and the message received by the parsing module necessarily contains some messages that are not related to the parsing process. For such messages, the parsing module does not Any processing, directly discard.
  • the log sending module is mainly responsible for sending the generated logs to the log server.
  • the traditional method is to wait for a log to be generated and then send it, and the method uses the streaming mode to transmit the log.
  • the parsing module generates a log while parsing the edge, and the generated log is written into the log cache. When the length of the cached log reaches the sending length, the log is sent immediately. It is not necessary to wait until a complete log is generated before sending the log, and the sending module logs the log. Monitoring and timely processing have improved the efficiency of log transmission to a certain extent, and also greatly saved the cache space.
  • the foregoing packet processing module further includes:
  • the first processing sub-module is configured to first check whether there is a cached data packet in the buffer area after receiving a data packet based on the SSH protocol session, and directly calculate the first message in the received data packet if there is no cache data packet.
  • the length and drive the second processing sub-module if there is a cache data packet in the cache, it indicates that the current data packet is a continuation of the content contained in the cache data packet, and directly drives the third processing unit;
  • a second processing submodule configured to enter a length of the calculated first message and a length of the received data packet
  • the first processing unit if the length of the first message is equal to the length of the received data packet, indicating that the current data packet content is exactly a complete message, the message can be directly parsed;
  • the second processing unit if the length of the first message is smaller than the length of the data packet, splitting the data packet, that is, extracting the complete message from the data packet, and characterizing a complete message by using the message first address and the message length Message
  • the third processing unit if the length of the first message is greater than the length of the data packet, completes the splicing of several data packets by buffering the data packet, and finally obtains a complete message, and then calculates the length of the complete message and completes the obtained message.
  • the message is parsed.
  • the foregoing parsing module further includes:
  • the message filtering sub-module is configured to identify the message type according to the message code, and determine whether the message is related to the log generation according to the identified type. If the message is not related to the generated log, the message is directly discarded; otherwise, the message related to the generated log is directly discarded. Perform the following processing separately:
  • For the version negotiation message obtain the protocol version number in the message and cache it;
  • the user name is extracted from the message and cached;
  • For the channel request message obtain the requested channel type and cache
  • the direction of the message For messages transmitted in the channel, it is determined by the direction of the message whether it belongs to the request or the response, and the direction of the message is cached. Wherein, if the message direction is from the client to the server, it is a request message, and vice versa is a response message;
  • the log generation submodule is configured to generate a parsing log based on the cached content and the response packet, and the parsing log includes: a TCP/IP quad, a session ID, a login user name, a login time, a client request command, and a request start. Time, the response data returned by the server to the client and the response end time;
  • the request command of the client and the response data of the server returning the client can occur repeatedly during the lifetime of a session, and each parsed log generated includes only one client request command and one server-side response, that is, different parsing logs. Requests and responses are independent of each other;
  • the TCP/IP quad, session ID, login session username, and login time information remain unchanged during the lifetime of a session.
  • the foregoing log sending module further includes:
  • the encapsulation submodule is used to fill a log header when the log is sent.
  • the log header includes: a log number, a segmentation, a segmentation number, and a last segment; wherein, the log number, Used to represent a unique log; "whether segmentation" is used to mark whether the log is sent in segments. If the identifier is 0, the content of this paragraph is the entire log content; otherwise, the log is divided into several segments; The segment number and the last segment are meaningful only when the "segmentation" flag is 1, and the "segment number" is the unique identifier of the log segment;
  • a sending submodule configured to send the encapsulated log to the storage server
  • the storage server After receiving the log segment, the storage server will splicing the log segments with the same "log number" according to the "segment number" from small to large, and then piece together a complete log.
  • the present invention proposes a session parsing method based on SSH protocol.
  • the session resolution method based on the SSH protocol provided by the present invention comprises the following steps, the method processing the plaintext SSH data packet:
  • the packet processing module After each SSH packet arrives, it is submitted to the packet processing module.
  • the packet before processing may contain one An incomplete message may also contain a complete message, and may also contain multiple messages.
  • the packet processing module generates a complete message for parsing and splicing of the data packet for parsing by the protocol parsing module.
  • the process of packet splitting is actually a process of extracting a message from a packet, and characterizing a message by using a message first address and a message length; and the process of packet splicing is implemented by buffering a data packet, and the process of submitting to the packet processing module is
  • the reassembled data packet can guarantee the timing of the SSH packet, which ensures the integrity of the spliced message and the correctness of the message content.
  • the protocol parsing module identifies the message type according to the message code. Different message types correspond to different phases of the SSH session. The parsing module recognizes that the message is related to the log generation, and parses the message header. If the message is not related to the generated log, the message is Discard directly.
  • the method for parsing different types of messages is different.
  • the message is cached directly.
  • the user name is extracted from the message and cached.
  • the channel request message the requested channel type is obtained, and the channel type is ensured.
  • the channel is used for the SSH session.
  • the message transmitted in the channel it is judged whether it belongs to the request or the response through the message direction. If the message direction is C ⁇ S, it is the request message, and if the message direction is S ⁇ C, it is the response message. Parse different types of messages and cache related content to generate parsing logs.
  • the log generated by the method includes information such as TCP/IP quaternion, session ID, user name of login session, login time, etc.
  • information such as TCP/IP quaternion, session ID, user name of login session, login time, etc.
  • TCP maintained during parsing
  • the information of the /IP quad, session ID, login session username, login time, etc. will not change during the lifetime of a session.
  • the generated log also includes the command requested by the client, the request start time, the response data returned by the server to the client, and the response end time.
  • the client request and the server response can occur repeatedly during the lifetime of a session.
  • the method defines that each log contains and contains only one request and one response, so Different logs of the same session share information such as TCP/IP quaternion, session ID, user name of login session, login time, etc.
  • the requests and responses of different logs are independent of each other.
  • a log-side buffer is generated, and the log transmission is performed by means of streaming. That is, when the length of the cached log reaches the transmission length, the log is sent to the specified storage server, and the log is not sent until all the logs are generated.
  • FIG. 2 is a process flow diagram of a packet processing module, including the following steps:
  • the packet processing module After receiving a data packet, the packet processing module first checks whether there is a cached data packet in the buffer area. If there is no cache data packet, directly calculates the length of the first message in the data packet; if there is a cache data packet, it indicates The current data packet is a continuation of the content of the cached data packet. After the current data packet content is copied to the cache data packet, the incomplete message is spliced, and the length of the first message in the currently cached data packet is calculated after splicing;
  • the message length is smaller than the packet length, it indicates that the current data packet contains more than one complete message, the first complete message is taken out from the data packet, submitted to the parsing module for parsing, and then the first message in the remaining data packet is calculated. Length, repeat step b);
  • the length of the message is greater than the length of the data packet, it indicates that the current data packet contains only a part of a message, and the incomplete message cannot be submitted to the parsing module. If the current data packet has not been cached, the data packet is cached. The packet is already in the buffer, then the packet content is moved to the buffer header for subsequent Cache packets to make room for memory.
  • the user input may use various shortcut keys or function keys to restore the user's request, and need to recognize and understand the echo message returned by the server to the client, and understand the echo message.
  • the key is to identify the escape character in the echo message.
  • Table 1 is an escape character set in an echo message of the method of the present invention
  • the client Each time the client enters a request, it receives an echo message from the server.
  • the echo message includes escape characters, as shown in Table 1, which can be accurately located by parsing the escaped characters. The position of the cursor and the current request content at any time, so that a complete restoration of any requested content can be achieved.
  • FIG. 3 is a response analysis flowchart, including the following steps:
  • the parsing module receives a message of S ⁇ C and determines whether the request status is “complete”. ;
  • the request status is "Complete"
  • the response message starts with ‘ ⁇ r ⁇ n', and when the ‘ ⁇ r ⁇ n’ message is received, the response status is set to “READY”.
  • the method handles the response by writing all response message content directly into the cache log when the response status is "READY”.
  • next request is reached as the identifier of the end of the previous response.
  • the response end time and the log end tag are added to the end of the cache log, and the log is immediately sent.
  • the timer triggers the log sending module to monitor the log status. If the log status is not related to the previous timing period. A change indicates that the entire log has been generated and the currently cached log fragment should be sent immediately.
  • log header is added to each log segment.
  • the format of the log header is as shown in the figure. 4 is shown in the dotted box.
  • the "log number” is used to represent a unique log; whether "segmentation” is used to mark whether the log is sent in segments. If the identifier is 0, the content of this segment is the entire log content. Otherwise, the log is It is divided into several segments; the "segment number" and the “last segment” are meaningful only when the "segmentation” flag is 1.
  • the "segment number” is the unique identifier of the log segment, and the storage server will have the log segment.
  • the same "log number” log segment can be pieced together to complete a complete log by splicing from "segment number" to small.
  • Table 2 is a log format customized by the method of the present invention
  • the present invention proposes a session parsing method based on the SSH protocol, which involves three modules: a packet processing module, a parsing module, and a log sending module.
  • the packet processing module splits and splices the arriving data packets to obtain a complete message and submits it to the parsing module;
  • the parsing module distinguishes the message type by the message code, and extracts different content from different types of messages.
  • each log contains and only contains one request and one response;
  • the log sending module is responsible for monitoring the log status, and transmitting the log by means of streaming, that is, when When the length of the locally cached log reaches the sending length, the log sending module immediately sends the log to the storage server, and does not need to wait for the log generation to complete before sending, thus saving cache space.
  • the technology of the present invention can implement auditing based on SSH sessions, and can provide security for organizations such as banks.

Landscapes

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

Abstract

本发明提出了一种基于SSH协议的会话解析方法及系统，所述方法包含：步骤101)接收基于SSH协议会话的数据包，并对接收的数据包分别进行如下预处理：当一个数据包包含若干条完整的消息时，从该数据包中依次提取出每一条完整的消息；当一个数据包所含的消息不完整时，首先将当前数据包包含的不完整的消息进行缓存，然后接收后续的数据包，最后将后续数据包包含的消息和缓存的消息内容进行拼接，直至拼接出一条完整的消息；步骤102)从得到的各条完整的消息中提取与生成日志相关的内容，并按照设定的格式封装与日志相关的内容，进而得到解析日志完成会话解析。本发明的技术能实现基于SSH会话的审计，可以为诸如银行等机构提供安全保障。

Description

一种基于SSH协议的会话解析方法及系统 技术领域
本发明属于计算机网络技术领域，具体涉及到一种基于SSH协议的会话解析方法及系统。
背景技术
协议是各种计算机应用中及应用间通信的方式，协议解析已成为网络应用中不可或缺的技术。通信双方将通信内容封装在协议中进行传输，某些协议还对传输的数据进行加密，如SSH协议，它是在不安全的网络上进行安全远程登录和其他安全网络服务的协议，通过SSH信道传输的数据均为加密数据。
在某些企业或机构的业务系统中，需要对用户端的登陆和操作行为进行监控和记录，用于业务审计。而对用户行为的监控一般采用在服务端和客户端之间加入中间人来实现，对于SSH协议而言，中间人截获的数据包均为加密内容，需要先将其解密为明文数据包，再对明文数据包进行解析，解析之后生成解析日志，审计人员可以通过解析日志重现客户端的所有操作行为，从而为这些企业或机构的业务系统提供了安全保障。审计的目的在于不影响客户端和服务器之间正常通信质量的前提下对客户端行为进行监控，中间人的处理效率会影响到客户端和服务端的通信质量，而协议解析是中间人处理很重要的一步，这对协议解析的效率也提出了更高的要求。
目前，基于SSH协议的解析较少，现有协议解析技术往往都只适用于一些预设的固定场景，可扩展性较差。此外，当前方法还是以纯软的解析方式为主，并发性能还有待提高。
发明内容
本发明的目的在于，为了为某些企业或机构的业务系统提供审计支持，从而提出了 一种基于SSH协议的会话解析方法及系统。
为了实现上述目的，本发明提供一种基于SSH协议的会话解析方法，所述方法包含：
步骤101)接收基于SSH协议会话的数据包，并对接收的数据包分别进行如下预处理：
当一个数据包包含若干条完整的消息时，从该数据包中依次提取出每一条完整的消息；
当一个数据包所含的消息不完整时，首先将当前数据包包含的不完整的消息进行缓存，然后接收后续的数据包，最后将后续数据包包含的消息和缓存的消息内容进行拼接，直至拼接出一条完整的消息；
步骤102)从得到的各条完整的消息中提取与生成日志相关的内容，并按照设定的格式封装与日志相关的内容，进而得到解析日志完成会话解析。
可选的，上述步骤102)之后还包含：
步骤103)将生成的解析日志采用流式发送模式发送至日志服务器；
其中，所述的流式发送模式为：将生成的解析日志写入日志缓存中，当缓存的日志长度达到设定的发送长度时，立即向日志服务器发送解析日志信息。
可选的，上述步骤101)进一步包含：
步骤101-1)当收到一个基于SSH协议会话的数据包后，首先查看缓存区是否有缓存数据包，若不存在缓存数据包，则直接计算接收的数据包中第一条消息的长度；若缓存中存在缓存数据包，则表示当前数据包是缓存数据包包含的内容的延续，则将当前数据包内容拷贝到缓存数据包之后，进而对不完整的消息进行拼接，拼接后再计算当前缓 存的数据包中第一条消息的长度；
步骤101-2)将计算得出的第一条消息的长度和接收的数据包的长度进行比较，针对判决结果的不同情况分别执行如下步骤：
步骤101-2-1)若第一条消息的长度等于接收的数据包长度，表示当前数据包内容恰好为一条完整的消息，则能够对该消息直接进行解析；
步骤101-2-2)若第一条消息的长度小于数据包的长度，则对该数据包进行拆分处理，即从数据包中提取完整的消息，并采用消息首地址和消息长度表征一条完整的消息；
步骤101-2-3)若第一条消息的长度大于数据包的长度，则通过缓存该数据包进而完成若干数据包的拼接，最终得到一条完整的消息，并将得到的完整的消息进行解析。
上述步骤102)具体为：
步骤102-1)根据消息码识别消息类型，进而依据识别的类型判断消息与日志生成是否相关，若消息与生成日志无关，则将其直接舍弃；否则对与生成日志相关的各类型消息分别进行如下处理：
对于版本协商消息，获取消息中的协议版本号并缓存；
对于用户认证请求消息，从消息中提取用户名并缓存；
对于信道请求消息，获取请求的信道类型并缓存；
对于信道中传输的消息，通过消息方向判断属于请求还是响应，并缓存消息方向；其中，若消息方向为从客户端至服务器，则为请求消息，反之为响应消息；
步骤102-2)基于缓存的内容和响应数据包生成解析日志，生成的日志包含：TCP/IP四元组、会话ID、登陆会话的用户名、登陆时间、客户端请求的命令、请求开始时间、服务端返回给客户端的响应数据和响应结束时间；
其中，
所述客户端的请求的命令和服务端返回客户端的响应数据在一个会话的生命期内能够反复发生，而生成的每条解析日志仅包含一条客户端的请求命令和一次服务器端的响应，即不同解析日志的请求和响应相互独立；
在一次会话的生命周期内所述的TCP/IP四元组、会话ID、登陆会话的用户名和登陆时间信息保持不变。
进一步可选的，客户端每次输入都会以消息的形式被送至服务器，并通过服务端返回的回显消息将输入的结果呈现在终端；通过识别回显消息中的转义字符，实现对光标位置的准确控制，结合消息中携带的请求字符复原请求命令，当检测到客户端请求结束时立即将复原的请求命令写入日志缓存中。仅仅将用户请求结束后服务器返回给客户端的数据作为响应数据，将响应数据依次写入日志缓存中，当缓存的日志片段的长度达到设定的发送长度时，立即发送日志片段，对于最后一个日志片段的发送，可由下一次请求驱动，也可由定时器驱动。
此外，本发明还提供了一种基于SSH协议的会话解析系统，所述系统包含：
包处理模块，用于接收基于SSH协议会话的数据包，并对接收的数据包分别进行如下预处理：
当一个数据包包含若干条完整的消息时，从该数据包中依次提取出每一条完整的消息；
当一个数据包所含的消息不完整时，首先将当前数据包包含的不完整的消息进行缓存，然后接收后续的数据包，最后将后续数据包包含的消息和缓存的消息内容进行拼接，直至拼接出一条完整的消息；
解析模块，用于从得到的各条完整的消息中提取与生成日志相关的内容，并按照设定的格式封装与日志相关的内容，进而得到解析日志完成会话解析。
可选的，上述系统还包含：
日志发送模块，用于将生成的解析日志采用流式发送模式发送至日志服务器；其中，所述的流式发送模式为：将生成的解析日志写入日志缓存中，当缓存的日志长度达到设定的发送长度时，立即向日志服务器发送日志。
与现有技术相比，本发明的优势在于：
简化流程——通过对数据包的处理，得到一条条完整的消息，让解析流程变得更简单、更可靠。
节约缓存——对一条完整的消息进行解析，简化处理流程的同时也节约了内存空间；此外，日志传输采用流式发送的方式则大大节约了缓存空间，只需要为每一个解析任务申请一小块缓存空间则可满足日志生成和发送的需求。
附图说明
图1-a是本发明提供的解析系统的各模块的逻辑结构示意图；
图1-b是本发明解析系统的应用场景示意图；
图2是本发明所述方法中包处理模块的处理流程图；
图3是本发明所述方法中响应解析流程图；
图4是本发明所述方法中流式发送的日志片段格式示意图；
具体实施方式
下面结合附图和优选实施例对本发明进行详细说明。
实施例1
为了实现上述方法本发明提供了一种解析系统，所述解析系统如图1-a和1-b所示，图1-a是三个模块的逻辑结构示意图，图1-b是解析系统的应用场景示意图；本发明涉及的三个模块包括：包处理模块、解析模块和日志发送模块。
包处理模块，用于对收到的数据包进行处理，收到的数据包和消息的关系是多对多映射，即有可能一个数据包中包含一条或多条消息，也可能一条消息存在于多个数据包中，若直接对此类数据包进行解析，容易出现消息内容遗漏，造成解析不完整。因此解析前需要先对数据包进行处理，对于包含有多条消息的数据包，从包中依次提取消息，每次提取一条完整的消息，对于包中所含消息不完整时，将不完整的消息进行缓存，待收到后续数据包后，将新到数据和缓存中消息内容进行拼接，直到拼接出一条完整的消息再提交给解析模块进行处理，经过该模块处理后，大大简化了解析模块处理流程，提高了解析效率。
解析模块是所述方法最核心的模块，它负责从一条条完整的SSH消息中识别、分析、提取出与生成日志相关的内容并加以处理，最终生成符合既定格式的解析日志。解析模块的输入是一条完整的SSH消息，消息格式如下：
Figure PCTCN2015074091-appb-000001
Figure PCTCN2015074091-appb-000002
解析模块拿到消息后首先从payload中获取消息码，消息码是消息类型的唯一标识，通过消息码可以得知当前消息对应SSH协议的哪个阶段，进而对不同阶段的SSH消息做不同的分析和处理，如SSH_MSG_USERAUTH_REQUEST对应于SSH协议的用户认证请求阶段，所述方法对该阶段消息的解析主要在于获取请求认证的用户名。由于包处理模块不对数据包进行识别，因此包处理模块对SSH会话过程中的所有数据包进行处理，解析模块收到的消息必然包含一些与解析过程无关的消息，对于此类消息，解析模块不作任何处理，直接舍弃。
日志发送模块，主要负责将生成的日志发送给日志服务器。传统的方法是等一条日志生成完成后再发送，而该方法中采用流式发送模式传输日志。解析模块边解析边生成日志，生成的日志写入日志缓存中，当缓存的日志长度达到发送长度时，立即将日志发出，不需要等到一条完整的日志生成结束再发送日志，发送模块对日志的监测和及时处理，一定程度上提高了日志传输的效率，同时也大大节省了缓存空间。
可选的，上述包处理模块进一步包含：
第一处理子模块，用于当收到一个基于SSH协议会话的数据包后，首先查看缓存区是否有缓存数据包，若不存在缓存数据包，则直接计算接收的数据包中第一条消息的长度并驱动第二处理子模块；若缓存中存在缓存数据包，则表示当前数据包是缓存数据包包含的内容的延续，则直接驱动第三处理单元；
第二处理子模块，用于将计算得出的第一条消息的长度和接收的数据包的长度进 行比较，针对判决结果的不同情况分别启动如下各单元：
第一处理单元，若第一条消息的长度等于接收的数据包长度，表示当前数据包内容恰好为一条完整的消息，则能够对该消息直接进行解析；
第二处理单元，若第一条消息的长度小于数据包的长度，则对该数据包进行拆分处理，即从数据包中提取完整的消息，并采用消息首地址和消息长度表征一条完整的消息；
第三处理单元，若第一条消息的长度大于数据包的长度，则通过缓存该数据包进而完成若干数据包的拼接，最终得到一条完整的消息，再计算完整消息的长度并将得到的完整的消息进行解析。
可选的，上述解析模块进一步包含：
消息过滤子模块，用于根据消息码识别消息类型，进而依据识别的类型判断消息与日志生成是否相关，若消息与生成日志无关，则将其直接舍弃；否则对与生成日志相关的各类型消息分别进行如下处理：
对于版本协商消息，获取消息中的协议版本号并缓存；
对于用户认证请求消息，从消息中提取用户名并缓存；
对于信道请求消息，获取请求的信道类型并缓存；
对于信道中传输的消息，通过消息方向判断属于请求还是响应，并缓存消息方向。其中，若消息方向为从客户端至服务器，则为请求消息，反之为响应消息；
日志生成子模块，用于基于缓存的内容和响应数据包生成解析日志，解析日志包含：TCP/IP四元组、会话ID、登陆会话的用户名、登陆时间、客户端请求的命令、请求开始时间、服务端返回给客户端的响应数据和响应结束时间；
其中，
所述客户端的请求的命令和服务端返回客户端的响应数据在一个会话的生命期内能够反复发生，而生成的每条解析日志仅包含一条客户端的请求命令和一次服务器端的响应，即不同解析日志的请求和响应相互独立；
在一次会话的生命周期内所述的TCP/IP四元组、会话ID、登陆会话的用户名和登陆时间信息保持不变。
进一步可选的，上述日志发送模块进一步包含：
封装子模块，用于发送日志时为其填充日志头，所述日志头包含：“日志编号”、“是否分段”、“分段号”和“最后一段”；其中，“日志编号”，用于表征一条唯一的日志；“是否分段”，用于标记本条日志是否被分段发送，此标识为0表示本段内容即为整条日志内容，否则，日志被分为若干段；“分段号”和“最后一段”在“是否分段”标识为1时才有意义，“分段号”是日志片段的唯一标识；和
发送子模块，用于将封装后的日志发送至存储服务器；
其中，存储服务器收到日志片段后将具有相同“日志编号”的日志片段按“分段号”从小到大依次拼接便进而拼凑出一条完整的日志。
实施例2
本发明为了满足某些企业或机构对业务审计的需求，提出了一种基于SSH协议的会话解析方法。
本发明提供的一种基于SSH协议的会话解析方法包含以下步骤，所述方法处理的是明文SSH数据包：
每到达一个SSH数据包后，将其提交给包处理模块。处理前的数据包中可能包含一 条不完整的消息，也可能包含一条完整的消息，还可能包含多条消息，包处理模块通过对数据包的拆分和拼接，生成一条完整的消息，供协议解析模块解析。
其中，包拆分的过程实际是从包中提取消息的过程，用消息首地址和消息长度表征一条消息；而包拼接的过程则是通过缓存数据包实现的，提交给包处理模块的是经过重组的数据包，能保障SSH报文的时序，这保证了拼接后的消息的完整性和消息内容的正确性。
协议解析模块根据消息码识别消息类型，不同的消息类型对应SSH会话的不同阶段，解析模块识别出该消息与日志生成有关，则对消息头进行解析，若该消息与生成日志无关，则将其直接舍弃。
其中，对不同类型的消息解析的方法不同，对于版本协商消息，直接将消息缓存；对于用户认证请求消息，从消息中提取用户名并缓存，对于信道请求消息，获取请求的信道类型，确保该信道用于SSH会话，对于信道中传输的消息，通过消息方向判断属于请求还是响应，若消息方向为C→S，则为请求消息，反之消息方向为S→C则为响应消息。对不同类型的消息进行解析，并缓存相关内容以生成解析日志。
该方法生成的日志包括TCP/IP四元组、会话ID、登陆会话的用户名、登陆时间等信息，一条会话的生命期内，只会发生一次版本协商和用户认证过程，解析时维护的TCP/IP四元组、会话ID、登陆会话的用户名、登陆时间等信息在一次会话生命期内不会改变。
生成的日志还包括客户端请求的命令、请求开始时间、服务端返回给客户端的响应数据和响应结束时间，不同于登陆信息，客户端的请求和服务端的响应在一个会话的生命期内可以反复发生，该方法限定每条日志中包含且仅包含一条请求和一条响应，所以 同一会话的不同日志共用TCP/IP四元组、会话ID、登录会话的用户名、登陆时间等信息，不同日志的请求和响应则是相互独立的。
解析过程中边生成日志边缓存，日志传输采用流式发送的方式，即当缓存的日志长度达到发送长度时便将日志发送到指定的存储服务器，不需要等一条日志全部生成完成才发送。
图2是包处理模块的处理流程图，包含以下步骤：
a)包处理模块收到一个数据包后，首先查看缓存区是否有缓存数据包，若不存在缓存数据包，则直接计算数据包中第一条消息的长度；若存在缓存数据包，则表示当前数据包是缓存数据包内容的延续，将当前数据包内容拷贝到缓存数据包之后，对不完整的消息进行拼接，拼接后再计算当前缓存的数据包中第一条消息的长度；
b)将计算出的第一条消息长度和数据包长度进行比较，根据比较结果执行c)、d)、e)步骤；
c)若消息长度等于数据包长度，表示当前数据包内容恰好为一条完整的消息，直接将消息提交给解析模块进行解析；
d)若消息长度小于数据包长度，表示当前数据包不止包含一条完整的消息，从数据包中取出第一条完整的消息，提交给解析模块进行解析，再计算剩余数据包中第一条消息的长度，重复b)步骤；
e)若消息长度大于数据包长度，表示当前数据包所含内容仅为一条消息的一部分，不完整的消息则不能提交给解析模块，若当前数据包尚未缓存，则缓存该数据包，若当前数据包已在缓存区中则将数据包内容移动缓存区头，以便为后续待 缓存数据包腾出内存空间。
解析时需要记录用户输入的完整请求，而用户输入可能借助各种快捷键或功能键，要复原用户的请求，需识别并能理解服务端返回给客户端的回显消息，而理解回显消息的关键在于识别回显消息中的转义字符。
表1是本发明所述方法的回显消息中的转义字符集
操作 字符 功能
回车 0d 将光标移至行首
左移 08 光标向左移一位
右移 1b 5b 43 光标向右移一位
删除至行尾 1b 5b 4b 删除当前光标至行尾的字符
插入字符 1b 5b Pn 40 在当前光标出插入Pn个空字符
删除字符 1b 5b Pn 50 从当前光标开始向后删除Pn个字符
客户端每次输入请求都会收到来自服务端的回显消息，回显消息中除了包含客户端输入的字符，还包括转义字符，如表1所示，通过对转义字符的解析可准确定位任意时刻光标的位置和当前请求内容，从而可实现对任意请求内容的完整复原。
图3是响应解析流程图，包含以下步骤：
1)解析模块收到一个S→C的消息，判断请求状态是否为“完成”。；
2)若请求状态为“完成”，表示当前消息为响应消息，响应消息均以‘\r\n’开头，收到‘\r\n’消息时，将响应状态置为“READY”。所述方法对响应的处理是当响应状态为“READY”时将所有响应消息内容直接写入缓存日志中。
3)向日志缓存中写入响应内容时，判断当前缓存日志的长度，若缓存日志长度已达日志发送长度，则立即发送日志。
4)将下一次请求达到作为上一次响应结束的标识，此时不管缓存日志长度多少，在缓存日志尾部加上响应结束时间和日志结束标记，并立即发送日志。
若下一次请求迟迟未到，则上一次解析生成的最后一段日志需要通过定时器触发其发送，定时器触发日志发送模块对日志状态进行监测，若日志状态相对于前一个定时周期已无任何变化，则表明已生成整条日志，应立即发送当前缓存的日志片段。
因为采用流式发送方式传输日志，所以每次发送的内容仅为整条日志的一小段，为了保证日志内容的完整性和正确性，为每个日志片段加上日志头，日志头格式如图4虚线框中所示。其中，“日志编号”用于表征一条唯一的日志；“是否分段”用于标记本段日志是否被分段发送，此标识为0表示本段内容即为整条日志内容，否则，日志被分为若干段；“分段号”和“最后一段”在“是否分段”标识为1时才有意义，“分段号”是日志片段的唯一标识，存储服务器收到日志片段后将具有相同“日志编号”的日志片段按“分段号”从小到大依次拼接便能拼凑出一条完整的日志。
采用上述技术方案得到的日志如表2所示。
表2是本发明所述方法定制的日志格式
数据内容 数据类型 序号
源端口 Ushort 1
目的端口 Ushort 2
源IP IPv4 3
服务器IP IPv4 4
数据ID String 5
会话ID String 6
UUID String 7
数据详细类型 Ulong 8
服务器版本 String 9
登陆时间 Time 10
登陆名称 String 11
数据操作开始时间 Time 12
操作命令 String 13
返回数据 String 14
数据操作结束时间 Time 15
综上所述，本发明提出了一种基于SSH协议的会话解析方法，所述方法涉及三个模块：包处理模块、解析模块和日志发送模块。(1)包处理模块将到达的数据包进行拆分和拼接，得到一条条完整的消息并提交给解析模块；(2)解析模块通过消息码区分消息类型，从不同类型的消息中提取不同内容，再将提取出的内容处理后写入日志中，每条日志包含且仅包含一次请求和一次响应；(3)日志发送模块负责监测日志状态，并采用流式发送的方式传输日志，即当本地缓存的日志长度达到发送长度时，日志发送模块立即将日志发送给存储服务器，不用等日志生成完成才发送，从而节约了缓存空间。本发明的技术能实现基于SSH会话的审计，可以为诸如银行等机构提供安全保障。
最后所应说明的是，以上实施例仅用以说明本发明的技术方案而非限制。尽管参照实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，对本发明的技术方案进行修改或者等同替换，都不脱离本发明技术方案的精神和范围，其均应涵盖在本发明的权利要求范围当中。

Claims (10)

  1. 一种基于SSH协议的会话解析方法，所述方法包含：
    步骤101)接收基于SSH协议会话的数据包，并对接收的数据包分别进行如下预处理：
    当一个数据包包含若干条完整的消息时，从该数据包中依次提取出每一条完整的消息；
    当一个数据包所含的消息不完整时，首先将当前数据包包含的不完整的消息进行缓存，然后接收后续的数据包，最后将后续数据包包含的消息和缓存的消息内容进行拼接，直至拼接出一条完整的消息；
    步骤102)从得到的各条完整的消息中提取与生成日志相关的内容，并按照设定的格式封装与日志相关的内容，进而得到解析日志完成会话解析。
  2. 根据权利要求1所述的基于SSH协议的会话解析方法，其特征在于，所述步骤102)之后还包含：
    步骤103)将生成的解析日志采用流式发送模式发送至日志服务器；
    其中，所述的流式发送模式为：将生成的解析日志写入日志缓存中，当缓存的日志长度达到设定的发送长度时，立即向日志服务器发送解析日志信息。
  3. 根据权利要求1所述的基于SSH协议的会话解析方法，其特征在于，所述步骤101)进一步包含：
    步骤101-1)当收到一个基于SSH协议会话的数据包后，首先查看缓存区是否有缓存数据包，若不存在缓存数据包，则直接计算接收的数据包中第一条消息的长度；若缓存中存在缓存数据包，则表示当前数据包是缓存数据包包含的内容的延续，则将当前数 据包内容拷贝到缓存数据包之后，进而对不完整的消息进行拼接，拼接后再计算当前缓存的数据包中第一条消息的长度；
    步骤101-2)将计算得出的第一条消息的长度和接收的数据包的长度进行比较，针对判决结果的不同情况分别执行如下步骤：
    步骤101-2-1)若第一条消息的长度等于接收的数据包长度，表示当前数据包内容恰好为一条完整的消息，则能够对该消息直接进行解析；
    步骤101-2-2)若第一条消息的长度小于数据包的长度，则对该数据包进行拆分处理，即从数据包中提取完整的消息，并采用消息首地址和消息长度表征一条完整的消息；
    步骤101-2-3)若第一条消息的长度大于数据包的长度，则通过缓存该数据包进而完成若干数据包的拼接，最终得到一条完整的消息，并将得到的完整的消息进行解析。
  4. 根据权利要求1所述的基于SSH协议的会话解析方法，其特征在于，所述步骤102)具体为：
    步骤102-1)根据消息码识别消息类型，进而依据识别的类型判断消息与日志生成是否相关，若消息与生成日志无关，则将其直接舍弃；否则对与生成日志相关的各类型消息分别进行如下处理：
    对于版本协商消息，获取消息中的协议版本号并缓存；
    对于用户认证请求消息，从消息中提取用户名并缓存；
    对于信道请求消息，获取请求的信道类型并缓存；
    对于信道中传输的消息，通过消息方向判断属于请求还是响应，并缓存消息方向；其中，若消息方向为从客户端至服务器，则为请求消息，反之为响应消息；
    步骤102-2)基于缓存的内容和响应数据包生成解析日志，生成的日志包含：TCP/IP 四元组、会话ID、登陆会话的用户名、登陆时间、客户端请求的命令、请求开始时间、服务端返回给客户端的响应数据和响应结束时间；
    其中，
    所述客户端的请求的命令和服务端返回客户端的响应数据在一个会话的生命期内能够反复发生，而生成的每条解析日志仅包含一条客户端的请求命令和一次服务器端的响应，即不同解析日志的请求和响应相互独立；
    在一次会话的生命周期内所述的TCP/IP四元组、会话ID、登陆会话的用户名和登陆时间信息保持不变。
  5. 根据权利要求4所述的基于SSH协议的会话解析方法，其特征在于，客户端每次输入都会以消息的形式被送至服务器，并通过服务端返回的回显消息将输入的结果呈现在终端；通过识别回显消息中的转义字符，实现对光标位置的准确控制，结合消息中携带的请求字符复原请求命令，当检测到客户端请求结束时立即将复原的请求命令写入日志缓存中。
  6. 一种基于SSH协议的会话解析系统，其特征在于，所述系统包含：
    包处理模块，用于接收基于SSH协议会话的数据包，并对接收的数据包分别进行如下预处理：
    当一个数据包包含若干条完整的消息时，从该数据包中依次提取出每一条完整的消息；
    当一个数据包所含的消息不完整时，首先将当前数据包包含的不完整的消息进行缓存，然后接收后续的数据包，最后将后续数据包包含的消息和缓存的消息内容进行拼接，直至拼接出一条完整的消息；
    解析模块，用于从得到的各条完整的消息中提取与生成日志相关的内容，并按照设定的格式封装与日志相关的内容，进而得到解析日志完成会话解析。
  7. 根据权利要求6所述的基于SSH协议的会话解析系统，其特征在于，所述系统还包含：
    日志发送模块，用于将生成的解析日志采用流式发送模式发送至日志服务器；其中，所述的流式发送模式为：将生成的解析日志写入日志缓存中，当缓存的日志长度达到设定的发送长度时，立即向日志服务器发送日志。
  8. 根据权利要求7所述的基于SSH协议的会话解析系统，其特征在于，所述包处理模块进一步包含：
    第一处理子模块，用于当收到一个基于SSH协议会话的数据包后，首先查看缓存区是否有缓存数据包，若不存在缓存数据包，则直接计算接收的数据包中第一条消息的长度并驱动第二处理子模块；若缓存中存在缓存数据包，则表示当前数据包是缓存数据包包含的内容的延续，则直接驱动第三处理单元；
    第二处理子模块，用于将计算得出的第一条消息的长度和接收的数据包的长度进行比较，针对判决结果的不同情况分别启动如下各单元：
    第一处理单元，若第一条消息的长度等于接收的数据包长度，表示当前数据包内容恰好为一条完整的消息，则能够对该消息直接进行解析；
    第二处理单元，若第一条消息的长度小于数据包的长度，则对该数据包进行拆分处理，即从数据包中提取完整的消息，并采用消息首地址和消息长度表征一条完整的消息；
    第三处理单元，若第一条消息的长度大于数据包的长度，则通过缓存该数据包进而完成若干数据包的拼接，最终得到一条完整的消息，再计算完整消息的长度并将得到的 完整的消息进行解析。
  9. 根据权利要求7所述的基于SSH协议的会话解析系统，其特征在于，所述解析模块进一步包含：
    消息过滤子模块，用于根据消息码识别消息类型，进而依据识别的类型判断消息与日志生成是否相关，若消息与生成日志无关，则将其直接舍弃；否则对与生成日志相关的各类型消息分别进行如下处理：
    对于版本协商消息，获取消息中的协议版本号并缓存；
    对于用户认证请求消息，从消息中提取用户名并缓存；
    对于信道请求消息，获取请求的信道类型并缓存；
    对于信道中传输的消息，通过消息方向判断属于请求还是响应，并缓存消息方向。其中，若消息方向为从客户端至服务器，则为请求消息，反之为响应消息；
    日志生成子模块，用于基于缓存的内容和响应数据包生成解析日志，解析日志包含：TCP/IP四元组、会话ID、登陆会话的用户名、登陆时间、客户端请求的命令、请求开始时间、服务端返回给客户端的响应数据和响应结束时间；
    其中，
    所述客户端的请求的命令和服务端返回客户端的响应数据在一个会话的生命期内能够反复发生，而生成的每条解析日志仅包含一条客户端的请求命令和一次服务器端的响应，即不同解析日志的请求和响应相互独立；
    在一次会话的生命周期内所述的TCP/IP四元组、会话ID、登陆会话的用户名和登陆时间信息保持不变。
  10. 根据权利要求7所述的基于SSH协议的会话解析系统，其特征在于，所述日 志发送模块进一步包含：
    封装子模块，用于发送日志时为其填充日志头，所述日志头包含：“日志编号”、“是否分段”、“分段号”和“最后一段”；其中，“日志编号”，用于表征一条唯一的日志；“是否分段”，用于标记本条日志是否被分段发送，此标识为0表示本段内容即为整条日志内容，否则，日志被分为若干段；“分段号”和“最后一段”在“是否分段”标识为1时才有意义，“分段号”是日志片段的唯一标识；和
    发送子模块，用于将封装后的日志发送至存储服务器；
    其中，存储服务器收到日志片段后将具有相同“日志编号”的日志片段按“分段号”从小到大依次拼接便进而拼凑出一条完整的日志。
PCT/CN2015/074091 2014-11-25 2015-03-12 一种基于ssh协议的会话解析方法及系统 WO2016082371A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP15863662.1A EP3211852A4 (en) 2014-11-25 2015-03-12 Ssh protocol-based session parsing method and system
JP2017528151A JP2017539163A (ja) 2014-11-25 2015-03-12 Ｓｓｈプロトコルに基づく会話解析方法及びシステム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201410690049.4A CN105704091B (zh) 2014-11-25 2014-11-25 一种基于ssh协议的会话解析方法及系统
CN201410690049.4 2014-11-25

Publications (1)

Publication Number Publication Date
WO2016082371A1 true WO2016082371A1 (zh) 2016-06-02

Family

ID=56073450

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2015/074091 WO2016082371A1 (zh) 2014-11-25 2015-03-12 一种基于ssh协议的会话解析方法及系统

Country Status (4)

Country Link
EP (1) EP3211852A4 (zh)
JP (1) JP2017539163A (zh)
CN (1) CN105704091B (zh)
WO (1) WO2016082371A1 (zh)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109101440A (zh) * 2018-08-01 2018-12-28 浪潮软件集团有限公司 一种基于jvm缓存处理追溯数据并发请求的方法
CN110933094A (zh) * 2019-12-04 2020-03-27 深信服科技股份有限公司 一种网络安全设备及其smb漏洞检测方法、装置和介质
CN111371887A (zh) * 2020-03-02 2020-07-03 杭州海康威视数字技术股份有限公司 物联网日志传输方法、客户端、服务端、设备及存储介质
CN111722979A (zh) * 2020-06-10 2020-09-29 北京百度网讯科技有限公司 质量监测方法、装置、服务器及存储介质
CN112052227A (zh) * 2020-09-25 2020-12-08 郑州阿帕斯数云信息科技有限公司 数据变更日志的处理方法、装置和电子设备
CN112468343A (zh) * 2020-12-02 2021-03-09 天津光电通信技术有限公司 基于x86卡进行网络数据包重要素材的还原平台及方法
CN112751851A (zh) * 2020-12-29 2021-05-04 成都科来网络技术有限公司 一种ssh登录成功行为判断方法、装置及存储介质
CN112926050A (zh) * 2021-02-05 2021-06-08 北京亿赛通网络安全技术有限公司 基于hook技术获取ssh加密内容的方法及其应用

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107040549B (zh) * 2017-06-08 2021-03-19 山大鲁能信息科技有限公司 一种tcp粘包处理方法、服务器及系统
CN107135235B (zh) * 2017-07-05 2019-11-05 湖北鑫英泰系统技术股份有限公司 一种多级跳转后的ssh连接源追踪方法及装置
CN109981548B (zh) * 2017-12-28 2021-09-10 中移信息技术有限公司 一种计费消息的解析方法及装置
JP2020508592A (ja) * 2018-02-02 2020-03-19 イージーサーティ インコーポレイテッド ビッグデータシステムにおけるセッション別パケット収集に基づくログ生成方法及び装置
CN109451041A (zh) * 2018-12-10 2019-03-08 浪潮(北京)电子信息产业有限公司 一种ssh链接连接方法、装置、设备及存储介质
CN109714345B (zh) * 2018-12-28 2021-05-14 中电福富信息科技有限公司 一种用户无感知的字符堡垒机方法及系统
CN111327625A (zh) * 2020-03-02 2020-06-23 武汉中旗生物医疗电子有限公司 一种参数监测方法、装置、多参数监护仪以及存储介质
CN112685368A (zh) * 2020-12-30 2021-04-20 成都科来网络技术有限公司 超大数据包文件完整会话处理方法、系统及可读存储介质
CN115277885A (zh) * 2022-07-27 2022-11-01 北京天融信网络安全技术有限公司 数据检测方法、装置、设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110185419A1 (en) * 2010-01-26 2011-07-28 Bae Systems Information And Electronic Systems Integration Inc. Method and apparatus for detecting ssh login attacks
CN103916406A (zh) * 2014-04-25 2014-07-09 上海交通大学 一种基于dns日志分析的apt攻击检测系统和方法
CN103944763A (zh) * 2014-04-25 2014-07-23 国家电网公司 一种电力系统网络辅助管理系统及管理方法
CN104144071A (zh) * 2013-05-10 2014-11-12 北京新媒传信科技有限公司 系统日志的处理方法和系统日志的处理平台

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07262109A (ja) * 1994-03-23 1995-10-13 Mitsubishi Electric Corp ホストエミュレーション方式
JP3983716B2 (ja) * 2003-05-21 2007-09-26 ソフトバンクモバイル株式会社 課金記録情報収集装置
DE10335811A1 (de) * 2003-08-05 2005-03-03 Rohde & Schwarz Gmbh & Co. Kg Nachrichtenanalyseeinrichtung und Verfahren zum Analysieren
JP4802123B2 (ja) * 2007-03-07 2011-10-26 富士通株式会社 情報送信装置、情報送信方法、情報送信プログラムおよび該プログラムを記録した記録媒体
CN101286850B (zh) * 2007-04-10 2010-12-15 深圳职业技术学院 路由器安全防御装置及防御系统和方法
JP4905395B2 (ja) * 2008-03-21 2012-03-28 富士通株式会社 通信監視装置、通信監視プログラム、および通信監視方法
CN101656710B (zh) * 2008-08-21 2013-07-24 北京神州绿盟信息安全科技股份有限公司 主动审计系统及方法
EP2807560B1 (en) * 2012-01-24 2019-12-04 SSH Communications Security Oyj Privileged access auditing
CN104135389B (zh) * 2014-08-14 2017-11-14 北京华电天益信息科技有限公司 一种基于代理技术的ssh协议运维审计系统的审计方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110185419A1 (en) * 2010-01-26 2011-07-28 Bae Systems Information And Electronic Systems Integration Inc. Method and apparatus for detecting ssh login attacks
CN104144071A (zh) * 2013-05-10 2014-11-12 北京新媒传信科技有限公司 系统日志的处理方法和系统日志的处理平台
CN103916406A (zh) * 2014-04-25 2014-07-09 上海交通大学 一种基于dns日志分析的apt攻击检测系统和方法
CN103944763A (zh) * 2014-04-25 2014-07-23 国家电网公司 一种电力系统网络辅助管理系统及管理方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3211852A4 *

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109101440A (zh) * 2018-08-01 2018-12-28 浪潮软件集团有限公司 一种基于jvm缓存处理追溯数据并发请求的方法
CN109101440B (zh) * 2018-08-01 2023-08-04 浪潮软件集团有限公司 一种基于jvm缓存处理追溯数据并发请求的方法
CN110933094A (zh) * 2019-12-04 2020-03-27 深信服科技股份有限公司 一种网络安全设备及其smb漏洞检测方法、装置和介质
CN111371887B (zh) * 2020-03-02 2022-10-04 杭州海康威视数字技术股份有限公司 物联网日志传输方法、客户端、服务端、设备及存储介质
CN111371887A (zh) * 2020-03-02 2020-07-03 杭州海康威视数字技术股份有限公司 物联网日志传输方法、客户端、服务端、设备及存储介质
CN111722979A (zh) * 2020-06-10 2020-09-29 北京百度网讯科技有限公司 质量监测方法、装置、服务器及存储介质
CN111722979B (zh) * 2020-06-10 2024-02-13 北京百度网讯科技有限公司 质量监测方法、装置、服务器及存储介质
CN112052227A (zh) * 2020-09-25 2020-12-08 郑州阿帕斯数云信息科技有限公司 数据变更日志的处理方法、装置和电子设备
CN112468343A (zh) * 2020-12-02 2021-03-09 天津光电通信技术有限公司 基于x86卡进行网络数据包重要素材的还原平台及方法
CN112468343B (zh) * 2020-12-02 2023-10-24 天津光电通信技术有限公司 基于x86卡进行网络数据包重要素材的还原平台及方法
CN112751851A (zh) * 2020-12-29 2021-05-04 成都科来网络技术有限公司 一种ssh登录成功行为判断方法、装置及存储介质
CN112926050A (zh) * 2021-02-05 2021-06-08 北京亿赛通网络安全技术有限公司 基于hook技术获取ssh加密内容的方法及其应用
CN112926050B (zh) * 2021-02-05 2024-02-09 北京亿赛通网络安全技术有限公司 基于hook技术获取ssh加密内容的方法及其应用

Also Published As

Publication number Publication date
CN105704091A (zh) 2016-06-22
CN105704091B (zh) 2018-12-04
EP3211852A4 (en) 2017-11-01
JP2017539163A (ja) 2017-12-28
EP3211852A1 (en) 2017-08-30

Similar Documents

Publication Publication Date Title
WO2016082371A1 (zh) 一种基于ssh协议的会话解析方法及系统
US10862871B2 (en) Hardware-accelerated payload filtering in secure communication
US10587544B2 (en) Message processing method, processing server, terminal, and storage medium
US11425047B2 (en) Traffic analysis method, common service traffic attribution method, and corresponding computer system
US9203734B2 (en) Optimized bi-directional communication in an information centric network
US8626903B2 (en) Method and device for identifying an SCTP packet
WO2019144836A1 (zh) 数据传输方法、装置和系统
US9100291B2 (en) Systems and methods for extracting structured application data from a communications link
US8949952B2 (en) Multi-stack subscriber sign on
US10498618B2 (en) Attributing network address translation device processed traffic to individual hosts
US10015205B1 (en) Techniques for traffic capture and reconstruction
US11539747B2 (en) Secure communication session resumption in a service function chain
EP3226516B1 (en) Unified data networking across heterogeneous networks
WO2017148419A1 (zh) 数据传输方法及服务器
CN110545230B (zh) 用于转发vxlan报文的方法和装置
US20190387051A1 (en) Method, device and computer program product for managing network system
WO2015027931A1 (en) Method and system for realizing cross-domain remote command
US8819107B2 (en) Relay apparatus, recording medium storing a relay program, and a relay method
US11811734B2 (en) Protocol switching for connections to zero-trust proxy
US11399054B2 (en) Method and system for profiling teleconference session quality in communication networks
WO2023213086A1 (zh) 数据处理方法、装置、计算机可读介质及电子设备
CN107257327B (zh) 一种高并发ssl会话管理方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15863662

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2017528151

Country of ref document: JP

Kind code of ref document: A

REEP Request for entry into the european phase

Ref document number: 2015863662

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE