CN115514537A - Method and system for judging suspicious traffic in encrypted traffic - Google Patents

Abstract

The embodiments of this specification provide a method and system for judging suspicious traffic in encrypted traffic. The method includes: collecting encrypted traffic to be tested, and extracting encrypted traffic characteristics of the encrypted traffic to be tested; wherein, the encrypted traffic characteristics include the first traffic characteristic, the second A traffic feature includes access feature information, protocol feature information, and transfer feature information; based on the encrypted traffic feature of the encrypted traffic to be tested, the traffic type of the encrypted traffic to be tested is determined. The traffic type includes normal traffic and suspicious traffic, and the suspicious traffic is used for testing Subsequent decryption analysis of encrypted traffic.

Description

Method and system for judging suspicious traffic in encrypted traffic

technical field

This specification relates to the field of network security, in particular to a method and system for judging suspicious traffic in encrypted traffic.

Background technique

With the development of the Internet, people's awareness of privacy is also improving, so people's demand for traffic encryption continues to grow. However, while encrypted traffic protects privacy, it also facilitates the hiding of malicious traffic. Encrypted malicious traffic hides many known and unknown threats. It is necessary to provide a method for judging suspicious traffic in encrypted traffic that can improve network security protection capabilities.

Contents of the invention

One or more embodiments of this specification provide a method for judging suspicious traffic in encrypted traffic. The method includes: collecting encrypted traffic to be tested, and extracting encrypted traffic features of the encrypted traffic to be tested; wherein, the encrypted traffic features include first traffic features, and the first traffic features include access feature information and protocol feature information and transfer characteristic information; based on the encrypted traffic characteristics of the encrypted traffic to be tested, determine the traffic type of the encrypted traffic to be tested, the traffic type includes normal traffic and the suspicious traffic, and the suspicious traffic is used for the Describe the subsequent decryption analysis of the encrypted traffic to be tested.

One or more embodiments of this specification provide a judging system for suspicious traffic in encrypted traffic, the system includes: a traffic collection module, configured to collect encrypted traffic to be tested, and extract encrypted traffic characteristics of the encrypted traffic to be tested; wherein , the encrypted traffic feature includes a first traffic feature, and the first traffic feature includes access feature information, protocol feature information, and delivery feature information; a type determination module, configured to be based on the encrypted traffic feature of the encrypted traffic to be tested , determining a traffic type of the encrypted traffic to be tested, where the traffic type includes normal traffic and the suspicious traffic, and the suspicious traffic is used for subsequent decryption and analysis of the encrypted traffic to be tested.

One or more embodiments of this specification provide an apparatus for judging suspicious traffic in encrypted traffic, including a processor configured to execute at least some of the computer instructions to implement a method for judging suspicious traffic in encrypted traffic.

One or more embodiments of this specification provide a computer-readable storage medium, the storage medium stores computer instructions, and when the computer instructions are executed by a processor, a method for judging suspicious traffic in encrypted traffic is implemented.

Description of drawings

This specification will be further illustrated by way of exemplary embodiments, which will be described in detail with the accompanying drawings. These examples are non-limiting, and in these examples, the same number indicates the same structure, wherein:

FIG. 1 is a schematic diagram of an application scenario of a judging system for suspicious traffic in encrypted traffic according to some embodiments of this specification;

Fig. 2 is an exemplary block diagram of a system for judging suspicious traffic in encrypted traffic according to some embodiments of the present specification;

Fig. 3 is an exemplary flow chart of a method for judging suspicious traffic in encrypted traffic according to some embodiments of this specification;

Fig. 4 is an exemplary schematic diagram of acquiring second traffic characteristics through a relationship graph according to some embodiments of the present specification;

Fig. 5 is a schematic diagram of a suspicious traffic identification model according to some embodiments of the present specification.

detailed description

In order to more clearly illustrate the technical solutions of the embodiments of the present specification, the following briefly introduces the drawings that need to be used in the description of the embodiments. Apparently, the accompanying drawings in the following description are only some examples or embodiments of this specification, and those skilled in the art can also apply this specification to other similar scenarios. Unless otherwise apparent from context or otherwise indicated, like reference numerals in the figures represent like structures or operations.

It should be understood that "system", "device", "unit" and/or "module" as used herein is a method for distinguishing different components, elements, parts, parts or assemblies of different levels. However, the words may be replaced by other expressions if other words can achieve the same purpose.

As indicated in the specification and claims, the terms "a", "an", "an" and/or "the" are not specific to the singular and may include the plural unless the context clearly indicates an exception. Generally speaking, the terms "comprising" and "comprising" only suggest the inclusion of clearly identified steps and elements, and these steps and elements do not constitute an exclusive list, and the method or device may also contain other steps or elements.

The flowchart is used in this specification to illustrate the operations performed by the system according to the embodiment of this specification. It should be understood that the preceding or following operations are not necessarily performed in the exact order. Instead, various steps may be processed in reverse order or simultaneously. At the same time, other operations can be added to these procedures, or a certain step or steps can be removed from these procedures.

Fig. 1 is a schematic diagram of an application scenario of a system for judging suspicious traffic in encrypted traffic according to some embodiments of the present specification.

