Data processing method and device, equipment, storage medium and program product

Abstract

The invention discloses a data processing method and device, equipment, a storage medium and a program product, and relates to the technical field of communication. The method comprises the steps of obtaining original log data of a data center; based on the original log data, generating an original request sequence of the user, the original request sequence being a set of continuous access requests aggregated based on the same user and arranged in a sliding time window according to a timestamp sequence; extracting data of multiple user access behavior dimensions from the access requests in the original request sequence to obtain a request feature vector sequence corresponding to the original request sequence; and determining a network attack risk type of the original request sequence according to the request feature vector sequence through a sequence classification model. Therefore, the hidden network attack taking the client debugging as the entrance can be accurately identified, and the service security and the service continuity of the data center are improved.

Description

Technical Field

[0001] This application belongs to the field of communication technology, and in particular relates to a data processing method, apparatus, device, storage medium and program product. Background Technology

[0002] Data centers are the infrastructure supporting an organization's service operations, and their responsibility is to ensure the continuous, stable, and secure operation of the service environment. With the widespread application of technologies such as cloud computing, big data, and generative artificial intelligence, the system scale and architectural complexity of data centers are constantly increasing, making security protection tasks increasingly demanding. If cyberattacks are not detected by the protection system in a timely manner, they will lead to system anomalies, interruptions, or data leaks, seriously affecting the service continuity of the data center.

[0003] In recent years, the front-end and back-end separation architecture has been widely adopted, with more and more service logic being moved to the front end, i.e., the client, for execution. While this has improved system flexibility, it has also expanded the security exposure surface. Specifically, attackers can use browser developer tools or debugging proxies to analyze and modify the front-end interface, thereby indirectly probing the back-end service logic and carrying out attacks such as unauthorized access, identity forgery, or data tampering, which can easily evade the identification of traditional protection systems. Summary of the Invention

[0004] This application provides a data processing method, apparatus, device, storage medium, and program product that can solve the technical problem of being unable to accurately identify covert network attacks that start with client debugging, leading to low data center service security and poor service continuity.

[0005] In a first aspect, embodiments of this application provide a data processing method, including: Obtain raw log data from the data center; Based on the raw log data, the user's original request sequence is generated. The original request sequence is a set of consecutive access requests aggregated based on the same user and arranged in timestamp order within a sliding time window. From the access requests in the original request sequence, data from multiple user access behavior dimensions are extracted to obtain a request feature vector sequence corresponding to the original request sequence. By using a sequence classification model, the network attack risk type of the original request sequence can be determined based on the request feature vector sequence.

[0006] Secondly, embodiments of this application provide a data processing apparatus, including: The acquisition module is used to acquire raw log data from the data center. The generation module is used to generate the user's original request sequence based on the raw log data. The original request sequence is a set of consecutive access requests aggregated from the same user and arranged in timestamp order within a sliding time window. The extraction module is used to extract data from multiple user access behavior dimensions from the access requests in the original request sequence, and obtain a request feature vector sequence corresponding to the original request sequence. The determination module is used to determine the network attack risk type of the original request sequence based on the request feature vector sequence using a sequence classification model.

[0007] Thirdly, embodiments of this application provide a computer device, which includes: a processor and a memory storing computer program instructions; When the processor executes computer program instructions, it implements the data processing method as described in the first aspect.

[0008] Fourthly, embodiments of this application provide a computer storage medium storing computer program instructions, which, when executed by a processor, implement the data processing method as described in the first aspect.

[0009] Fifthly, embodiments of this application provide a chip, which includes a processor and a communication interface. The communication interface and the processor are coupled, and the processor is used to run programs or instructions to implement the data processing method as shown in the first aspect.

[0010] In a sixth aspect, embodiments of this application provide a computer program product stored in a storage medium, which is executed by at least one processor to implement the data processing method as described in the first aspect.

[0011] The data processing method, apparatus, device, storage medium, and program product of this application embodiment acquire raw log data from a data center; based on the raw log data, generate a user's raw request sequence, wherein the raw request sequence is a set of consecutive access requests aggregated based on the same user and arranged in timestamp order within a sliding time window; extract data from multiple user access behavior dimensions from the access requests in the raw request sequence to obtain a request feature vector sequence corresponding to the raw request sequence; and determine the network attack risk type of the raw request sequence based on the request feature vector sequence using a sequence classification model. In this way, based on the raw logs of the data center, a standardized raw request sequence is constructed by aggregating requests from the same user, combining sliding time windows for filtering, and sorting by timestamp. This sequence can integrate fragmented client debugging and probing requests into time-correlated analysis units, eliminating irrelevant request interference, and solving the pain point that traditional detection cannot track continuous debugging behavior. Furthermore, multi-dimensional access behavior quantitative data is extracted based on the raw request sequence to construct a high-dimensional feature vector sequence, transforming unstructured client debugging behavior into standardized numerical features that the model can directly process. This compensates for the deficiency of traditional detection in capturing the timing features of attacks, improves the feature extraction capability of covert debugging attacks, and accurately determines the attack risk type based on the high-dimensional feature vector sequence through a sequence classification model. It automatically identifies covert client debugging attacks, blocks malicious intrusions from the source, improves data center service security, avoids service interruptions and data leaks, and ensures stable service operation. Attached Figure Description

[0012] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a schematic diagram of a data processing system according to an embodiment of the data processing method provided in this application; Figure 2 This is a flowchart of a data processing method according to an embodiment of the data processing method provided in this application; Figure 3 This is a schematic diagram of the structure of a data processing apparatus provided in one embodiment of this application; Figure 4 This is a schematic diagram of the structure of a computer device provided in one embodiment of this application. Detailed Implementation

[0014] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0015] It should be noted that, in this document, relational terms such as "first" and "second" are used merely 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..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0016] The acquisition, storage, use, and processing of data (including but not limited to features and information mentioned in this document) in the technical solution of this application all comply with the relevant provisions of national laws and regulations.

[0017] In related technologies, network attacks can be detected in the following two ways, as detailed below.

[0018] Option 1 can detect unauthorized attack methods based on the consistency rules of Hypertext Transfer Protocol (HTTP) request sequences and parameters. Specifically, this can include obtaining the HTTP request, parsing the HTTP request to obtain the URL address of the HTTP request; determining whether there is a protection rule corresponding to the URL address; if there is a protection rule corresponding to the URL address, obtaining the access data of the HTTP request; determining whether the access data meets the protection rule; if not, determining that the HTTP request corresponding to the access data is an unauthorized attack.

[0019] Option two involves injecting a detection script into the server response data to identify whether a client is using a debugging proxy tool. Specifically, this can involve the gateway embedding a pre-configured detection script when forwarding the server response. This script is configured to attempt to access a specific proxy tool's identifier file address and send a notification message to a predetermined network address upon successful access. By determining whether this notification is received, it can be determined whether the electronic device is using a proxy debugging tool, thereby effectively identifying potential attackers and achieving pre-emptive attack detection.

[0020] However, the aforementioned methods still have significant shortcomings. First, they require embedding Software Development Kits (SDKs) or scripts on the client side to collect environments and fingerprints, leading to end-to-end compatibility and performance overhead, as well as privacy and compliance risks. In adversarial scenarios, they are easily simulated, tampered with, and bypassed by anti-fingerprinting, and the cost of cross-electronic device and multi-version adaptation is high. Second, they are prone to failure under service gray-scale deployment, multi-version parallelism, and rapid iteration, resulting in high manual maintenance costs and difficulties in cross-system migration. Attack actions are sparse, slow-paced, and scattered across multiple sessions and / or stages, rendering the traditional assumption that high frequency equates to anomaly invalid. The lack of a unified expression for cross-session temporal dependencies and relationships makes detection capabilities highly dependent on rule quality and update frequency. Furthermore, the aforementioned methods are mostly static matching or single-point decisions, making it difficult to express higher-order semantics such as process state transitions, time interval patterns, parameter entropy changes, and minor mutations. They cannot distinguish the intent layer of seemingly normal slow-paced sequences, which is the root cause of the difficulty in distinguishing concealment.

[0021] Therefore, there is an urgent need for a solution that can capture client behavior semantics, understand operational intent, and identify malicious debugging attack patterns that use client debugging as an entry point, without requiring application modification or adaptation. This solution can improve the accuracy of identifying covert network attacks, reduce false positive rates, and ensure data center service security and improve service continuity.

