Access control methods and systems for network services

Abstract

This application discloses an access control method and system for network services. The method is applied to a network service provider, which deploys an auxiliary server, a target server, and a firewall. The target server runs a target service. The method includes: the auxiliary server receiving a user request; the request being adapted to a predetermined message format of the auxiliary server, the content including combined information and a checksum; the combined information including an access identifier and firewall configuration commands; the auxiliary server locating the associated target server based on the access identifier and forwarding the combined information and checksum to the target server; the target server verifying the combined information and checksum; if the verification result is successful, the target server, based on the configuration commands, notifying the firewall to adjust firewall settings regarding user access to the target service. This method can improve the security and universality of network services and enhance the user's access experience. This application can be widely applied in the field of network service technology.

Description

Technical Field

[0001] This application relates to the field of network service technology, and in particular to an access control method and system for network services. Background Technology

[0002] On the Internet, almost all network service providers have suffered greatly from network snooping (such as port scanning) and network attacks (such as denial of service, especially distributed denial of service). The basic measure to combat network snooping and attacks is to use various firewalls, which protect network applications by filtering the source IP addresses of network requests. Enabling a firewall is only a passive defense measure: because it's impossible to predict whether every source IP address is legitimate or malicious, firewall administrators usually only configure the firewall during or after a network snooping or attack, making its effectiveness relatively delayed and limited. Another strategy is to preemptively apply indiscriminate rate limiting to services. This way, even if the origin of malicious users cannot be predicted, the damage they can cause will have an upper limit; however, this also affects legitimate users, such as causing network slowdowns and congestion.

[0003] In related fields, some technical solutions "actively" hide network services (called target services) from their host servers (called target servers) through default firewall policies. Obviously, when such network services disappear from the internet and become inaccessible, they are naturally protected from network snooping or attacks. For authorized users, the target server instructs the firewall to allow access only to them and only to them when certain conditions are triggered. For example, a user can send messages to the target server in a specific form (i.e., a coded message). When these messages match the pre-configured rules of the network service provider, the firewall, which is always disabled by default, is opened for the user. However, this implementation is vulnerable to replay attacks, compromising the security of the network service. Frequent changes to the coded message can be inconvenient for users, and over time, the coded messages become increasingly complex and may even become exhausted. Summary of the Invention

[0004] The purpose of this application is to at least partially solve one of the technical problems existing in the relevant field.

[0005] Therefore, one objective of the embodiments of this application is to provide an access control method and system for network services.

[0006] To achieve the above-mentioned technical objectives, the technical solutions adopted in the embodiments of this application include:

[0007] On one hand, embodiments of this application provide an access control method for a network service, applied to a network service provider, wherein the network service provider deploys an auxiliary server, a target server, and a firewall, and a target service runs on the target server, the method comprising:

[0008] The auxiliary server receives a user's request; wherein the request is adapted to a predetermined message format of the auxiliary server, and the content of the request includes combined information and a checksum generated based on the combined information. The combined information includes an access identifier and a setting command from the firewall regarding the user's access to the target service, wherein the setting command is an enable command or a disable command.

[0009] The auxiliary server locates the associated target server based on the access identifier and forwards the combined information and the verification code to the target server.

[0010] The target server verifies the combined information and the checksum;

[0011] If the verification result is successful, the target server, based on the setting command, notifies the firewall to adjust the firewall settings regarding the user's access to the target service.

[0012] In addition, the network service access control method according to the above embodiments of this application may also have the following additional technical features:

[0013] Furthermore, in one embodiment of this application, the network service provider receives the user's registration request for a target service under the first server, determines the authentication credentials used by the user to access the target service, and assigns an access identifier to the access relationship between the user and the target service; wherein, the first server is any of the target servers;

[0014] The network service provider registers and maintains the association between the access identifier and the user, the target service, and the authentication credentials used by the user to access the target service.

[0015] Furthermore, in one embodiment of this application, the verification code is generated through the following steps:

[0016] The user obtains the current first timestamp;

[0017] The user calculates the verification code using a predetermined verification algorithm, with the authentication credential as the first input and the access identifier, the first timestamp, and the setting command as the second input.

[0018] Furthermore, in one embodiment of this application, the target server verifies the combined information and the checksum, including:

[0019] The target server obtains the current second timestamp;

[0020] Based on the second timestamp, the target server infers at least one of the sending timestamps used by the user when generating the verification code within a preset time difference.

[0021] The target server obtains the authentication credentials corresponding to the user based on the access identifier.

[0022] Using a predetermined verification algorithm, the target server performs verification based on the authentication credential, the combined information, the sending timestamp, and the verification code to obtain the verification result.

[0023] Furthermore, in one embodiment of this application, the first timing granularity of the first timestamp is different from the second timing granularity of the second timestamp; the target server, based on the second timestamp, within a preset error range, infers at least one sending timestamp used by the user when generating the verification code, including:

[0024] The target server performs a conversion process on the second timestamp according to the first timing granularity of the first timestamp to obtain a third timestamp; wherein, the timing granularity of the third timestamp is the same as that of the first timing granularity;

[0025] The target server uses the third timestamp as the sending timestamp, or uses the timestamps of the N nearest first timing granularities of the third timestamp as the sending timestamp; where N is a positive integer.

[0026] Furthermore, in one embodiment of this application, the step of the target server performing verification based on the authentication credential, the combined information, the sending timestamp, and the checksum using a predetermined verification algorithm to obtain a verification result includes:

[0027] Using a predetermined verification algorithm, the target server performs verification based on the authentication credential, the combined information, each of the sending timestamps, and the verification code to obtain a sub-verification result corresponding to each of the sending timestamps;

[0028] If any of the sub-verification results corresponding to the sending timestamp is passed, the target server determines that the verification result is passed;

[0029] If all the sub-verification results corresponding to the sending timestamps are unsuccessful, the target server determines that the verification result is unsuccessful.

[0030] Furthermore, in one embodiment of this application, the combined information further includes a first timestamp; the target server verifies the combined information and the checksum, including:

[0031] The target server obtains the current second timestamp;