DPI (Deep Packet Inspection) means that the device detects and analyzes the traffic and packet content at the key points of the network, and can filter and control the detected traffic according to the pre-defined policy, and can complete the inspection of the link where it is located. Fine-grained business identification, business traffic flow analysis, business traffic proportion statistics, business proportion shaping, application layer denial of service attacks, virus and Trojan horse filtering, and P2P abuse control. For example, the decryption DPI module may perform subsequent decryption analysis on the encrypted traffic to be tested when determining that the traffic type of the encrypted traffic to be tested is suspicious traffic.

As shown in FIG. 1 , an application scenario 100 may include a network 110 , a router 120 , a processor 130 , encrypted traffic 140 and a traffic judgment result 150 . The router 120 can acquire the encrypted traffic 140 to be tested from the network 110 , and the processor 130 can copy the encrypted traffic 140 in the router 120 to collect the encrypted traffic 140 and generate a traffic judgment result 150 .

Network 110 may include any suitable network that provides information and/or data exchange capable of facilitating bandwidth application scenario 100 . The router 120 in the application scenario 100 may exchange information and/or data with the network 110 . For example, network 110 may send user-generated traffic information to router 120 . In some embodiments, the network 110 may be any one or more of a wired network or a wireless network. In some embodiments, network 110 may include one or more network access points. For example, network 110 may include wired or wireless network access points. In some embodiments, the network may be in various topologies such as point-to-point, shared, and central, or a combination of multiple topologies.

The router 120 may be a network device for storing, grouping and forwarding the data packets after reading the addresses in the data packets. In some embodiments, a router 120 may be used to connect two or more networks 110 . In some embodiments, the router 120 receives the encrypted traffic 140 of the network 110 , and forwards the encrypted traffic 140 stored in the router 120 to the processor 130 . Router 120 may be local or remote.

The processor 130 may include an execution device for judging the suspicious traffic in the encrypted traffic 140, may process the data and/or information obtained from the router 120, and execute the judging method for the suspicious traffic in the encrypted traffic provided in this specification according to the relevant data, A flow judgment result 150 is generated. For example, the processor 130 may determine traffic characteristics according to the encrypted traffic information received by the router 120 , and then judge whether the encrypted traffic 140 is suspicious traffic based on the traffic characteristics, and then generate the traffic judging result 150 . In some embodiments, processor 130 may be a single server or a group of servers. In some embodiments, the processor 130 may be integrated into the suspicious traffic judging system (such as being integrated in the router 120). Processor 130 may be local or remote. The processor 130 may be implemented on a cloud platform.

The traffic may be traffic generated by the user while surfing the Internet. In some embodiments, traffic may be encrypted traffic or non-encrypted traffic. The purpose of encrypting the traffic is to deal with various eavesdropping and man-in-the-middle attacks, so that the webpage will basically not be tampered with, ensuring the security of users surfing the Internet. However, some malicious traffic will still be hidden in the encrypted traffic 140. In some embodiments, the determination of malicious traffic is performed by the processor 130 . For example, after the encrypted traffic 140 containing malicious traffic is transmitted to the router by the network 110 , it is determined by the processor 130 as suspicious traffic.

The traffic judging result 150 may include that the encrypted traffic 140 is suspicious traffic or the encrypted traffic 140 is normal traffic. In some embodiments, the flow determination result 150 is executed by the processor 130 .

It should be noted that the application scenario 100 is provided for illustrative purposes only, and is not intended to limit the scope of the present application. For those skilled in the art, various modifications or changes can be made according to the description in this specification. For example, the application scenario 100 may also include information sources. However, these changes and modifications do not depart from the scope of the present application.

Fig. 2 is a block diagram of a system for judging suspicious traffic in encrypted traffic according to some embodiments of the present specification.

As shown in FIG. 2 , in some embodiments, the suspicious traffic judgment system 200 may include a traffic characteristic acquisition module 210 and a traffic type determination module 220 .

The traffic feature acquiring module 210 may be used to collect the encrypted traffic to be tested, and extract the encrypted traffic feature of the encrypted traffic to be tested. In some embodiments, the encrypted traffic feature may include a first traffic feature, and the first traffic feature may include access feature information, protocol feature information, and delivery feature information. For specific content about acquiring traffic characteristics, refer to step 310 and related descriptions.

The traffic type determining module 220 may be configured to determine the traffic type of the encrypted traffic to be tested based on the encrypted traffic characteristics of the encrypted traffic to be tested. In some embodiments, traffic types may include normal traffic and suspicious traffic. Suspicious traffic is used for subsequent decryption and analysis of the encrypted traffic to be tested. For details about determining the traffic type, refer to step 320 and its related descriptions.

In some embodiments, the traffic type determination module 220 can be further used to: process the encrypted traffic characteristics of the encrypted traffic to be tested based on the suspicious traffic identification model, and determine the traffic type of the encrypted traffic to be tested. The suspicious traffic identification model is a machine learning model. For the specific content of the suspicious traffic identification model, please refer to Figure 5 and its related descriptions.

In some embodiments, the suspicious traffic judging system 200 may further include a decryption DPI module 230, configured to perform subsequent decryption analysis on the encrypted traffic to be tested in response to the traffic type of the encrypted traffic to be tested as suspicious traffic.