[0022] To address the aforementioned pain points, embodiments of this application provide a data processing method, apparatus, device, storage medium, and program product that models logs generated by users in a data center during their access, thereby identifying implicit and abnormal debugging behavior patterns and achieving real-time network attack identification and defense.

[0023] The following will be combined with the appendix Figures 1 to 4 This application describes in detail the data processing methods, apparatus, computer equipment, storage media, and program products of the embodiments thereof. It should be noted that these embodiments are not intended to limit the scope of this application.

[0024] The following is combined Figure 1 The data processing system provided in the embodiments of this application will be described in detail.

[0025] Figure 1 This is a schematic diagram of a data processing system provided in an embodiment of this application.

[0026] like Figure 1 As shown, this embodiment proposes a data processing system for identifying debugging network attack behaviors based on sequence representation learning. This system is deployed in a data center using either a bypass deployment or log analysis mode, without affecting the performance of the main service link. Based on this, the data processing system 10 in this embodiment may include a log collection and session reconstruction module 101, a multi-dimensional feature extraction and serialization module 102, a sequence representation learning inference module 103, and an asymmetric response and self-learning module 104.

[0027] The above modules are described in detail below.

[0028] The log collection and session reassembly module 101 is used to extract log streams from target devices such as load balancers, web application protection devices, and application servers in the data center, and to standardize the log streams to generate raw log data. Specifically, the log collection and session reassembly module 101 can be used to extract log streams from target devices according to the service flow of access requests processed in the data center; wherein, the target devices are devices in the data center that generate access request logs, and the target devices include at least one of the following: load balancers, web application protection devices, and application servers. Among them, the web application protection devices can be devices deployed with a World Wide Web (Web) Application Firewall (WAF), and the application servers can be at least one of the following: Nginx (enginex) servers, i.e., high-performance HTTP and reverse proxy web servers, and web servers. The log collection and session reassembly module 101 can also be used to standardize the log streams (access logs) extracted from each target device, and obtain raw log data based on the standardized log streams.

[0029] The multidimensional feature extraction and serialization module 102 is used to aggregate log data belonging to the same user based on the original log data, using request identifiers, and then extracting and sorting the data by timestamps using a sliding time window to generate the user's original request sequence. Specifically, the multidimensional feature extraction and serialization module 102 can generate the user's original request sequence based on the original log data. Further, using request identifiers as aggregation conditions, log data belonging to the same user in the original log data is aggregated based on at least one request identifier to obtain user log data by user. The request identifier is information in the log used to associate access requests of the same user, and the request identifier includes at least one of the following: Session ID, Authorization Token, Internet Protocol Address (IP address), or User Agent. Log window data within the sliding time window is extracted from the user log data according to a preset duration sliding time window. All access requests within the log window data are sorted according to the order of access request timestamps to obtain the user's original request sequence.

[0030] The sequence representation learning and inference module 103 is used to extract multi-dimensional user access behavior features, such as access time, request parameter content, and request structure, from the original request sequence, and generate a corresponding request feature vector sequence. Specifically, the sequence representation learning and inference module 103 can extract data from multiple user access behavior dimensions from the access requests in the original request sequence to obtain a request feature vector sequence corresponding to the original request sequence.

[0031] The multiple user access behavior dimensions in this application embodiment include the access time dimension, the access request parameter content dimension, and the access request structure dimension. Further, the data in the access time dimension includes the request variation coefficient, which characterizes the relative dispersion of the time intervals between access requests in the original request sequence; the data in the access request parameter content dimension includes the parameter entropy change rate, which characterizes the randomness of the character distribution of key parameter values ​​in the access requests in the original request sequence, where key parameter values ​​are the Uniform Resource Locator URLs within the access requests or the parameter values ​​carrying service identifiers in the request body; the data in the access request structure dimension includes the request structure variation rate, which characterizes the relative variation of the URL templates of every two adjacent access requests in the original request sequence.

[0032] The asymmetric response and self-learning module 104 is used to map the quantized request feature vector sequence to network attack risk types, and to determine the network attack risk type of the original request sequence based on the request feature vector sequence, execute graded security responses, and update and optimize the sequence classification model using manually labeled samples to achieve self-learning iteration. Specifically, the sequence classification model determines the network attack risk type of the original request sequence based on the request feature vector sequence. The asymmetric response and self-learning module 104 can also be used to execute corresponding level security response operations based on the comparison result between the confidence level corresponding to the network attack risk type and a preset confidence threshold. It also receives confirmation attack tags or false alarm tags from operations personnel for alarm information; uses the labeled original request sequence, the network attack risk type corresponding to the labeled original request sequence, and the request feature vector sequence corresponding to the labeled original request sequence as training samples for the sequence classification model, trains the sequence classification model until preset training conditions are met, and obtains an updated sequence classification model, which is used for subsequent determination of network attack risk types.

[0033] Therefore, to address the lack of scientific and efficient methods and tools in data center production system security protection, which fails to effectively meet the needs of system security and data security risk prevention and control, the data processing system provided in this application embodiment can define the original request sequence triggered by client debugging tools and used to detect and exploit service logic vulnerabilities as a debugging attack, and conduct detection on this attack type as an independent category, which is fundamentally different from traditional network layer attacks and injection attacks. Furthermore, by capturing the context and continuity of operational intent in the time dimension of access behavior, it can detect covert and slow logic-level debugging attacks. Simultaneously, relying on the supporting data processing system, it performs sequence semantic modeling on access requests in the original log data, covering key clues such as time interval patterns, parameter entropy changes, and process state transitions. It uses a lightweight machine learning model to complete online low-latency judgment, and combines asymmetric hierarchical response and evidence chain replay to reduce the probability of false alarms and handling costs. Without intruding on the client, it improves the reliability, interpretability, and operability of security detection, providing support for risk control in data center production operations and further enhancing the risk control capabilities of data center production systems.

[0034] Based on this, the following is combined with Figure 2 The data processing methods performed by the data processing system in the embodiments of this application will be described in detail.

[0035] Figure 2 This is a flowchart of a data processing method provided in an embodiment of this application.

[0036] like Figure 2As shown, this data processing method can be applied to data processing equipment in data centers, and specifically includes: Step 210, obtaining raw log data from the data center; Step 220, generating a user's original request sequence based on the raw log data, wherein the original request sequence is a set of consecutive access requests aggregated based on the same user and arranged in timestamp order within a sliding time window; Step 230, extracting data from multiple user access behavior dimensions from the access requests in the original request sequence to obtain a request feature vector sequence corresponding to the original request sequence; Step 240, determining the network attack risk type of the original request sequence based on the request feature vector sequence using a sequence classification model.

[0037] In this embodiment, the log collection and session reassembly module can collect log streams from load balancers, WAF devices, and Nginx application servers. After standardization processing, raw log data is obtained. Taking four raw log data entries as an example: Raw Log Data 1: Session ID: SESSION_20260130_001; Request Timestamp: 2026-01-30-14:00:00; Request Method: POST; Request URL: / mall / order / query; Request Body: {"order_id":"1001"}; Target Device: Nginx Server; Raw Log Data 2: Session ID: SESSION_20260130_001; Request Timestamp: 2026-01-30-14:00:03; Request Method: POST; Request URL: / mall / order / query; Request body: {"order_id":"1001"}; Target device: WAF device; Original log data 3: Session ID: SESSION_20260130_001; Request timestamp: 2026-01-30-14:00:07; Request method: POST; Request URL: / mall / order / query; Request body: {"order_id":"1002"}; Target device: Load balancer; Original log data 4: Session ID: SESSION_20260130_001; Request timestamp: 2026-01-30-14:00:22; Request method: POST; Request URL: / mall / order / query; Request body: {"order_id":"1001"}; Target device: Nginx server.

[0038] Next, using the session ID as the aggregation condition, all logs belonging to the user are filtered out. Specifically, a 10-second sliding window is set to select requests with timestamps between 14:00:00 and 14:00:10, while requests exceeding the window (14:00:22) are discarded. Arranged in chronological order by request timestamp, the user's original request sequence is obtained: R = [r1, r2, r3], where r1 is the access request at 14:00:00, r2 is the access request at 14:00:03, and r3 is the access request at 14:00:07.

