Request processing methods, devices, electronic devices and storage media

Abstract

This application discloses a request processing method, apparatus, electronic device, and storage medium, relating to the field of server technology. The method includes: identifying most known, well-defined risky requests through configuration rules in a configuration rule base; identifying the degree of anomalousness of a target request compared to a normal request through an unsupervised model; and identifying the similarity between a first operation sequence and an anomalous operation sequence through a reference directed graph. Therefore, for unknown, novel risky requests, this solution can detect them promptly through reference directed graphs and unsupervised models, and respond accordingly. Furthermore, this solution jointly determines whether a target request is risky from both the request and operation sequence dimensions, detecting situations where the request is normal but the operation sequence is anomalous, thus making the final judgment more accurate.

Description

Technical Field

[0001] This application relates to the field of server technology, and in particular to request processing methods, apparatus, electronic devices and storage media. Background Technology

[0002] In the field of server technology, the Baseboard Management Controller (BMC) can receive external requests through a management interface. However, some requests are risky, meaning that executing these requests may harm the server.

[0003] Currently, network isolation, authentication and authorization, rule matching, transmission encryption, and physical isolation are commonly used to handle requests. However, new types of risky requests cannot be identified and responded to in a timely manner. Summary of the Invention

[0004] This application provides request processing methods, apparatus, electronic devices, storage media, and program products to address the problem that related technologies cannot promptly identify and respond to new types of risky requests.

[0005] This application provides a request processing method, including: Obtain the total operation information and reference directed graph corresponding to the target request. The total operation information includes at least the first operation sequence corresponding to the target task and the sub-operation information of the target request. The reference directed graph includes multiple abnormal operation sequences. Based on the sub-operation information of the target request, determine whether there is a target configuration rule in the pre-built configuration rule base that matches the sub-operation information of the target request; If a target configuration rule is determined to exist, the risk indicator value corresponding to the target configuration rule will be determined as the first risk indicator value. Based on the overall operational information and the pre-built unsupervised model, the value of the second risk indicator is obtained; The third risk indicator value is determined based on the first operation sequence and multiple abnormal operation sequences in the reference directed graph; The target request is processed based on the first risk indicator value, the second risk indicator value, and the third risk indicator value.

[0006] This application also provides a request processing apparatus, including: The acquisition module is used to acquire the total operation information and the reference directed graph corresponding to the target request. The total operation information includes at least the first operation sequence corresponding to the target task and the sub-operation information of the target request. The reference directed graph includes multiple abnormal operation sequences. The determination module is used to determine whether there is a target configuration rule in the pre-built configuration rule base that matches the sub-operation information of the target request, based on the sub-operation information of the target request; if the target configuration rule is determined to exist, the risk indicator value corresponding to the target configuration rule is determined as the first risk indicator value; the second risk indicator value is obtained based on the total operation information and the pre-built unsupervised model; and the third risk indicator value is determined based on the first operation sequence and multiple abnormal operation sequences in the reference directed graph. The processing module is used to process the target request based on the first risk indicator value, the second risk indicator value, and the third risk indicator value.

[0007] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described request processing methods when executing the computer program.

[0008] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described request processing methods.

[0009] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described request processing methods.

[0010] This application utilizes configuration rules from a rule base to identify most known and clearly defined risky requests. An unsupervised model can assess the degree of anomaly of a target request compared to a normal request. A directed graph reference can identify the similarity between the first operation sequence and an anomalous operation sequence. Therefore, for unknown and novel risky requests, this solution can detect them promptly using both directed graphs and unsupervised models, and respond accordingly. Furthermore, this solution jointly determines the risk of a target request from both the request and operation sequence dimensions, detecting situations where the request is normal but the operation sequence is anomalous, thus making the final judgment more accurate. Attached Figure Description

[0011] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A flowchart illustrating a request processing method provided in an embodiment of this application; Figure 2 A directed graph provided for an embodiment of this application; Figure 3 A flowchart illustrating the calculation of a third risk indicator value is provided for an embodiment of this application. Figure 4 This application provides a schematic diagram of a risk handling process as an embodiment of the present application. Figure 5 A schematic diagram of a feedback learning process provided for an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a request processing device provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0013] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0014] It should be noted that, in the description of this application, 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. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0015] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0016] In servers, the Baseboard Management Controller (BMC) can be configured with a management application programming interface (API). This API allows for operations such as power management, firmware updates, and sensor monitoring. For example, this management interface could be the Redfish API. While BMCs are typically deployed in out-of-band management networks and physically isolated from business systems, the widespread adoption of enterprise hybrid cloud architectures exposes their management interfaces to the enterprise's internal network and even the public internet boundary via API gateways (the entry point for API requests). For instance, in edge computing and remote maintenance scenarios, this exposure amplifies the security risks of the BMC. If an attacker breaches API protection, they could directly manipulate the server's hardware layer, severely compromising server security.