It should be noted that the above description of the suspicious traffic judging system 200 and its modules is only for convenience of description, and does not limit this description to the scope of the illustrated embodiments. It can be understood that for those skilled in the art, after understanding the principle of the system, it is possible to combine various modules arbitrarily, or form a subsystem to connect with other modules without departing from this principle. In some embodiments, the traffic feature acquisition module 210 and the traffic type determination module 220 disclosed in FIG. 2 may be different modules in one system, or one module may realize the functions of the above two or more modules. For example, each module may share one storage module, or each module may have its own storage module. Such deformations are within the protection scope of this specification.

Fig. 3 is an exemplary flowchart of a method for judging suspicious traffic in encrypted traffic according to some embodiments of the present specification. In some embodiments, the process 300 may be executed by the processor 130 . As shown in FIG. 3 , the process 300 includes the following steps.

Step 310, collect the encrypted traffic to be tested, and extract the encrypted traffic characteristics of the encrypted traffic to be tested.

Encrypted traffic refers to traffic that has been encrypted in network traffic. Encrypted traffic can be encrypted by the user or by the service provider to protect privacy. For example, for users who need to process business online based on Internet communication, they can rely on encryption mechanisms in mobile applications, cloud applications, and web applications, and use keys and certificates to ensure security and establish trust through the data encryption process.

Among them, the basic process of data encryption includes processing the original plaintext files or data (traffic) according to the algorithm to make it an unreadable piece of code, usually called "ciphertext". Through this data encryption method, the protection of data from being illegally stolen and read is realized. In some embodiments, encrypting traffic may include encrypting normal traffic and encrypting suspicious traffic. Among them, encrypted suspicious traffic often disguises or hides malicious traffic characteristics. For example, encrypted suspicious traffic often disguises or hides attacking Trojan horses, infectious viruses, worms, malicious downloaders, etc., and attacks the server, causing server crashes and other problems.

The encrypted traffic feature is a traffic feature related to the encrypted traffic to be tested. Traffic characteristics can include statistical information such as quintuple information, encryption protocol information, average data packet size, and average data packet sending interval. The five-tuple information includes source IP address, source port, destination IP address, destination port and transport layer protocol. Encrypted protocol information refers to messages related to the protocol for the secure communication established between the server and the client during the authentication process. The authentication process includes: the client sends a message to the server; the server sends a self-authenticated message to respond to the client; the client and the server complete the key exchange and end the authentication process. In some embodiments, the encryption protocol information may include TLS/SSL protocol version, extension fields, and the like. The average data packet size refers to the average length of data in several data packets, expressed in bytes, for example, the average length of ten IP packets is 1000 bytes. The average data packet sending interval refers to the average time interval between sending a current data frame and sending a next data frame during data transmission, for example, sending a data frame every 2 seconds on average.

In some embodiments, the encrypted traffic feature may include a first traffic feature, and the first traffic feature is a feature related to content included in the encrypted traffic to be tested. In some embodiments, the first traffic feature may include access feature information, protocol feature information, and delivery feature information.

Access characteristic information refers to characteristic information related to access. Access can refer to the process in which visitors actively search for a specific purpose and use the network platform to generate traffic during the access process. For example, the encrypted traffic may be the traffic generated by the visitor clicking on the URL of the website saved in the bookmark or the traffic generated by the visitor directly entering the URL in the address bar of the browser. Access characteristic information can be used to distinguish different sessions, such as communications between different users. In some embodiments, the access feature information may include source IP address, source port, destination IP address, destination port and other information.

Whether the encrypted traffic is suspicious traffic can be judged based on the access feature information. For example, the visit volume of the IP address corresponding to a certain browser in one day is 500% higher than before. At this time, it is necessary to check whether the increase in visit data is caused by suspicious traffic.

The protocol characteristic information refers to characteristic information related to the protocol. The protocol characteristic information can be used to distinguish the transmission mode of the network traffic, for example, whether the transmission is encrypted or not. In some embodiments, the protocol feature information may include transmission protocol information, encryption protocol information, and the like.

The probability that encrypted traffic is suspicious traffic can be judged based on protocol feature information. For example, statistics on historical malicious traffic often choose hidden encrypted transmission protocols. By identifying the encryption protocol used by encrypted traffic, such as SecureSocket Layer (SSL), it can be determined that the encryption protocol is more likely to be attacked by malicious traffic.

The transfer characteristic information refers to characteristic information related to information transfer. In some embodiments, the delivery feature information may include an average data packet size, an average data packet sending interval, and the like.

Whether the encrypted traffic is suspicious traffic can be judged based on the transfer feature information. For example, the normal access time of a network platform is 8:00-18:00, the average data packet size is 512 bytes, and the average data packet sending interval is 20ms, but a large number of intensive accesses occur during 02:00-04:00 in a certain day , The average size of data packets is 1500 bytes, and the average sending interval of data packets is abnormally reduced to 6ms. This part of abnormal traffic can be determined as suspicious traffic.

In some embodiments, the first traffic characteristic may further include a byte distribution probability vector.