[0039] Furthermore, quantitative features can be extracted according to the access time dimension, request parameter content dimension, and request structure dimension, and corresponding feature vectors can be generated after calculation. Specifically, the request variation coefficient of the access time dimension can be calculated through the following steps: calculate the time interval between adjacent requests, r1 to r2 interval is 3S, r2 to r3 interval is 4S, the time interval sequence is (3,4), the mean of the time interval sequence is 3.5, and the standard deviation of the time interval sequence is 0.707. Then, its request variation coefficient is 0.707 / 3.5≈0.202. The parameter entropy change rate under the request parameter content dimension can be calculated through the following steps: extract the characters of each access request in the original request sequence, calculate the entropy, i.e., r1 character distribution uniformity is average, parameter entropy change rate is recorded as 1.79, r2 adds special characters, character randomness increases, parameter entropy change rate is recorded as 1.92, r3 is the same as r1, parameter entropy change rate is recorded as 1.79. The request structure variation rate under the quantitative features extracted from the request structure dimension is calculated through the following steps, i.e., URL templating: all 3 request URLs are / mall / order / query, and after templating, they are all / mall / order / query, with no difference. Levinstein distance = 0, maximum template length = 16, and structure variation rate = 0 / 16 = 0. Based on this, the multi-dimensional quantitative features of a single access request are combined into a request feature vector sequence X = [request variation coefficient x1, parameter entropy variation rate x2, request structure variation rate x3], where x1 = [0.202, 1.79, 0], x2 = [0.202, 1.92, 0], and x3 = [0.202, 1.79, 0].

[0040] Then, the request feature vector sequences x1=[0.202, 1.79, 0], x2=[0.202, 1.92, 0], and x3=[0.202, 1.79, 0] are input into the sequence classification model to obtain the three-class confidence scores of the original request sequence: normal traffic confidence score: 0.12; automated tool attack confidence score: 0.21; and manual debugging privilege escalation attack confidence score: 0.67. Based on this, the classification with the highest confidence score is selected, and the network attack risk type of the original request sequence is finally determined to be a manual debugging privilege escalation attack.

[0041] In this way, based on the raw logs of the data center, a standardized raw request sequence is constructed by aggregating requests from the same user, combining sliding time windows for filtering, and sorting by timestamp. This sequence can integrate fragmented client debugging and probing requests into time-correlated analysis units, eliminating irrelevant request interference, and solving the pain point that traditional detection cannot track continuous debugging behavior. Furthermore, multi-dimensional access behavior quantitative data is extracted based on the raw request sequence to construct a high-dimensional feature vector sequence, transforming unstructured client debugging behavior into standardized numerical features that the model can directly process. This compensates for the deficiency of traditional detection in capturing the timing features of attacks, improves the feature extraction capability of covert debugging attacks, and accurately determines the attack risk type based on the high-dimensional feature vector sequence through a sequence classification model. It automatically identifies covert client debugging attacks, blocks malicious intrusions from the source, improves data center service security, avoids service interruptions and data leaks, and ensures stable service operation.

[0042] The steps described above are explained in detail below.

[0043] Regarding step 210, the data center in this application embodiment may include a load balancing device, a web application protection device, and an application server. Therefore, in some embodiments of this application, step 210 may specifically include steps 2101 and 2102.

[0044] Step 2101: Extract the log stream from the target device according to the service flow of the data center for processing access requests; wherein, the target device is the device in the data center that generates access request logs, and the target device includes at least one of the following: load balancing device, web application protection device, and application server.

[0045] In some embodiments, the service flow for data center to process access requests is from user request, load balancer, web application protection device to application server. This service flow sequence can be followed, in which request distribution logs are extracted from the load balancer, request detection logs are extracted from the web application protection device, and request processing logs are extracted from the application server in sequence. There are no additional restrictions on the log generation format or field requirements. All log data is collected in the order of service flow to form a log stream.

[0046] Step 2102: Standardize the log stream extracted from each target device, and obtain the original log data based on the standardized log stream.

[0047] The standardization process involved in this step includes, but is not limited to, the following steps: field alignment, format standardization, and invalid log removal.

[0048] In addition, in some other embodiments of this application, step 2101 above can be replaced by extracting log streams from the target device according to the data center's service process for handling access requests and log generation rules.

[0049] In this step, the service flow from user request, load balancer, web application protection device to application server can be followed first to determine the device order and scope for log extraction. Then, according to the preset log generation rules, the log content of each device is filtered. Log fields including request timestamp, request identifier, request URL, and device processing result are extracted. Empty logs and logs with incorrect formats are removed, and the log timestamp format is standardized, such as converting it to yyyy-MM-dd HH:mm:ss. The filtered log data is then integrated according to the service flow order to generate a log stream that meets the requirements of subsequent processing.

[0050] Therefore, by extracting log streams from target devices in the data center through the above steps and performing standardized processing to generate raw log data, a compliant and standardized data foundation is provided for attack detection. This application embodiment can conduct detection based on server-side log data without performing any intrusive operations on the client environment. It can be quickly integrated into existing security protection systems to achieve collaborative protection with WAF, security panoramic traffic analysis platforms, and other systems. Simultaneously, based on this standardized raw log data, machine learning can be used to logically infer the client's intent reflected in the logs. Without directly monitoring the client, debugging behavior can be determined simply by analyzing indirect evidence in the server-side logs. Machine learning enables the discovery and management of various abnormal features, covering scenarios such as temporal anomaly patterns, parameter entropy changes and semantic anomalies, sequence logic violations, request replays, and mutations. Furthermore, it can achieve real-time detection and tiered response without interrupting normal services, effectively ensuring the operational stability of the data center while strengthening system security protection capabilities.

[0051] Regarding step 220, in some embodiments of this application, since the Hypertext Transfer Protocol is a stateless protocol, the scattered log streams need to be aggregated first. Based on this, step 220 may specifically include steps 2201 to 2203.

[0052] Step 2201: Using the request identifier as the aggregation condition, aggregate the log data belonging to the same user in the original log data based on at least one request identifier to obtain user log data by user. The request identifier is the information in the log used to associate access requests of the same user. The request identifier includes at least one of the following: session identifier, authorization token, Internet Protocol address, user agent identifier.

[0053] In this step, log streams of the same user can be aggregated into user-based behavioral session windows, which are user log data, based on at least one of session identifier, authorization token, Internet Protocol address, and user agent identifier.

[0054] Step 2202: Extract log window data from the user log data that falls within the preset sliding time window. The sliding time window is used to define the time range of the access request.

[0055] In this step, a preset sliding time window, such as 5 minutes, can be configured to define the time range for log aggregation.

[0056] Step 2203: Sort all access requests in the log window data according to the order of access request timestamps to obtain the user's original request sequence.

[0057] In this step, all requests within the same sliding time window are strictly ordered according to their timestamps, resulting in the final user's original request sequence. .

[0058] This allows for the precise aggregation of log data from the same user. By filtering through sliding time windows and sorting by timestamps, a well-ordered sequence of original requests can be generated, filtering out irrelevant requests and providing standardized analytical data for subsequent feature extraction.

[0059] Regarding step 230, in some embodiments of this application, in order to enable the sequence classification model to understand the debugging intent, this embodiment does not directly use the raw log data, but instead uses the raw log data... Transform into a sequence composed of high-dimensional feature vectors Therefore, step 230 may specifically include steps 2301 and 2302.

[0060] Step 2301: For each access request in the original request sequence, extract the data of each user access behavior dimension to obtain the feature vector corresponding to each access request.

[0061] In this step, the original request sequence is based on the output of the log collection and session reassembly module. For each access request, create a record for each access request. eigenvectors Where i∈[1,n], the eigenvectors =[Data in the access time dimension, data in the access request parameter content dimension, and data in the access request structure dimension].

[0062] Step 2302: Arrange the feature vectors corresponding to all access requests in the original request sequence according to the timestamp order consistent with the original request sequence to obtain the request feature vector sequence corresponding to the original request sequence.

[0063] In this step, based on the feature vectors corresponding to all access requests in the original request sequence, they are arranged in the same timestamp order as the original request sequence to obtain a request feature vector sequence corresponding to the original request sequence. This request feature vector sequence is a high-dimensional feature vector sequence, i.e., X={x ,x ,…,x }

[0064] Therefore, the multi-dimensional behavioral data of a single access request is transformed into a feature vector, which is then arranged in chronological order to form a feature vector sequence, thereby realizing the numericalization and serialization of access behavior and adapting to the input requirements of sequence classification models.

