Traffic identification method and apparatus

Abstract

The application provides a traffic identification method and device, and relates to the technical field of network security. The method comprises the following steps: extracting first session traffic of a requestor and second session traffic of a responder from received target session; using a request direction detection model to perform traffic detection processing on request load data in the first session traffic, so as to obtain a first traffic detection result of whether the first session traffic meets Webshell encrypted communication; using a response direction traffic detection model to perform traffic detection on response load data in the second session traffic, so as to obtain a second traffic detection result of whether the second session traffic meets Webshell encrypted communication; and if the first traffic detection result and the second traffic detection result both meet Webshell encrypted communication and are matched, confirming that traffic in the target session is attack traffic in a Webshell encrypted communication mode.

Description

Technical Field

[0001] This application relates to the field of network security technology, and in particular to a traffic identification method and apparatus. Background Technology

[0002] As the offensive and defensive confrontation intensifies, attackers are becoming increasingly sophisticated in their methods, constantly refining their methods to evade detection and increasing the cost of detection. Many attack traffic attacks are now encrypted in various ways, making encrypted webshells increasingly popular.

[0003] However, due to encrypted communication traffic, traditional firewalls (WAF) and intrusion detection systems (IDS) struggle to detect it, posing a significant challenge to threat hunting. Furthermore, the harm caused by webshells is substantial; if security devices cannot detect, identify, or block them, servers can be compromised, and even internal network servers can be completely controlled, posing a significant security threat.

[0004] Existing technologies for identifying attack traffic based on Webshell encrypted communication primarily rely on detecting weak features of HTTP requests during shell interactions, such as header fields and positional constraints. However, this detection method is prone to false positives in high-traffic environments, resulting in inaccurate identification results. Even when using a combination of multiple features to improve the false positive rate, these features are often weak, allowing attackers to easily bypass these detection methods by customizing request headers or using proxies to modify the request packets, leading to low detection accuracy.

[0005] Therefore, accurately identifying attack traffic based on Webshell encrypted communication is one of the technical issues worth considering. Summary of the Invention

[0006] In view of this, this application provides a traffic identification method and apparatus to improve the accuracy of identifying attack traffic based on Webshell encrypted communication.

[0007] Specifically, this application is implemented through the following technical solution:

[0008] According to a first aspect of this application, a traffic identification method is provided, comprising:

[0009] Based on the received target session, obtain the first session traffic of the requester and the second session traffic of the responder;

[0010] The request load data in the first session traffic is processed by the request direction detection model to obtain the first traffic detection result of whether the first session traffic meets the requirements of Webshell encrypted communication.

[0011] The response load data in the second session traffic is detected using a response direction traffic detection model to obtain the second traffic detection result of whether the second session traffic meets the requirements of Webshell encrypted communication.

[0012] If both the first traffic detection result and the second traffic detection result satisfy Webshell encrypted communication and match, then it is confirmed that the traffic involved in the target session is attack traffic using Webshell encrypted communication.

[0013] According to a second aspect of this application, a traffic flow identification device is provided, comprising:

[0014] The acquisition module is used to acquire the first session traffic of the requester and the second session traffic of the responder based on the received target session;

[0015] The first detection module is used to perform traffic detection processing on the request load data in the first session traffic using a request direction detection model, so as to obtain the first traffic detection result of whether the first session traffic meets the Webshell encrypted communication requirement.

[0016] The second detection module is used to perform traffic detection on the response load data in the second session traffic using the response direction traffic detection model, so as to obtain the second traffic detection result of whether the second session traffic meets the requirements of Webshell encrypted communication.

[0017] The identification module is used to confirm that the traffic involved in the target session is attack traffic using Webshell encrypted communication if both the first traffic detection result and the second traffic detection result satisfy Webshell encrypted communication and match.

[0018] According to a third aspect of this application, an electronic device is provided, including a processor and a machine-readable storage medium storing a computer program executable by the processor, the processor being prompted by the computer program to perform the method provided in the first aspect of the embodiments of this application.

[0019] According to a fourth aspect of this application, a machine-readable storage medium is provided, which stores a computer program that, when invoked and executed by a processor, causes the processor to perform the method provided in the first aspect of the embodiments of this application.

[0020] The beneficial effects of the embodiments of this application are as follows:

[0021] The traffic identification method and apparatus provided in this application obtain the first session traffic of the requester and the second session traffic of the responder based on the received target session; the request load data in the first session traffic is processed by a request direction detection model to obtain a first traffic detection result indicating whether the first session traffic satisfies Webshell encrypted communication; the response load data in the second session traffic is processed by a response direction traffic detection model to obtain a second traffic detection result indicating whether the second session traffic satisfies Webshell encrypted communication; if both the first and second traffic detection results satisfy Webshell encrypted communication and match, then the traffic involved in the target session is confirmed to be attack traffic using Webshell encrypted communication. By implementing the aforementioned method, the load data in the request and response direction traffic is identified and processed separately. This load data is the key data that Webshell attack traffic focuses on. Therefore, when performing traffic identification based on load data, the accuracy of Webshell attack traffic identification results can be greatly improved. Attached Figure Description

[0022] Figure 1 This is a flowchart illustrating a traffic identification method provided in an embodiment of this application;

[0023] Figure 2 This is a schematic diagram of the structure of a flow identification device provided in an embodiment of this application;

[0024] Figure 3 This is a schematic diagram of the hardware structure of an electronic device implementing a traffic identification method according to an embodiment of this application. Detailed Implementation

[0025] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application.

[0026] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used herein are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the corresponding listed items.

[0027] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0028] Before introducing the traffic identification method provided in this application, let's first explain the technical terms involved in this application:

[0029] Webshell: A command execution environment that exists as a webpage file such as ASP, ASPX, PHP, JSP, or CGI. It gains server privileges by accessing open ports on the server. By simply uploading a script file, one can achieve website and server management, and can also be considered a webpage backdoor. After hacking into a website, a hacker can use a browser or webshell management tools to access the backdoor file and execute related system commands to control the website server.

[0030] The traffic identification method provided in this application will be described in detail below.

[0031] See Figure 1 , Figure 1 This is a flowchart of a traffic identification method provided in this application. This method can be applied to network security devices, which may include, but are not limited to, firewall devices, security platforms, etc. For ease of description, the implementation of the above traffic identification method by a network security device is used as an example. The network security device implementing this method may include the following steps:

[0032] S101. Based on the received target session, obtain the first session traffic of the requester and the second session traffic of the responder.

[0033] In this step, since the network security device will receive the session between the requester and the responder in the network, in order to ensure the security of the network, after receiving the session, the network security device will confirm whether the traffic generated by the session is the attack traffic using the Webshell encrypted communication method. For ease of description, the attack traffic using the Webshell encrypted communication method can be recorded as Webshell attack traffic. Therefore, this embodiment proposes to obtain the first session traffic in the request direction and the second session traffic in the response direction based on the target session.

[0034] It should be noted that, since Webshell attacks typically encrypt and encode traffic using a predefined format, this embodiment can filter each received session to reduce computational load and improve the accuracy of attack traffic identification. When a session's encoding format matches the predefined format, that session is identified as the target session. That is, the target session can be any session using the predefined encoding format. Because this application is for identifying Webshell attack traffic, this embodiment only needs to perform traffic identification processing on sessions with the predefined encoding format, and does not need to identify sessions with other encoding formats, thus greatly reducing the computational load when identifying Webshell attack traffic.

[0035] Optionally, the encoding format set above may include, but is not limited to, BASE64 encoding format, etc. BASE64 encoding is a technique used to convert binary data into corresponding text. It uses 64 printable characters to represent binary data and is one of the most common encoding methods used on the Internet to transmit 8-bit byte code.

[0036] S102. Use the request direction detection model to perform traffic detection processing on the request load data in the first session traffic to obtain the first traffic detection result of whether the first session traffic meets the Webshell encrypted communication requirement.

[0037] In this step, since Webshell attack traffic often involves forging and tampering with the payload in the request direction to achieve the purpose of the attack, and the current detection method only detects weak features such as request headers, it is impossible to effectively identify Webshell attack traffic.

[0038] In view of this, this embodiment proposes to identify the load data in the session traffic. That is, after the network security device obtains the first session traffic, it can extract the load data from the first session traffic. Since the first session traffic is request-oriented session traffic, the extracted load data can be recorded as the aforementioned request load data. Then, a pre-established request-oriented detection model is called to identify the aforementioned request load data, thereby obtaining whether the first session traffic meets the first traffic detection result for Webshell encrypted communication.