[0017] To avoid the aforementioned problems, current methods generally employ network isolation, authentication and authorization, rule matching, transmission encryption, and physical isolation to handle requests. For example, network isolation can specifically involve setting up an Internet Protocol (IP) whitelist, creating independent virtual local area networks (VLANs), and using firewall port filtering to restrict access sources. Authentication can verify identity based on static API tokens, X.509 certificates, or the OAuth 2.0 protocol. Authorization can combine a Role-Based Access Control (RBAC) model to assign operation permissions according to roles, or it can allow only administrators to perform firmware updates. Rule detection relies on matching predefined attack signatures. Transmission encryption enforces the use of HyperText Transfer Protocol Secure (HTTPS) and configures Transport Layer Security (TLS) 1.2 with two-way certificate verification. Physical protection involves separating traffic through out-of-band management and enabling hardware write protection switches to restrict firmware write operations.

[0018] However, most of the above solutions rely on pre-defined rules. For risky requests that are not specified in the rules, they are mostly not identified in time. They are simply recorded or directly handed over to the administrator for processing. This results in a failure to respond to risky requests in a timely manner.

[0019] Embodiments of this application provide a request processing method that can be executed by the aforementioned BMC, such as... Figure 1 As shown, the specific processing steps of the request processing method may include: Step S101: Obtain the total operation information and reference directed graph corresponding to the target request.

[0020] The total operation information includes at least the first operation sequence corresponding to the target task and the sub-operation information of the target request. For example, the target task could be a firmware update task. The directed graph includes multiple abnormal operation sequences. The total operation information may also include the operation frequency of the target request per unit time. The operation sequence (abnormal operation sequence and first operation sequence) can include multiple operations, each corresponding to an API request, and the target request is any one of the multiple API requests corresponding to the target task.

[0021] Specifically, BMC can receive target tasks sent by external devices. For the target task, BMC's data acquisition layer can capture API request streams and context data in real time during the execution of the target task.

[0022] For each API request and response, BMC can mirror (i.e., copy) all content within all API requests and responses. For example, an API request may include the HTTP method name, Uniform Resource Locator (URL), parameters, payload, and request headers; a response may include the response status code and returned data. The URL is generally also referred to as a website address or link. The HTTP method name and URL indicate the operation target and type, while parameters and payload contain the specific instructions and data for the operation. Request headers contain identity information, such as authentication tokens and user agents.

[0023] The BMC can also collect physical environment data associated with API requests, i.e., the aforementioned context data. For example, physical environment data can include hardware status, session information, network topology, etc. Hardware status can include CPU load, memory usage, and temperature sensor readings; session information can include user roles, authentication methods, and login times; and network topology can include source IP addresses, BMC ports, and Virtual Local Area Network (VLAN) tags.

[0024] BMC can also attach high-precision timestamps to each API request and response to establish a global event sequence. For example, [t1]GET / Systems to [t2]POST / Reset means that at timestamp t1, an API request was received that included the HTTP method "GET" and the API endpoint " / Systems", and at timestamp t2, a request was received that included the HTTP method "POST" and the API endpoint " / Reset".

[0025] BMC can also filter invalid traffic without performing subsequent risk assessment operations to save resources. For example, invalid traffic may include health check requests, requests to compress redundant data, requests to remove duplicate headers, and requests to reduce downstream processing load.

[0026] For any given API request, after collecting the relevant data, BMC can convert the data into a unified format. This converted data can be the API request's operation information. For example, it could be converted to JavaScript Object Notation (JSON) format. The data converted to JSON format might look like this: {"timestamp":1678901235000, "src_ip":"100.13.1.99", "method":"POST", "endpoint":" / UpdateService", "params":{ "Targets":[" / FirmwareInventory / BMC"], "filename":"firmware.bin" }, "hardware_state":{ "cpu_load":12, "temperature":45, "power_state":"On" }, "session":{ "user":"attacker", "role":"Operator" } } In this context, "timestamp" represents the timestamp, "src_ip" represents the source IP address, "method" represents the method name, "endpoint" represents the API endpoint, "params" represents the parameters, where "Targets" represents the target path, "filename" represents the filename, "hardware_state" represents the hardware state, where "cpu_load" represents the CPU load, "temperature" represents the temperature sensor value, "power_state" represents the server's power state, "session" represents session information, where "user" represents the user and identifies who is performing the operation, and "role" represents a predefined set of permissions that defines what can be done and represents the scope of responsibility. Examples include Administrator, Operator, and Read Only.

[0027] Furthermore, for any given API request, BMC can also calculate the frequency of API request operations within a unit of time.

[0028] In addition, for the target task, BMC can also generate an operation sequence according to the timestamp order and the execution order of each API request.

[0029] For the target request, after processing in the above manner, we can obtain the first operation sequence, the sub-operation information of the target request, the operation frequency, etc.

[0030] Step S102: Based on the sub-operation information of the target request, determine whether there is a target configuration rule in the pre-built configuration rule library that matches the sub-operation information of the target request.

[0031] The configuration rule base can include multiple configuration rules, and each configuration rule can have one or more conditions set.

[0032] Specifically, to improve the accuracy and comprehensiveness of risk assessment, the BMC's behavioral analysis layer can perform risk determination operations in three dimensions. Correspondingly, for each dimension of risk determination operation, baseline behavioral information can be pre-established and used as a reference to determine whether the current target request carries risk. For example, for the risk determination operations in steps S102 and S103, the configuration rules in the configuration rule base serve as the baseline behavioral information for that type of risk determination operation. For the risk determination operation in step S104, the rules in the unsupervised model serve as the baseline behavioral information. For the risk determination operation in step S105, the reference directed graph serves as the baseline behavioral information.

