Access request processing method, device, medium and computing device

Abstract

The embodiment of the present disclosure provides an access request processing method, which is applied to a gateway device, including: obtaining the characteristics of the access request; matching the characteristics of the access request with a pre-established suspicious feature library; in response to a successful feature match of the access request, marking the status of the access request as a suspicious state; performing a security check on the access request in the suspected state based on a preset security rule library, and blocking the access request when the security check fails. In the above process, on the one hand, since there is no need to perform security checks on access requests in the normal state, the number of requests that need to be checked is reduced, the efficiency of the check is improved, and the forwarding of normal requests is not affected, thus reducing the scope of influence during the check; on the other hand, since the suspected state is determined first and then the security check is performed, the attack request can be accurately identified, the false interception rate is reduced, and a better security defense effect is achieved.

Description

Technical Field

[0001] The embodiments of the present disclosure relate to the field of network security technology. More specifically, the embodiments of the present disclosure relate to an access request processing method, apparatus, medium, and computing device. Background Art

[0002] This section is intended to provide a background or context to the embodiments of the present disclosure that are recited in the claims. No statement herein is admitted to be prior art by virtue of its inclusion in this section.

[0003] In recent years, with the rapid development of the Internet, the diversity of users, devices, and systems in the network has exploded. Correspondingly, the network environment has become increasingly complex, network attacks have emerged in an endless stream, and the attack surface has a tendency to continue to expand. The security threats currently facing the Internet are very severe.

[0004] The above-mentioned cyber attacks refer to acts that target computers or any elements of computerized information systems to change, destroy or steal data, as well as to exploit or damage networks.

[0005] Therefore, how to deal with network attacks, effectively defend against network attacks, ensure network security, and avoid the damage caused by network attacks is a hot topic in current research.

[0006] At present, most network attacks can be effectively dealt with by deploying security gateways. Security gateways can not only implement some simple protocol-level filtering, but also some more complex application-level filtering, thereby preventing some unsafe factors in the external network from spreading to the internal network of an enterprise or organization.

[0007] However, when filtering external access requests, if the security gateway is too lenient, it will be detrimental to network defense. If it is too strict, it will lead to excessively long service processing time or even false interception, which is detrimental to user experience. Summary of the Invention

[0008] In this context, embodiments of the present disclosure are intended to provide a method, apparatus, medium, and computing device for processing an access request.

[0009] In a first aspect of the embodiments of the present disclosure, a method for processing an access request is provided, which is applied to a gateway device and includes:

[0010] Get the characteristics of the access request;

[0011] Matching the features of the access request with a pre-established suspicious feature library;

[0012] In response to a successful feature matching of the access request, marking the status of the access request as a suspect status;

[0013] A security check is performed on the suspicious access request based on a preset security rule library, and the access request is blocked if the security check fails.

[0014] In a second aspect of the embodiments of the present disclosure, an access request processing apparatus is provided, which is applied to a gateway device and includes:

[0015] Acquisition module, obtains the characteristics of the access request;

[0016] A matching module, matching the features of the access request with a pre-established suspicious feature library;

[0017] a first marking module, in response to a successful feature matching of the access request, marking the status of the access request as a suspicious status;

[0018] The first detection module performs a security check on the access request in the suspicious state based on a preset security rule library, and blocks the access request if the security check fails.

[0019] In a third aspect of the embodiments of the present disclosure, a storage medium is provided; computer instructions are stored thereon, and when the instructions are executed by a processor, any of the access request processing methods described above is implemented.

[0020] In a fourth aspect of the embodiments of the present disclosure, there is provided a computing device, comprising:

[0021] a processor; and a memory for storing processor-executable instructions;

[0022] The processor implements any of the access request processing methods by running the executable instructions.

[0023] The above embodiments of the present disclosure have at least the following beneficial effects:

[0024] Through the above technical solution, the characteristics of the access request can be obtained, and the characteristics of the access request can be matched with a pre-established suspicious feature library. In response to a successful feature match of the access request, the status of the access request can be marked as a suspicious state. Then, a security check can be performed on the access request in the suspicious state based on the preset security rule library, and the access request can be blocked if the security check fails.

[0025] In the above process, by introducing a suspect state and performing security checks on access requests in this state, on the one hand, since security checks are no longer required for access requests in the normal state, the number of requests that need to be checked is reduced, improving detection efficiency. It also does not affect the forwarding of normal requests, reducing the impact range of the detection. On the other hand, by first determining the suspect state and then performing security checks, attack requests can be accurately identified, reducing the false interception rate and achieving better security defense effectiveness. Furthermore, this solution is universally applicable and can cover all business traffic and application scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The above and other objects, features and advantages of the exemplary embodiments of the present disclosure will become readily understood by reading the detailed description below with reference to the accompanying drawings, in which several embodiments of the present disclosure are shown by way of example and not limitation, wherein:

[0027] Figure 1 A schematic diagram of a gateway device involved in a related technology is schematically shown;

[0028] Figure 2 The following schematically shows a flow chart of a method for processing an access request according to an embodiment of the present disclosure;

[0029] Figure 3 The following schematically shows a flow chart for generating a suspect feature library according to an embodiment of the present disclosure;

[0030] Figure 4 A flowchart of performing a safety check according to an embodiment of the present disclosure is schematically shown;

[0031] Figure 5 A schematic diagram schematically illustrates an access request processing flow according to an embodiment of the present disclosure;

[0032] Figure 6 The following schematically shows a block diagram of an access request processing device according to an embodiment of the present disclosure;

[0033] Figure 7 A schematic diagram schematically illustrates an access request processing medium according to an embodiment of the present disclosure;

[0034] Figure 8 A schematic diagram of an electronic device capable of implementing the above method according to an embodiment of the present disclosure is schematically shown.

[0035] In the drawings, the same or corresponding reference numerals denote the same or corresponding parts. DETAILED DESCRIPTION

[0036] The principles and spirit of the present disclosure will be described below with reference to several exemplary embodiments. It should be understood that these embodiments are provided solely to enable those skilled in the art to better understand and implement the present disclosure, and are not intended to limit the scope of the present disclosure in any way. Rather, these embodiments are provided to make the present disclosure more thorough and complete, and to fully convey the scope of the present disclosure to those skilled in the art.

[0037] Those skilled in the art will appreciate that the embodiments of the present disclosure may be implemented as a system, apparatus, device, method, or computer-readable storage medium. Therefore, the present disclosure may be implemented in the following forms: entirely in hardware, entirely in software (including firmware, resident software, microcode, etc.), or in a combination of hardware and software.

[0038] According to an embodiment of the present disclosure, a method, apparatus, medium, and computing device for processing an access request are proposed.

[0039] It should be understood that the numbers of any elements in the drawings are for illustration only and not for limitation, and any names are for distinction only and do not have any limiting meaning. Furthermore, the data involved in this disclosure may be data authorized by the user or fully authorized by all parties.

[0040] The principles and spirit of the present disclosure are explained in detail below with reference to several representative embodiments of the present disclosure.

[0041] Application Scenario Overview

[0042] See Figure 1 , Figure 1 This is a schematic diagram of a gateway device in a related technology provided as an example. Figure 1 As shown, the gateway device is deployed between the intranet and the extranet to ensure the security of data entering the intranet. For example, the gateway device can have functions such as keyword filtering and spam blocking to play the role of a security gateway.

[0043] Among them, some gateway devices also have certain firewall functions, which can detect data entering and leaving the network, and scan viruses for data of protocols such as HTTP, FTP, SMTP, IMAP, and POP3. Once a virus is found, corresponding measures will be taken to isolate or kill it, which plays a very important role in protecting against viruses.

[0044] In related technologies, such as Figure 1As shown in the figure, access requests received by the gateway device can be divided into two types: normal requests and attack requests. Normal requests are requests that pose no security risks to business services and do not cause data leakage or service stability impacts on the business or system. Attack requests are requests that may cause security risks to business services, resulting in data leakage or service operation abnormalities.

[0045] Therefore, the gateway device first needs to identify the access request and determine whether it is a normal request or an attack request. If the access request is a normal request, the normal access request is allowed to be sent to the intranet. If the access request is an abnormal request, it needs to be blocked to protect the security of business services.

[0046] It's important to note that traditional gateway devices only support two security modes: observation mode and interception mode. In observation mode, the gateway device performs bypass detection logic. While the gateway device performs security checks on access requests, the test results are only used for attack collection and post-analysis. The test results do not affect the forwarding of access requests, and the gateway device does not block attack requests.

[0047] In intercept mode, the gateway device performs serial detection logic. After performing a security check on the access request, the gateway device determines whether to forward or block the request based on the test result. If the test result is a normal request, the request is forwarded; if the test result is an abnormal request, the request is blocked, thus ensuring the service and data security of the business system.

[0048] It should be noted that the above application scenarios are only shown to facilitate understanding of the spirit and principles of the present disclosure, and the embodiments of the present disclosure are not limited in this respect. On the contrary, the embodiments of the present disclosure can be applied to any applicable scenario. SUMMARY OF THE INVENTION

[0050] The inventors discovered that when processing access requests based on the aforementioned gateway device, when the gateway device is operating in observation mode, it can only be used to collect and analyze attack requests. It has no defensive capabilities and does not take any security measures. It is unable to directly block attack requests, has considerable lag, and has very low security defense capabilities. When the gateway device is operating in interception mode, it needs to wait for the detection result of the access request before determining whether to continue forwarding. This will increase the processing time of the access request, resulting in slower response on the user side and affecting the user experience.