[0039] It should be noted that the aforementioned request direction detection model can be constructed based on possible payload data samples from Webshell attack traffic in the request direction. In this way, the constructed request direction detection model can learn the attack characteristics in the payload data of Webshell attack traffic in the request direction. Therefore, when using this model to identify request payload data in the first session traffic, it can accurately identify whether the request payload data includes attack characteristics from Webshell attack traffic. This improves the accuracy of the first session traffic detection result in determining whether it meets the requirements for Webshell encrypted communication, laying the foundation for improving the accuracy of Webshell attack traffic identification results.

[0040] S103. Use the response direction traffic detection model to perform traffic detection on the response load data in the second session traffic to obtain the second traffic detection result of whether the second session traffic meets the requirements of Webshell encrypted communication.

[0041] In this step, Webshell attack traffic often involves forging and tampering with the payload in the request-direction traffic to achieve the attack objective. Correspondingly, when attacking the responder based on this attack traffic, the responder typically sends back corresponding response data, which is usually returned to the requester as response payload data. Therefore, this embodiment proposes that after obtaining the second session traffic in the response direction, payload data is extracted from the second session traffic and recorded as response payload data. Then, a pre-established response direction traffic detection model is called to perform traffic identification processing on the above response payload data, thereby obtaining the second traffic detection result of whether the second session traffic meets the requirements for Webshell encrypted communication.

[0042] It should be noted that the above response direction detection model can also be constructed based on possible payload data samples in the Webshell attack traffic in the response direction. In this way, the constructed response direction detection model can learn the attack characteristics in the response payload data of the Webshell attack traffic in the response direction. Therefore, when using this model to identify the response payload data in the second session traffic, it can accurately identify whether the response payload data includes the attack characteristics of the Webshell attack traffic. This improves the accuracy of the second session traffic detection results to determine whether the obtained second session traffic meets the requirements of Webshell encrypted communication, laying the foundation for improving the accuracy of Webshell attack traffic identification results.

[0043] S104. If the first traffic detection result and the second traffic detection result both satisfy Webshell encrypted communication and match, then it is confirmed that the traffic involved in the target session is attack traffic using Webshell encrypted communication.

[0044] In this step, when performing traffic detection based on steps S102 and S103, if the first traffic detection result indicates that both the first session traffic and the second session traffic satisfy Webshell encrypted communication, it indicates that the traffic involved in the target session may be Webshell attack traffic. However, even if both the first and second traffic detection results indicate that Webshell encrypted communication is satisfied, it does not necessarily mean that the traffic involved in the target session is Webshell attack traffic, because Webshell encrypted communication involves multiple functions. Therefore, in order to further improve the accuracy of the attack traffic identification result, this embodiment will further confirm whether the first traffic detection result and the second traffic detection result match. If they match, it is confirmed that the traffic involved in the target session is attack traffic using Webshell encrypted communication.

[0045] The traffic identification method provided in this application obtains the first session traffic of the requester and the second session traffic of the responder based on the received target session; it then uses a request-direction detection model to perform traffic detection processing on the request payload data in the first session traffic to obtain a first traffic detection result indicating whether the first session traffic satisfies Webshell encrypted communication; similarly, it uses a response-direction traffic detection model to perform traffic detection on the response payload data in the second session traffic to obtain a second traffic detection result indicating whether the second session traffic satisfies Webshell encrypted communication; if both the first and second traffic detection results satisfy Webshell encrypted communication and match, then the traffic involved in the target session is confirmed to be attack traffic using Webshell encrypted communication. By implementing the aforementioned method, the payload data in the request-direction and response-direction traffic is identified and processed separately. This payload data is the key data that Webshell attack traffic focuses on; therefore, when performing traffic identification based on payload data, the accuracy of Webshell attack traffic identification results can be greatly improved.

[0046] Optionally, based on the above embodiments, step S102 can be performed in this embodiment according to the following method: the request payload data is encrypted and encoded according to the set encryption encoding method, and the first target length range of the encrypted and encoded request payload data is estimated; the first target length range is matched with the first set length range corresponding to each function of the Webshell encrypted communication in the request direction to obtain the first traffic detection result.