[0033] For example, baseline behavior information in a task that updates the Basic Input Output System (BIOS) firmware can be shown in Table 1.

[0034] Table 1

[0035] In the first risk assessment operation, for a target request, BMC can determine whether the sub-operation information corresponding to the target request matches any configuration rule in the configuration rule base. If so, the risk indicator value corresponding to the matching configuration rule can be determined as the first risk indicator value corresponding to the target request.

[0036] Step S103: If it is determined that a target configuration rule exists, the risk indicator value corresponding to the target configuration rule is determined as the first risk indicator value.

[0037] Specifically, each configuration rule can include a risk indicator value corresponding to itself, or the BMC can pre-build a mapping table between the identification information of configuration rules and risk indicator values. Therefore, after determining the target configuration rule, for the former, the BMC can directly determine the risk indicator value included in the target configuration rule as the first risk indicator value corresponding to the API request; for the latter, the BMC can determine the risk indicator value corresponding to the identification information of the target configuration rule in the mapping table based on the identification information of the target configuration rule, and determine the risk indicator value corresponding to the target configuration rule as the first risk indicator value.

[0038] Step S104: Based on the total operational information and the pre-built unsupervised model, obtain the second risk index value.

[0039] Specifically, BMC can input the total operational information into a pre-built unsupervised model, and the unsupervised model will evaluate the total operational information to obtain the second risk index value.

[0040] Step S105: Determine the third risk indicator value based on the first operation sequence and multiple abnormal operation sequences in the reference directed graph.

[0041] Specifically, BMC can compare the first operation sequence with each abnormal operation sequence in the reference directed graph to determine the degree of similarity between the first operation sequence and the abnormal operation sequence, that is, to determine the third risk indicator value.

[0042] Step S106: Process the target request based on the first risk indicator value, the second risk indicator value, and the third risk indicator value.

[0043] Specifically, after the three risk assessment operations described above, three risk indicator values ​​can be determined. The BMC's real-time blocking layer can then determine whether a target request is a risky request based on these three risk indicator values. For example, it can determine whether all three risk indicator values ​​are within their respective risk ranges, or it can calculate a total risk indicator value by weighted summation of the three risk indicator values ​​and determine whether the total risk indicator value is within a preset risk range. If so, the exception handling operation corresponding to the target request is executed; otherwise, the target request can be allowed to proceed according to the normal processing method. For example, risky requests could be requests related to tasks such as forced server restarts, unreasonable firmware flashing operations, sensitive configuration tampering, and data theft.

[0044] The request processing method in this application can identify most known and clearly characterized risky requests by configuring rules in a rule base. It can also identify the degree of anomalousness of a target request compared to a normal request using an unsupervised model, and the similarity between a first operation sequence and an anomalous operation sequence by referencing a directed graph. Therefore, for unknown and novel risky requests, this solution can detect them promptly using a directed graph and an unsupervised model, and respond accordingly. Furthermore, it enables the BMC to reject abnormal external calls in real time, improving the security of the management interface and the server. In addition, this solution jointly determines whether a target request is risky from both the request and operation sequence dimensions, detecting situations where the request is normal but the operation sequence is abnormal, thus making the final judgment more accurate.

[0045] In some optional implementations, the sub-operation information of the target request may include at least one configuration item, which can be any of the items in the JSON example above. The configuration rule base includes at least one configuration rule, and each configuration rule includes at least one condition, each condition being used to indicate the value condition of a configuration item. Accordingly, step S102 above may include the following specific steps: Step 1: Based on at least one configuration item of the sub-operation information of the target request, determine whether the sub-operation information of the target request satisfies all the conditions in the first configuration rule.

[0046] Step 2: If the sub-operation information of the target request satisfies all the conditions in the first configuration rule, then the first configuration rule is determined as the target configuration rule.

[0047] The first configuration rule can be any of a variety of configuration rules.

[0048] Specifically, the BMC can iterate through the configuration rules in the configuration rule base. For each configuration rule encountered, it determines whether the configuration items in the sub-operation information of the target request meet all the conditions of that rule. If so, the rule is designated as the target configuration rule. If not, it continues to iterate through the next rule, checking if the configuration items in the sub-operation information of the target request meet all the conditions of that rule. If so, the rule is designated as the target configuration rule; otherwise, it continues through the next rule, and so on, until a target configuration rule is determined, or the iteration stops after all configuration rules have been iterated through. In the latter case, if no target configuration rule is determined after iteration, the target request can be considered a new type of request, which may be a normal request or a risky request.

[0049] For example, the first configuration rule can be as follows: "IF($method=="POST"AND $endpointCONTAINS" / UpdateService"AND $payload.filenameMATCHES".*\\.(bin|img)$"AND $session.role!="Administrator") THEN$risk_score+=85” The first configuration rule includes four conditions: $method=="POST", $endpointCONTAINS" / UpdateService", $payload.filename MATCHES".*\\.(bin|img)$", and $session.role!="Administrator". $method=="POST" indicates that the method name is "POST", which is usually used to indicate a create or submit operation. $endpoint CONTAINS" / UpdateService" indicates that the API endpoint is " / UpdateService", which is used to indicate a firmware or software update operation. $session.role!="Administrator" indicates that the role is not an administrator. In other words, this configuration rule specifies that it is a risky behavior for a user with a non-administrator role to perform a firmware update operation.