In the field of computer security, data is transmitted from the sender to the receiver in the form of data packets. The data packet contains a header. The data sent by the sender is called the payload, that is, the receiver subtracts the length of the IP header from the total length of the IP data packet , the packet payload size can be determined. Headers are appended to the payload for transmission and then discarded when it successfully reaches its destination. The main source of malicious traffic spreading viruses is the payload. Payloads include data destruction, messages with abusive text, or bulk emails sent to large numbers of people. Byte distribution refers to the count of each byte value in the packet payload. For example, the byte distribution of a data packet may be: in the payload of the data packet, the first byte "00000001" appears 10 times, the second byte "00000011" appears 15 times, ..., the Nth byte "11111111" occurs 5 times. The byte distribution probability refers to the occurrence probability of each byte value in the payload of the packet. In some embodiments, the occurrence frequency of each byte value can be used to approximate the occurrence probability of the byte value. The byte distribution probability vector refers to a vector composed of the probabilities of the 256 values that a byte may take in appearing in the data stream. The byte distribution probability vector can provide a large amount of data encoding and data filling information, and many illegal behaviors of malicious traffic are often hidden in this information. In some embodiments, the byte distribution count of each byte value can be divided by the total number of bytes in the payload to obtain the byte distribution frequency, and use it to represent the byte distribution probability, and finally express this feature as A 1*256-dimensional byte distribution probability vector. For example, malicious traffic may use certain fields of the HTTP header (for example, content-type, server, etc.) to initiate some malicious activities, which shows that HTTP fields can well indicate some malicious activities. HTTP context flow refers to all HTTP flows sent by the same source IP address within a 5-minute window of the secure transmission protocol TLS (Transport Layer Security). A feature vector of binary variables represents all observed HTTP header information. If any HTTP flow has a specific header value (i.e., a header containing malicious traffic), then the feature will be is 1. For the byte distribution probability vector P1, the processor 130 can count the 100 flows of P1 in the network flow within the preset time period, among which, 60 of the HTTP header features are 1, which means that these 60 are malicious flows, and the encryption to be tested The byte distribution probability vector of traffic is P1, and the frequency of malicious traffic is 60%.

The encrypted traffic to be tested can be collected through different traffic collection methods. The encrypted flow collection method to be tested includes but is not limited to Sniffer (sniffing method), SNMP (Simple Network Management Protocol, Simple Network Management Protocol), Netflow, sFlow, and the like.

In some embodiments, Sniffer may be used to collect encrypted traffic. As an example only, a data collection point may be set on the mirror port of the switch, and the data information in the network may be completely copied through the mirror port to collect the encrypted traffic information to be tested.

After the encrypted traffic to be tested is collected, the encrypted traffic characteristics of the encrypted traffic to be tested are extracted. Encrypted traffic features can be extracted in a variety of ways, such as encrypted traffic basic information extraction libraries (for example, Flowcontainer), encrypted traffic feature extraction tools (for example, WireShark, QPA, Tstat, etc.) or other encrypted traffic extraction algorithms, machine learning models, etc.

In some embodiments, the encrypted traffic characteristic may further include a second traffic characteristic. The second traffic feature is a feature derived from the content of the encrypted traffic to be tested. The second traffic feature (domain name popularity) can be determined by extracting the destination domain name from the encrypted traffic to be tested, and then determining it through other external content involved in the second traffic feature (such as querying the domain name on the Internet or knowledge graph). In some embodiments, the second traffic feature may include domain name popularity.

Domain popularity is the degree to which malicious traffic tends to visit a domain name. In some embodiments, the popularity of the domain name may include the number of times (or frequency, probability, etc.) that malicious traffic visits the domain name. The higher the frequency of a domain name being accessed by malicious traffic, the higher the popularity of the domain name. In some embodiments, if the network traffic includes a high-profile domain name, the traffic type determination module 220 may determine that the network traffic has a higher probability of being suspicious traffic.

In some embodiments, the traffic characteristic acquiring module 210 may acquire the second traffic characteristic of the encrypted traffic to be tested. In some embodiments, the second traffic characteristic may represent a fractional value. For example, when the second traffic feature is domain name popularity, the higher the domain name popularity score, the higher the domain name popularity, and vice versa. The score value can be obtained according to the historical access status of the domain name, the report status of the domain name by the user, and so on. In some embodiments, the second traffic feature may be used to determine whether the domain name is vulnerable to malicious traffic attacks, and further used to determine the traffic type.

In some embodiments, the second flow characteristic can be obtained through a relational graph.

Fig. 4 is an exemplary schematic diagram of obtaining a second traffic characteristic through a relationship graph according to some embodiments of the present specification.

The relationship graph may include domain name nodes, entity nodes, edges connecting entity nodes, and edges connecting entity nodes and domain name nodes; edge attributes of edges may include communication-related data and traffic types. For example, the domain name node may be Jming.com, and the entity node may be the IP address 207.46.197.101 corresponding to the domain name. An IP address can correspond to multiple domain names, but a domain name has only one IP address. When a user enters a domain name, the domain name first reaches the domain name resolution server (Domain Name System, DNS), and then resolves the domain name to the IP address of the corresponding website. The process of completing this task is called domain name resolution. The client host's access to the server is completed through the domain name node and the entity node.