[0047] Specifically, Webshell management tools have multiple functions, with different functions corresponding to different codes and varying lengths. Furthermore, before executing a function, the corresponding code is typically encrypted and sent to the server for execution. However, the payload length for each function is fixed. Therefore, the request direction detection model in this embodiment needs to be established according to the following rules: different Webshell attack traffic generally undergoes encryption and encoding processing. Therefore, for each function provided by the Webshell, the length range corresponding to the payload data (fixed length) under each encryption and encoding combination under that function can be pre-calculated according to each encryption method and each encoding method used, and denoted as the first set length range. Following the aforementioned calculation method, the first set length range corresponding to each function can be calculated. It should be noted that each encryption and encoding combination includes an encryption algorithm and an encoding algorithm, but the encryption and encoding algorithms of each encryption and encoding combination are algorithms commonly used in Webshell attacks.

[0048] Based on this, when performing traffic detection on request load data, the identification approach of the request direction basic model can be followed. First, the request load data is encrypted and encoded according to each encryption and encoding combination in the request direction detection model, and then the encrypted and encoded request load data is calculated. For each encrypted and encoded request load data, a first target length range of the encrypted and encoded request load data is estimated; then, this first target length range is matched with the first set length range corresponding to each function in the request direction detection model, thereby obtaining the first traffic detection result.

[0049] Optionally, the encryption algorithm mentioned above can be, but is not limited to, AES encryption, etc. The encoding algorithm can be, but is not limited to, BASE64 encoding, etc. Based on this, the methods for determining the encryption length of the AES encryption algorithm and the encoding length of the BASE64 encoding algorithm can be as follows:

[0050] AES encryption length: 16 * (rawstring.length() / 16 + 1)

[0051] BASE64 encoded length: rawstring.length() * (4 / 3)

[0052] However, it should be noted that in the calculation of the BASE64 encoding length, if the value of rawstring.length() is not divisible by 3, then the value of rawstring.length() is added to the smallest value divisible by 3. For example, if the value of rawstring.length() is 64, then 64 needs to be added to 66, so that the encoding length is 66*(4 / 3)=88.

[0053] It should be noted that the functions included in the above-mentioned Webshell encrypted communication may include, but are not limited to, connection functions, command execution functions, etc.

[0054] Taking the connection function as an example, if the payload data length under this connection function is 'a' bytes, then after concatenating a random character length within the range of [0, 3000] and performing encryption encoding, the first set length range corresponding to this connection function can be obtained as [min(a), max(a+3000)]. Furthermore, taking the command execution function as another example, if the payload data length under this command execution function is fixed at 'b' bytes, then the second set length range after encryption encoding can be denoted as [min(b), max(b)].

[0055] Furthermore, when matching the first target length range with the first preset length range corresponding to each function in the request direction detection model, if the first target length range falls within the first preset length range of any function, it can be confirmed that the first session traffic is session traffic used to implement that function. Therefore, it can be confirmed that the first traffic detection result satisfies Webshell encrypted communication. Additionally, the first traffic detection result can also include the function corresponding to the first preset length range into which the first target length range falls, which can be denoted as the aforementioned target function. For example, when the matched target function is a connection function, the first traffic detection result can be represented as: YES, connection function.

[0056] Conversely, if it is confirmed that the first target length range does not fall within the first set length range corresponding to each function of Webshell encrypted communication, then it can be confirmed that the first session traffic does not meet the Webshell encrypted communication requirement, and the first traffic detection result is a mismatch.

[0057] When a mismatch is detected in the first traffic detection result, in one embodiment, it can be identified to some extent that the first session traffic does not belong to Webshell attack traffic. In another embodiment, to improve the accuracy of the traffic identification result, further confirmation will be performed, which will be described in detail later.

[0058] Optionally, based on the above embodiments, step S103 can be performed in this embodiment according to the following method: the response payload data is encrypted and encoded according to the set encryption encoding method, and the second target length range of the encrypted response payload data is estimated; the second target length range is matched with the second set length range corresponding to each function of the Webshell encrypted communication in the response direction to obtain the second traffic detection result.

[0059] Specifically, after different function request payload data are sent to the server, the server executes the request payload data and then returns the execution result as response payload data in the second session traffic to the client. During the return process, the network security device captures this second session traffic, parses the response payload data from it, and then performs traffic detection. Similar to the traffic detection method in the request direction, when performing traffic detection in the response direction, since the length of the response payload data (effective payload data) corresponding to each function is fixed, the pre-established response direction traffic detection model in this embodiment can be established based on the following rules: For each function provided by the Webshell, the length range corresponding to the payload data (fixed length) under each encryption and encoding combination under that function can be pre-calculated according to each encryption method and each encoding method used, and recorded as the second set length range; according to the aforementioned calculation method, the second set length range corresponding to each function can be calculated respectively. It should be noted that each encryption and encoding combination includes an encryption algorithm and an encoding algorithm, but the encryption algorithm and encoding algorithm of each encryption and encoding combination are algorithms commonly used in Webshell attacks.