[0050] During the above traversal process, BMC can determine whether the method name configuration item included in the sub-operation information of the target request is POST. If so, it can further determine whether the API endpoint of the request contains the path " / UpdateService". If so, it can further determine whether the filename in the payload of the target request's sub-operation information matches a regular expression ending with ".bin" and "img". ".bin" and "img" are common extensions for firmware files. This condition is used to confirm that the user uploaded a firmware file, rather than a regular configuration file or log file. If so, it can further determine whether the current session user's role is equal to an administrator. If not, it can determine that the first configuration rule is the target configuration rule and set "85" as the first risk indicator value.

[0051] In this way, by comparing the values ​​of configuration items in the configuration rules with the values ​​of configuration items in the sub-operation information of the target request, it can be accurately determined whether the configuration items comply with the provisions of the configuration rules, thereby accurately determining the first risk indicator value of the target request.

[0052] In some optional implementations, the unsupervised model includes multiple normal sample data, the number of which is the target number; accordingly, step S104 above may include the following specific steps: Step 1: Based on the total operational information and multiple normal sample data, determine the degree of abnormality of the total operational information compared to the multiple normal sample data; Step two: Determine the value of the second risk indicator based on the target quantity and the degree of abnormality.

[0053] Among them, the unsupervised model can be the isolation forest model.

[0054] Specifically, during the training phase, a massive dataset of historically accumulated normal behavior samples can be used as the training dataset to train an Isolation Forest model. The Isolation Forest model can include normal sample data based on normal patterns, with content similar to the overall operational information. The Isolation Forest model first calculates the path length of the overall operational information on each normal sample, then averages all calculated path lengths based on the number of normal samples to obtain the average path length, thus determining the degree of anomaly. Furthermore, a path length standardization factor can be calculated based on the target quantity. Finally, a second risk indicator value is calculated based on the average path length and the path length standardization factor.

[0055] For example, the above process can be expressed as follows: (1) Where Y represents the value of the second risk indicator. This represents the path length of the total operational information x in the random tree (i.e., the normal sample data). This represents the average path length of the total operation information. This represents the path length standardization factor, where n represents the number of normal sample data. L1 is a constant related to n, and it is an adjustment coefficient used to ensure that the magnitude of the second risk indicator value is consistent with that of the first risk indicator value. For example, L1 can be 100.

[0056] In this way, by comparing the total operational information of the target request as a comprehensive feature with the features of normal behavior, the degree of abnormality of the target request can be determined. This solution can also accurately identify unknown risky requests.

[0057] In some optional implementations, in addition to confirming whether the target request is abnormal at the request dimension and the comprehensive information dimension, the target request can also be analyzed at the operation sequence dimension. Accordingly, in step S105 above, BMC can use the following specific steps to calculate the third risk indicator value: Step 1: Determine the probability of the starting operation based on the starting operation and multiple abnormal operation sequences in the first operation sequence.

[0058] Step 2: Based on each pair of adjacent operations in the first operation sequence and multiple abnormal operation sequences, determine the transition probability between each pair of adjacent operations.

[0059] Step 3: Determine the first probability value based on the probability of the initial operation and the transition probability between every two adjacent operations.

[0060] Step 4: Determine the length of the first operation sequence.

[0061] Step 5: Determine the first logarithmic probability value corresponding to the first probability value based on the first probability value and the length of the first operation sequence.

[0062] Step six: Normalize and adjust the coefficients of the first logarithmic probability value to obtain the third risk index value.

[0063] The directed graph consists of nodes and edges. Nodes represent operations, and the edges between two nodes represent transition probabilities. A transition probability is the probability that, after executing the operation corresponding to node 1, the operation corresponding to node 2 will be executed. Node 1 is the node connected to node 2 and located before node 2. (See reference) Figure 2For the objective task of updating the Basic Input Output System (BIOS) firmware, a sequence of operations in a directed graph may include multiple nodes such as login, querying system information, reading BIOS settings, modifying BIOS, and forced restart. The weights of the edges between these nodes are 0.9, 0.7, 0.3, and 0.1, respectively. The edge weights around a given node satisfy... , where i represents the identifier of the node, and j represents the identifier of the node that has an edge connection with this node. The whole can be represented as a node whose weights are less than or equal to 1.

[0064] Specifically, for a first operation sequence, the target starting node corresponding to the starting operation in the first operation sequence can be determined in the reference directed graph. Furthermore, the BMC can determine the reference starting node corresponding to each of the aberrant operation sequences in the reference directed graph. Then, the BMC can calculate a first number of all aberrant operation sequences in the reference directed graph, and a second number of aberrant operation sequences whose reference starting node is the target starting node. The ratio between the second number and the first number is determined as the probability of the starting operation. For example, if 1000 operation sequences are analyzed, and 600 operation sequences begin with operation A, then the probability of operation A is 0.6.

[0065] Furthermore, for all operations in the first operation sequence other than the initial operation, the corresponding transition probabilities need to be determined. Taking the first operation (any operation among the other operations) as an example, the BMC can determine the first node corresponding to the first operation in the reference directed graph. Then, the edge weight between the first node and the second node is determined as the transition probability between the first and second operations, where the second node is the node corresponding to the second operation in the reference directed graph, and the second operation is the operation preceding the first operation in the first operation sequence. The BMC can multiply the initial probability and each transition probability to obtain the first probability value. If there is no first node, no second node, or no edge between the first and second nodes in the reference directed graph, it means the probability of executing the first operation after the second operation is 0. In this case, 0 can be directly determined as the first probability value. In this way, the transition probability between every two adjacent operations can be calculated.

