Service request processing method and apparatus

Abstract

The embodiment of the present specification provides a service request processing method and device, wherein the service request processing method comprises the following steps: extracting an access path field from network address information carried by a service request submitted through a target service, detecting a distribution path field matched with the access path field in a routing rule, and reading a distribution label corresponding to the detected distribution path field; in the case that the distribution label is a negative distribution label, forwarding the service request to a honeypot container corresponding to the distribution label for request response processing.

Description

Technical Field

[0001] This document relates to the field of data processing technology, and in particular to a service request processing method and apparatus. Background Technology

[0002] With the continuous development of internet technology, various internet services have emerged, and users are accessing these services more and more frequently. Users use these services to meet their service needs, such as resource services. In this context, internet services may be subject to malicious attacks from users, such as malicious data acquisition, which could pose security risks or even threaten system paralysis. This also brings significant management challenges to the service management of internet services. Summary of the Invention

[0003] This specification provides one or more embodiments of a service request processing method applied to a routing component. The method includes: acquiring a service request submitted through a target service, and extracting an access path field from the network address information carried in the service request; detecting a distribution path field in a routing rule that matches the access path field according to the field detection order; reading the distribution tag corresponding to the detected distribution path field from the routing rule; and forwarding the service request to the honeypot container corresponding to the distribution tag for request-response processing if the distribution tag is a negative distribution tag.

[0004] This specification provides one or more embodiments of a service request processing apparatus, operating within a routing component. The apparatus includes: a field extraction module configured to acquire service requests submitted through a target service and extract an access path field from the network address information carried in the service request; a field detection module configured to detect distribution path fields in routing rules that match the access path fields, according to a field detection order; a tag reading module configured to read distribution tags corresponding to the detected distribution path fields from the routing rules; and a request forwarding module configured to forward the service request to the honeypot container corresponding to the distribution tag for request-response processing when the distribution tag is a negative distribution tag.

[0005] This specification provides one or more embodiments of a service request processing device, including: a processor; and a memory configured to store computer-executable instructions, which, when executed, cause the processor to: obtain a service request submitted through a target service and extract an access path field from network address information carried in the service request; detect distribution path fields in routing rules that match the access path fields according to a field detection order; read a distribution tag corresponding to the detected distribution path field from the routing rules; and, if the distribution tag is a negative distribution tag, forward the service request to a honeypot container corresponding to the distribution tag for request-response processing.

[0006] This specification provides one or more embodiments of a storage medium for storing computer-executable instructions that, when executed by a processor, implement the following process: obtaining a service request submitted through a target service and extracting an access path field from the network address information carried in the service request; detecting distribution path fields in routing rules that match the access path fields according to the field detection order; reading the distribution tag corresponding to the detected distribution path field from the routing rules; and forwarding the service request to the honeypot container corresponding to the distribution tag for request-response processing if the distribution tag is a negative distribution tag. Attached Figure Description

[0007] To more clearly illustrate the technical solutions in one or more embodiments of this specification or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0008] Figure 1 A schematic diagram illustrating the implementation environment of a service request processing method provided in one or more embodiments of this specification;

[0009] Figure 2 A flowchart illustrating a service request processing method provided in one or more embodiments of this specification;

[0010] Figure 3 A flowchart illustrating a service request processing method for a resource service scenario, provided in one or more embodiments of this specification;

[0011] Figure 4 A schematic diagram of an embodiment of a service request processing apparatus provided in one or more embodiments of this specification;

[0012] Figure 5This is a schematic diagram of the structure of a service request processing device provided for one or more embodiments of this specification. Detailed Implementation

[0013] To enable those skilled in the art to better understand the technical solutions in one or more embodiments of this specification, the technical solutions in one or more embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of the embodiments. Based on one or more embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of this document.

[0014] Reference Figure 1 This specification provides a schematic diagram of the implementation environment for a service request processing method according to one or more embodiments. The implementation environment may include a user terminal 101, a routing system 102, a default server 103, and a honeypot server 104.

[0015] User terminal 101 can be a mobile phone, personal computer, tablet computer, e-book reader, device for information interaction based on VR (Virtual Reality) technology, vehicle terminal, IoT device, wearable device, laptop computer and desktop computer, etc.