In some embodiments, the traffic characteristic acquisition module 210 may construct a relational graph based on the encrypted traffic information to be tested, and obtain the second traffic characteristic according to the malicious neighbor degree value determined in the relational graph. The malicious adjacency value indicates the number of edges of a certain node (for example, node A) satisfying a preset condition. Wherein, the preset condition may include: the direction of the edge points to node A, that is, node A is an end point. Wherein, the traffic type of the edge is malicious traffic.

As shown in FIG. 4 , the relationship graph 410 may include domain name nodes 420 (eg, node A, node B, node C), entity nodes 430 (eg, node 1 , node 2 , node 3 ), and edges 440 connecting the nodes. Among them, the edge is a directed edge.

In some embodiments, the traffic characteristic acquisition module 210 may construct the edges of the relationship graph according to the communication between each node. The communication represented by an edge is an abstract communication. An abstract communication can include multiple information exchanges in a short period of time. For example, nodes A and B are connected by a directed edge, which means that there have been multiple information exchanges between nodes A and B in a short period of time. These multiple information exchanges can be regarded as an abstract communication. The direction of the edge can be determined by the initiator of the first information interaction. Exemplarily, in the above multiple information exchanges, the first information exchange is initiated by A to B, then the direction of multiple information exchanges can be determined as A pointing to B accordingly. In some embodiments, in response to multiple communications between node A and node B (eg, communications occurring at different times with a long time span), node A and node B may have multiple directed edges. In some embodiments, the processor 130 may count the number of edges whose traffic type is "malicious traffic" between nodes based on the attributes of the edges. A malicious adjacency value of 0 means that there is no edge with the traffic type of "malicious traffic" between two nodes. A malicious adjacency value of 1 means that there is an edge with a traffic type of malicious traffic between two nodes. Malicious adjacency A value of 2 indicates that there are two edges with the traffic type of malicious traffic between two nodes, and so on. In some embodiments, the second traffic characteristic may be determined according to the malicious neighbor value. For more details about determining the second traffic characteristic based on the malicious neighbor value, refer to FIG. 4 and related descriptions.

The schematic flow 400 is an example of determining the second traffic characteristic through a relational graph. Exemplarily, the second traffic feature 460 in the schematic process 400 is the popularity of domain names. Specifically, the traffic feature acquisition module 210 can find the corresponding node based on the encrypted traffic information (for example, IP address) to be tested, and the processor 130 can obtain all edges 440 connected to the node based on the relationship graph 410, and count the nodes The number of edges whose traffic type in the corresponding edge attribute in the graph is malicious traffic; determine the malicious neighborhood value 450 based on the number of edges; determine the popularity of the domain name based on the malicious neighborhood value. As shown in Figure 4, the malicious adjacency value of node 1 and node B is 1, the malicious adjacency value of node 3 is 2, and the malicious adjacency value of node 2 is 3, so the domain name popularity of node 2 is the highest.

In some embodiments, the traffic feature acquisition module 210 may determine the popularity of the domain name according to the malicious proximity value 450 and preset proximity rules. Wherein, the preset neighbor degree rule may be to sort the malicious neighbor degree values corresponding to each node according to the size, and the higher the ranking, the higher the popularity of the domain name. The preset proximity rules can be set according to actual needs. For example, output the domain name corresponding to the top three nodes with the highest domain name popularity. For the domain name with high domain name popularity, the traffic corresponding to the domain name can directly enter the subsequent decryption DPI analysis without classifying the traffic type.

In some embodiments, the edge feature of the relationship graph may also include the number of times the communication data between two nodes is reported by the user. Among them, the client is located at a node attacked by malicious traffic. When the communication data between two nodes is reported by the user, the traffic type corresponding to the communication is recorded as malicious traffic. The processor 130 may count the number of edges whose traffic type is "malicious traffic" between nodes. Further, based on the number of edges, the second flow characteristic is determined. As an example only, when the second traffic feature is domain name popularity, the more edges whose traffic type is "malicious traffic", the higher the domain name popularity of the domain name corresponding to this node is.

In the embodiment of this specification, the determination of the second traffic characteristics through the relationship graph can effectively integrate the traffic types of network traffic, and construct the association between domain names and domain names, entity IPs and entity IPs, and domain names and entity IPs, that is, according to traffic The flow direction is used to construct the edge between nodes, so as to support the mining and extraction of the second traffic feature more efficiently; by determining the second traffic feature, the accuracy of judging that the encrypted traffic feature is malicious traffic can be improved.

Step 320: Determine the traffic type of the encrypted traffic to be tested based on the encrypted traffic characteristics of the encrypted traffic to be tested.

In some embodiments, traffic types may include normal traffic and suspicious traffic. There are several ways to determine the traffic type of the encrypted traffic to be tested. In some embodiments, the traffic type may be determined based on historical data, preset rules, or a suspicious traffic identification model. In some embodiments, determining the traffic type based on historical data includes: obtaining historical suspicious traffic through the traffic type determination module 220, and comparing the historical suspicious traffic with the traffic characteristics of the encrypted traffic to be tested, when the similarity is greater than a certain threshold (for example, When greater than 0.8), it is determined that the traffic type of the encrypted traffic to be tested is suspicious traffic. In some embodiments, determining the traffic type based on preset rules includes determining that the traffic type of the encrypted traffic to be tested is suspicious traffic when the number of suspicious traffic characteristics of the traffic signature of the encrypted traffic to be tested is greater than a certain value (for example, greater than 1). In some embodiments, the suspicious traffic identification model may be a machine learning model. For the specific content of the suspicious traffic identification model, please refer to Figure 5 and its related descriptions.