[0066] In addition, to eliminate the influence of sequence length, BMC can first determine the length of the first operation sequence, and calculate the average log-likelihood corresponding to the first probability value based on the length of the first operation sequence, that is, calculate the first log probability value.

[0067] Finally, in order to make the third risk indicator value the same in magnitude as the first and second risk indicator values, the first logarithmic probability value can be normalized and its coefficients adjusted to obtain the third risk indicator value.

[0068] For example, the first operation sequence can be represented as S=[s1,s2,…,sk], and the probability of the first operation sequence appearing on the reference directed graph can be represented as: (2) in, The first probability value, The initial probability, Indicates the first operation Second operation The transition probability between them.

[0069] The first logarithmic probability value of BMC can be calculated using the following expression: (3) in, Here, k represents the first logarithmic probability value, and k represents the length of the first operation sequence. It is a smoothing factor used to prevent... It can be zero, or a small value that is set in advance, such as 1e-5.

[0070] In this way, by comparing the first operation sequence with the abnormal operation sequence, the degree of similarity between the two sequences can be determined. A higher similarity, i.e., a higher third risk index value, indicates a higher risk for the first operation sequence. The target request is a request corresponding to an operation within the first operation sequence. If executing the target request is highly likely to expose the BMC to risk, it also needs to be intercepted. Therefore, the third risk index value allows for a macro-level assessment of the danger of executing the target request, thereby minimizing the occurrence of dangerous problems. For example, if the target request itself has low risk, but its corresponding operation sequence has extremely high risk, existing rules might allow the target request to proceed, leading to a high risk for the BMC. This solution can prevent such risks and is therefore safer.

[0071] In some alternative implementations, in step six above, BMC may calculate the third risk indicator value using the following specific steps: Step 1: Among multiple abnormal operation sequences, determine the second operation sequence with the highest probability of occurrence, and obtain the second probability value of the second operation sequence.

[0072] Step 2: Determine the length of the second operation sequence.

[0073] Step 3: Determine the second logarithmic probability value corresponding to the second probability value based on the second probability value and the length of the second operation sequence.

[0074] Step 4: Normalize the first logarithmic probability value based on the second logarithmic probability value and the preset third logarithmic probability value to obtain the initial risk index value.

[0075] Step 5: Adjust the initial risk indicator value using a preset adjustment coefficient to obtain the third risk indicator value.

[0076] Specifically, similar to the first probability value, BMC can use the above formula (2) to determine the probability value corresponding to each operation sequence in the reference directed graph, and then determine the second operation sequence with the largest probability value, and extract the second probability value of the second operation sequence. Similarly, BMC can determine the length of the second operation sequence, that is, determine the number of operations included in it. Then, after converting the second probability value using the above formula (3), the second logarithmic probability value is obtained.

[0077] Furthermore, in step 4, BMC can normalize the first logarithmic probability value based on the second logarithmic probability value and the preset third logarithmic probability value to obtain the initial risk index value, and determine the third risk index value by multiplying the preset adjustment coefficient with the initial risk index value.

[0078] For example, the third risk indicator value can be expressed as follows: (4) in, This is the third risk indicator value, and L2 is an adjustment factor. For example, L2 can be equal to 100. This is the first logarithmic probability value. This is the second logarithmic probability value. The third logarithmic probability value can be expressed as log( ) / k.

[0079] In this way, the sequence length ensures fairness in the comparison operation, making the final determined third risk index value more accurate. Furthermore, by using the best and worst random operation sequences as upper and lower bounds for linear normalization, the value is mapped to a fixed range. This allows the third risk index value to indicate the correlation between the first operation sequence and the operation sequences of the anomalous pattern. For example, a third risk index value of 100 indicates that the first operation sequence perfectly matches the most typical anomalous operation sequence, while a third risk index value of 0 indicates that the first operation sequence has no correlation with the most typical anomalous operation sequence, and is relatively safe.

[0080] In some alternative implementations, in step S106 above, the BMC may process the target request using the following specific steps: Step 1: Determine the target risk indicator value based on the first risk indicator value, the second risk indicator value, and the third risk indicator value.

[0081] Step 2: Based on the target risk indicator value, determine the target risk range within which the target risk indicator value falls within a set of preset risk ranges.

[0082] Step 3: Use risk management methods that correspond to the target risk range to handle the target task.

[0083] Specifically, such as Figure 3 As shown, BMC can calculate risk indicator values ​​for a target request from three dimensions, then perform a weighted sum of the three values ​​to obtain the target risk indicator value. This target risk indicator value is then compared with multiple preset risk ranges to determine the target risk range into which the target risk indicator value falls. For each risk range, a corresponding risk handling method can be set. Therefore, this solution can use the risk handling method corresponding to the target risk range to process the target task. For example, triggering blocking or updating the configuration rule base.

[0084] In this way, by setting risk ranges, risks can be categorized into levels, and corresponding risk handling methods can be adopted for different risk levels. This can prevent the problem of low business efficiency caused by excessive blocking, while also ensuring server security.