[0016] User terminal 101 may have a target service client installed, or a browser installed to access the target service via a web client, or a third-party application installed where the target service runs. The application client and web client mentioned in one or more embodiments of this specification are collectively referred to as "clients," and will not be specifically stated below. A client may be a client with request distribution or request routing functions, or a client with both request distribution and social functions, or a client with both request distribution and data receiving functions, or a client with both request distribution and data sending functions. Furthermore, a client may also have other types of functions, which will not be elaborated here.

[0017] The routing system 102 can be a single server or a server cluster consisting of several servers. Considering the actual request processing scenario, the number and deployment method of servers can be determined based on the magnitude of the number of service requests submitted within a time period during the request distribution process. For example, when the number of requests is small, one or more servers can be deployed; conversely, when the number of requests reaches a certain level, a server cluster consisting of several servers can be deployed. The routing system 102 may include routing components.

[0018] User terminal 101 and routing system 102 can communicate via wireless or wired network. Routing system 102 and default server 103 can communicate via wireless or wired network. Routing system 102 and honeypot server 104 can communicate via wireless or wired network. Default server 103 and honeypot server 104 can communicate via wireless or wired network.

[0019] User terminal 101 can interact with routing system 102. Specifically, user terminal 101 can submit service requests to routing components deployed in routing system 102 through target services. Routing components deployed in routing system 102 can obtain service requests submitted by user terminal 101 through target services, extract access path fields from network address information carried in service requests, detect distribution path fields in routing rules that match access path fields, read distribution tags corresponding to distribution path fields in routing rules, and forward service requests to honeypot containers running on honeypot server 104 corresponding to distribution tags for request and response processing when the distribution tag is a negative distribution tag.

[0020] The default service container running on default server 103 interacts with the routing component deployed on routing system 102, specifically receiving service requests forwarded by the routing component deployed on routing system 102. Similarly, the honeypot container running on honeypot server 104 interacts with the routing component deployed on routing system 102, specifically receiving service requests forwarded by the routing component deployed on routing system 102. The default service container running on default server 103 and the honeypot container running on honeypot server 104 can interact, specifically performing data forwarding, etc.

[0021] This specification provides an example of a service request processing method:

[0022] The service request processing method provided in this embodiment can be applied to a routing component. First, it extracts the access path field from the network address information carried in the service request submitted through the target service. Second, it detects the distribution path field in the routing rules that matches the access path field and reads the distribution tag corresponding to the detected distribution path field. Finally, if the distribution tag is a negative distribution tag, it forwards the service request to the honeypot container corresponding to the distribution tag for request-response processing. In this way, it uses the routing rules to distribute requests, achieving convenience and effectiveness in request distribution. It also uses the honeypot container to enhance the security of the target service and reduce the probability of the target service being attacked by malicious attacks and causing failures.

[0023] Reference Figure 2 The service request processing method provided in this embodiment specifically includes steps S202 to S208.

[0024] Step S202: Obtain the service request submitted through the target service, and extract the access path field from the network address information carried by the service request.

[0025] The target service described in this embodiment includes resource services, such as resource transfer services, resource query services, etc.; the service request refers to a request submitted through the target service, such as a transfer request submitted through the transfer service, or a query request submitted through the resource query service; in addition, the target service can also be a subroutine or a mini-program, such as a resource subroutine or a resource mini-program, and the service request is a request submitted through the subroutine or mini-program, such as a transfer request submitted through the resource subroutine.

[0026] The network address information refers to the address information of the network accessed by the user. Optionally, the network address information includes network domain name information and / or network resource address; wherein, the network domain name information includes a network domain name, and the network resource address may be a URL (Uniform Resource Locator).

[0027] The access path field includes all or part of the field information extracted from the network address information. For example, if the network address information is http: / / a.com / b.html, the access path field extracted from the network address information can be a.com / b.html or b.html.

[0028] This embodiment can be applied to a routing component. Optionally, the routing component is configured within a routing system. The routing system is deployed upstream of the honeypot container's processing, and also upstream of the target service's default service container's processing. The routing system can be Kubernetes (K8s, a container orchestration engine), and the routing component can be an Istio component. Istio itself is a service mesh platform that provides protection, connectivity, and detection services, and it can run within the routing system.