[0065] In some embodiments, the multiple user access behavior dimensions in this application include the access time dimension, the access request parameter content dimension, and the access request structure dimension. Based on this, step 2301 may specifically include steps 23011 to 23012.

[0066] Step 23011: For each access request in the original request sequence, extract data in the access time dimension, data in the access request parameter content dimension, and data in the access request structure dimension.

[0067] Step 23012: Based on the data in the access time dimension, the data in the access request parameter content dimension, and the data in the access request structure dimension corresponding to each access request, generate a feature vector corresponding to each access request.

[0068] In this step, each access request r The corresponding access time dimension data C Access request parameter content dimension data H(X), access request structure dimension data The features are then spliced ​​and merged to form a high-dimensional feature vector corresponding to each access request.

[0069] Therefore, the three core dimensions of feature extraction are clearly defined, the process of generating feature vectors for a single request is standardized, the targeting and consistency of feature extraction are improved, and the foundation for accurately determining attack risks is laid.

[0070] In this embodiment, the data in the access time dimension includes the request variation coefficient, which is used to characterize the relative dispersion of the access request time interval in the original request sequence. Based on this, step 23011 may specifically include steps 230111 to 230113.

[0071] Step 230111: For each access request in the original request sequence, extract the timestamp of each access request from the original request sequence to obtain a timestamp sequence.

[0072] In this step, each access request r is extracted from the original request sequence S. The corresponding timestamps form a timestamp sequence, which is T={t}. ,t ,…,t }, where t Let be the timestamp of the i-th access request.

[0073] Step 230112: Based on the timestamp sequence, calculate the time interval between every two adjacent access requests in the original request sequence to obtain the time interval sequence.

[0074] In this step, the time interval Δt between two adjacent requests is calculated based on the timestamp sequence T. , i from 2 to n, Δt =t -t This forms a time interval sequence, namely Δt={δ} ,δ ,…,δ }

[0075] Step 230113: Determine the Coefficient of Variation based on the mean and standard deviation of the time interval sequence; wherein, the mean of the time interval sequence is used to characterize the central tendency of adjacent access request time intervals in the original request sequence, and the standard deviation of the time interval sequence is used to characterize the absolute dispersion of adjacent access request time intervals in the original request sequence.

[0076] In this step, the mean of the time interval sequence can be determined using the following formula (1). .

[0077] The standard deviation of the time interval series can be determined by the following formula (2). .

[0078] Based on this, the requested coefficient of variation can be determined using the following formula (3). .

[0079] It should be noted that when At that time, representing Extremely small intervals indicate very evenly spaced access requests, typically found in automated tools. When... When traffic is moderate and follows a normal distribution, it typically represents normal user traffic. An abnormally large value indicates extremely high data dispersion, reflecting pulse-like debugging behavior by an attacker who manually modifies parameters, thinks, and sends signals. Specifically, in terms of timing characteristics, normal user operations have physiological reaction time, typically... And it has a random element). Script attacks are usually extremely fast, typically... Manual debugging attacks often exhibit characteristics of suddenness, pause, and re-emergence. For example, they might sequentially modify parameters, send the request, observe the response, reflect, and then modify it again, by calculating the sequence... The standard deviation and coefficient of variation are used to quantify this characteristic.

[0080] Therefore, by quantifying the relative dispersion of request time intervals using the coefficient of variation, abnormal access time rhythms can be captured, helping to distinguish the time behavior differences between manual debugging and automated attacks.

[0081] In this embodiment, normal service parameters are usually relatively fixed or regular, such as auto-incrementing IDs. During debugging attacks, attackers often construct special characters, such as OR1=1 or .. / .. / .. / etc / passwd, which causes the entropy value of key parameters to spike instantly. Therefore, the entropy value, i.e., the parameter entropy change rate, can be used to detect sudden changes in access requests. Based on this, the data in the access request parameter content dimension includes the parameter entropy change rate. The parameter entropy change rate is used to characterize the randomness of the character distribution of key parameter values ​​in the access request in the original request sequence. The key parameter values ​​are the Uniform Resource Locator URLs in the access request in the original request sequence or the parameter values ​​carrying service identifiers in the request body. Based on this, step 23011 can specifically include steps 230114 to 230116.

[0082] Step 230114: For each access request in the original request sequence, extract at least one key parameter value from the URL and / or request body of each access request.

[0083] Specifically, from each original request r Extract key service parameter values, such as order ID and user ID, from the Uniform Resource Locator (URL) and request body.

[0084] Step 230115: For each key parameter value, use the Shannon entropy algorithm to determine the probability of each character appearing in the string for each key parameter value.

[0085] In this step, for each key parameter value, the probability of each character appearing in the string for each key parameter value can be calculated according to the Shannon entropy algorithm as shown in the following formula (4): in, This represents the probability of the i-th character appearing in the parameter value string, thus reflecting the randomness of the parameter value.

[0086] Step 230116: Determine the parameter entropy change rate for each access request based on the probability of occurrence of each character in the string of each key parameter value.

[0087] In this step, if there is a key parameter, the probability of occurrence of each character in the string containing the key parameter value is used to determine the parameter entropy change rate for each access request. If there are multiple key parameters, the maximum or average entropy value (i.e., the probability of occurrence) is taken as the parameter entropy change rate for the access request.

[0088] Therefore, by quantifying the randomness of the character distribution of key parameters through parameter entropy values, abnormal behaviors such as parameter tampering and probing can be accurately identified, supplementing the attack feature support of the parameter dimension.

[0089] In this embodiment, the data for the access request structure dimension includes the request structure variation rate, which is used to characterize the relative variation of the URL templates of every two adjacent access requests in the original request sequence. Based on this, step 23011 may specifically include steps 230117 to 230118.

[0090] Step 230117: For each access request in the original request sequence, perform a template transformation on the URL path of each access request to obtain the URL template of each access request.

[0091] Step 230118: Determine the request structure variation rate of each access request based on the minimum edit distance of the URL templates of every two adjacent access requests in the original request sequence and the maximum length of the URL templates corresponding to every two adjacent access requests.

[0092] Thus, the mutation rate of the request structure is used to quantify the degree of mutation between adjacent request URL templates, capture abnormal changes in the request structure, and identify debugging attack behaviors at the structural level.

[0093] Further, step 230117 can specifically include: replacing the numeric characters in the URL path of each access request with a first preset tag, and replacing the service identifier in the URL path of each access request with a second preset tag, to obtain the URL template of each access request.

[0094] Exemplarily, for each original request r perform templatization conversion on the URL path, that is, replace the specific numeric characters in the path with a first preset tag, namely <Numeric Tag (NUM)>, and replace specific service IDs, such as user ID, product ID, with a second preset tag, namely <ID Tag (ID)>. Identify the pure numbers in the path and replace them with a unified tag to achieve URL normalization.

[0095] Thus, perform standardized templatization conversion on the URL path to eliminate interference from irrelevant characters and provide a unified benchmark for subsequent calculation of the edit distance and structural mutation rate of the URL template.

[0096] Further, in order to identify fuzz testing behaviors, if the templates of multiple consecutive access requests are the same, but the parameters only change slightly, such as the edit distance is very small, it is very likely that an attacker is using a tool for parameter enumeration or brute force cracking. Based on this, step 230118 can specifically include steps 2301181 to step 2301184.

[0097] Step 2301181, for each group of adjacent access requests in the original request sequence, obtain the URL template of each adjacent access request in each group of adjacent access requests.

[0098] In this step, for each group of adjacent access requests in the original request sequence, that is, r

[0099] , , , t , t-1 , , t ,

[0097] , t-1 , ,

[0098] ,

[0100] , and r t-1 , let t be the URL template of r let t-1 be the URL template of r

[0099] Step 2301182, through the Levenshtein distance algorithm, calculate the minimum edit distance between the URL templates of each adjacent access request in each group of adjacent access requests. The minimum edit distance is the minimum number of character addition, deletion, and modification operations required to modify the URL template of one adjacent access request in each group of adjacent access requests to the URL template of another adjacent access request.

[0100] In this step, for two consecutive access requests r t and r t-1 Calculate its corresponding URL template The minimum edit distance between and is That is, the URL template Modified to The minimum number of character operations required, with each of adding, deleting, and modifying counted as 1 operation.

[0101] Step 2301183: Determine the maximum value among the string length values ​​of the URL templates of adjacent access requests in each group of adjacent access requests as the maximum length value of the URL template of each adjacent access request in each group of adjacent access requests.