[0051] In view of this, this specification provides a technical solution for intelligent interception by introducing a suspicious state for access requests, first filtering out normal requests based on whether they are in a suspicious state, and then performing security checks on access requests in a suspicious state.

[0052] The core technical concept of this manual is:

[0053] Access requests are categorized into three states: normal, suspected, and attack. Requests in different states undergo different processing logic. Two rounds of judgment are required for each of these three states. In the first round, signature matching is used to determine whether the request is normal or suspected, eliminating the need for security checks. Furthermore, for requests in the suspected state, a second round of judgment is required, using security checks to accurately determine whether the request is normal or in an attack state.

[0054] In the above process, by introducing a suspect state and performing security checks on access requests in this state, on the one hand, since security checks are no longer required for access requests in the normal state, the number of requests that need to be checked is reduced, improving detection efficiency. It also does not affect the forwarding of normal requests, reducing the impact range of the detection. On the other hand, by first determining the suspect state and then performing security checks, attack requests can be accurately identified, reducing the false interception rate and achieving better security defense effectiveness. Furthermore, this solution is universally applicable and can cover all business traffic and application scenarios.

[0055] After introducing the basic principles of the present disclosure, various non-limiting embodiments of the present disclosure are described in detail below.

[0056] Exemplary Methods

[0057] The technical concept of this specification will be described in detail below through specific embodiments.

[0058] The present disclosure aims to provide a technical solution for intelligent interception by introducing a suspicious state into access requests, first screening out normal requests based on whether they are in a suspicious state, and then performing security checks on access requests in a suspicious state.

[0059] When implemented, it is possible to obtain the characteristics of the access request;

[0060] For example, the above-mentioned features may include the source IP address of the access request or the request header of the access request.

[0061] Then, the features of the access request may be matched with a pre-established suspicious feature library;

[0062] For example, assuming that the above feature is a source IP, a search can be performed in a pre-established suspicious feature library to determine whether the same source IP exists. If so, the match is successful.

[0063] Then, in response to a successful feature matching of the access request, the status of the access request may be marked as a suspect status;

[0064] For example, if the feature matching of the access request succeeds, the status of the access request may be marked as a suspect status; and if the feature matching of the access request fails, the status of the access request may be marked as a normal status.

[0065] Afterwards, a security check can be performed on the access request in the suspected state based on a preset security rule library, and the access request can be blocked if the security check fails;

[0066] For example, security checks can be performed on the access request in the suspected state based on a preset security rule library to identify the risk level of the access request in the suspected state. When the risk level reaches a preset threshold, the state of the access request in the suspected state is updated to an attack state, and the access request in the attack state is blocked.

[0067] In the above process, by introducing a suspect state and performing security checks on access requests in this state, on the one hand, since security checks are no longer required for access requests in the normal state, the number of requests that need to be checked is reduced, improving detection efficiency. It also does not affect the forwarding of normal requests, reducing the impact range of the detection. On the other hand, by first determining the suspect state and then performing security checks, attack requests can be accurately identified, reducing the false interception rate and achieving better security defense effectiveness. Furthermore, this solution is universally applicable and can cover all business traffic and application scenarios.

[0068] See Figure 2 , Figure 2 This is a flowchart of a method for processing an access request provided by an exemplary embodiment, which is applied to a gateway device and includes the following steps:

[0069] Step 201: Obtain the characteristics of the access request.

[0070] In this embodiment, in response to a received access request, a feature of the access request may be obtained.

[0071] For example, after receiving an access request, a preset field may be extracted from the access request to obtain features corresponding to the access request.

[0072] It should be noted that hackers usually send multiple attack requests continuously when launching attacks, and these attack requests usually have the same characteristics. Therefore, a suspicious feature library can be established to match the features of access requests to identify access requests with suspicious features.

[0073] Step 202: Match the features of the access request with a pre-established suspicious feature library.

[0074] In this embodiment, the features of the access request may be matched with a pre-established suspicious feature library to determine whether the suspicious feature library contains features identical to those of the access request.

[0075] For example, assuming that the feature of the access request is feature A, and the features in the pre-established suspicious feature library are {feature A, feature B, feature C...}, then when matching, it can be determined that there is a feature in the suspicious feature library that is the same as feature A of the access request.

[0076] In one embodiment shown, the feature of the access request includes the source IP address of the access request or the request header of the access request.

[0077] In one example, the above feature may be the source IP of an access request. For example, when the source IP of an access request is 192.168.1.3, if the IP address is matched in the suspicious feature library, it indicates that the IP address is at risk, and the access request may be considered a suspicious request; otherwise, if it is not matched, the access request may be excluded from suspicion.