[0032] The target server calculates the time difference between the second timestamp and the first timestamp;

[0033] If the absolute value of the time difference is greater than the preset time difference, the target server determines that the verification result is unsuccessful.

[0034] Furthermore, in one embodiment of this application, the verification of the combined information and the check code by the target server further includes:

[0035] If the absolute value of the time difference is less than or equal to the preset time difference, the target server obtains the authentication credential corresponding to the user based on the access identifier.

[0036] Using a predetermined verification algorithm, the target server performs verification based on the authentication credential, the combined information, and the verification code to obtain a verification result.

[0037] On the other hand, embodiments of this application provide another access control method for network services, applied to a network service provider, wherein the network service provider deploys an auxiliary server, a target server, and a firewall, and a target service runs on the target server, the method comprising:

[0038] The auxiliary server receives a user's request; wherein the request is adapted to a predetermined message format of the auxiliary server, and the content of the request includes combined information and a checksum generated based on the combined information. The combined information includes an access identifier and a setting command from the firewall regarding the user's access to the target service, wherein the setting command is an enable command or a disable command.

[0039] The auxiliary server locates the associated target server based on the access identifier;

[0040] If an associated target server is found, the auxiliary server verifies the combined information and the checksum.

[0041] If the verification result is successful, the auxiliary server, based on the setting command, notifies the firewall to adjust the firewall settings regarding the user's access to the target service.

[0042] On the other hand, embodiments of this application provide an access control system for network services, including: an auxiliary server and a target server;

[0043] The auxiliary server is used to receive user requests; wherein the request is adapted to a predetermined message format of the auxiliary server, and the content of the request includes combined information and a check code generated based on the combined information. The combined information includes an access identifier and a setting command from the firewall regarding the user's access to the target service, wherein the setting command is an enable command or a disable command.

[0044] The auxiliary server is used to locate the associated target server based on the access identifier;

[0045] The auxiliary server is also used to forward the combined information and the verification code to the target server or to verify the combined information and the verification code, and when the verification result is successful, to notify the firewall to adjust the firewall settings regarding the user's access to the target service based on the setting command;

[0046] The target server is used to verify the combined information and the verification code, and when the verification result is successful, it notifies the firewall to adjust the firewall settings regarding the user's access to the target service based on the setting command.

[0047] The advantages and beneficial effects of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application:

[0048] This application discloses an access control method and system for network services, applied to a network service provider. The network service provider deploys an auxiliary server, a target server, and a firewall. A target service runs on the target server. The method includes: the auxiliary server receiving a user request; wherein the request is adapted to a predetermined message format of the auxiliary server, and the request content includes combined information and a checksum generated based on the combined information. The combined information includes an access identifier and a setting command from the firewall regarding the user's access to the target service, the setting command being either an enable or disable command; the auxiliary server locates the associated target server based on the access identifier and forwards the combined information and the checksum to the target server; the target server verifies the combined information and the checksum; if the verification result is successful, the target server, based on the setting command, notifies the firewall to adjust the firewall settings regarding the user's access to the target service. This method can improve the security and versatility of network services and enhance the user's access experience. Attached Figure Description

[0049] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the following description is provided with accompanying drawings of the relevant technical solutions in the embodiments of this application or the prior art. It should be understood that the accompanying drawings described below are only for the purpose of clearly illustrating some embodiments of the technical solutions in this application. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.

[0050] Figure 1 A schematic diagram illustrating the setup of a firewall in a related field;

[0051] Figure 2 This is a flowchart of an access control method for a network service provided in an embodiment of this application;

[0052] Figure 3 This is a schematic diagram illustrating an implementation scenario of an access control method for a network service provided in this application embodiment;

[0053] Figure 4 This is a schematic diagram of a process for generating a verification code provided in an embodiment of this application;

[0054] Figure 5 This is a schematic diagram illustrating the process by which a target server verifies combined information and a checksum, as provided in an embodiment of this application.

[0055] Figure 6 This is a schematic diagram illustrating a process by which a target server verifies data based on authentication credentials, combined information, sending timestamps, and verification codes, as provided in an embodiment of this application.

[0056] Figure 7 This is a schematic diagram illustrating the process by which a target server verifies combined information and a checksum, as provided in another embodiment of this application.

[0057] Figure 8 A flowchart illustrating another network service access control method provided in this application embodiment;

[0058] Figure 9 This is a schematic diagram illustrating the specific implementation process of an access control method for a network service provided in this application embodiment;

[0059] Figure 10 This is a schematic diagram of an access control system for a network service provided in an embodiment of this application. Detailed Implementation

[0060] The present application will be further described below with reference to the accompanying drawings and specific embodiments. The described embodiments should not be considered as limitations on the present application, and all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of the present application.

[0061] In the following description, reference is made to “some embodiments”, which describes a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0062] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0063] 1) A network service is an application (also called a daemon) in a computer network such as the Internet, used to meet users' various computing and communication needs such as data storage, information retrieval and browsing, and remote login to hosts.

[0064] 2) Port: An integer with a value greater than or equal to 1 and less than or equal to 65535, is a software identifier. A network server (identified by a network address such as IPv4 or IPv6) can provide multiple network services simultaneously. These services are distinguished by a protocol (either connection-oriented TCP or connectionless UDP) plus a port number. In other words, network services are "bound" to protocols and port numbers.

[0065] 3) Message Authentication Code (MAC): A type of cryptographic algorithm used by both the sender and receiver to verify the integrity of data, such as those described in the national standard GB / T 15852. Before using a message authentication code mechanism, the sender and receiver need to agree on a shared authentication credential, typically a key.

[0066] On the Internet, almost all network service providers have suffered greatly from network snooping (such as port scanning) and network attacks (such as denial of service, especially distributed denial of service). The basic measure to combat network snooping and attacks is to use various firewalls, which protect network applications by filtering information such as the source IP address of the network request. Below are two typical firewall strategies, used together to filter incoming network traffic, protecting TCP port x on server X, ensuring it is open only to source IP address A and hidden from the rest of the Internet:

[0067] {Source IP address A, Protocol TCP, Destination IP address X, Destination port x} => Receive

[0068] {Source IP address is arbitrary, destination IP address is X} => Discard

[0069] For example, please refer to Figure 1 , Figure 1 A schematic diagram of a firewall setup in a related field is shown. Figure 1 In this scenario, the firewall's effect is that visitors other than user A, such as user B, will perceive that server X does not exist on the internet. Since B cannot find X, they are naturally unable to probe or attack it. If, in addition to user A, authorized user C also needs access to the service, a separate allow policy needs to be added for C.

[0070] However, enabling a firewall is only a passive defense measure: since it's impossible to predict whether every source IP is legitimate or malicious, firewall administrators typically only configure the firewall during or after network probing and attacks occur, making its effectiveness relatively delayed and limited. Another strategy is to preemptively implement indiscriminate rate limiting. This way, even if the origin of malicious users is unpredictable, the damage they can cause will have an upper limit; however, legitimate users will also be affected, such as experiencing network slowdowns and congestion.

[0071] In related fields, some technical solutions "actively" hide network services (called target services) from their host servers (called target servers) through default firewall policies. Obviously, when such network services disappear from the internet and become inaccessible, they are naturally protected from network snooping or attacks. For authorized users, the target server instructs the firewall to allow access only to them and only to them when certain conditions are triggered. For example, a user can send messages to the target server in a specific format (i.e., a coded message), and when these messages match the pre-configured rules of the network service provider, the firewall, which is always disabled by default, is opened for the user.