Step 330, in response to the traffic type of the encrypted traffic to be tested being suspicious traffic, perform subsequent decryption analysis on the encrypted traffic to be tested.

In some embodiments, if the traffic type of the encrypted traffic to be tested is normal traffic, no subsequent decryption analysis is required.

Decryption analysis can include confirmation of protocol type, segmentation protocol, segmentation protocol domain, SSL offloading, payload analysis, identification and negotiation protocol, etc. Through decryption and analysis of suspicious traffic, it can be further determined whether suspicious traffic is malicious traffic, or through decryption The DPI module 230 marks the traffic characteristics corresponding to the suspicious traffic, and stores the suspicious traffic characteristics in the traffic type determination module 220, so as to identify the suspicious traffic in the encrypted traffic to be tested, and at the same time, it is convenient to obtain more training samples for use Model training makes the judgment of encryption analysis more accurate.

In the embodiment of the present specification, by filtering out normal traffic and suspicious traffic in encrypted traffic, only subsequent decryption analysis is performed on suspicious traffic, thereby reducing the load of subsequent analysis work and improving analysis efficiency.

Fig. 5 is a schematic diagram of a suspicious traffic identification model according to some embodiments of the present specification.

In some embodiments, determining the traffic type of the encrypted traffic to be tested based on the encrypted traffic characteristics of the encrypted traffic to be tested includes: processing the encrypted traffic characteristics of the encrypted traffic to be tested based on a suspicious traffic identification model, and determining the encrypted traffic to be tested traffic types, and the suspicious traffic identification model is a machine learning model.

As shown in FIG. 5 , the initial suspicious traffic identification model 550 may be based on a large number of labeled training samples 540 to obtain a trained suspicious traffic identification model 520 . Specifically, the training sample 540 with the identification is input into the initial suspicious traffic identification model 550, and the initial suspicious traffic identification model is trained based on the identification. In some embodiments, training samples 540 may be normal traffic and suspicious traffic.

In some embodiments, the identification of the training samples may be whether the training samples are suspicious traffic. For example, if the training sample is suspicious traffic, it is marked as 1, otherwise it is 0.

In some embodiments, the initial suspicious traffic identification model 550 may be a binary classifier trained by taking suspicious traffic as positive samples and normal traffic as negative samples. In some embodiments, the binary classifier may be one of a logistic regression model, a support vector machine, a random forest, or other classification models.

In some embodiments, the suspicious traffic identification model 520 may be used to determine the type of traffic corresponding to the input traffic feature. In some embodiments, the input of the suspicious traffic identification model 520 may include the first traffic feature 510-1 or/ With the second traffic feature 510-2, the output of the suspicious traffic identification model 520 may include one of the suspicious traffic 530-1 and the normal traffic 530-2.

In some embodiments, when the trained suspicious traffic identification model satisfies a preset condition, the training ends. Wherein, the preset condition may be that the accuracy rate is greater than or equal to a preset threshold. Wherein, the preset threshold can be specifically set according to actual needs, such as 90% or 95%.

In some embodiments, multiple test samples may be used to determine the accuracy of the trained suspicious traffic identification model, and the test samples include labels indicating whether the suspicious traffic is suspicious. After multiple test samples are input into the trained suspicious traffic identification model, the corresponding predicted category can be output. When the predicted category is consistent with the label, the prediction is correct, otherwise the prediction is wrong. The accuracy rate can be the value obtained by dividing the number of correct samples by the total number of test samples.

The embodiment of this specification uses a machine learning model to identify traffic types, and can learn the inherent characteristics of malicious traffic based on a large amount of historical traffic data, so as to more accurately determine whether the encrypted traffic to be tested is suspicious traffic.

In some embodiments, the output of the suspicious traffic identification model may further include a classification vector 530-3, and the classification vector 530-3 includes confidence levels that the encrypted traffic to be tested belongs to different categories of suspicious traffic.

In some embodiments, before using the suspicious traffic identification model to output classification vectors, a large number of multi-classification training samples should be used to train the initial suspicious traffic identification model so that it has a certain multi-classification capability. In some embodiments, the training samples may be normal traffic and different types of malicious traffic, for example, the malicious traffic may belong to "suspicious privacy leakage traffic", "suspicious malicious attack traffic" and so on. In some embodiments, the identification of the training sample may be the class of the training sample. For example, if the malicious traffic is identified as A, it means that the category of the malicious traffic is "suspicious privacy leakage traffic"; if the malicious traffic is marked as B, it means that the category of the malicious traffic is suspicious malicious traffic. In some embodiments, the classification vector output by the suspicious traffic identification model may represent the confidence that the suspicious traffic belongs to different malicious behaviors. In some embodiments, the classification vector output by the suspicious traffic model includes a plurality of values between 0-1, which are respectively used to represent the confidence that the sample belongs to the corresponding category. As an example, the suspicious traffic identification model can output a vector [0.2, 0.8, 0.1], where 0.2 means that the sample belongs to class A with a confidence of 0.2, 0.8 means that the sample belongs to class B with a confidence of 0.8, and 0.1 means that the If the confidence that the sample belongs to category C is 0.1, it can be determined that the sample belongs to category B.