[0029] In practical applications, the routing system can be deployed upstream of the default service container and honeypot container. This means the routing component is deployed upstream of the default service container and honeypot container, allowing it to intercept service requests submitted through the target service and thus obtain the service requests submitted through the target service, thereby enabling the distribution and processing of service requests. Furthermore, the routing component can be deployed on a second server running the honeypot container or on a first server running the default service container.

[0030] The default service container can run on a first server (first host); the honeypot container can run on a second server (second host). In this embodiment, a container refers to a runtime framework or engine provided to a server. By installing a container on the server, the target service can run within the container; that is, a honeypot container refers to a runtime framework or engine provided to the second server. Alternatively, the container in this embodiment can also be a server.

[0031] Step S204: Detect the distribution path field in the routing rules that matches the access path field, according to the field detection order.

[0032] The above steps involve obtaining service requests submitted through the target service and extracting the access path field from the network address information carried in the service request. In this step, to improve the convenience and efficiency of request distribution, routing rules can be introduced. The distribution path field that matches the access path field in the routing rules is detected according to the field detection order.

[0033] The field detection order described in this embodiment refers to the detection order of the distribution path field in the routing rule, starting from the access path field. The field detection order can be the top-down detection order for the routing rule, that is, the access path field is detected to see if it matches the distribution path field in the routing rule, until a distribution path field that matches the access path field is obtained.

[0034] The routing rule refers to the rule for distributing service requests. Optionally, the routing rule includes at least one distribution path field and at least one distribution tag corresponding to the distribution path field. The distribution path field refers to the path field for distributing service requests, such as a distribution path field of b.html or c.html. The distribution path field here is only illustrative; the distribution path field in actual applications is determined according to the actual scenario.

[0035] In one optional implementation of this embodiment, the routing rules are obtained in the following manner:

[0036] Retrieve the route files for each service configured by calling the file configuration interface;

[0037] The routing files of each service are assembled to obtain the routing rules.

[0038] The file configuration interface refers to the configuration interface set up by each service for configuring routing files; the file configuration interface can be an Istio interface; the routing file refers to the file used by each service to distribute service requests.

[0039] In addition, to improve the ease of detecting the distribution path field, the routing rules can also be set for each service, that is, the routing rules correspond to the target service.

[0040] In specific implementation, during the process of detecting the distribution path field in the routing rules that matches the access path field according to the field detection order, in an optional implementation method provided in this embodiment, the following operation is performed:

[0041] Check whether the access path field matches the first distribution path field in the routing rule. If yes, use the first distribution path field as the distribution path field. If no, check whether the access path field matches the target distribution path field in the path rule.

[0042] If yes, use the target distribution path field as the distribution path field obtained by the detection; otherwise, return to perform the operation of detecting whether the access path field matches the target distribution path field in the path rule.

[0043] Optionally, the target distribution path field includes the remaining distribution path fields in the routing rule, excluding the first distribution path field.

[0044] Furthermore, during the process of detecting the distribution path field in the routing rule that matches the access path field according to the field detection order, it is also possible to first detect whether the first path field in the access path field matches the service path field in the routing rule; if not, no processing is required; if so, the distribution path field under the service path field that matches the second path field in the access path field in the routing rule is detected according to the field detection order. Here, the first path field refers to the field that represents the service type of the target service accessed by the user.

[0045] Step S206: Read the distribution label corresponding to the distribution path field obtained by detection from the routing rule.

[0046] In the above steps, the distribution path field that matches the access path field in the routing rules is detected according to the field detection order. In this step, in order to distribute service requests in a targeted manner, the distribution tag corresponding to the detected distribution path field is read from the routing rules.

[0047] The distribution tag described in this embodiment includes a container tag identifier that marks the distribution of service requests. For example, the distribution tag records 'b', which represents the container identifier 'b'.

[0048] For example, if the distribution path field is b.html, the distribution tag corresponding to the distribution path field b.html obtained from the detection in the routing rule is b.

[0049] In specific implementation, after reading the distribution tag corresponding to the detected distribution path field in the routing rules and executing it, this embodiment provides an optional implementation method that also performs the following operations:

[0050] If the distribution tag is a positive distribution tag, the service request is forwarded to the default service container corresponding to the distribution tag to determine the service action corresponding to the service request and execute the service action.

[0051] The forward distribution label described in this embodiment includes a distribution label that forwards service requests to the default service container. For example, if the distribution label records 'b', it means that the service request is forwarded to the default service container corresponding to 'b'. In this case, the distribution label is a forward distribution label. The default service container corresponding to 'b' is only illustrative. In actual applications, the container identifier of the default service container of the target service is determined according to the actual scenario.

[0052] The default service container refers to the service container that performs default response processing for service requests; the service action includes response actions that process service requests, such as a transfer request, in which case the service action is a transfer processing action.

[0053] Step S208: If the distribution tag is a negative distribution tag, the service request is forwarded to the honeypot container corresponding to the distribution tag for request response processing.

[0054] The above-mentioned process reads the distribution tag corresponding to the distribution path field obtained from the detection in the routing rules. After that, if the distribution tag is a positive distribution tag, the service request is forwarded to the default service container corresponding to the distribution tag to determine the service action corresponding to the service request and execute the service action. In this step, if the distribution tag is a negative distribution tag, the service request is forwarded to the honeypot container corresponding to the distribution tag for request and response processing.

[0055] The negative distribution label described in this embodiment includes a distribution label that forwards a service request to a honeypot container. For example, if the distribution label records the honeypot container corresponding to 'c', it means that the service request is forwarded to the honeypot container corresponding to 'c'. In this case, the distribution label is a negative distribution label. Here, the honeypot container corresponding to 'c' is just an illustration. In actual applications, the container identifier of the honeypot container of the target service is determined according to the actual scenario.

[0056] The honeypot container includes a container containing vulnerability information used to deceive attackers. In practical applications, honeypot technology refers to techniques that deceive attackers by deploying decoy hosts, network services, or network information to lure them into attacking. This allows for the capture and analysis of attack behavior, revealing the tools and methods used by the attacker and enabling defenders to understand the security threats they face. Optionally, the honeypot container is obtained by mirroring the configuration information of the default service container of the target service and then filling it with anomaly information based on the mirroring results.

[0057] The image processing includes copying the configuration information of the default service container and generating an intermediate honeypot container based on the copied configuration information. The intermediate honeypot container can be populated with anomaly information to obtain the honeypot container. The anomaly information includes decoy information used to lure attackers; optionally, the anomaly information is determined based on the target service's preferred access information and / or the target service's available item information.

[0058] In practical applications, a single honeypot container can be set up, or corresponding honeypot containers can be set up for each service. Optionally, the honeypot containers are set based on the service type of the target service. The number of honeypot containers can also be determined based on the service request volume of each service containing the target service, and the service request volume of each service can be directly proportional to the number of honeypot containers. The service request volume of each service includes the total number of service requests for each service. For example, if there are target service 1 and target service 2, the number of honeypot containers is determined based on the total number of service requests for target service 1 and target service 2.

[0059] In practice, when the distribution tag is a negative distribution tag, it means that the service request is an abnormal service request. In this case, the service request is forwarded to the honeypot container corresponding to the distribution tag to avoid the abnormal service request directly accessing the default service container and causing a security threat to the default service container.

[0060] In the specific execution process, in order to improve the authenticity of the honeypot container and prevent attackers from discovering it too early, during the request-response processing of the honeypot container, a service success message generated based on the service request and / or the obtained request feedback information can be returned to the routing component. In one optional implementation of this embodiment, the request-response processing includes:

[0061] Generate a service success message and / or obtain request feedback information based on the service request;

[0062] Return the service success message and / or the request feedback information to the routing component.

[0063] The service success message includes a message indicating that the service request has been successfully processed. For example, if the service request is a transfer request, a transfer success message is generated based on the transfer request. The request feedback information includes feedback information obtained after responding to the service request. For example, if the service request is a query request, the query result obtained based on the query request is the request feedback information.

[0064] In practical applications, the default service container and / or honeypot container of the target service may expand or shrink. In order to promptly detect the expansion or shrinkage of the default service container and / or honeypot container and enable timely updates to routing rules, in an optional implementation of this embodiment, the following operations are also performed:

[0065] If an update instruction for the default service container and / or honeypot container of the target service is detected, a target distribution tag is generated based on the container identifier carried in the update instruction;

[0066] The routing rules are updated based on the target distribution label.

[0067] In addition, when the container is scaling up or down, the following operations can also be performed: if a capacity update instruction for the target service container and / or the target honeypot container is detected, a target service path field is generated based on the service identifier carried in the capacity update instruction, and the routing rules are updated according to the target service path field.

[0068] In specific implementation, in order to increase the sweetness and interactivity of the honeypot container, lure attackers to launch attacks, and prompt the target service to collect the attackers' attack behavior, in an optional implementation of this embodiment, the following operations are also performed:

[0069] Obtain available project information of the default service container of the target service, and obtain abnormal access information of the honeypot container;

[0070] Based on the abnormal access information, target project information is determined from the available project information, and an abnormal access entry is deployed in the target service based on the target project information, and the abnormal access entry is bound to the honeypot container.

[0071] The available project information includes idle project information of the default service container, such as inter-bank transfer projects and points redemption projects in the transfer service. The abnormal access information includes preference access information for the honeypot container.

[0072] For example, the available project information of the default service container of the transfer service includes interbank transfer projects and points redemption projects. If the honeypot container's preferred access information is points redemption projects, then the target project information will be determined as points redemption projects. Based on the points redemption projects, an abnormal access entry point will be deployed in the transfer service, and the abnormal access entry point will be bound to the honeypot container to increase the abnormal access volume of the honeypot container.

[0073] In practical applications, abnormal behavior information corresponding to submitted service requests can be collected, and abnormal access intents can be identified based on the abnormal behavior information. This allows for the patching of vulnerabilities in the default service container based on the abnormal access intent, thereby improving the security of the default service container. In one optional implementation of this embodiment, when the distribution tag is a negative distribution tag, after forwarding the service request to the honeypot container corresponding to the distribution tag for request-response processing, the following operations are also performed:

[0074] Obtain the abnormal behavior information corresponding to the service request;

[0075] Based on the abnormal behavior information, an abnormal access intent is obtained through intent recognition. The abnormal behavior information and the abnormal access intent are then sent to the default service container of the target service to update the target service.

[0076] Furthermore, when the distribution tag is a negative distribution tag, after forwarding the service request to the honeypot container corresponding to the distribution tag for request and response processing, the abnormal behavior information corresponding to the service request can also be obtained. Based on the abnormal behavior information, intent recognition is performed to obtain the abnormal access intent, and the abnormal behavior information or abnormal access intent is sent to the default service container of the target service to update the target service.

[0077] In practical application scenarios, in order to ensure the security of the target service and prevent system paralysis due to malicious attacks, the service access permissions of abnormal users can be revoked. In an optional implementation method provided in this embodiment, the following operations are also performed:

[0078] Identify users who have abnormal access based on the abnormal access information of the target service;

[0079] Revoke the service access permissions of the user who made the abnormal access to the target service.

[0080] In addition, after identifying abnormal access users based on abnormal access information of the target service, the access permissions of the abnormal access users to the access items corresponding to the abnormal access information can be revoked; the credit level of the abnormal access users in the target service can also be downgraded; a credit task can be created for the abnormal access users and sent to them; after the triggering instruction of the credit task is detected, the credit task can be activated for the abnormal access users; and after the credit task is detected and completed, the credit of the abnormal access users can be upgraded.

[0081] It should be added that step S208 can be replaced by forwarding the service request to the default service container corresponding to the distribution tag when the distribution tag is a positive distribution tag, in order to determine the service action corresponding to the service request and execute the service action, and forming a new implementation method with other processing steps provided in this embodiment;

[0082] Alternatively, it can be replaced by forwarding the service request to the service container corresponding to the distribution tag to perform request-response processing on the service request, and forming a new implementation method with other processing steps provided in this embodiment.