[0060] Based on this, when performing traffic detection on the response load data, the identification approach of the response direction basic model can be followed. First, the response load data is encrypted and encoded according to each encryption encoding combination in the response direction detection model, and then the encrypted response load data is calculated. For each encrypted response load data, the second target length range of the encrypted response load data is estimated; then, this second target length range is matched with the second set length range corresponding to each function in the response direction detection model, thereby obtaining the second traffic detection result.

[0061] For ease of understanding, let's take the connection function and command execution function as examples. For the connection function, assuming the server's response payload data length after executing the code is x bytes, and after concatenating the same length of random characters sent by the requesting side and encrypting it, the second target length range of the content returned to the client after encryption and encoding when the execution is successful can be calculated as: [min(x), max(x+3000)]. As for the command execution function, assuming the length of the response result (response payload data) after the server's execution is successful is m bytes, and the length of the response payload data after the execution fails is n bytes, then the second target length range after encryption and encoding after successful execution and failure can be calculated as: [min(m), max(m)] and [min(n), max(n)], respectively.

[0062] Furthermore, when matching the second target length range with the respective second preset length ranges of each function in the request direction detection model, if the second target length range falls within the second preset length range of any function, it can be confirmed that the second session traffic is session traffic used to implement that function. Therefore, it can be confirmed that the second traffic detection result satisfies Webshell encrypted communication. Additionally, the second traffic detection result can also include the function corresponding to the second preset length range into which the second target length range falls, which can be denoted as the aforementioned target function. For example, when the matched target function is a connection function, the second traffic detection result can be expressed as: Connection function: YES.

[0063] Conversely, if it is confirmed that the length range of the second target does not fall within the second set length range corresponding to each function of Webshell encrypted communication, then it can be confirmed that the second session traffic does not meet the Webshell encrypted communication requirement, and the second traffic detection result is a mismatch.

[0064] When a mismatch is detected in the second traffic detection result, in one embodiment, it can be identified to some extent that the second session traffic does not belong to Webshell attack traffic. In another embodiment, to improve the accuracy of the traffic identification result, further confirmation will be performed, which will be described in detail later.

[0065] Optionally, in one possible embodiment, the first traffic detection result and the second traffic detection result can be confirmed to satisfy Webshell encrypted communication and match by the following method: when the first traffic detection result includes a first target function corresponding to a first set length range containing the first target length range, and the second traffic detection result includes a second target function corresponding to a second set length range containing the second target length access, if the first target function and the second target function are the same, then it is confirmed that the first traffic detection result and the second traffic detection result satisfy Webshell encrypted communication and match.

[0066] Specifically, when identifying traffic based on the aforementioned method, if the first traffic detection result is YES (connection function), it indicates that the first session traffic satisfies Webshell encrypted communication, and the function corresponding to the request payload data of the first session traffic is the connection function; that is, the aforementioned first target function is the connection function. If the second traffic detection result is YES (connection function), it indicates that the second session traffic also satisfies Webshell encrypted communication, and the function corresponding to the response payload data of the second session traffic is also the connection function; that is, the aforementioned second target function is the connection function. Based on this, both the first and second session traffic point to the target session executing the Webshell connection function, thus confirming that the traffic involved in the target session is Webshell attack traffic.

[0067] Conversely, if the first target function is inconsistent with the second target function, it can be confirmed to some extent that the traffic involved in the target session may not be Webshell attack traffic.

[0068] Optionally, in another embodiment, the first traffic detection result and the second traffic detection result can be confirmed to satisfy Webshell encrypted communication and match by the following method: determining the target length difference range between the first target length range and the second target length access; matching the target length difference range with the set length difference range corresponding to each function of the Webshell encrypted communication, wherein the set length difference range of each function is determined by the first set length range of the function in the request direction and the second set length range of the function in the response direction; when it is confirmed that the target length difference range is within the set length difference range of any function, it is confirmed that the first traffic detection result and the second traffic detection result satisfy Webshell encrypted communication and match.