In some embodiments, the input of the suspicious traffic identification model may also include the reference malicious value 510-3 of the byte distribution probability vector. For the method of determining the byte distribution probability vector, refer to step 310 and related descriptions.

The reference malicious value refers to the possibility that the byte distribution probability vector is suspicious traffic.

In some embodiments, the reference malicious value of the byte distribution probability vector may be determined based on historical data or the like.

In some embodiments, determining the reference malicious value based on the historical data includes obtaining the byte distribution probability vector of the historical suspicious traffic by the suspicious traffic determination model, and matching the byte distribution probability vector of the historical suspicious traffic with the encrypted traffic to be tested is the byte distribution The probability vectors are compared, and when the similarity is greater than a certain threshold (for example, greater than 0.8), the malicious value of the byte distribution probability vector of historical suspicious traffic is determined as the reference malicious value of the current byte distribution probability vector.

In some embodiments, the edge attribute of the relationship graph further includes a byte distribution probability vector.

In some embodiments, the reference malicious value may be obtained based on the relationship graph, including: based on the edges satisfying the preset condition in the relationship graph, counting the frequency of the edge whose traffic type in the edge attribute of the edge satisfying the preset condition is malicious traffic, A reference malicious value is determined based on frequency.

In some embodiments, the preset condition is that the similarity between the byte distribution probability vector in the edge attribute and the byte distribution probability vector of the encrypted traffic to be tested is close to a preset range. The preset range may be one of system default values, experience values, artificial preset values, and the like. For example, for the byte distribution probability vector P2, the processor 130 can count 100 pieces of flow of P2 in the network flow within a preset period of time, wherein 40 pieces are normal flow and 60 pieces are malicious flow, which means that the encrypted flow to be tested is The frequency of the traffic whose byte distribution probability vector is P2 is malicious traffic is 60%.

The reference malicious value can be further calculated based on the aforementioned 60%, and the greater the frequency, the greater the reference malicious value. In some embodiments, the current byte distribution probability vector of the traffic to be measured is P2, and all vectors with a similarity close to the vector P2 are searched in the relationship graph. For example, all the vectors with close similarity to vector P2 are: P3, P4, P5, where the edges corresponding to P3 and P4 are malicious traffic; the edges corresponding to P5 are normal traffic. Then the frequency of malicious traffic is 75%, and based on the frequency of malicious traffic of 75%, the reference malicious value of P2 is calculated. The manner of determining the reference malicious value according to the frequency may include determining the reference malicious value according to a rule table. For example, if the frequency of the byte distribution probability vector is malicious traffic is 60%, then the malicious value in the corresponding rule table is 80; if the frequency of the byte distribution probability vector is malicious traffic is 80%, then the malicious value in the corresponding rule table is 90.

In some embodiments of this specification, the preset relationship graph may be updated according to the correlation between the encrypted traffic information to be tested and the reference malicious value, including: converting the byte distribution probability vector corresponding to the encrypted traffic to be tested into the malicious traffic The frequency is compared with the frequency corresponding to the reference malicious value; if the byte distribution probability vector corresponding to the encrypted traffic to be tested is that the frequency of malicious traffic is greater than the frequency corresponding to the current reference malicious value, a new child node is added to the encrypted traffic to be tested and Associate the child node with the byte distribution probability vector representing malicious traffic to update the preset relationship map; if the frequency of the byte distribution probability vector corresponding to the encrypted traffic to be tested is malicious traffic is less than the frequency corresponding to the current reference malicious value, then in Add new sub-nodes to the encrypted traffic to be tested and associate the sub-nodes with byte distribution probability vectors representing normal traffic to update the preset relationship graph.

In the embodiment of this specification, the reference malicious value is obtained through the relationship map, and a more accurate reference malicious value can be obtained based on a large number of statistically obtained byte distribution probability vectors. At the same time, the relationship map is updated in real time, and the reference malicious value can be obtained in real time more accurately and efficiently. .

The basic concept has been described above, obviously, for those skilled in the art, the above detailed disclosure is only an example, and does not constitute a limitation to this description. Although not expressly stated here, those skilled in the art may make various modifications, improvements and corrections to this description. Such modifications, improvements and corrections are suggested in this specification, so such modifications, improvements and corrections still belong to the spirit and scope of the exemplary embodiments of this specification.

Meanwhile, this specification uses specific words to describe the embodiments of this specification. For example, "one embodiment", "an embodiment", and/or "some embodiments" refer to a certain feature, structure or characteristic related to at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment" or "an embodiment" or "an alternative embodiment" two or more times in different places in this specification do not necessarily refer to the same embodiment . In addition, certain features, structures or characteristics in one or more embodiments of this specification may be properly combined.

In addition, unless explicitly stated in the claims, the order of processing elements and sequences described in this specification, the use of numbers and letters, or the use of other names are not used to limit the sequence of processes and methods in this specification. While the foregoing disclosure has discussed by way of various examples some embodiments of the invention that are presently believed to be useful, it should be understood that such detail is for illustrative purposes only and that the appended claims are not limited to the disclosed embodiments, but rather, the claims The claims are intended to cover all modifications and equivalent combinations that fall within the spirit and scope of the embodiments of this specification. For example, although the system components described above may be implemented by hardware devices, they may also be implemented by a software-only solution, such as installing the described system on an existing server or mobile device.