[0085] In some optional implementations, requests with high risk index values ​​can be considered abnormal or high-risk requests, requiring timely interception and blocking to shorten the attack window. Requests with low risk index values ​​can be allowed, but for security reasons, relevant information can still be recorded for subsequent analysis. Accordingly, in step three above, BMC can process API requests using the following specific steps: Step 1: If the target risk range is within the first risk range, discard the target task and block the source address included in the target task.

[0086] Alternatively, in step 2, if the target risk range is the second risk range, the target task is redirected to the target device so that the target device can process the target task.

[0087] Alternatively, in step 3, if the target risk range is the third risk range, allow the target task to proceed and perform one or more of the following operations: alarm, log recording, and monitoring.

[0088] Alternatively, in step 4, if the target risk range is the fourth risk range, the target task is allowed to proceed and a log entry is made.

[0089] Specifically, the BMC can store a mapping table between risk ranges and actions to be performed, as shown in Table 2.

[0090] Table 2

[0091] After determining the target risk range to which the target risk indicator value belongs, BMC can determine the risk handling method corresponding to the target risk range in the mapping relationship table, and use the risk handling method corresponding to the target risk range to process the target request.

[0092] like Figure 4 As shown, when the target risk range is determined to be the first risk range (e.g., a risk index value ≥ 80), it indicates an extremely high risk. In this case, the blocking module can be triggered to drop the target request, forcibly close the connection with the source IP, and permanently block the source IP in the target request, preventing any further requests from that source IP from being processed. Additionally, in this situation, the total operation information of the target request can be synchronized to the firewall and the IP address table to achieve network layer blocking. For example, this scenario could be a zero-day vulnerability exploit, which refers to a risky behavior initiated by exploiting a security vulnerability that has not yet been discovered by developers or is known but has not yet been patched.

[0093] When the target risk range is determined to be the second risk range (e.g., a risk index value of 40-79), the redirection module can be triggered to use reverse proxy hijacking technology to redirect the target request to an isolated environment for behavioral analysis. Specifically, this can be a target device operating in a different environment than the BMC, allowing the target device to analyze the target request in an isolated environment, thus reducing the risk to BMC services. For example, this could be a low-frequency port scan request. If the target device's analysis result (which could be an analysis result given after assessment by technical personnel) is normal, the request can be allowed; if the analysis result is abnormal, it can be blocked.

[0094] When the target risk range is determined to be the third risk range (e.g., a risk index value of 10-39), it indicates that the risk of the target request is low, and the target task can be allowed. Simultaneously, the alarm module can be invoked to perform one or more operations in the monitoring process (this operation can be handled by the alarm module in the BMC), ensuring the security of the BMC. For example, updating firmware at unconventional times.

[0095] If the target risk range is determined to be the fourth risk range (for example, the risk index value is less than 10), it means that the risk is extremely low. In this case, the target request can be allowed directly, and only basic logging is required.

[0096] In this way, for severe threats (i.e., the first risk range), the most stringent circuit breaker protection is implemented to ensure system security with absolute priority, minimizing the attack window and losses. For highly suspicious behavior (i.e., the second risk range), a controlled observation strategy (i.e., redirection) is adopted, which neither overlooks potential threats nor avoids the potential collateral damage to normal business operations caused by direct blocking, providing valuable samples and buffer time for security analysis. For low-risk anomalies (i.e., the third risk range), a supervised operation strategy is adopted to improve security visibility while allowing business operations to continue. For normal requests (i.e., the fourth risk range), only minimal logging is performed to minimize the impact on system performance and business latency.

[0097] In some optional implementations, in step S102 above, if after traversing all the configuration rules in the configuration rule base, it is still impossible to determine a target configuration rule that matches the target request, the BMC can perform the following specific steps: If it is determined that the operation information corresponding to the API request does not match any configuration rule in the configuration rule base, a preset value can be set as the first risk indicator value. For example, the preset value can be a value within the second risk range. When the second risk range is 40-79, 60 can be set as the preset value. In this way, setting a value within the second risk range for unknown requests can avoid the accidental damage that might be caused to normal business operations by directly blocking them.

[0098] In some optional implementations, when a target configuration rule matching the target request cannot be determined, after performing a risk assessment on the target request, if it is determined to be a risky request (e.g., the target risk indicator value falls within a first risk range or a second risk range), a second configuration rule can be generated based on the sub-operation information of the target request, and this second configuration rule can be added to the configuration rule base. For example, the value of at least one configuration item in the target request (which could be an API endpoint, method name, etc.) can be determined as a condition, and a second configuration rule can be constructed based on the determined at least one condition. This allows for dynamic updates to the configuration rule base, enabling more comprehensive and accurate identification of risky requests in subsequent processes.

[0099] In some alternative implementations, such as Figure 5As shown, after step S106 above, BMC can send the recorded logs, false alarm records (false alarm records can be generated for requests that are judged as risky requests but are determined to be risk-free after analysis or processing by the target device), and total operation information of the target request to the training device.

[0100] The training device, acting as a feedback learning layer, can acquire total operation information, logs, false alarm records, and other information from the target request collected by the BMC. Then, it initiates three optimization paths in parallel, including: The training device can use the acquired information through the model optimizer to retrain the unsupervised model and add the retrained model to the target repository so that the latest unsupervised model can be used to calculate the second risk index value in the next risk assessment operation.