[0069] Specifically, when both the first and second traffic detection results confirm Webshell encrypted communication, to further confirm whether it is Webshell attack traffic and improve identification accuracy while reducing false alarm rate, this embodiment proposes a specific process for matching the first and second traffic detection results: a difference model is invoked for traffic identification processing. The processing of this difference model is roughly as follows: based on the first and second target length ranges calculated from the request and response load data respectively, the difference between these two ranges is calculated to estimate the target length difference range. The difference model pre-calculates the set length difference range corresponding to each function of the Webshell encrypted communication, and the set length difference range for each function can be calculated from the first set length range in the request direction and the second set length range in the response direction.

[0070] Once the target length difference range is determined, it can be matched with the set length difference range of each function to confirm whether there is a set length difference range that includes the target length difference range. If so, it indicates that the first traffic detection result matches the second traffic detection result, and also indicates that the traffic involved in the target session belongs to Webshell attack traffic.

[0071] Conversely, if it is confirmed that there is no set length difference range that includes the target length difference range, then it is confirmed that the target session is not involved in a Webshell attack.

[0072] When establishing the difference model, the length range difference of the encrypted response content after encryption for each function request of the encrypted webshell and different execution results of the server is calculated in advance, and a difference model is established. For example, for the connection function, since the request payload is fixed, the response content (payload data) after successful execution is fixed, and the length of the random characters filled is the same in both the request and response directions, the length difference between the encrypted request and response content after encryption will remain within a finer-grained range regardless of how the length of the random characters changes. Similarly, for the command execution function, based on the encrypted traffic of the command execution request and response content (payload data), multiple difference ranges can be established according to different execution results of the server to fully cover different situations. This improves the accuracy of traffic identification results.

[0073] Optionally, in practical applications, there may be situations where both the first and second traffic detection results satisfy Webshell encrypted communication, but the first traffic detection result does not match. In this case, in order to further improve the accuracy of the traffic identification results, this embodiment proposes to adopt the traffic detection steps of the above-mentioned difference model, thereby improving the accuracy of the traffic detection results.

[0074] Furthermore, if it is confirmed that either the first traffic detection result or the second traffic detection result does not meet the Webshell encrypted communication requirement, this embodiment can also adopt the traffic detection steps of the above-mentioned difference model in order to further improve the accuracy of the traffic identification result, thereby improving the accuracy of the traffic detection result.

[0075] Optionally, based on any of the above embodiments, in this embodiment, before traffic identification, the received sessions can be cached. Since the WebShell performs multiple functions, multiple BASE64 encoded traffics of inconsistent lengths will be generated under the same source and destination IP and URL. In order to reduce the amount of computation and improve accuracy, all BASE64 encoded traffic under a fixed source and destination IP and URL is cached, and then the traffic detection method proposed in any embodiment of this application is executed for each traffic.

[0076] Based on any of the above embodiments, this embodiment proposes that the traffic identification method in any of the above embodiments can be executed by the detection engine in the network security device.

[0077] Based on any of the embodiments, this embodiment also provides the following traffic identification method: obtaining input features and performing traffic detection based on the input features, wherein the input features may include traffic-related features in statistical analysis methods.

[0078] Therefore, by implementing the traffic identification method provided in any embodiment of this application, it is helpful to identify encrypted Webshell encrypted communication attacks with high accuracy, and the traffic identification method provided in this application has strong versatility. In addition, this application performs traffic detection based on the load data in the traffic, which can greatly reduce the false alarm rate. Moreover, this application does not require decoding or decryption operations, and can directly identify traffic by detecting session traffic (raw encrypted traffic), effectively reducing the impact on the performance of network security equipment.

[0079] Based on the same inventive concept, this application also provides a flow identification device corresponding to the above-described flow identification method. Specific implementation details of this flow identification device can be found in the above description of the flow identification method, and will not be elaborated upon here.

[0080] See Figure 2 , Figure 2 This application provides an exemplary embodiment of a traffic identification device, comprising:

[0081] The acquisition module 201 is used to acquire the first session traffic of the requester and the second session traffic of the responder based on the received target session;

[0082] The first detection module 202 is used to perform traffic detection processing on the request load data in the first session traffic using the request direction detection model, so as to obtain the first traffic detection result of whether the first session traffic meets the Webshell encrypted communication requirement.