[0102] In this step, two adjacent URL templates are retrieved. and The maximum value among the string length values, i.e. =max(| |,| |), where |S| represents the length of the URL template string.

[0103] Step 2301184: The ratio of the minimum edit distance between the URL templates of each adjacent access request in each group of adjacent access requests to the maximum length of the URL templates of each adjacent access request in each group of adjacent access requests is determined as the request structure variation rate.

[0104] In this step, the requested structural variation rate can be calculated using the following formula (5). .

[0105] And, the first access request r No pre-set template, can be set Set to 0 or the default value.

[0106] It should be noted that the execution order of steps 2301182 and 2301183 is not limited here. Steps 2301182 and 2301183 can be executed in sequence, or steps 2301183 and 2301182 can be executed in sequence. Of course, steps 2301182 and 2301183 can also be executed in parallel.

[0107] This allows for precise quantification of the variation in adjacent URL templates, improving the reliability of request structure dimension features and enhancing the ability to identify covert attacks at the structural level.

[0108] Regarding step 240, in some embodiments of this application, considering the strong contextual dependence and variable time span of user session sequences, this embodiment can employ any network structure capable of long sequence modeling, such as Long Short-Term Memory (LSTM), Recurrent Neural Network (RNN), or Transformer. The reason for choosing the LSTM model in this embodiment is as follows: compared to traditional RNNs and Transformers, LSTM introduces a gating mechanism—input gate, forget gate, and output gate—which can effectively solve the gradient vanishing problem in long sequence training. In debugging attack scenarios, there may be multiple unrelated requests between an attacker's probing behavior (such as attempting to modify parameters) and the final exploit behavior (such as successfully exceeding privileges). LSTM can remember long-distance historical states, thereby accurately capturing logical violations across requests.

[0109] Based on this, the sequence classification model in the embodiments of this application may include a long short-term memory network model, and step 240 may specifically include steps 2401 and 2402.

[0110] Step 2401: Input the request feature vector sequence and the time step of the preset sliding time window into the Long Short-Term Memory Network model, and obtain the three-class confidence scores corresponding to the original request sequence output by the Long Short-Term Memory Network model. The three-class confidence scores include the confidence score that the original request sequence is normal traffic, the confidence score that the original request sequence is an automated tool attack, and the confidence score that the original request sequence is a manual debugging attack.

[0111] In this step, the structure of the Long Short-Term Memory (LSTM) network model can be as follows: the input layer, i.e., the receptive dimension, is... The feature matrix of , where The time step of the sliding time window, i.e., the number of access requests, for example, taking... , This represents the feature vector corresponding to a single access request. The LSTM layer can be configured with two stacked LSTM units: the first LSTM layer outputs the hidden state sequence at each time step to capture local temporal features, and the second LSTM layer extracts global semantic information and outputs the hidden state vector at the last time step. A fully connected layer can Mapped to the classification space. The output layer can output a three-class probability distribution: These correspond to the confidence levels of normal traffic, the confidence levels of the original request sequence being an automated tool attack, and the confidence levels of the original request sequence being a manual debugging attack, respectively.

[0112] Step 2402: Based on the three-category confidence scores corresponding to the original request sequence, determine the category with the highest confidence score as the network attack risk type of the original request sequence.

[0113] Therefore, by relying on the LSTM model to adapt to time series features, the attack risk type can be accurately determined through three-class confidence, thereby achieving differentiated identification of different types of attacks.

[0114] It should be noted that a cross-entropy loss function can be used, and a dropout mechanism can be introduced, i.e., the dropout rate is set to 0.2 to prevent overfitting and avoid the model from overfitting the training data. The LSTM model is iteratively trained, and a gradient descent optimizer such as the Adam optimizer is used to iteratively update the model parameters, continuously minimizing the cross-entropy loss until the model converges, i.e., the loss value stabilizes and the accuracy on the validation set reaches the target, ensuring that the LSTM model has good generalization ability to unknown mutation attacks.

[0115] Therefore, machine learning can be used to perform semantic-level analysis on server-side log sequences, enabling the understanding of logical relationships and operational intentions between requests, thereby distinguishing between normal operations and potential debugging attacks. By fusing data from the access time dimension, access request parameter content dimension, and access request structure dimension time sequence data, it is possible to identify covert and low-frequency attack behaviors that traditional rules cannot capture, significantly improving detection accuracy and reducing false positive rates.

[0116] Furthermore, after step 240, in some embodiments of this application, the data processing method may further include: Step 250: Based on the comparison between the confidence level corresponding to the network attack risk type and the preset confidence threshold, execute the corresponding level of security response operation.

[0117] This establishes a link between risk confidence and security response, enabling differentiated protection, avoiding over-handling or overlooking risks, and balancing security and flexibility.

[0118] In this embodiment, the preset confidence threshold includes a first threshold and a second threshold, where the first threshold is less than the second threshold. Based on this, step 250 may specifically include: If the confidence level corresponding to the network attack risk type is less than the first threshold, allow access requests in the user's original request sequence and record the access log corresponding to the original request sequence. If the confidence level corresponding to the network attack risk type is greater than or equal to the first threshold and less than the second threshold, trigger human verification or execute a silent delay operation. If the confidence level corresponding to the network attack risk type is greater than or equal to the second threshold, the access request in the original request sequence is blocked, and the account of the user corresponding to the access request is temporarily frozen.

[0119] In this step, the three-category confidence scores are received, including P = {P_normal (confidence score of normal traffic), P_bot (confidence score of automated tool attacks), and P_debug (confidence score of manual debugging attacks)}. The category with the highest confidence score is used as the core risk assessment basis to initiate the subsequent processing procedure.

[0120] The risk levels are as follows: Low risk (Level 1): when the highest confidence level is less than the first threshold of 0.6, it is considered low risk; Medium risk (Level 2): ​​when 0.6 ≤ the highest risk probability is less than the second threshold of 0.85, it is considered medium risk; High risk (Level 3): when the highest risk probability is greater than or equal to 0.85, it is considered high risk.

[0121] If the risk is low, the access request is allowed directly to ensure normal business continuity; at the same time, detailed logs are recorded in the background, including information such as request parameters, timestamps, feature vectors, and risk probabilities, for subsequent traceability and model optimization.

[0122] If the risk level is medium, human-machine verification will be triggered, such as by sending a slider verification code or SMS verification, or a silent delay will be executed, such as by artificially increasing the response delay to disrupt the attacker's debugging rhythm. If the verification passes, the attacker is allowed to proceed; if the verification fails, the risk level will be upgraded.

[0123] If the risk is high, the internet protocol address that initiated the request will be blocked in real time, prohibiting subsequent access from that IP. Simultaneously, an alert will be automatically generated, which may include the attack type, risk probability, request source, and behavioral characteristics, and pushed to the security operations platform to remind staff to take timely action.

[0124] Therefore, the three-tiered security response actions are refined to adapt to different risk levels. Low-risk actions allow smooth service while high-risk actions block attacks to reduce their harm, thus balancing security protection and user experience.

[0125] Furthermore, when the confidence level corresponding to the network attack risk type is greater than or equal to the second threshold, an alarm message is generated; wherein, the alarm message includes an attack behavior trajectory diagram of the original request sequence, the attack behavior trajectory diagram is used to display the access behavior information of the access request and the risk judgment information corresponding to the access behavior information in the order of timestamps.