[0101] The training device can extract new configuration rules from the total operation information of the target request through the rule miner and add them to the configuration rule database (see the second configuration rule addition process for details).

[0102] The training device can add new risk handling methods to the policy configuration library (e.g., the mapping table between the aforementioned risk range and risk handling methods) through the policy trainer. For example, the new risk handling method could be to return a false response to a target request with a risk index value greater than 90 to confuse the sender of the risk request.

[0103] In this way, through a continuously cyclical data-driven mechanism, that is, learning the characteristics of new risky requests from actual interception and then feeding the optimization results back to the protection strategy in real time, the dynamic evolution of BMC defense capabilities can be achieved, and an intelligent security protection system with self-learning and self-adaptive capabilities can be built, which can effectively cope with rapidly changing network attacks.

[0104] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0105] Embodiments of this application also provide a request processing apparatus, such as... Figure 6 As shown, it includes: The acquisition module 610 is used to acquire the total operation information and the reference directed graph corresponding to the target request. The total operation information includes at least the first operation sequence corresponding to the target task and the sub-operation information of the target request. The reference directed graph includes multiple abnormal operation sequences. The determination module 620 is used to determine whether there is a target configuration rule in the pre-built configuration rule base that matches the sub-operation information of the target request, based on the sub-operation information of the target request; if the target configuration rule is determined to exist, the risk indicator value corresponding to the target configuration rule is determined as the first risk indicator value; the second risk indicator value is obtained based on the total operation information and the pre-built unsupervised model; and the third risk indicator value is determined based on the first operation sequence and multiple abnormal operation sequences in the reference directed graph. The processing module 630 is used to process the target request based on the first risk indicator value, the second risk indicator value, and the third risk indicator value.

[0106] In some optional implementations, the sub-operation information of the target request includes at least one configuration item, the configuration rule base includes at least one configuration rule, and the configuration rule includes at least one condition; the determination module 620 is specifically used for: Based on at least one configuration item of the sub-operation information of the target request, determine whether the sub-operation information of the target request satisfies all the conditions in the first configuration rule, wherein the first configuration rule is any one of a variety of configuration rules; If the sub-operation information of the target request satisfies all the conditions in the first configuration rule, the first configuration rule is determined as the target configuration rule.

[0107] In some optional implementations, the unsupervised model includes multiple normal sample data points, the number of which is the target number; the determination module 620 is specifically used for: Based on the total operational information and multiple normal sample data, determine the degree of abnormality of the total operational information compared to the multiple normal sample data; The value of the second risk indicator is determined based on the target quantity and the degree of abnormality.

[0108] In some alternative implementations, the determining module 620 is specifically used for: Determine the probability of the initial operation based on the initial operation and multiple abnormal operation sequences in the first operation sequence; Based on each pair of adjacent operations in the first operation sequence and multiple abnormal operation sequences, determine the transition probability between each pair of adjacent operations; The first probability value is determined based on the probability of the initial operation and the transition probability between every two adjacent operations; Determine the length of the first operation sequence; Based on the first probability value and the length of the first operation sequence, determine the first logarithmic probability value corresponding to the first probability value; The third risk index value is obtained by normalizing and adjusting the coefficients of the first logarithmic probability value.

[0109] In some alternative implementations, the determining module 620 is specifically used for: Among multiple abnormal operation sequences, determine the second operation sequence with the highest probability of occurrence, and obtain the second probability value of the second operation sequence; Determine the length of the second operation sequence; Based on the second probability value and the length of the second operation sequence, determine the second logarithmic probability value corresponding to the second probability value; Based on the second logarithmic probability value and the preset third logarithmic probability value, the first logarithmic probability value is normalized to obtain the initial risk index value. The initial risk indicator value is adjusted using a preset adjustment coefficient to obtain the third risk indicator value.

[0110] In some alternative implementations, the processing module 630 is specifically used for: The target risk indicator value is determined based on the first risk indicator value, the second risk indicator value, and the third risk indicator value. Based on the target risk indicator value, determine the target risk range within which the target risk indicator value falls within multiple preset risk ranges; The target task is handled using risk management methods that correspond to the target risk range.

[0111] In some alternative implementations, the processing module 630 is specifically used for: If the target risk range is within the first risk range, the target task will be discarded and the source address included in the target task will be blocked. Alternatively, if the target risk range is the second risk range, the target task can be redirected to the target device so that the target device can process the target task; Alternatively, if the target risk range is the third risk range, allow the target task to proceed and perform one or more of the following operations: alarm, logging, and monitoring. Alternatively, if the target risk range is the fourth risk range, the target task can be allowed to proceed and logged.

[0112] For a description of the features in the embodiment corresponding to the request processing device, please refer to the relevant description in the embodiment corresponding to the request processing method, which will not be repeated here.

[0113] Embodiments of this application also provide an electronic device, such as... Figure 7 As shown, it includes a memory 10 and a processor 20. The memory 10 stores a computer program, and the processor 20 is configured to run the computer program to perform the steps in any of the above-described request processing method embodiments.

[0114] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described request processing method embodiments at runtime.

[0115] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0116] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described request processing method embodiments.

[0117] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described request processing method embodiments.