[0083] In summary, this embodiment provides one or more service request processing methods. First, it obtains the service request submitted through the target service and extracts the access path field from the network address information carried in the service request. Second, it detects the distribution path field in the routing rules that matches the access path field according to the field detection order. It reads the distribution tag corresponding to the detected distribution path field from the routing rules. If the distribution tag is a positive distribution tag, it forwards the service request to the default service container corresponding to the distribution tag to determine the service action corresponding to the service request and executes the service action. If the distribution tag is a negative distribution tag, it forwards the service request to the honeypot container corresponding to the distribution tag for request response processing. In this way, it uses the routing rules to distribute requests, achieving convenience and effectiveness in request distribution. It also uses the honeypot container to enhance the security protection of the target service and prevent the target service from being maliciously attacked and causing failure.

[0084] The following description uses the application of a service request processing method provided in this embodiment in a resource service scenario as an example to further illustrate the service request processing method provided in this embodiment. (See also...) Figure 3 The service request processing method applied to resource service scenarios includes the following steps.

[0085] Step S302: Obtain the service request submitted through the resource service, and extract the access path field from the network domain name information carried in the service request.

[0086] Step S304: Check whether the access path field matches the first distribution path field in the routing rule;

[0087] If so, use the first distribution path field as the distribution path field obtained by detection, and execute steps S308 to S314;

[0088] If not, proceed to step S306.

[0089] Step S306: Check whether the access path field matches the target distribution path field in the path rule;

[0090] If so, use the target distribution path field as the distribution path field obtained by detection, and execute steps S308 to S314;

[0091] If not, return to step S306.

[0092] Step S308: Read the distribution label corresponding to the distribution path field obtained by detection in the routing rules.

[0093] Step S310: If the distribution tag is a negative distribution tag, forward the service request to the honeypot container corresponding to the distribution tag for request response processing.

[0094] Step S312: If an update instruction for a honeypot container for a resource service is detected, a target distribution tag is generated based on the container identifier carried in the update instruction.

[0095] Step S314: Update the routing rules based on the target distribution label.

[0096] It should be noted that step S310 above can be replaced by forwarding the service request to the default service container corresponding to the distribution tag when the distribution tag is a positive distribution tag, in order to determine the service action corresponding to the service request and execute the service action, and forming a new implementation method with other processing steps provided in this embodiment.

[0097] It should be added that the service request processing method in the asset service scenario of this embodiment can be applied to the Istio component.

[0098] This specification provides an embodiment of a service request processing device as follows:

[0099] In the above embodiments, a service request processing method is provided, and correspondingly, a service request processing apparatus is also provided, which will be described below with reference to the accompanying drawings.

[0100] Reference Figure 4 This illustration shows a schematic diagram of an embodiment of a service request processing device provided in this embodiment.

[0101] Since the apparatus embodiments correspond to the method embodiments, the descriptions are relatively simple. For relevant parts, please refer to the corresponding descriptions of the method embodiments provided above. The apparatus embodiments described below are merely illustrative.

[0102] This embodiment provides a service request processing device that runs on a routing component. The device includes:

[0103] The field extraction module 402 is configured to obtain the service request submitted through the target service and extract the access path field from the network address information carried by the service request.

[0104] The field detection module 404 is configured to detect, in the order of field detection, the distribution path field in the routing rules that matches the access path field;

[0105] The tag reading module 406 is configured to read the distribution tag corresponding to the detected distribution path field in the routing rule;

[0106] The request forwarding module 408 is configured to forward the service request to the honeypot container corresponding to the distribution tag for request response processing when the distribution tag is a negative distribution tag.

[0107] This specification provides an example of a service request processing device as follows:

[0108] Corresponding to the service request processing method described above, based on the same technical concept, one or more embodiments of this specification also provide a service request processing device for executing the service request processing method provided above. Figure 5 This is a schematic diagram of the structure of a service request processing device provided for one or more embodiments of this specification.

[0109] This embodiment provides a service request processing device, including:

[0110] like Figure 5As shown, the service request processing device can vary considerably due to differences in configuration or performance. It may include one or more processors 501 and memory 502, where one or more application programs or data may be stored. The memory 502 may be temporary or persistent storage. The application programs stored in the memory 502 may include one or more modules (not shown), each module including a series of computer-executable instructions from the service request processing device. Furthermore, the processor 501 may be configured to communicate with the memory 502 and execute the series of computer-executable instructions in the memory 502 on the service request processing device. The service request processing device may also include one or more power supplies 503, one or more wired or wireless network interfaces 504, one or more input / output interfaces 505, one or more keyboards 506, etc.