[0072] For example, taking Linux and FreeBSD operating systems as examples, knockd is a special daemon process that listens for TCP / UDP protocol packets received from the network on its host. When these packets match the pre-configured rules of the network service operator in a specific event sequence, i.e., a knocking code (for example, three packets sequentially accessing the target server's TCP ports 7000, 8000, and 9000, even if these ports are not bound to any network service), knockd will call firewall commands accordingly to open the firewall, which is always closed by default, only to the source IP address that sent the correct knocking code (here, accessing predefined ports in a predefined order). In other words, knockd will dynamically enable a "hole-opening" policy on the firewall for the source IP address that "matches the code"; for other source IP addresses, the firewall remains closed, meaning the target service remains hidden. In addition, knockd can also automatically disable the opening policy through mechanisms such as time limits.

[0073] However, the above implementation method has some problems in application. For example, network attackers may listen in to discover the knocking signals sent by authorized users to the target server and then replay them. For instance, in the aforementioned embodiment where packets accessing predefined ports in a predefined order are used as knocking signals, after a network attacker listens to an authorized user's request, they also send packets to the target server's TCP ports 7000, 8000, and 9000 in sequence. They will then be considered an authorized user by knockd, potentially leading to brute-force attacks, denial-of-service attacks, and other malicious behaviors. To address this, the relevant mitigation measure is for the network service provider to pre-configure a long string of knocking signals for knockd. Each knocking signal is used only once and immediately discarded, replaced by the next signal (e.g., changing the predefined port access order to 7070, 8080, and 9090), and then by the next signal (e.g., changing the predefined port access order to 7777, 8888, and 9999), and so on. The drawbacks of this measure are also obvious: authorized users have to change their passwords every time, which is very inconvenient, and this long pre-configured string of passwords will eventually run out; when a website serves two or more authorized users simultaneously, conflicts will occur between users, as no one knows which password others have already used, so no one is sure which password to use next, resulting in the embarrassing situation of being unable to log in. In addition, for security control reasons, some enterprise networks or small ISPs have strict restrictions on outbound (upbound) traffic, only allowing access to the most commonly used external ports such as 22, 53, 80, 123, and 443, and disallowing access to non-standard ports such as 7000, 7070, and 7777.

[0074] In summary, it can be seen that existing technologies have drawbacks in terms of network service security and universality, which affects user experience.

[0075] In view of this, this application provides an access control method for a network service, applied to a network service provider. The network service provider deploys an auxiliary server, a target server, and a firewall. A target service runs on the target server. The method includes: the auxiliary server receiving a user's request; wherein the request is adapted to a predetermined message format of the auxiliary server, the request content includes combined information and a checksum generated based on the combined information, the combined information including an access identifier and a setting command from the firewall regarding the user's access to the target service, the setting command being an enable or disable command; the auxiliary server searching for an associated target server based on the access identifier and forwarding the combined information and the checksum to the target server; the target server verifying the combined information and the checksum; if the verification result is successful, the target server, based on the setting command, notifying the firewall to adjust the firewall settings regarding the user's access to the target service. This method can improve the security and versatility of network services and enhance the user's access experience.

[0076] Please refer to Figure 2 , Figure 2 This illustration shows a flowchart of an access control method for a network service provided in an embodiment of this application. The network service access control method provided in this embodiment is applied to a network service provider, which deploys an auxiliary server, a target server, and a firewall. The method includes at least the following steps:

[0077] Step 210: The auxiliary server receives a user's request; wherein the request is adapted to a predetermined message format of the auxiliary server, and the content of the request includes combined information and a checksum generated based on the combined information. The combined information includes an access identifier and a setting command from the firewall regarding the user's access to the target service, wherein the setting command is an enable command or a disable command.

[0078] Step 220: The auxiliary server locates the associated target server based on the access identifier and forwards the combined information and the verification code to the target server;

[0079] Step 230: The target server verifies the combined information and the verification code;

[0080] Step 240: If the verification result is successful, the target server, based on the setting command, notifies the firewall to adjust the firewall settings regarding the user's access to the target service.

[0081] In this embodiment, the network service provider may deploy an auxiliary server, a target server, and a firewall. A target service runs on the target server. This target service may be a network service accessible only to a small number of specific users (such as VIP users). The number of target services running on the target server can be one or more; this application does not limit the number. Similarly, auxiliary services run on the auxiliary server. These auxiliary services are services accessible to potential users (regardless of their location on the Internet, even in a strictly controlled corporate network or a small ISP). They can use common port numbers, and the number of auxiliary services running on the auxiliary server can also be one or more. It should be noted that in this embodiment, the auxiliary service may be a virtual service, meaning it does not actually provide a real service and may not even respond to requests (i.e., it is silent and invisible). In this embodiment, the firewall deployed by the network service provider is used to protect the target server. The firewall can allow or deny user access to the target service through appropriate settings. Of course, in some embodiments, the firewall can also be used to protect the auxiliary server; this application does not limit this.

[0082] In some embodiments, the target service and the auxiliary service can run on the same server; that is, the auxiliary server and the target server can be the same server. In other embodiments, the auxiliary server and the target server can be different servers, and there can be one or more auxiliary servers and target servers.

[0083] For example, please refer to Figure 3 , Figure 3 This illustration shows a schematic diagram of an implementation scenario for an access control method for a network service provided in an embodiment of this application. Figure 3 In this scenario, the network service provider can set up two secondary servers, DNS1.example.com and DNS2.example.com. The target server (SSH.example.com) has a firewall (which may or may not be located on the target server) that blocks external access to the target service by default, and the secondary servers also do not access the target service. However, the secondary servers maintain communication with the target server through a secure channel (such as a VPN) to forward knocking signals. Both the secondary and target servers can be physical machines or virtual machines. Both the secondary and target servers reside within the network service provider's autonomous system (example.com), and the secure channel between them is maintained by the network service provider. Users originating from outside this autonomous system can access the target server via a firewall, but a firewall may or may not be required between the user and the secondary servers.

[0084] For authorized users of the target server, they can send requests to the network service provider to adjust firewall settings for accessing the target service on the target server. Specifically, users can send requests to a secondary server whose message format is adapted to the secondary server's predefined message format. For example, the secondary server may run a DNS-adapted secondary service, and the requests received by the secondary server may default to the DNS request message format, such as including domain names in the format "knock code.example.com". Of course, it is understood that the actual predefined message format of the secondary server can be determined according to specific circumstances, and this application does not impose any restrictions on it.

[0085] The user-initiated request may include combined information and a verification code generated based on the combined information. The combined information may include an access identifier and a user-specified configuration command. The access identifier is an identifier assigned by the network service provider to the access relationship between an authorized user and a target service. The access identifier is used to register the "user-target service" access relationship, and its specific data content may include numbers or characters, which is not limited in this application. The configuration command in the combined information can be used to adjust the firewall settings of the target service accessed by the user. This target service is the target service associated with the access identifier. For example, if the currently authorized user wants the firewall to enable the target service for them, the configuration command can be a command to enable the target service; conversely, the configuration command can also be a command to disable the target service. In this application's embodiments, the specific content and form of the configuration command, as well as its meaning of enabling or disabling, are not limited. For example, in some embodiments, the configuration command may use 1 bit of data, such as 1 representing enable and 0 representing disable.

[0086] In this embodiment, the verification code can be generated based on combined information, such as through relevant cryptographic calculations. For example, in asymmetric cryptography, digital signatures can be used to generate the verification code; in symmetric cryptography, methods such as message authentication codes can be used to generate the verification code.

[0087] The auxiliary service can be nominal, meaning it doesn't actually provide any service. Upon receiving a user's request, the auxiliary server can directly extract the combined information and checksum from the request without responding. After obtaining the combined information and checksum, the auxiliary server can locate the associated target server based on the access identifier in the combined information. This access identifier registers the "user-target service" access relationship, and the location of the target server is clear. Therefore, the association between the access identifier and the target server can be clearly determined based on this relationship. If the associated target server is found, the auxiliary server can forward the combined information and checksum to that target server. Upon receiving the combined information and checksum, the target server can verify them and obtain the corresponding verification result. There are two types of verification results: pass and fail. When the verification result is pass, the user is determined to be an authorized user, and the firewall settings for the user's access to the target service can be adjusted according to the configuration command. Conversely, if the verification result is fail, the server can choose not to respond to the configuration command, i.e., discard the request.

[0088] It is understood that in this embodiment of the application, if the auxiliary server cannot find the target server associated with the access identifier after the user initiates a request, the request can be discarded and no further processing will be performed.

[0089] In some embodiments, the method in this application may further include a preparation phase, in which the user can register with the network service provider to determine the authorized user corresponding to each target service. In this phase, the user sends a registration request to the network service provider, which can be used to register the user's legal access rights to a specific target service. In this application embodiment, the target server where the user requests registration for legal access rights for the target service is located is denoted as the first server. The first server can be any target server, and the target service for which the user requests registration for legal access rights can be any target service on the first server.

[0090] After receiving a user's registration request for a target service under a first server, the network service provider can determine the authentication credentials used by the user to access the target service and assign an access identifier to the access relationship between the user and the target service. This authentication credentials can subsequently be used to verify the user's access rights to the target service. This application does not limit the specific source of the authentication credentials; for example, in some embodiments, they may be provided by the network service provider to the user, and in other embodiments, they may be selected by the user. This application does not impose any restrictions on this. The access identifier is used to identify a set of user-target service access relationships, and different access relationships correspond to different access identifiers. For example, for the same user, the access identifiers corresponding to their access relationships with different target services are different; for the same target service, the access identifiers corresponding to the access relationships between different users and that target service are also different.

[0091] In this embodiment, the network service provider can also register and maintain the association between the access identifier and the user, the target service, and the authentication credentials used by the user to access the target service. This facilitates subsequent determination of the target service or authentication credentials corresponding to the request based on the access identifier. Users can modify or reset the authentication credentials they use according to their actual needs. After the adjustment, the network service provider can update the association between the access identifier and the authentication credentials.

[0092] For example, when registering the aforementioned associations, network service providers can use the access identifier as the key and the user, target service, and authentication credential used by the user to access the target service as values ​​to establish key-value pairs to store their associations. For instance, in some embodiments, the user, target service, and authentication credential used by the user to access the target service can be used as a whole to register the aforementioned associations, with the corresponding key-value pair represented as (access identifier, (user, target service, authentication credential)). In some embodiments, the user, target service, and authentication credential used by the user to access the target service can each be used as a separate value to register the aforementioned associations, resulting in multiple key-value pairs, represented as (access identifier, user), (access identifier, target service), and (access identifier, authentication credential). Specifically, in this embodiment of the application, in order to facilitate quick verification of whether a user has registered the relevant access relationship during registration, the user and the target service as a whole can be used as a value, and the access identifier can be used as the key to construct a key-value pair. The authentication credential used by the user to access the target service can be used as another value, and the access identifier can be used as the key to construct another key-value pair. The resulting key-value pair is represented as (access identifier, (user, target service)) and (access identifier, authentication credential).

[0093] It should be noted that, in the embodiments of this application, the association relationship registered and maintained by the network service provider can be either stored by the network service provider on a dedicated registration server for querying by the auxiliary server or the target server, or it can be stored locally on the auxiliary server or the target server as needed. This application does not impose any restrictions on this.

[0094] Specifically, in some embodiments, reference is made to Figure 4 , Figure 4 This illustration shows a flowchart of a verification code generation process provided in an embodiment of this application. In this embodiment, when generating the verification code in a request, the user can obtain the current timestamp and record it as the first timestamp. Then, the user can calculate the corresponding verification code using a predetermined verification algorithm, with authentication credentials as one input (recorded as the first input) and access identifier, the first timestamp, and a setting command as another input (recorded as the second input). This application does not limit the type of verification algorithm used in this process. For example, a message authentication code can be used as the predetermined verification algorithm.

[0095] for Figure 4 The verification code generation process shown is referenced. Figure 5 , Figure 5 This illustration shows a flowchart of a target server verifying combined information and a checksum according to an embodiment of this application. In this embodiment, the combined information does not include timestamp-related content. When verifying the combined information and checksum, the target server can estimate the timestamp used by the user when generating the checksum by inference. It is easy to understand that after the user generates the checksum, the entire process of sending a request to the target server is relatively short. Therefore, the target server can infer the timestamp used by the user when generating the checksum based on the timestamp when it receives the request. In this embodiment, the timestamp when the target server receives the request is recorded as the second timestamp. The target server can determine the second timestamp by querying the current timestamp when it receives the request. Furthermore, the timestamp used by the target server to infer the user's use to generate the checksum is recorded as the sending timestamp.

[0096] In this embodiment, when the target server infers the sending timestamp, it can estimate the sending timestamp within a preset time difference based on the second timestamp. This preset time difference is used to limit a suitable time range; that is, the absolute value of the time difference between the selected sending timestamp and the second timestamp must be less than or equal to the preset time difference. For example, several timestamps before (or after) the second timestamp can be selected as the sending timestamp, meaning there can be multiple candidate sending timestamps. Of course, in some embodiments, a single sending timestamp can be inferred, and this application does not impose any restrictions on this.

[0097] It's easy to understand that, assuming the clocks of the target server and the user side are synchronized, the timestamp used by the user to actually generate the verification code (i.e., the first timestamp) will be slightly earlier than the second timestamp. Therefore, a timestamp before the second timestamp can be selected as the estimated sending timestamp. However, in other cases, the clocks of the target server and the user side may be out of sync, which can cause a misalignment between the first and second timestamps. For example, the first timestamp recorded by the user side may be later than the second timestamp recorded by the target server side. To accommodate these situations as much as possible, in this embodiment, a timestamp after the second timestamp can also be selected as the estimated sending timestamp. This application does not limit the specific number of estimated sending timestamps.

[0098] As described above, network service providers can pre-register the association between access identifiers and authentication credentials. Therefore, the target server can obtain the corresponding authentication credentials based on the access identifier. Then, the target server can verify the credentials, combined information, sending timestamp, and checksum to obtain the corresponding verification result.

[0099] Reference Figure 6 , Figure 6 This illustration shows a flowchart illustrating a process by which a target server verifies data based on authentication credentials, combined information, sending timestamps, and a checksum, according to an embodiment of this application. In this embodiment, the number of estimated sending timestamps can be multiple. Therefore, during verification by the target server, a predetermined verification algorithm can be used to verify each sending timestamp individually. That is, verification is performed based on authentication credentials, combined information, each sending timestamp, and a checksum, yielding a verification result corresponding to each sending timestamp. In this embodiment, this result can be recorded as a sub-verification result. If any sub-verification result corresponding to any sending timestamp passes, it indicates that the estimated sending timestamp is the same as the first timestamp, and the request is legitimate; the target server can determine that the verification result is passed. If all sub-verification results corresponding to sending timestamps fail, it is highly likely that the request is illegitimate; the target server can determine that the verification result is failed.

[0100] Of course, it is understandable that in this embodiment, when the target server actually performs verification, it can determine the verification result as passed and end the verification process when it determines that a certain sub-verification result is passed, without having to determine other sub-verification results. Moreover, in this embodiment, verifying requests based on timestamps can effectively resist replay attacks.

[0101] It should be noted that in some embodiments, the timing granularity of the timestamp used on the user side may differ from that used on the target server side, resulting in a first timing granularity for the first timestamp differing from a second timing granularity for the second timestamp. For example, the timing granularity of the timestamp used on the user side may be seconds, while the timing granularity used on the target server side may be milliseconds. In this case, when the target server infers the sending timestamp, it can first convert the timing granularity of the second timestamp to the same timetamp data as the timing granularity used for the first timestamp.

[0102] In this embodiment, the timing granularity of the timestamp used by the user (i.e., the timing granularity of the first timestamp) is recorded as the first timing granularity, and the timing granularity of the timestamp used by the target server (i.e., the timing granularity of the second timestamp) is recorded as the second timing granularity. When estimating the sending timestamp, the second timestamp can be converted according to the first timing granularity to obtain the third timestamp. Thus, the timing granularity of the obtained third timestamp is the same as that of the first timing granularity. Then, the target server can determine the sending timestamp under the first timing granularity based on the third timestamp. For example, in some embodiments, the third timestamp can be directly used as the sending timestamp; in some embodiments, the N timestamps of the first timing granularity adjacent to the third timestamp can be used as the sending timestamps, where N is a positive integer, and its size can be flexibly adjusted according to actual needs. This application does not impose any restrictions on this.

[0103] In this embodiment of the application, in the aforementioned example, the combined information received by the target server does not include a first timestamp, and the request can be verified by inferring the sending timestamp. In other embodiments, the combined information sent by the user may also include a first timestamp. In this case, the verification code can be generated based on the combined information containing the first timestamp. With this implementation, the target server can directly use the first timestamp when verifying the request, without having to infer the sending timestamp again.

[0104] Please refer to Figure 7 , Figure 7 This illustration shows another flowchart of a target server verifying combined information and a checksum according to an embodiment of this application. In this embodiment, when verifying the combined information and checksum, the target server can also obtain the current timestamp, i.e., the second timestamp. Then, the target server can calculate the time difference between the second timestamp and the first timestamp. This time difference can be compared with the preset time difference value described in the previous embodiment. If the absolute value of the time difference is greater than the preset time difference value, it indicates that the first timestamp used in the request is earlier, possibly expired, or is a malicious request from a replay attack. Therefore, in this case, the target server can directly determine that the verification result is unsuccessful.

[0105] Conversely, if the absolute value of the time difference is less than or equal to a preset time difference, it indicates that the request is fresh. The target server can then further obtain the user's authentication credentials based on the access identifier, and then verify the credentials, combined information, and checksum using a predetermined verification algorithm to obtain a verification result. Similarly, the verification result here is either pass or fail. If the verification result is pass, it can be determined that the user is an authorized user, and the firewall settings for the user's access to the target service can be adjusted according to the setting command. If the verification result is fail, the setting command can be ignored, i.e., the request is discarded.

[0106] Reference Figure 8 In this embodiment of the application, another access control method for network services is also provided, the method comprising:

[0107] The auxiliary server receives a user's request; wherein the request is adapted to a predetermined message format of the auxiliary server, and the content of the request includes combined information and a checksum generated based on the combined information. The combined information includes an access identifier and a setting command from the firewall regarding the user's access to the target service, wherein the setting command is an enable command or a disable command.

[0108] The auxiliary server locates the associated target server based on the access identifier;

[0109] If an associated target server is found, the auxiliary server verifies the combined information and the checksum.

[0110] If the verification result is successful, the auxiliary server, based on the setting command, notifies the firewall to adjust the firewall settings regarding the user's access to the target service.

[0111] The methods and embodiments of this application Figure 2 The methods shown correspond to the same application scenarios. The difference lies in... Figure 2 The method shown primarily involves the target server performing the verification and notification process to the firewall. However, in this embodiment, the verification and notification process to the firewall can also be delegated to an auxiliary server instead of the target server. This allows the auxiliary server to perform more auxiliary tasks in addition to verifying the access identifier, thereby minimizing the load on the target server and improving the smoothness and stability of the services provided by the target server.

[0112] It is understood that the content of the above method embodiments is applicable to this embodiment, and the specific functions implemented in this embodiment are the same as those in the above method embodiments, and will not be repeated here.

[0113] The following section describes and explains an access control method for a network service provided in this application embodiment, using specific application scenarios as examples.

[0114] Example 1:

[0115] A cloud computing company provides hosting services. Some tenants, wanting their servers to be privately accessible only to them and not detectable by external entities (including worms, web crawlers, and automated attacks like brute-force attacks), purchased VIP security protection. The cloud computing company supports 32,768 VIP tenants (this is because a 15-bit access identifier is used to register the access relationship between users and target services; these identifiers can be reclaimed). Different tenants request the cloud computing company to deploy their respective target services. All target services share a firewall and a set of auxiliary servers deployed by the cloud computing company. The auxiliary service running on these servers is DNS.

[0116] During the preparation phase, User A applies to the cloud computing company for VIP security protection, which requires registering their target service, such as TCP port 22 of 66.55.44.33. Assume that the access identifier assigned to User A and the target service is 100, and the registered key is 0x000102030405060708090A0B0C0D0E0F (0x represents unsigned hexadecimal integers, hereinafter the same). This is the symmetric key shared between User A and the cloud computing company, serving as the authentication credential used by User A to access the target service. For the subsequent data processing procedures, please refer to [link to relevant documentation]. Figure 9 .

[0117] During the usage phase, User A initiated a firewall "hole opening" request at 10:00 AM on January 1, 2025, to access his target service. For this purpose, User A's client was configured with {combined information} = {0x80646774A1A0}, in the format {1-bit enable / disable indicator || 15-bit access ID || 32-bit UNIX timestamp}, where || represents the concatenation of binary data (the correctness of this combined information is easily verified; for example, 0x0064 is the access ID, the highest bit is 0x8064 because it is the enable indicator, and 0x6774A1A0 = 1735696800 is the UNIX timestamp). The HMAC-MD5 hash calculated based on the symmetric key and this combined information is {checksum} = {0x8f03143705f625bb1d99708b23132286}.

[0118] User A initiates a request, and the client encodes {combined information, checksum} according to the predetermined message format of the auxiliary server. In this embodiment, the virtual auxiliary service on the auxiliary server is the DNS service. Therefore, the message format of the encoded result is a domain name, such as 80646774A1A08f03143705f625bb1d99708b23132286.example.com, with a total length of only 56 characters, which is far less than the upper limit of a complete domain name in the Internet specification (usually 253 characters). The client sends this domain name as a password to one of the auxiliary servers. The auxiliary server receives it at 10:00:01. It finds that the UNIX timestamp 0x6774A1A0 extracted from the password is 1 second ago, therefore fresh enough. The extracted access ID, 0x64, is a valid ID. Using the corresponding authentication credentials, it can verify that the received {combined information, checksum} is legitimate. Therefore, it finds the target server and port (i.e., the target service) corresponding to this access ID and calls the firewall interface to enable access to the target service for user A. Afterward, the target service is available to user A but remains invisible to the rest of the Internet. After the access ends, user A can explicitly disable this policy (or wait for the firewall to automatically delete it after a timeout). Assuming user A initiates the request at 10:59:59 AM on January 1, 2025, then {combined information} = {0x00646774AFAF}, and {verification code} = {0x15e160a4cbbb55bb4c3a2987d72836d6}.

[0119] like Figure 9 As shown in the embodiment of this application, user A is the sender, and the cloud computing company, as the network service provider, is the receiver. The actual process of verifying the request and notifying the firewall to execute relevant policies can be performed on either the auxiliary server or the target server; this application does not impose any restrictions on this.

[0120] Example 2:

[0121] For security reasons and compliance pressures, Company Z minimizes its exposure to the internet. Company Z has its own office automation website, https: / / OA.example.com, which is closed to the external network by default, but employees can access it from the company intranet. When employees are at home or traveling, they can use this application to manually activate access to the target service, i.e., the OA network. Since all employees of Company Z only have this one target service (https: / / OA.example.com), the access ID can be reduced to the employee ID. Company Z has a stable workforce of several dozen employees. Each employee receives a USB drive upon joining the company, which contains the client software installation program for accessing the target service from the external network, as well as a symmetric key associated with that employee ID. For example, employee V with ID 99 is assigned a symmetric key with the value 0xF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF during the preparation phase of this application, which can be used as an authentication credential.

[0122] During the usage phase, this application embodiment uses timestamps in minutes instead of seconds; that is, the UNIX timestamp is divided by 60 and any possible remainders are discarded. This is done to implicitly transmit the timestamp. The overall request process is as follows:

[0123] Step 1: Employee V's client initiates a knocking password at 14:59:59 on December 31, 2030. It sets {Combined Information} = {0xE301E98903}, in the format {1-bit enable / disable indicator || 7-bit access ID || 32-bit timestamp}. The UNIX timestamp of the initiation time is 1924930799, which, divided by 60, gives 32082179, or 0x01E98903. The HMAC-MD5 corresponding to this complete combined information is 0x32d03626fe041079a6db6505bd51ca47. However, when the client encodes the {combined information, checksum}, it discards the timestamp 0x01E98903 instead of explicitly transmitting it. Thus, E332d03626fe041079a6db6505bd51ca47.example.com becomes the encoded domain name, reducing its length to only 46 characters. The client randomly selects DNS3.example.com from the secondary server and sends the domain name to it, just like a normal DNS resolution request.

[0124] Step 2: The auxiliary server extracts employee ID 99 from the domain name, finds that this is a currently valid ID, and then forwards the knocking code and employee V's IP address to the target server where the target service registered with this ID is located.

[0125] Step 3: The target server receives the knocking code at 15:00:01 on December 31, 2030. As mentioned before, the knocking code E332d03626fe041079a6db6505bd51ca47 does not contain a timestamp. However, the target server's local timestamp is 1924930801 / 60 = 32082180 = 0x01E98904. Based on this, the target server knows that the client's timestamp should be either 0x01E98904 or 0x01E98903, and the complete combination information is either {0xE301E98904} or {0xE301E98903}. The target server extracts the key with id 0x63 and verifies the {combined information, verification code}. The knocking code is considered invalid only if both candidates for the combined information fail verification. As a result, the combination of information {0xE301E98903} passed the verification, so the target server V called the firewall management interface to "open a hole and allow access".

[0126] Step 4: Employee V accesses the OA network normally. Employee V can explicitly disable the access policy after the access is completed. During this process, the timestamp is still implicitly transmitted instead of explicitly transmitted to shorten the length of the domain name after the coded access code. Alternatively, Employee V can wait for the firewall to automatically remove the access policy enabled for them after the access is completed.

[0127] It is understood that the technical solutions in the embodiments of this application have at least the following advantages:

[0128] 1) A knock-on password based on timestamps and checksums was introduced to replace port knocking, effectively solving the problems of knock-on passwords being vulnerable to replay attacks and the exhaustion of knock-on passwords.