[0118] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0119] The foregoing has provided a detailed description of a request processing method, apparatus, electronic device, storage medium, and program product provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A request processing method, characterized in that, include: Obtain total operation information and a reference directed graph corresponding to the target request, wherein the total operation information includes at least a first operation sequence corresponding to the target task and sub-operation information of the target request, and the reference directed graph includes multiple abnormal operation sequences; Based on the sub-operation information of the target request, determine whether there is a target configuration rule in the pre-built configuration rule base that matches the sub-operation information of the target request; If the target configuration rule is determined to exist, the risk indicator value corresponding to the target configuration rule is determined as the first risk indicator value; Based on the total operational information and the pre-built unsupervised model, the second risk index value is obtained; A third risk indicator value is determined based on the first operation sequence and multiple abnormal operation sequences in the reference directed graph; The target request is processed based on the first risk indicator value, the second risk indicator value, and the third risk indicator value.

2. The request processing method according to claim 1, characterized in that, The sub-operation information of the target request includes at least one configuration item, the configuration rule base includes at least one configuration rule, and the configuration rule includes at least one condition; The step of determining whether a target configuration rule matching the operation information exists in the pre-built configuration rule base based on the sub-operation information of the target request includes: Based on at least one of the configuration items of the sub-operation information of the target request, determine whether the sub-operation information of the target request satisfies all the conditions in the first configuration rule, wherein the first configuration rule is any one of a variety of configuration rules; If the sub-operation information of the target request satisfies all the conditions in the first configuration rule, the first configuration rule is determined as the target configuration rule.

3. The request processing method according to claim 1, characterized in that, The unsupervised model includes multiple normal sample data, and the number of normal sample data is the target number. The process of obtaining the second risk index value based on the total operational information and the pre-built unsupervised model includes: Based on the total operational information and multiple normal sample data, determine the degree of abnormality of the total operational information compared to the multiple normal sample data; The second risk indicator value is determined based on the target quantity and the degree of anomaly.

4. The request processing method according to claim 1, characterized in that, The step of determining the third risk indicator value based on the first operation sequence and the plurality of abnormal operation sequences in the reference directed graph includes: The probability of the starting operation is determined based on the starting operation in the first operation sequence and the multiple abnormal operation sequences; Based on each pair of adjacent operations in the first operation sequence and the multiple abnormal operation sequences, the transition probability between each pair of adjacent operations is determined; A first probability value is determined based on the probability of the initial operation and the transition probability between every two adjacent operations; Determine the length of the first operation sequence; Based on the first probability value and the length of the first operation sequence, determine the first logarithmic probability value corresponding to the first probability value; The third risk index value is obtained by normalizing and adjusting the coefficients of the first logarithmic probability value.

5. The request processing method according to claim 4, characterized in that, The normalization and coefficient adjustment operations performed on the first logarithmic probability value to obtain the third risk index value include: Among the multiple abnormal operation sequences, the second operation sequence with the highest probability of occurrence is determined, and the second probability value of the second operation sequence is obtained; Determine the length of the second operation sequence; Based on the second probability value and the length of the second operation sequence, determine the second logarithmic probability value corresponding to the second probability value; Based on the second logarithmic probability value and the preset third logarithmic probability value, the first logarithmic probability value is normalized to obtain the initial risk index value. The initial risk index value is adjusted using a preset adjustment coefficient to obtain the third risk index value.

6. The request processing method according to any one of claims 1 to 5, characterized in that, The step of processing the target request based on the first risk indicator value, the second risk indicator value, and the third risk indicator value includes: The target risk indicator value is determined based on the first risk indicator value, the second risk indicator value, and the third risk indicator value. Based on the target risk index value, determine the target risk range into which the target risk index value falls within a preset range of multiple risks; The target task is processed using a risk management method corresponding to the target risk range.

7. The request processing method according to claim 6, characterized in that, The step of processing the target task using a risk management method corresponding to the target risk range includes: If the target risk range is within the first risk range, the target task will be discarded and the source address included in the target task will be blocked. Alternatively, if the target risk range is the second risk range, the target task can be redirected to the target device so that the target device can process the target task; Alternatively, if the target risk range is the third risk range, the target task can be allowed to proceed, and one or more of the following operations can be performed: alarm, log recording, and monitoring. Alternatively, if the target risk range is the fourth risk range, the target task can be allowed to proceed and log entries can be made.

8. A request processing apparatus, characterized in that, include: The acquisition module is used to acquire total operation information and a reference directed graph corresponding to the target request. The total operation information includes at least a first operation sequence corresponding to the target task and sub-operation information of the target request. The reference directed graph includes multiple abnormal operation sequences. The determination module is used to determine whether there is a target configuration rule in the pre-built configuration rule base that matches the sub-operation information of the target request, based on the sub-operation information of the target request; if the target configuration rule is determined to exist, the risk indicator value corresponding to the target configuration rule is determined as the first risk indicator value; a second risk indicator value is obtained based on the total operation information and the pre-built unsupervised model; and a third risk indicator value is determined based on the first operation sequence and multiple abnormal operation sequences in the reference directed graph. The processing module is used to process the target request based on the first risk indicator value, the second risk indicator value, and the third risk indicator value.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the request processing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the request processing method as described in any one of claims 1 to 7.

Images