In the same way, it should be noted that in order to simplify the expression disclosed in this specification and help the understanding of one or more embodiments of the invention, in the foregoing description of the embodiments of this specification, sometimes multiple features are combined into one embodiment, drawings or descriptions thereof. This method of disclosure does not, however, imply that the subject matter of the specification requires more features than are recited in the claims. Indeed, embodiment features are less than all features of a single foregoing disclosed embodiment.

In some embodiments, numbers describing the quantity of components and attributes are used. It should be understood that such numbers used in the description of the embodiments use the modifiers "about", "approximately" or "substantially" in some examples. grooming. Unless otherwise stated, "about", "approximately" or "substantially" indicates that the stated figure allows for a variation of ±20%. Accordingly, in some embodiments, the numerical parameters used in the specification and claims are approximations that can vary depending upon the desired characteristics of individual embodiments. In some embodiments, numerical parameters should take into account the specified significant digits and adopt the general digit reservation method. Although the numerical ranges and parameters used in some embodiments of this specification to confirm the breadth of the range are approximations, in specific embodiments, such numerical values are set as precisely as practicable.

Each patent, patent application, patent application publication, and other material, such as article, book, specification, publication, document, etc., cited in this specification is hereby incorporated by reference in its entirety. Application history documents that are inconsistent with or conflict with the content of this specification are excluded, and documents (currently or later appended to this specification) that limit the broadest scope of the claims of this specification are also excluded. It should be noted that if there is any inconsistency or conflict between the descriptions, definitions, and/or terms used in the accompanying materials of this manual and the contents of this manual, the descriptions, definitions and/or terms used in this manual shall prevail .

Finally, it should be understood that the embodiments described in this specification are only used to illustrate the principles of the embodiments of this specification. Other modifications are also possible within the scope of this description. Therefore, by way of example and not limitation, alternative configurations of the embodiments of this specification may be considered consistent with the teachings of this specification. Accordingly, the embodiments of this specification are not limited to the embodiments explicitly introduced and described in this specification.

Claims (10)

1. A method for judging suspicious traffic in encrypted traffic is characterized by comprising the following steps:

acquiring encrypted flow to be detected, and extracting encrypted flow characteristics of the encrypted flow to be detected; wherein the encrypted traffic characteristics include first traffic characteristics including access characteristic information, protocol characteristic information, and transfer characteristic information;

determining the traffic type of the encrypted traffic to be detected based on the encrypted traffic characteristics of the encrypted traffic to be detected, wherein the traffic type comprises normal traffic and the suspicious traffic;

and in response to the fact that the flow type of the encrypted flow to be detected is the suspicious flow, performing subsequent decryption analysis on the encrypted flow to be detected through a decryption DPI module.

2. The method of claim 1, wherein the encrypted traffic characteristics further comprise a second traffic characteristic, the second traffic characteristic being obtained via a relational graph.

3. The method of claim 1, wherein the determining the traffic type of the encrypted traffic under test based on the encrypted traffic characteristics of the encrypted traffic under test comprises:

and processing the encrypted flow characteristics of the encrypted flow to be detected based on a suspicious flow identification model, and determining the flow type of the encrypted flow to be detected, wherein the suspicious flow identification model is a machine learning model.

4. The method of claim 3, wherein the inputs to the suspicious traffic identification model further comprise reference malicious values of byte distributed probability vectors, the reference malicious values obtained based on the relationship graph.

5. A system for determining suspicious traffic in encrypted traffic, the system comprising:

the flow characteristic acquisition module is used for acquiring encrypted flow to be detected and extracting encrypted flow characteristics of the encrypted flow to be detected; wherein the encrypted traffic characteristics include first traffic characteristics including access characteristic information, protocol characteristic information, and transfer characteristic information;

a traffic type determining module, configured to determine a traffic type of the encrypted traffic to be detected based on the encrypted traffic feature of the encrypted traffic to be detected, where the traffic type includes a normal traffic and the suspicious traffic;

and the decryption DPI module is used for responding to the suspicious traffic of the traffic type of the encrypted traffic to be detected and carrying out subsequent decryption analysis on the encrypted traffic to be detected.

6. The system of claim 5, wherein the encrypted traffic characteristics further comprise a second traffic characteristic, the second traffic characteristic being obtained via a relational map.

7. The system of claim 5, the traffic type determination module further to:

and processing the encrypted flow characteristics of the encrypted flow to be detected based on a suspicious flow identification model, and determining the flow type of the encrypted flow to be detected, wherein the suspicious flow identification model is a machine learning model.

8. The system of claim 7, wherein the inputs to the suspicious traffic identification model further comprise reference malice values of byte distribution probability vectors, the reference malice values obtained based on the relationship graph.

9. A device for judging suspicious traffic in encrypted traffic comprises at least one processor and at least one memory; the at least one memory is for storing computer instructions; the at least one processor is configured to execute at least some of the computer instructions to implement the method of any of claims 1-4.

10. A computer readable storage medium storing computer instructions which, when executed by a processor, implement the method of any one of claims 1 to 4.

Images