[0083] The second detection module 203 is used to perform traffic detection on the response load data in the second session traffic using the response direction traffic detection model, so as to obtain the second traffic detection result of whether the second session traffic meets the Webshell encrypted communication requirement.

[0084] The identification module 204 is used to confirm that the traffic involved in the target session is attack traffic using Webshell encrypted communication if both the first traffic detection result and the second traffic detection result satisfy Webshell encrypted communication and match.

[0085] Optionally, based on the above embodiments, in this embodiment, the first detection module 202 is specifically used to encrypt and encode the request payload data according to a set encryption encoding method, estimate the first target length range of the encrypted request payload data, and match the first target length range with the first set length range corresponding to each function of the Webshell encrypted communication in the request direction to obtain the first traffic detection result.

[0086] Optionally, based on the above embodiments, in this embodiment, the second detection module 203 is specifically used to encrypt and encode the response payload data according to a set encryption encoding method, estimate the second target length range of the encrypted response payload data, and match the second target length range with the second set length range corresponding to each function of the Webshell encrypted communication in the response direction to obtain the second traffic detection result.

[0087] Optionally, based on the above embodiments, in one possible embodiment, the identification module 204 is specifically used to confirm that the first traffic detection result and the second traffic detection result both satisfy Webshell encrypted communication and match according to the following method: when the first traffic detection result includes a first target function corresponding to a first set length range containing the first target length range, and the second traffic detection result includes a second target function corresponding to a second set length range containing the second target length access, if the first target function and the second target function are the same, then it is confirmed that the first traffic detection result and the second traffic detection result both satisfy Webshell encrypted communication and match.

[0088] Optionally, based on the above embodiments, in another possible embodiment, the identification module 204 is specifically used to confirm that the first traffic detection result and the second traffic detection result both satisfy Webshell encrypted communication and match according to the following method: determining the target length difference range between the first target length range and the second target length access; matching the target length difference range with the set length difference range corresponding to each function of the Webshell encrypted communication, wherein the set length difference range of each function is determined by the first set length range of the function in the request direction and the second set length range of the function in the response direction; when it is confirmed that the target length difference range is within the set length difference range of any function, it is confirmed that the first traffic detection result and the second traffic detection result both satisfy Webshell encrypted communication and match.

[0089] In any embodiment of this application, the traffic identification device identifies and processes the load data in the traffic in the request direction and the response direction, respectively. This load data is the key data that Webshell attack traffic focuses on. Therefore, when identifying traffic based on load data, the accuracy of Webshell attack traffic identification results can be greatly improved.

[0090] Based on the same inventive concept, embodiments of this application provide an electronic device, which may be, but is not limited to, the aforementioned network security device. For example... Figure 3 As shown, the electronic device includes a processor 301 and a machine-readable storage medium 302. The machine-readable storage medium 302 stores a computer program executable by the processor 301. The processor 301 is prompted by the computer program to execute the traffic identification method provided in any embodiment of this application. Furthermore, the electronic device also includes a communication interface 303 and a communication bus 304, wherein the processor 301, the communication interface 303, and the machine-readable storage medium 302 communicate with each other via the communication bus 304.

[0091] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0092] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0093] The machine-readable storage medium 302 described above can be a memory, which may include random access memory (RAM), DDR SRAM (Double Data Rate Synchronous Dynamic Random Access Memory), or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0094] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0095] For embodiments of electronic devices and machine-readable storage media, since the methods involved are basically similar to those in the foregoing method embodiments, the description is relatively simple, and relevant details can be found in the descriptions of the method embodiments.