[0078] In another example, the above feature may be a request header of an access request. For example, for an access request of the HTTP protocol, the HTTP header information includes four parts: a general header, a request header, a response header, and an entity header.

[0079] Among them, the client carries a request header when sending a request to the server, and the server carries a response header when responding to the client data. The request header mainly includes some basic information of the client, such as the file type that the current browser can accept, the data encoding that the current browser can accept, the current browsing language used, the cookie that stores user-related information, and the browser version information.

[0080] Therefore, by matching the request header of the access request with the preset suspicious feature library, it is possible to determine the access request with risks, and the access request can be considered as a suspicious request.

[0081] In step 203 , in response to a successful feature matching of the access request, the status of the access request may be marked as a suspect status.

[0082] In this embodiment, if the features of the access request successfully match the pre-established suspicious feature library, the access request can be considered a suspicious request and the status of the access request can be marked as a suspicious status.

[0083] It should be noted that, as can be seen from the above, this disclosure divides access requests into three states, namely normal state, suspected state and attack state. Accordingly, in this specification, access requests in the above three states are referred to as normal requests, suspected requests and attack requests.

[0084] For example, before an access request is matched against a suspicious signature database, its status is uncertain. Matching is required to determine whether the access request is in a suspicious or normal state. If a successful signature match is found for the access request, the request is considered suspicious and can be marked as suspicious.

[0085] In one embodiment shown, in response to the feature of the access request not being successfully matched, the status of the access request is marked as a normal state; and the access request in the normal state is forwarded, and an asynchronous security check is performed on the access request in the normal state based on a preset security rule library.

[0086] Continuing with the example, in response to the feature of the access request not being matched successfully, it can be considered that the access request is not a suspicious request but a normal request. Therefore, the status of the access request can be marked as normal, and the access request in the normal state can be forwarded.

[0087] It should be noted that in the above process, normal access requests do not need to be security checked before forwarding, and normal requests account for the majority of access requests. Therefore, the number of requests that need to be checked can be greatly reduced, and the efficiency of detection can be improved.

[0088] Furthermore, for normal requests, asynchronous security detection can be performed on the normal access requests based on the preset security rule library. Since the detection results of normal requests do not affect the forwarding of normal requests, there will be no false interception, nor will the problem of slow response to users' normal requests occur.

[0089] In one embodiment shown, asynchronous security detection can be performed on the access request in the normal state based on a preset security rule library to identify the risk level of the access request in the normal state; in response to the risk level reaching a preset threshold, the state of the access request in the normal state is updated to an attack state; based on the access request in the attack state, a suspect feature in the suspect feature library is generated.

[0090] It is worth noting that the above-mentioned suspicious feature library can be pre-imported or determined based on the results of security detection.

[0091] For example, when the above-mentioned suspicious feature library has not yet been established, it can be assumed that all access requests are normal access requests, and then asynchronous security detection of normal access requests based on a preset security rule library is used to determine the features in the suspicious feature library.

[0092] Continuing with the example, see Figure 3 , Figure 3 This is a flow chart of generating a suspect feature library provided by an exemplary embodiment. Figure 3 As shown, the following steps may be included:

[0093] Step 301: Perform asynchronous security detection on the normal access request based on a preset security rule library to identify the risk level of the normal access request.

[0094] For example, asynchronous security detection can be performed on normal access requests based on a preset security rule library to determine which security rules in the security rule library are hit by the access request, and the risk level of the access request can be calculated based on the weights corresponding to the hit security rules.

[0095] For a description of the above security rule base, please refer to the detailed description of the WAF security rule base and the DDOS security rule base in the following text, which will not be repeated here.

[0096] Continuing with the example, suppose there are 10 security rules preset in the security rule library, and the access request to be detected hits security rule 1, security rule 3, and security rule 7. The score corresponding to security rule 1 is 15, the score corresponding to security rule 3 is 20, and the score corresponding to security rule 7 is 30. Then it can be calculated that the risk level corresponding to the access request is 65.

[0097] The risk level can be directly expressed using a calculated numerical value; or it can be divided into corresponding levels based on the calculated numerical value. For example, the risk level can be 1-10, with a range of 60-70 points corresponding to level 6. The risk level can also be divided into low, medium, and high, with a score greater than 60 being a high risk level. Those skilled in the art can set this as needed, and this specification does not limit this.

[0098] Step 302: in response to the risk level reaching a preset threshold, updating the state of the normal access request to an attack state;

[0099] Continuing with the above example, assuming that the threshold score is set to 60, then since the risk level value of the access request is 65, which is greater than 60, the status of the access request can be updated from the normal state to the attack state.

[0100] Step 303: Generate a suspicious feature in the suspicious feature library based on the access request of the attack status.

[0101] For example, for an access request in an attack state, a feature of the access request may be obtained and used as a suspect feature in a suspect feature library.