[0126] In this step, an attack behavior trajectory diagram can be generated, which fully displays the key behavior nodes according to the time axis. Example format: [T1: Normal access]->[T2: Pause for 10 seconds (consider modifying parameters)]->[T3: Parameter changes from id=1 to id=1']->[T4: Trigger 500 error (request exception)]->[Conclusion: Manually debug the attack].

[0127] This generates alarm information containing attack behavior trajectory diagrams, enabling traceability of attack behavior, providing complete evidence for manual review, and improving the explainability of security operations.

[0128] In other embodiments of this application, after step 250, the data processing method may further include: Receive confirmation of alarm information from operations personnel, including attack flags or false alarm flags. The original request sequence with labels, the network attack risk type corresponding to the original request sequence with labels, and the request feature vector sequence corresponding to the original request sequence with labels are used as training samples for the sequence classification model. The sequence classification model is trained until the preset training conditions are met, and the updated sequence classification model is obtained. The updated sequence classification model is used for subsequent determination of network attack risk type.

[0129] In this step, operators confirm alarm information or mark false alarms. This marked data is automatically fed back to the sample library, triggering incremental learning of the model, enabling the model to adapt to iterative changes in service logic.

[0130] Therefore, the model can be continuously optimized based on human confirmation and feedback, so that the detection capability can be continuously improved as the service evolves, adapt to changes in attack methods, form a protection closed loop of detection, verification and optimization, optimize the detection accuracy of the model, generate behavioral trajectory features, support human-machine collaborative judgment, and enhance interpretability and traceability.

[0131] It should be noted that the data processing method provided in this application embodiment can be applied to the needs of large-scale production and operation in medium and large data centers. While ensuring the high availability and security of the system, it can realize real-time identification and intelligent early warning of potential debugging attacks, thereby improving the overall security defense capability and operation and maintenance efficiency without interrupting services.

[0132] Let's take a typical application scenario as an example to illustrate the difference between the sequence of attack behaviors of normal users and debugging attack behaviors.

[0133] The original request sequence of normal user behavior is fully described in timeline. Specifically, T1 is the initial behavior: the user initiates a request to browse product details: Request method: GET; Request interface: / item / 1001. Behavior description: Normal product browsing, low parameter entropy value, and state transition conforms to business logic. After a 2-second interval, T2 is the user's request to add to cart: Request method: POST; Request interface: / cart / add. Behavior description: The user naturally initiates the action of adding to cart after browsing the product, 2 seconds after T1; low parameter entropy value, and state transition conforms to the normal business logic of "browse → add to cart". After a 3-second interval, T3 is the user's request to submit an order: Request method: POST; Request interface: / order / submit. Behavior description: The user naturally initiates the action of placing an order after adding to cart, 3 seconds after T2; low parameter entropy value, and state transition conforms to the normal business logic of "add to cart → submit order". This original request sequence can be represented as having reasonable time intervals, behaviors that conform to the business process of "browse → add to cart → place order", low parameter entropy value, and no abnormal probing or variant behaviors.

[0134] After logging in normally, the attacker manually modifies the `order_id` parameter in the order interface to attempt to view other users' orders. Since the operation is manual, the request frequency is low, and the payload itself does not include Structured Query Language (SQL) injection features, making it difficult for traditional WAFs to intercept. However, the data processing method provided in this application can capture the original request sequence of continuous access requests generated by the user on the "view order" interface. This sequence can present the debugging attack process of an attacker probing system vulnerabilities through continuous probing and parameter tampering. For example, T1 is the initial probing request behavior, where the attacker directly initiates an order submission request (POST / order / submit) with the parameter `id=1001`. The server returns 200 OK, confirming the interface's availability. The abnormal characteristic is skipping the normal business process of "browsing products → adding to cart" and directly submitting the order, violating normal business logic. Next, there is a 15-second pause, the parameter construction phase. This phase allows the attacker to pause for 15 seconds to analyze the response of the initial request and construct new parameters containing malicious characters. Its abnormal characteristics can be that the time interval (Δt) far exceeds the normal user operation rhythm, indicating an abnormal timing. T2 is an injection attack probe, which can be represented by re-initiating an order submission request (POST / order / submit) with the parameter changed to 'id=1001' (adding single quotes to attempt SQL injection). The response: the server returns a 500 Error (the injection operation caused a server error). Abnormal characteristics can be a sudden change in parameter entropy (introducing special characters), highly repetitive URL templates (completely identical to the T1 interface), and abnormal time intervals (initiated after a 15-second pause). Another 10-second pause can be the analysis and adjustment phase, in which the attacker pauses for 10 seconds to analyze the error response of T2 and adjust subsequent attack parameters. Abnormal characteristics can include another abnormal time interval (Δt). Then, T3 is an privilege escalation attack probe, which can be represented by initiating an order submission request (POST / order / submit) with the parameter changed to 'id=1002' (attempting to access someone else's order to test for privilege escalation vulnerabilities). The response: the server returns a 403 Forbidden (privilege escalation access denied). Abnormal characteristics may include highly repeated URL templates (completely identical to the previous two interfaces), parameter variations (order ID changes from 1001 to 1002), and abnormal time intervals (initiated after a 10-second pause).

[0135] Therefore, the LSTM model can comprehensively determine the time sequence anomaly based on sequence features, namely, the Δt anomaly caused by long pauses, the parameter entropy anomaly, and the business logic anomaly, which violates the normal process of "browsing → adding to cart → placing order", and finally determine the original request sequence as a network attack.

[0136] Based on the same inventive concept, this application also provides a data processing apparatus. (Specifically combined with...) Figure 3 Please provide a detailed explanation.

[0137] Figure 3 This is a schematic diagram of the structure of a data processing apparatus provided in one embodiment of this application.

[0138] In some embodiments of this application, Figure 3 The data processing device shown can be installed in a data processing facility within a data center.

[0139] like Figure 3 As shown, the data processing device 30 may specifically include: Module 301 is used to acquire raw log data from the data center; The generation module 302 is used to generate the user's original request sequence based on the original log data. The original request sequence is a set of consecutive access requests aggregated based on the same user and arranged in timestamp order within a sliding time window. The extraction module 303 is used to extract data from multiple user access behavior dimensions from the access requests in the original request sequence to obtain a request feature vector sequence corresponding to the original request sequence. The determination module 304 is used to determine the network attack risk type of the original request sequence based on the request feature vector sequence using a sequence classification model.

[0140] The data processing apparatus of this application embodiment can construct a standardized original request sequence based on the original logs of the data center, by aggregating requests from the same user, combining sliding time windows for filtering, and sorting by timestamp. This sequence can integrate fragmented client debugging and probing requests into time-series correlated analysis units, eliminate irrelevant request interference, and solve the pain point that traditional detection cannot track continuous debugging behavior. Furthermore, it extracts multi-dimensional access behavior quantitative data based on the original request sequence, constructs a high-dimensional feature vector sequence, and transforms unstructured client debugging behavior into standardized numerical features that the model can directly process. This compensates for the deficiency of traditional detection in capturing the timing features of attacks, improves the feature extraction capability of covert debugging attacks, and accurately determines the attack risk type based on the high-dimensional feature vector sequence through a sequence classification model. It automatically identifies covert client debugging attacks, blocks malicious intrusions from the source, improves the security of data center services, avoids service interruptions and data leaks, and ensures stable service operation.

[0141] The data processing device 30 in the embodiments of this application will be described in detail below.

[0142] In one or more optional embodiments, the extraction module 303 can also be used to extract log streams from the target device according to the service flow of the data center in processing access requests, in the case where the data center includes load balancing devices, web application protection devices and application servers; wherein, the target device is the device in the data center that generates access request logs, and the target device includes at least one of the following: load balancing devices, web application protection devices, and application servers; In this embodiment, the data processing device 30 may further include a processing module for standardizing the log stream extracted from each target device and obtaining the original log data based on the standardized log stream.

[0143] In one or more optional embodiments, the data processing device 30 in this application embodiment may further include an aggregation module, which is used to aggregate log data belonging to the same user in the original log data based on at least one request identifier, using a request identifier as the aggregation condition, to obtain user log data in units of users. The request identifier is information in the log used to associate access requests of the same user, and the request identifier includes at least one of the following: session identifier, authorization token, Internet Protocol address, user agent identifier. In this embodiment of the application, the data processing device 30 may further include a capture module, which is used to capture log window data within the sliding time window from the user log data according to a preset time window. In this embodiment, the data processing device 30 may further include a sorting module, which sorts all access requests in the log window data according to the order of access request timestamps to obtain the user's original request sequence.

[0144] In one or more optional embodiments, the extraction module 303 may be specifically used to extract data of each user access behavior dimension for each access request in the original request sequence, and obtain a feature vector corresponding to each access request. In this embodiment, the data processing device 30 may further include a sorting module, which is used to arrange the feature vectors corresponding to all access requests in the original request sequence according to the timestamp order consistent with the original request sequence, so as to obtain a request feature vector sequence corresponding to the original request sequence.

[0145] In one or more optional embodiments, the extraction module 303 is used to extract data in the access time dimension, data in the access request parameter content dimension, and data in the access request structure dimension for each access request in the original request sequence when multiple user access behavior dimensions include access time dimension, access request parameter content dimension, and access request structure dimension. The generation module 302 is used to generate a feature vector corresponding to each access request based on the data in the access time dimension, the data in the access request parameter content dimension, and the data in the access request structure dimension.

[0146] In one or more optional embodiments, the extraction module 303 is used to extract the timestamp of each access request from the original request sequence to obtain a timestamp sequence, provided that the data in the access time dimension includes the request variation coefficient, and the request variation coefficient is used to characterize the relative dispersion of the access request time interval in the original request sequence. In this embodiment, the data processing device 30 may further include a calculation module, which is used to calculate the time interval between every two adjacent access requests in the original request sequence based on the timestamp sequence, so as to obtain a time interval sequence. Module 304 is used to determine the requested coefficient of variation based on the mean and standard deviation of the time interval series. The mean of the time interval sequence is used to characterize the central tendency of adjacent access request time intervals in the original request sequence, while the standard deviation of the time interval sequence is used to characterize the absolute dispersion of adjacent access request time intervals in the original request sequence.

[0147] In one or more optional embodiments, the extraction module 303 is used to extract at least one key parameter value from the URL and / or request body of each access request in the original request sequence, provided that the data in the access request parameter content dimension includes the parameter entropy change rate, the parameter entropy change rate is used to characterize the randomness of the character distribution of key parameter values ​​in the access request in the original request sequence, and the key parameter value is a Uniform Resource Locator URL in the access request in the original request sequence or a parameter value carrying a service identifier in the request body. Module 304 is used to determine the probability of occurrence of each character in the string for each key parameter value using the Shannon entropy algorithm. The determination module 304 can also be used to determine the parameter entropy change rate of each access request based on the probability of occurrence of each character in the string of each key parameter value.

[0148] In one or more optional embodiments, the data processing device 30 in this application embodiment may further include a conversion module, which is used to perform template conversion on the URL path of each access request in the original request sequence, when the data in the access request structure dimension includes the request structure variation rate, and the request structure variation rate is used to characterize the relative variation of the URL templates of every two adjacent access requests in the original request sequence, to obtain the URL template of each access request. The determination module 304 is used to determine the request structure variation rate of each access request based on the minimum edit distance of the URL templates of every two adjacent access requests in the original request sequence and the maximum length value of the URL templates corresponding to every two adjacent access requests.

[0149] In one or more optional embodiments, the data processing device 30 in this application embodiment may further include a tagging module, used to replace numeric characters in the URL path of each access request with a first preset tag, and to replace the service identifier in the URL path of each access request with a second preset tag, so as to obtain a URL template for each access request.

[0150] In one or more optional embodiments, the acquisition module 301 is used to acquire the URL template of each adjacent access request in each group of adjacent access requests in the original request sequence. In this embodiment of the application, the data processing device 30 may further include a calculation module, which is used to calculate the minimum edit distance between the URL templates of each adjacent access request in each group of adjacent access requests using the Levenstein distance algorithm. The minimum edit distance is the minimum number of character addition, deletion, and modification operations required to modify the URL template of one adjacent access request in each group of adjacent access requests to the URL template of another adjacent access request. The determining module 304 is used to determine the maximum value among the string length values ​​of the URL templates of adjacent access requests in each group of adjacent access requests as the maximum length value of the URL template of each adjacent access request in each group of adjacent access requests. The determination module 304 can also be used to determine the request structure variation rate as the ratio of the minimum edit distance between the URL templates of each adjacent access request in each group of adjacent access requests to the maximum length value of the URL templates of each adjacent access request in each group of adjacent access requests.

[0151] In one or more optional embodiments, the acquisition module 301 is used to input the request feature vector sequence and the time step of a preset sliding time window into the long short-term memory network model when the sequence classification model includes a long short-term memory network model, and to obtain the three-class confidence scores corresponding to the original request sequence output by the long short-term memory network model. The three-class confidence scores include the confidence score that the original request sequence is normal traffic, the confidence score that the original request sequence is an automated tool attack, and the confidence score that the original request sequence is a manual debugging attack. The determination module 304 is used to determine the category with the highest confidence level as the network attack risk type of the original request sequence based on the three-category confidence level corresponding to the original request sequence.

[0152] In one or more optional embodiments, the data processing device 30 in this application embodiment may further include an execution module, which is used to perform a corresponding level of security response operation based on the comparison result between the confidence level corresponding to the network attack risk type and a preset confidence threshold.

[0153] In one or more optional embodiments, the preset confidence threshold includes a first threshold and a second threshold, where the first threshold is less than the second threshold. Based on this, the data processing device 30 in this embodiment may further include an execution module, which is used to allow access requests in the user's original request sequence and record access logs corresponding to the original request sequence when the confidence level corresponding to the network attack risk type is less than the first threshold. If the confidence level corresponding to the network attack risk type is greater than or equal to the first threshold and less than the second threshold, trigger human verification or execute a silent delay operation. If the confidence level corresponding to the network attack risk type is greater than or equal to the second threshold, the access request in the original request sequence is blocked, and the account of the user corresponding to the access request is temporarily frozen.

[0154] In one or more optional embodiments, the generation module 302 can also be used to generate alarm information when the confidence level corresponding to the network attack risk type is greater than or equal to the second threshold. The alarm information includes an attack behavior trajectory diagram of the original request sequence. The attack behavior trajectory diagram is used to display access behavior information of access requests and risk assessment information corresponding to the access behavior information in timestamp order.

[0155] In one or more optional embodiments, the data processing device 30 in this application embodiment may further include a receiving module for receiving confirmation attack flags or false alarm flags of alarm information from operators; In this embodiment, the data processing device 30 may further include a training module, which is used to use the marked original request sequence, the network attack risk type corresponding to the marked original request sequence, and the request feature vector sequence corresponding to the marked original request sequence as training samples for the sequence classification model, and to train the sequence classification model until the preset training conditions are met, so as to obtain an updated sequence classification model. The updated sequence classification model is used for subsequent determination of network attack risk type.

[0156] Based on the same inventive concept, this application also provides a computer device. (Specifically combined with...) Figure 4 Please provide a detailed explanation.

[0157] Figure 4 This is a schematic diagram of the structure of a computer device provided in one embodiment of this application.

[0158] like Figure 4 As shown, the computer device may include the data center equipment involved in the embodiments of this application. The computer device may include a processor 401 and a memory 402 storing computer program instructions.

[0159] Specifically, the processor 401 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0160] Memory 402 may include a large-capacity memory for data or instructions. For example, and not limitingly, memory 402 may include a hard disk drive (HDD), a floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or a Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 402 may include removable or non-removable (or fixed) media. Where appropriate, memory 402 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 402 is non-volatile solid-state memory. In a particular embodiment, memory 402 includes solid-state storage (ROM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically rewritable ROM (EAROM), or flash memory, or a combination of two or more of these.

[0161] The processor 401 implements any of the data processing methods described in the above embodiments by reading and executing computer program instructions stored in the memory 402.

[0162] In one example, the computer device may also include a communication interface 403 and a bus 410. Wherein, as... Figure 4 As shown, the processor 401, memory 402, and communication interface 403 are connected through bus 410 and complete communication with each other.

[0163] The communication interface 403 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0164] Bus 410 includes hardware, software, or both, that couples components of a flow control device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 410 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.

[0165] The computer device can execute the data processing method described in the embodiments of this application, thereby achieving the combination Figures 1 to 4 The data processing methods and apparatus described.

[0166] Furthermore, in conjunction with the data processing methods in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the data processing methods in the above embodiments.

[0167] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0168] The functional blocks shown in the above block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0169] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0170] The above are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A data processing method, characterized in that, include: Obtain raw log data from the data center; Based on the original log data, a user's original request sequence is generated. The original request sequence is a set of consecutive access requests aggregated based on the same user and arranged in timestamp order within a sliding time window. From the access requests in the original request sequence, data of multiple user access behavior dimensions are extracted to obtain a request feature vector sequence corresponding to the original request sequence; The network attack risk type of the original request sequence is determined by using a sequence classification model based on the request feature vector sequence.