[0129] 2) The verification code mechanism only requires users to save a fixed key that can be revoked when necessary (instead of a long string of one-time passwords), which solves the problem of user ease of use.

[0130] 3) An auxiliary server was introduced, and the coded message was packaged as a request to the auxiliary service. This overcomes the problem that port knocking is unusable on some enterprise networks or ISPs. The virtual auxiliary service also makes the coded message more covert. The protected target service is not visible to the outside world, resulting in better security.

[0131] 4) A user management mechanism was introduced, which enabled user isolation based on verification codes, allowing multiple users to access the target service simultaneously and solving the problem of mutual coupling and influence among multiple users.

[0132] Reference Figure 10 In this embodiment of the application, an access control system for network services is also provided, which includes an auxiliary server 1020 and a target server 1010;

[0133] The auxiliary server is used to receive user requests; wherein the request is adapted to a predetermined message format of the auxiliary server, and the content of the request includes combined information and a check code generated based on the combined information. The combined information includes an access identifier and a setting command from the firewall regarding the user's access to the target service, wherein the setting command is an enable command or a disable command.

[0134] The auxiliary server is used to locate the associated target server based on the access identifier;

[0135] The auxiliary server is also used to forward the combined information and the verification code to the target server or to verify the combined information and the verification code, and when the verification result is successful, to notify the firewall to adjust the firewall settings regarding the user's access to the target service based on the setting command;