[0102] It is worth noting that when generating the above-mentioned suspicious features, currently popular big data calculations and machine learning models can be used to determine the suspicious features in the access request, and this specification does not limit this.

[0103] In addition, although some suspicious requests can be identified by importing a suspicious feature library, the suspicious features determined by generating a suspicious feature library based on the above steps 301-303 are more suitable for the current network environment and application scenario of the gateway device, thereby improving the accuracy of identifying suspicious requests.

[0104] In step 204, a security check may be performed on the suspicious access request based on a preset security rule library, and the access request may be blocked if the security check fails.

[0105] In this embodiment, a security check may be performed on a suspicious access request based on a preset security rule library. If the security check fails, the access request may be blocked.

[0106] For example, security checks can be performed on suspicious access requests based on a preset security rule library, and different operations can be performed based on the results of the security check. If the result of the security check is that the security check has failed, then it can be determined that the access request does pose a risk and is an attack request, and the access request can be blocked; if the result of the security check is that the security check has passed, then the access request can be free of risk suspicion and can be forwarded normally.

[0107] In one embodiment shown, the security rule base includes at least a WAF security rule base and a DDOS security rule base.

[0108] For example, the above-mentioned gateway device may maintain at least a DDOS security rule library and a WAF security rule library.

[0109] The WAF mentioned above refers to a website application-level intrusion prevention system (Web Application Firewall). Through the WAF security rule library, it can perform content inspection and verification on various requests from web application clients to ensure the security and legitimacy of the requests, thereby blocking illegal requests in a timely manner.

[0110] In one example, the above-mentioned gateway device can maintain a WAF security rule library. By performing security detection on suspicious access requests based on the WAF security rule library, a series of tests can be performed on the access requests, and each test is composed of one or more detection rules. If the test fails, the access request can be considered an attack request and needs to be blocked.

[0111] The aforementioned DDOS refers to a distributed denial of service (DDoS) attack, which occurs when multiple attackers in different locations simultaneously attack one or more targets, or when a single attacker controls multiple machines in different locations and uses them to simultaneously attack the victim. The DDOS security rule library can analyze network traffic anomalies to determine whether suspected requests are DDOS attack requests, thereby ensuring the passage of legitimate requests and denying DDOS attack requests.

[0112] In another example, the above-mentioned gateway device can maintain a DDOS security rule library. By performing security checks on access requests in suspicious states based on the DDOS security rule library, it can be determined whether the suspicious requests are DDOS attack requests based on the characteristics of the DDOS attack. For example, when a large number of ESTABLISHED connection states are observed, and the number of access requests from a single IP is as high as dozens or even hundreds, it can be considered as a TCP flood attack in a DDOS attack, and timely defense can be carried out to block the DDOS attack requests.

[0113] In one embodiment shown, a security check can be performed on the access request in the suspected state based on a preset security rule base to identify the risk level of the access request in the suspected state; in response to the risk level reaching a preset threshold, the state of the access request in the suspected state is updated to an attack state, and the access request in the attack state is blocked; in response to the risk level not reaching the preset threshold, the state of the access request in the suspected state is updated to a normal state, and the access request in the normal state is forwarded.

[0114] For example, see Figure 4 , Figure 4 This is a flow chart of a safety test provided by an exemplary embodiment. Figure 4 As shown, the above step 204 may specifically include the following steps:

[0115] Step 401: Perform security checks on the suspected access request based on a preset security rule library to identify the risk level of the suspected access request.

[0116] For example, a security check may be performed on a suspicious access request based on a preset security rule library to identify a risk level of the suspicious access request. Assume that the risk level is 1-10, and a larger number indicates a higher risk.

[0117] It is worth noting that the difference between the above step 401 and step 301 is that the security detection result of step 301 does not affect the forwarding of normal access requests. The detection and forwarding are asynchronous, while the security detection result of step 401 determines whether the suspicious request can be forwarded.

[0118] Step 402: In response to the risk level reaching a preset threshold, the state of the access request in the suspected state is updated to the attack state, and the access request in the attack state is blocked;

[0119] For example, assuming that the risk level threshold is 6, and the risk level of the identified suspicious access request is 7, which exceeds the risk level threshold, the status of the access request can be updated from suspicious status to attack status, and the access request in the attack status can be blocked.

[0120] It is worth noting that, for an access request determined to be in an attack state, the characteristics of the attack request can also be obtained as suspicious characteristics by referring to the description in the aforementioned step 303, which will not be elaborated here.

[0121] Step 403: In response to the risk level not reaching the preset threshold, the state of the access request in the suspected state is updated to a normal state, and the access request in the normal state is forwarded;