2. The method according to claim 1, characterized in that, The data center includes load balancing equipment, web application protection equipment, and application servers; obtaining the raw log data of the data center includes: According to the service flow for processing access requests in the data center, log streams are extracted from the target device; wherein, the target device is the device in the data center that generates access request logs, and the target device includes at least one of the following: the load balancing device, the web application protection device, and the application server; The log streams extracted from each target device are standardized, and the original log data is obtained based on the standardized log streams.

3. The method according to claim 1, characterized in that, The step of generating the user's original request sequence based on the original log data includes: Using request identifiers as aggregation conditions, log data belonging to the same user in the original log data are aggregated based on at least one request identifier to obtain user log data by user. The request identifier is information in the log used to associate access requests of the same user, and the request identifier includes at least one of the following: session identifier, authorization token, Internet Protocol address, user agent identifier. According to a preset time window, extract log window data within the time window from the user log data; The original request sequence of the user is obtained by sorting all access requests in the log window data according to the order of access request timestamps.

4. The method according to claim 1, characterized in that, The step of extracting data from multiple user access behavior dimensions from the access requests in the original request sequence to obtain a request feature vector sequence corresponding to the original request sequence includes: For each access request in the original request sequence, data for each user access behavior dimension is extracted to obtain a feature vector corresponding to each access request; Arrange the feature vectors corresponding to all access requests in the original request sequence according to the timestamp order consistent with the original request sequence to obtain the request feature vector sequence corresponding to the original request sequence.