[0096] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0097] The specific implementation process of the functions and roles of each unit / module in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0098] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units / modules described as separate components may or may not be physically separate. The components shown as units / modules may or may not be physical units / modules, that is, they may be located in one place or distributed across multiple network units / modules. Some or all of the units / modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0099] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A traffic flow identification method, characterized in that, include: Based on the received target session, obtain the first session traffic of the requester and the second session traffic of the responder; The request load data in the first session traffic is processed using a request direction detection model to obtain a first traffic detection result for whether the first session traffic meets the requirements of Webshell encrypted communication. The response load data in the second session traffic is detected using a response direction traffic detection model to obtain the second traffic detection result of whether the second session traffic meets the requirements of Webshell encrypted communication. If both the first traffic detection result and the second traffic detection result satisfy Webshell encrypted communication and match, then it is confirmed that the traffic involved in the target session is attack traffic using Webshell encrypted communication. The method confirms that both the first traffic detection result and the second traffic detection result satisfy Webshell encrypted communication and match in the following manner: If the first target function and the second target function are the same, then it is confirmed that both the first traffic detection result and the second traffic detection result satisfy Webshell encrypted communication and match; wherein, the first target function refers to the Webshell encrypted communication function corresponding to the request load data of the first session traffic, and the second target function refers to the Webshell encrypted communication function corresponding to the response load data of the second session traffic. or, If the set length difference range corresponding to any function of Webshell encrypted communication includes the target length difference range, then it is confirmed that both the first traffic detection result and the second traffic detection result satisfy Webshell encrypted communication and match; wherein, the set length difference range refers to the difference range between the first set length range of the Webshell encrypted communication function in the request direction and the second set length range of the function in the response direction, the target length difference range refers to the difference range between the first target length range and the second target length range, the first target length range refers to the length range of the encrypted request payload data, and the second target length range refers to the length range of the encrypted response payload data.

2. The method according to claim 1, characterized in that, The request load data in the first session traffic is processed using a request direction detection model to obtain a first traffic detection result indicating whether the first session traffic meets the requirements for encrypted Webshell communication, including: According to the set encryption encoding method, the request payload data is encrypted and encoded, and the first target length range of the encrypted and encoded request payload data is estimated. The first target length range is matched with the first set length range corresponding to each function of the Webshell encrypted communication in the request direction to obtain the first traffic detection result.

3. The method according to claim 2, characterized in that, The response load data in the second session traffic is inspected using a response direction traffic detection model to obtain a second traffic detection result indicating whether the second session traffic meets the requirements for Webshell encrypted communication, including: According to the set encryption encoding method, the response payload data is encrypted and encoded, and the second target length range of the encrypted response payload data is estimated. The second target length range is matched with the second set length range corresponding to each function of the Webshell encrypted communication in the response direction to obtain the second traffic detection result.

4. A flow rate identification device, characterized in that, include: The acquisition module is used to acquire the first session traffic of the requester and the second session traffic of the responder based on the received target session; The first detection module is used to perform traffic detection processing on the request load data in the first session traffic using a request direction detection model, so as to obtain the first traffic detection result of whether the first session traffic meets the requirements of Webshell encrypted communication. The second detection module is used to perform traffic detection on the response load data in the second session traffic using the response direction traffic detection model, so as to obtain the second traffic detection result of whether the second session traffic meets the requirements of Webshell encrypted communication. The identification module is used to confirm that the traffic involved in the target session is attack traffic using Webshell encrypted communication if both the first traffic detection result and the second traffic detection result satisfy Webshell encrypted communication and match. The identification module confirms that both the first traffic detection result and the second traffic detection result satisfy Webshell encrypted communication and match in the following way: If the first target function and the second target function are the same, then it is confirmed that both the first traffic detection result and the second traffic detection result satisfy Webshell encrypted communication and match; wherein, the first target function refers to the Webshell encrypted communication function corresponding to the request load data of the first session traffic, and the second target function refers to the Webshell encrypted communication function corresponding to the response load data of the second session traffic. or, If the set length difference range corresponding to any function of Webshell encrypted communication includes the target length difference range, then it is confirmed that both the first traffic detection result and the second traffic detection result satisfy Webshell encrypted communication and match; wherein, the set length difference range refers to the difference range between the first set length range of the Webshell encrypted communication function in the request direction and the second set length range of the function in the response direction, the target length difference range refers to the difference range between the first target length range and the second target length range, the first target length range refers to the length range of the encrypted request payload data, and the second target length range refers to the length range of the encrypted response payload data.

5. The apparatus according to claim 4, characterized in that, The first detection module is specifically used to encrypt and encode the request payload data according to a set encryption encoding method, estimate the first target length range of the encrypted request payload data, and match the first target length range with the first set length range corresponding to each function of the Webshell encrypted communication in the request direction to obtain the first traffic detection result.

6. The apparatus according to claim 5, characterized in that, The second detection module is specifically used to encrypt and encode the response payload data according to a set encryption encoding method, estimate the second target length range of the encrypted response payload data, and match the second target length range with the second set length range corresponding to each function of the Webshell encrypted communication in the response direction to obtain the second traffic detection result.

Images