[0122] For example, when the risk level of the identified suspicious access request is 3, which does not reach the risk level threshold of 6, the status of the access request can be updated from the suspicious state to the normal state, and the normal state access request is forwarded.

[0123] Since the principles of the above steps 401-403 are the same as those of steps 301-302, to avoid repetition, only a simple example is given here, and those skilled in the art can refer to the above detailed description.

[0124] In one embodiment shown, in response to a suspicious feature in the suspicious feature library not matching any feature of an access request within a preset time period, the suspicious feature may be removed from the suspicious feature library.

[0125] It should be noted that since attack requests have a certain timeliness, if suspicious features are not updated and eliminated in a timely manner, it may affect normal business and cause misidentification or misinterpretation. Therefore, the validity period of the suspicious features can be set.

[0126] For example, if the suspicious features in the suspicious feature library do not match the features of any access request within a preset time period, such as a suspicious IP has not made any access request within 12 hours, the suspicious IP can be removed from the suspicious feature library.

[0127] In addition, when no attack request having a suspicious feature appears within a preset time period, the suspicious feature may be removed from the suspicious feature database.

[0128] See also Figure 5 , Figure 5 This is a schematic diagram of an access request processing flow provided by an exemplary embodiment. Figure 5 As shown, the following steps are included:

[0129] S501: The access request from the external network user is forwarded to the gateway device for processing through the access layer;

[0130] S502: The gateway device is in intelligent interception mode. For a received access request, the gateway device obtains features of the access request and matches the features of the access request with a pre-established suspicious feature library.

[0131] S503: In response to the above matching failure, the access request may be deemed risk-free and not a suspicious request, and the access request may enter observation mode and be marked as normal.

[0132] S504, forwarding the normal access request to the business service;

[0133] S505: For a normal access request, bypass detection logic may be executed on the access request to perform security detection;

[0134] S506: In response to the successful match, the access request may be considered to be a risky request. However, whether it is an attack request needs further confirmation. It is temporarily determined to be a suspect request and the interception mode may be entered, marking the access request status as suspect.

[0135] S507: For a suspicious access request, a serial detection logic may be executed on the access request to perform a security check.

[0136] S508: Perform security checks on the access request to be checked based on a preset security rule library, identify the risk level of the access request, and then determine whether the access request is an attack request based on whether the risk level reaches a threshold;

[0137] S509, after the suspicious request is further determined to be an attack request, the attack request may be blocked;

[0138] S510: After the suspicious request is further determined to be a normal request, the normal request may be forwarded.

[0139] The implementation process of each of the above steps is detailed in the implementation process described in the above method, which will not be repeated here.

[0140] Through the above technical solution, the characteristics of the access request can be obtained, and the characteristics of the access request can be matched with a pre-established suspicious feature library. In response to a successful feature match of the access request, the status of the access request can be marked as a suspicious state. Then, a security check can be performed on the access request in the suspicious state based on the preset security rule library, and the access request can be blocked if the security check fails.

[0141] In the above process, by introducing a suspect state and performing security checks on access requests in this state, on the one hand, since security checks are no longer required for access requests in the normal state, the number of requests that need to be checked is reduced, improving detection efficiency. It also does not affect the forwarding of normal requests, reducing the impact range of the detection. On the other hand, by first determining the suspect state and then performing security checks, attack requests can be accurately identified, reducing the false interception rate and achieving better security defense effectiveness. Furthermore, this solution is universally applicable and can cover all business traffic and application scenarios.

[0142] Exemplary devices

[0143] After introducing the method of the exemplary embodiment of the present disclosure, see Figure 6 , Figure 6 It is a block diagram of an access request processing device provided by an exemplary embodiment.

[0144] The implementation process of the functions and effects of each module in the following device is specifically described in the implementation process of the corresponding steps in the above method, which will not be repeated here. For the device embodiment, since it basically corresponds to the method embodiment, the relevant parts can be referred to the partial description of the method embodiment.

[0145] like Figure 6 As shown, the access request processing device 600 may include: an acquisition module 601, a matching module 602, a first marking module 603 and a first detection module 604.

[0146] The acquisition module 601 is configured to acquire characteristics of the access request;

[0147] The matching module 602 is configured to match the features of the access request with a pre-established suspicious feature library;

[0148] The first marking module 603 is configured to, in response to a successful feature matching of the access request, mark the status of the access request as a suspicious status;

[0149] The first detection module 604 is configured to perform a security check on the access request in the suspected state based on a preset security rule library, and block the access request if the security check fails.

[0150] In one embodiment, the feature of the access request includes a source IP address of the access request or the access request.

[0151] In one embodiment, the apparatus 600 further includes:

[0152] The second marking module 605 is configured to, in response to the feature of the access request not being successfully matched, mark the status of the access request as normal;

[0153] The second detection module 606 is configured to forward the normal access request and perform asynchronous security detection on the normal access request based on a preset security rule library.