[0111] In one specific embodiment, the service request processing device includes a memory and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs may include one or more modules, and each module may include a series of computer-executable instructions for the service request processing device, and is configured to be executed by one or more processors. The one or more programs include computer-executable instructions for performing the following:

[0112] Obtain the service request submitted through the target service, and extract the access path field from the network address information carried by the service request;

[0113] According to the field detection order, detect the distribution path field in the routing rules that matches the access path field;

[0114] Read the distribution tag corresponding to the detected distribution path field from the routing rule;

[0115] If the distribution tag is a negative distribution tag, the service request is forwarded to the honeypot container corresponding to the distribution tag for request response processing.

[0116] This specification provides an example of a storage medium as follows:

[0117] Corresponding to the service request processing method described above, based on the same technical concept, one or more embodiments of this specification also provide a storage medium.

[0118] The storage medium provided in this embodiment is used to store computer-executable instructions, which, when executed by a processor, implement the following process:

[0119] Obtain the service request submitted through the target service, and extract the access path field from the network address information carried by the service request;

[0120] According to the field detection order, detect the distribution path field in the routing rules that matches the access path field;

[0121] Read the distribution tag corresponding to the detected distribution path field from the routing rule;

[0122] If the distribution tag is a negative distribution tag, the service request is forwarded to the honeypot container corresponding to the distribution tag for request response processing.

[0123] It should be noted that the embodiments concerning storage media and the embodiments concerning service request processing methods in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding methods described above, and repeated details will not be repeated.

[0124] The various embodiments in this specification are described in a progressive manner. For the same or similar parts between the various embodiments, please refer to each other. Each embodiment focuses on describing the differences from other embodiments. For example, the device embodiment, equipment embodiment, and storage medium embodiment are all similar to the method embodiment, so the description is relatively simple. For reading the relevant content of the device embodiment, equipment embodiment, and storage medium embodiment, please refer to the description of the method embodiment.

[0125] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0126] In the 1930s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many improvements to the methodology today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that an improvement to the methodology cannot be implemented using a hardware physical module. For example, a Programmable Logic Device (PLD) (e.g., a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program a digital system themselves to "integrate" it onto a PLD, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0127] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0128] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0129] For ease of description, the above apparatus is described by dividing it into various functional units. Of course, when implementing the embodiments of this specification, the functions of each unit can be implemented in one or more software and / or hardware.

[0130] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this specification may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0131] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0132] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0133] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0134] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0135] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0136] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0137] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0138] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0139] The above description is merely an embodiment of this document and is not intended to limit the scope of this document. Various modifications and variations can be made to this document by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this document should be included within the scope of the claims of this document.

Claims

1. A service request processing method, applied to a routing component, the method comprising: Obtain the service request submitted through the target service, and extract the access path field from the network address information carried by the service request; According to the field detection order, detect the distribution path field in the routing rules that matches the access path field; Read the distribution tag corresponding to the detected distribution path field from the routing rule; When the distribution tag is a negative distribution tag, the service request is determined to be an abnormal service request, and the abnormal service request is forwarded to the honeypot container corresponding to the distribution tag for request response processing, so as to avoid the abnormal service request directly accessing the default service container; the honeypot container is bound to the abnormal access entry deployed in the target service based on the target project information, and the target project information is determined from the available project information of the default service container of the target service based on the abnormal access information of the honeypot container.

2. The service request processing method according to claim 1, wherein the routing component is configured in the routing system; the routing system is deployed upstream of the honeypot container in the processing.

3. The service request processing method according to claim 1, wherein detecting the distribution path field in the routing rule that matches the access path field according to the field detection order includes: Check whether the access path field matches the first distribution path field in the routing rule; if not, check whether the access path field matches the target distribution path field in the routing rule. If so, the target distribution path field is used as the distribution path field obtained by the detection; If not, return to the operation of checking whether the access path field matches the target distribution path field in the routing rule.