[0136] The target server is used to verify the combined information and the verification code, and when the verification result is successful, it notifies the firewall to adjust the firewall settings regarding the user's access to the target service based on the setting command.

[0137] It is understood that the content of the above method embodiments is applicable to this system embodiment. The specific functions implemented in this system embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0138] The method in this application embodiment can be set in a computer-readable storage medium, which can be used in an auxiliary server and a target server to execute relevant program code, thereby realizing the application described above.

[0139] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this application are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is changed and sub-operations described as part of a larger operation are executed independently.

[0140] Furthermore, although this application is described in the context of functional modules, it should be understood that, unless otherwise stated to the contrary, one or more of the functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding this application. Rather, given the properties, functions, and internal relationships of the various functional modules in the apparatus disclosed herein, the actual implementation of the module will be understood within the scope of conventional technology for an engineer. Therefore, those skilled in the art can implement the application set forth in the claims using ordinary techniques without excessive experimentation. It is also understood that the specific concepts disclosed are merely illustrative and not intended to limit the scope of this application, which is determined by the full scope of the appended claims and their equivalents.

[0141] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0142] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device.

[0143] More specific examples of computer-readable media (a non-exhaustive list) include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which programs can be printed, because programs can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0144] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0145] In the foregoing description of this specification, the references to terms such as "one embodiment," "another embodiment," or "some embodiments," etc., indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0146] Although embodiments of this application have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of this application, the scope of which is defined by the claims and their equivalents.