[0154] In one embodiment, the second detection module 606 further:

[0155] Performing asynchronous security detection on the normal access request based on a preset security rule library to identify the risk level of the normal access request;

[0156] In response to the risk level reaching a preset threshold, updating the state of the access request in the normal state to an attack state;

[0157] Based on the access request of the attack status, a suspicious feature in the suspicious feature library is generated.

[0158] In one embodiment, the first detection module 604 further:

[0159] Performing security checks on the suspicious access request based on a preset security rule library to identify the risk level of the suspicious access request;

[0160] In response to the risk level reaching a preset threshold, updating the state of the access request in the suspect state to an attack state, and blocking the access request in the attack state;

[0161] In response to the risk level not reaching the preset threshold, the state of the suspicious access request is updated to a normal state, and the normal state access request is forwarded.

[0162] In one embodiment, the security rule base includes at least a WAF security rule base and a DDOS security rule base.

[0163] In one embodiment, the apparatus 600 further includes:

[0164] The updating module 607 is configured to remove the suspicious feature from the suspicious feature library in response to the suspicious feature in the suspicious feature library not matching any feature of the access request within a preset time period.

[0165] The specific details of each module of the access request processing device 600 have been described in detail in the previous description of the access request processing method flow, and therefore will not be repeated here.

[0166] It should be noted that although the above detailed description mentions several modules or units of the access request processing device 600, this division is not mandatory. In fact, according to the embodiments of the present disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0167] Exemplary media

[0168] After introducing the apparatus of the exemplary embodiment of the present disclosure, see Figure 7 , Figure 7 It is a schematic diagram of an access request processing medium provided by an exemplary embodiment.

[0169] In exemplary embodiments of the present disclosure, a computer-readable storage medium is also provided, on which is stored a program product capable of implementing the aforementioned methods of this specification. In some possible embodiments, various aspects of the present disclosure may also be implemented in the form of a program product comprising program code. When the program product is executed on a terminal device, the program code is configured to cause the terminal device to execute the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of the present disclosure.

[0170] refer to Figure 7 As shown, a readable storage medium 700 for implementing the above method according to an embodiment of the present disclosure is described. The readable storage medium 700 may be a portable compact disk read-only memory (CD-ROM) and include program code, and may be run on a terminal device, such as a personal computer. However, the readable storage medium of the present disclosure is not limited thereto. In this document, a readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0171] The readable storage medium can be any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium can be, for example, but not limited to, a system, device or component of electricity, magnetism, light, electromagnetic, infrared, or semiconductor, or any combination thereof. More specific examples (non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0172] A computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0173] The program code embodied on the readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0174] Program code for performing the operations of the present disclosure may be written in any combination of one or more programming languages, including object-oriented programming languages such as Java, C++, and the like, as well as conventional procedural programming languages such as "C" or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving a remote computing device, the remote computing device may be connected to the user computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0175] Exemplary computing devices

[0176] After introducing the method, medium and apparatus of the exemplary embodiments of the present disclosure, see Figure 8 , Figure 8 It is a schematic diagram of an electronic device capable of implementing the above method provided by an exemplary embodiment.

[0177] Refer to the following Figure 8 800 according to this embodiment of the present disclosure will be described. Figure 8 The electronic device 800 shown is merely an example and should not limit the functions and scope of use of the embodiments of the present disclosure.

[0178] like Figure 8 As shown, electronic device 800 is implemented as a general-purpose computing device. Components of electronic device 800 may include, but are not limited to, at least one processing unit 801, at least one storage unit 802, and a bus 803 connecting different system components (including storage unit 802 and processing unit 801).

[0179] The storage unit stores program codes, which can be executed by the processing unit 801, so that the processing unit 801 executes the steps of the various embodiments described above in this specification.

[0180] The storage unit 802 may include a readable medium in the form of a volatile storage unit, such as a random access memory unit (RAM) 8021 and / or a cache memory unit 8022 , and may further include a read-only memory unit (ROM) 8023 .

[0181] The storage unit 802 may also include a program / utility 8024 having a set (at least one) of program modules 8025, such program modules 8025 including but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which or some combination may include the reality of a network environment.

[0182] The bus 803 may include a control bus, an address bus, and a data bus.

[0183] The electronic device 800 can also communicate with one or more external devices 804 (e.g., a keyboard, a pointing device, a Bluetooth device, etc.). Such communication can be performed via an input / output (I / O) interface 805. Furthermore, the electronic device 800 can also communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network, such as the Internet) via a network adapter 806. As shown, the network adapter 806 communicates with other modules of the electronic device 800 via a bus 803. It should be understood that, although not shown in the figure, other hardware and / or software modules can be used in conjunction with the electronic device 800, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0184] Through the description of the above embodiments, it is easy for those skilled in the art to understand that the example embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solution according to the embodiments of the present disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes a number of instructions to enable a computing device (which can be a personal computer, a server, a terminal device, or a network device, etc.) to execute the method according to the embodiments of the present disclosure.