4. The service request processing method according to claim 1 further includes: If an update instruction for the default service container and / or honeypot container of the target service is detected, a target distribution tag is generated based on the container identifier carried in the update instruction; The routing rules are updated based on the target distribution label.

5. The service request processing method according to claim 1, wherein the routing rules are obtained in the following manner: Retrieve the route files for each service configured by calling the file configuration interface; The routing files of each service are assembled to obtain the routing rules.

6. The service request processing method according to claim 1, wherein the honeypot container is obtained by performing image processing based on the configuration information of the default service container of the target service, and filling in exception information based on the image processing result.

7. The service request processing method according to claim 6, wherein the honeypot container is configured based on the service type of the target service; The anomaly information is determined based on the target service's preferred access information and / or the target service's available item information.

8. The service request processing method according to claim 1, wherein the request response processing includes: Generate a service success message and / or obtain request feedback information based on the service request; Return the service success message and / or the request feedback information to the routing component.

9. The service request processing method according to claim 1, after the step of reading the distribution tag corresponding to the detected distribution path field in the routing rule is executed, it further includes: If the distribution tag is a positive distribution tag, the service request is forwarded to the default service container corresponding to the distribution tag to determine the service action corresponding to the service request and execute the service action.

10. The service request processing method according to claim 1, wherein the network address information includes network domain name information and / or network resource address.

11. The service request processing method according to claim 1, further comprising, after the step of determining that the service request is an abnormal service request and forwarding the abnormal service request to the honeypot container corresponding to the distribution tag for request response processing when the distribution tag is a negative distribution tag: Obtain the abnormal behavior information corresponding to the service request; Based on the abnormal behavior information, an abnormal access intent is obtained through intent recognition. The abnormal behavior information and the abnormal access intent are then sent to the default service container of the target service to update the target service.

12. The service request processing method according to claim 1, further comprising: Identify users who have abnormal access based on the abnormal access information of the target service; Revoke the service access permissions of the user who made the abnormal access to the target service.

13. A service request processing apparatus, operating in a routing component, the apparatus comprising: The field extraction module is configured to obtain the service request submitted through the target service and extract the access path field from the network address information carried by the service request. The field detection module is configured to detect, in the order of field detection, the distribution path field in the routing rules that matches the access path field; The tag reading module is configured to read the distribution tag corresponding to the detected distribution path field in the routing rule; The request forwarding module is configured to determine that the service request is an abnormal service request when the distribution tag is a negative distribution tag, and forward the abnormal service request to the honeypot container corresponding to the distribution tag for request response processing, so as to avoid the abnormal service request directly accessing the default service container; the honeypot container is bound to an abnormal access entry deployed in the target service based on the target project information, and the target project information is determined from the available project information of the default service container of the target service based on the abnormal access information of the honeypot container.

14. A service request processing device, comprising: processor; And, a memory configured to store computer-executable instructions, which, when executed, cause the processor to: Obtain the service request submitted through the target service, and extract the access path field from the network address information carried by the service request; According to the field detection order, detect the distribution path field in the routing rules that matches the access path field; Read the distribution tag corresponding to the detected distribution path field from the routing rule; When the distribution tag is a negative distribution tag, the service request is determined to be an abnormal service request, and the abnormal service request is forwarded to the honeypot container corresponding to the distribution tag for request response processing, so as to avoid the abnormal service request directly accessing the default service container; the honeypot container is bound to the abnormal access entry deployed in the target service based on the target project information, and the target project information is determined from the available project information of the default service container of the target service based on the abnormal access information of the honeypot container.

15. A storage medium for storing computer-executable instructions, which, when executed by a processor, perform the following process: Obtain the service request submitted through the target service, and extract the access path field from the network address information carried by the service request; According to the field detection order, detect the distribution path field in the routing rules that matches the access path field; Read the distribution tag corresponding to the detected distribution path field from the routing rule; When the distribution tag is a negative distribution tag, the service request is determined to be an abnormal service request, and the abnormal service request is forwarded to the honeypot container corresponding to the distribution tag for request response processing, so as to avoid the abnormal service request directly accessing the default service container; the honeypot container is bound to the abnormal access entry deployed in the target service based on the target project information, and the target project information is determined from the available project information of the default service container of the target service based on the abnormal access information of the honeypot container.

Images