[0147] The above is a detailed description of the preferred embodiments of this application, but this application is not limited to the embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this application, and these equivalent modifications or substitutions are all included within the scope defined by the claims of this application.

Claims

1. An access control method for a network service, characterized in that, Applied to a network service provider, wherein the network service provider deploys an auxiliary server, a target server, and a firewall, and the target server runs a target service, the method includes: The auxiliary server receives a user's request; wherein the request is adapted to a predetermined message format of the auxiliary server, and the content of the request includes combined information and a checksum generated based on the combined information. The combined information includes an access identifier and a setting command from the firewall regarding the user's access to the target service, wherein the setting command is an enable command or a disable command. The auxiliary server locates the associated target server based on the access identifier and forwards the combined information and the verification code to the target server. The target server verifies the combined information and the checksum; If the verification result is successful, the target server, based on the setting command, notifies the firewall to adjust the firewall settings regarding the user's access to the target service.

2. The access control method for a network service according to claim 1, characterized in that, The method further includes: The network service provider receives the user's registration request for a target service under the first server, determines the authentication credentials used by the user to access the target service, and assigns an access identifier to the access relationship between the user and the target service; wherein, the first server is any of the target servers; The network service provider registers and maintains the association between the access identifier and the user, the target service, and the authentication credentials used by the user to access the target service.