5. The method according to claim 4, characterized in that, The multiple user access behavior dimensions include an access time dimension, an access request parameter content dimension, and an access request structure dimension; for each access request in the original request sequence, data for each of the user access behavior dimensions is extracted to obtain a feature vector corresponding to each access request, including: For each access request in the original request sequence, extract the data in the access time dimension, the data in the access request parameter content dimension, and the data in the access request structure dimension. Based on the data of the access time dimension, the data of the access request parameter content dimension, and the data of the access request structure dimension corresponding to each access request, a feature vector corresponding to each access request is generated.

6. The method according to claim 5, characterized in that, The data in the access time dimension includes the request variation coefficient, which is used to characterize the relative dispersion of the access request time interval in the original request sequence; The step of extracting data from the access time dimension, the access request parameter content dimension, and the access request structure dimension for each access request in the original request sequence includes: For each access request in the original request sequence, the timestamp of each access request is extracted from the original request sequence to obtain a timestamp sequence; Based on the timestamp sequence, the time interval between every two adjacent access requests in the original request sequence is calculated to obtain the time interval sequence; The coefficient of variation of the request is determined based on the mean and standard deviation of the time interval sequence. The mean of the time interval sequence is used to characterize the central tendency of adjacent access request time intervals in the original request sequence, and the standard deviation of the time interval sequence is used to characterize the absolute dispersion of adjacent access request time intervals in the original request sequence.

7. The method according to claim 5, characterized in that, The data in the access request parameter content dimension includes parameter entropy change rate, which is used to characterize the randomness of the character distribution of key parameter values ​​in the access request in the original request sequence. The key parameter values ​​are the Uniform Resource Locator URLs in the access request in the original request sequence or the parameter values ​​of the service identifiers carried in the request body. The step of extracting data from the access time dimension, the access request parameter content dimension, and the access request structure dimension for each access request in the original request sequence includes: For each access request in the original request sequence, extract at least one key parameter value from the URL and / or the request body of each access request; For each of the key parameter values, the probability of occurrence of each character in the string for each key parameter value is determined using the Shannon entropy algorithm; The parameter entropy change rate of each access request is determined based on the probability of occurrence of each character in the string of each of the key parameter values.

8. The method according to claim 5, characterized in that, The data in the access request structure dimension includes the request structure variation rate, which is used to characterize the relative variation of the URL templates of every two adjacent access requests in the original request sequence. The step of extracting data from the access time dimension, the access request parameter content dimension, and the access request structure dimension for each access request in the original request sequence includes: For each access request in the original request sequence, the URL path of each access request is templated to obtain the URL template of each access request; The request structure variation rate of each access request is determined based on the minimum edit distance of the URL templates of every two adjacent access requests in the original request sequence and the maximum length of the URL templates corresponding to every two adjacent access requests.

9. The method according to claim 8, characterized in that, For each access request in the original request sequence, the URL path of each access request is templated to obtain a URL template for each access request, including: The numeric characters in the URL path of each access request are replaced with a first preset marker, and the service identifier in the URL path of each access request is replaced with a second preset marker to obtain the URL template of each access request.

10. The method according to claim 8, characterized in that, The step of determining the request structure variation rate of each access request based on the minimum edit distance of the URL templates of every two adjacent access requests in the original request sequence and the maximum length of the URL templates corresponding to every two adjacent access requests includes: For each group of adjacent access requests in the original request sequence, obtain the URL template of each adjacent access request in each group of adjacent access requests; The minimum edit distance between the URL templates of each adjacent access request in each group of adjacent access requests is calculated using the Levenstein distance algorithm. The minimum edit distance is the minimum number of character addition, deletion, and modification operations required to change the URL template of one adjacent access request to the URL template of another adjacent access request in each group of adjacent access requests. The maximum value among the string length values ​​of the URL templates of adjacent access requests in each group of adjacent access requests is determined as the maximum length value of the URL template of each adjacent access request in each group of adjacent access requests. The ratio of the minimum edit distance between the URL templates of each adjacent access request in each group of adjacent access requests to the maximum length of the URL templates of each adjacent access request in each group of adjacent access requests is determined as the request structure variation rate.

11. The method according to claim 1, characterized in that, The sequence classification model includes a long short-term memory network model; the step of determining the network attack risk type of the original request sequence based on the request feature vector sequence using the sequence classification model includes: The request feature vector sequence and the time step of the preset sliding time window are input into the Long Short-Term Memory Network model to obtain the three-class confidence scores corresponding to the original request sequence output by the Long Short-Term Memory Network model. The three-class confidence scores include the confidence score that the original request sequence is normal traffic, the confidence score that the original request sequence is an automated tool attack, and the confidence score that the original request sequence is a manual debugging attack. Based on the three-category confidence scores corresponding to the original request sequence, the category with the highest confidence score is determined as the network attack risk type of the original request sequence.

12. The method according to claim 11, characterized in that, The method further includes: Based on the comparison between the confidence level corresponding to the network attack risk type and the preset confidence threshold, the corresponding level of security response operation is executed.

13. The method according to claim 12, characterized in that, The preset confidence threshold includes a first threshold and a second threshold, wherein the first threshold is less than the second threshold; The step of performing a corresponding level of security response operation based on the comparison result between the confidence level corresponding to the network attack risk type and the preset confidence threshold includes: If the confidence level corresponding to the network attack risk type is less than the first threshold, allow access requests in the user's original request sequence and record the access log corresponding to the original request sequence. If the confidence level corresponding to the network attack risk type is greater than or equal to the first threshold and less than the second threshold, human-machine verification or silent delay operation is triggered. If the confidence level corresponding to the network attack risk type is greater than or equal to the second threshold, the access request in the original request sequence is blocked, and the account of the user corresponding to the access request is temporarily frozen.

14. The method according to claim 13, characterized in that, The method further includes: If the confidence level corresponding to the network attack risk type is greater than or equal to the second threshold, an alarm message is generated. The alarm information includes an attack behavior trajectory diagram of the original request sequence. The attack behavior trajectory diagram is used to display access behavior information of the access request and risk judgment information corresponding to the access behavior information in timestamp order.

15. The method according to claim 14, characterized in that, The method further includes: Receive confirmation of attack flags or false alarm flags from operators regarding the alarm information; The original request sequence with labels, the network attack risk type corresponding to the original request sequence with labels, and the request feature vector sequence corresponding to the original request sequence with labels are used as training samples for the sequence classification model. The sequence classification model is trained until the preset training conditions are met to obtain an updated sequence classification model. The updated sequence classification model is used for subsequent determination of network attack risk types.

16. A data processing apparatus, characterized in that, include: The acquisition module is used to acquire raw log data from the data center. The generation module is used to generate the user's original request sequence based on the original log data. The original request sequence is a set of consecutive access requests aggregated from the same user and arranged in timestamp order within a sliding time window. The extraction module is used to extract data from multiple user access behavior dimensions from the access requests in the original request sequence to obtain a request feature vector sequence corresponding to the original request sequence. The determination module is used to determine the network attack risk type of the original request sequence based on the request feature vector sequence using a sequence classification model.

17. A computer device, characterized in that, The computer device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements the data processing method as described in any one of claims 1-15.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the data processing method as described in any one of claims 1-15.

19. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the data processing method as described in any one of claims 1-15.

Images