[0185] It should be noted that although several units / modules or sub-units / sub-modules of the device are mentioned in the above detailed description, this division is merely exemplary and not mandatory. In fact, according to the embodiments of the present disclosure, the features and functions of two or more units / modules described above can be embodied in one unit / module. Conversely, the features and functions of one unit / module described above can be further divided and embodied by multiple units / modules.

[0186] Furthermore, although the operations of the disclosed method are described in a particular order in the accompanying drawings, this does not require or imply that the operations must be performed in this particular order, or that all illustrated operations must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps.

[0187] Although the spirit and principles of the present disclosure have been described with reference to several specific embodiments, it should be understood that the present disclosure is not limited to the specific embodiments disclosed, and the division into various aspects does not mean that the features in these aspects cannot be combined to benefit. Such division is only for the convenience of expression. The present disclosure is intended to cover various modifications and equivalent arrangements included in the spirit and scope of the appended claims.

Claims

1. A method for processing an access request, applied to a gateway device, comprising: Get the characteristics of the access request; Matching the features of the access request with a pre-established suspicious feature library; In response to a successful feature matching of the access request, marking the status of the access request as a suspect status; Performing a security check on the suspicious access request based on a preset security rule library, and blocking the access request if the security check fails; Performing asynchronous security detection on normal access requests based on the preset security rule library to identify the risk level of the normal access requests; In response to the risk level reaching a preset threshold, updating the state of the access request in the normal state to an attack state; Based on the access request of the attack status, a suspicious feature in the suspicious feature library is generated. 2 . The method according to claim 1 , wherein the feature of the access request comprises a source IP address of the access request or a request header of the access request.

3. The method according to claim 1, further comprising: In response to failure to successfully match the features of the access request, marking the state of the access request as the normal state; Forward the normal access request.

4. The method according to claim 1, wherein the security check is performed on the suspicious access request based on a preset security rule library, and the access request is blocked if the security check fails, comprising: Performing security checks on the suspicious access request based on a preset security rule library to identify the risk level of the suspicious access request; In response to the risk level reaching a preset threshold, updating the state of the access request in the suspect state to an attack state, and blocking the access request in the attack state; In response to the risk level not reaching a preset threshold, the state of the access request in the suspected state is updated to a normal state, and the access request in the normal state is forwarded.

5. The method according to claim 1, wherein the security rule base includes at least a WAF security rule base and a DDOS security rule base.

6. The method according to claim 1, further comprising: In response to a suspicious feature in the suspicious feature library not matching any feature of an access request within a preset time period, the suspicious feature is removed from the suspicious feature library.

7. An access request processing device, applied to a gateway device, comprising: Acquisition module, obtains the characteristics of the access request; A matching module, matching the features of the access request with a pre-established suspicious feature library; a first marking module, in response to a successful feature matching of the access request, marking the status of the access request as a suspicious status; a first detection module, performing a security check on the suspicious access request based on a preset security rule library, and blocking the access request if the security check fails; a second detection module, performing asynchronous security detection on normal access requests based on the preset security rule library, and identifying the risk level of the normal access requests; In response to the risk level reaching a preset threshold, the state of the access request in the normal state is updated to an attack state; and based on the access request in the attack state, a suspicious feature in the suspicious feature library is generated.

8. The device according to claim 7, wherein the feature of the access request comprises a source IP address of the access request or a request header of the access request.

9. The apparatus according to claim 7, further comprising: a second marking module, in response to failure of matching the feature of the access request, marking the status of the access request as the normal status; The second detection module is further configured to forward the normal access request.

10. The apparatus according to claim 7, wherein the first detection module further: Performing security checks on the suspicious access request based on a preset security rule library to identify the risk level of the suspicious access request; In response to the risk level reaching a preset threshold, updating the state of the access request in the suspect state to an attack state, and blocking the access request in the attack state; In response to the risk level not reaching the preset threshold, the state of the suspicious access request is updated to a normal state, and the normal state access request is forwarded.

11. The device according to claim 7, wherein the security rule base comprises at least a WAF security rule base and a DDOS security rule base.

12. The apparatus according to claim 7, further comprising: The updating module removes the suspicious feature from the suspicious feature library in response to the suspicious feature in the suspicious feature library not matching any feature of the access request within a preset time period.

13. A storage medium having computer instructions stored thereon, wherein when the instructions are executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

14. A computing device comprising: processor; a memory for storing processor-executable instructions; The processor implements the method according to any one of claims 1 to 6 by running the executable instructions.

Images