3. The access control method for a network service according to claim 2, characterized in that, The verification code is generated through the following steps: The user obtains the current first timestamp; The user calculates the verification code using a predetermined verification algorithm, with the authentication credential as the first input and the access identifier, the first timestamp, and the setting command as the second input.

4. The access control method for a network service according to claim 3, characterized in that, The target server verifies the combined information and the checksum, including: The target server obtains the current second timestamp; Based on the second timestamp, the target server infers at least one of the sending timestamps used by the user when generating the verification code within a preset time difference. The target server obtains the authentication credentials corresponding to the user based on the access identifier. Using a predetermined verification algorithm, the target server performs verification based on the authentication credential, the combined information, the sending timestamp, and the verification code to obtain the verification result.

5. The access control method for a network service according to claim 4, characterized in that, The first timing granularity of the first timestamp is different from the second timing granularity of the second timestamp; Based on the second timestamp, the target server infers at least one sending timestamp used by the user when generating the verification code, within a preset error range, including: The target server performs a conversion process on the second timestamp according to the first timing granularity of the first timestamp to obtain a third timestamp; wherein, the timing granularity of the third timestamp is the same as that of the first timing granularity; The target server uses the third timestamp as the sending timestamp, or uses the timestamps of the N nearest first timing granularities of the third timestamp as the sending timestamp; where N is a positive integer.

6. The access control method for a network service according to claim 4, characterized in that, The target server performs verification based on the authentication credential, the combined information, the sending timestamp, and the checksum using a predetermined verification algorithm to obtain a verification result, including: Using a predetermined verification algorithm, the target server performs verification based on the authentication credential, the combined information, each of the sending timestamps, and the verification code to obtain a sub-verification result corresponding to each of the sending timestamps; If any of the sub-verification results corresponding to the sending timestamp is passed, the target server determines that the verification result is passed; If all the sub-verification results corresponding to the sending timestamps are unsuccessful, the target server determines that the verification result is unsuccessful.

7. The access control method for a network service according to claim 1, characterized in that, The combined information also includes a first timestamp; the target server verifies the combined information and the verification code, including: The target server obtains the current second timestamp; The target server calculates the time difference between the second timestamp and the first timestamp; If the absolute value of the time difference is greater than the preset time difference, the target server determines that the verification result is unsuccessful.

8. The access control method for a network service according to claim 7, characterized in that, The target server verifies the combined information and the checksum, and the verification also includes: If the absolute value of the time difference is less than or equal to the preset time difference, the target server obtains the authentication credential corresponding to the user based on the access identifier. Using a predetermined verification algorithm, the target server performs verification based on the authentication credential, the combined information, and the verification code to obtain a verification result.

9. An access control method for a network service, characterized in that, Applied to a network service provider, wherein the network service provider deploys an auxiliary server, a target server, and a firewall, and the target server runs a target service, the method includes: The auxiliary server receives a user's request; wherein the request is adapted to a predetermined message format of the auxiliary server, and the content of the request includes combined information and a checksum generated based on the combined information. The combined information includes an access identifier and a setting command from the firewall regarding the user's access to the target service, wherein the setting command is an enable command or a disable command. The auxiliary server locates the associated target server based on the access identifier; If an associated target server is found, the auxiliary server verifies the combined information and the checksum. If the verification result is successful, the auxiliary server, based on the setting command, notifies the firewall to adjust the firewall settings regarding the user's access to the target service.

10. An access control system for network services, characterized in that, include: Auxiliary server and target server; The auxiliary server is used to receive user requests; wherein the request is adapted to a predetermined message format of the auxiliary server, and the content of the request includes combined information and a check code generated based on the combined information. The combined information includes an access identifier and a firewall setting command regarding the user's access to the target service, and the setting command is an enable command or a disable command. The auxiliary server is used to locate the associated target server based on the access identifier; The auxiliary server is also used to forward the combined information and the verification code to the target server or to verify the combined information and the verification code, and when the verification result is successful, to notify the firewall to adjust the firewall settings regarding the user's access to the target service based on the setting command; The target server is used to verify the combined information and the verification code, and when the verification result is successful, it notifies the firewall to adjust the firewall settings regarding the user's access to the target service based on the setting command.

Images