A proactive defense gateway visitor data management method and system

Abstract

This invention discloses a proactive defense gateway visitor data management method and system. First, a visitor node table is generated to record the gateway node for backup of visitor data for each visitor identifier, and this table is synchronized to all gateway nodes. A hash operation maps visitor identifiers to location indices in the visitor node table, from which R unique gateway node identifiers can be retrieved for backup visitor data. When a gateway node receives an access request, if it cannot find visitor data locally or cannot determine the validity of its local visitor data, it uses the visitor identifier as the key to find the gateway node for backup visitor data in the visitor node table, retrieves the latest visitor data, and executes the business process. For new visitors, visitor data is created at the gateway node processing the access request. During the execution of the business process, if visitor data is created or updated, it is synchronized to the backup node. This invention improves the visitor data backup mechanism and enhances the availability and reliability of the gateway.

Description

Technical Field

[0001] This invention relates to a proactive defense gateway visitor data management method and system, belonging to the field of network security technology. Background Technology

[0002] A proactive defense gateway is a type of security gateway used to protect websites. Compared to traditional security gateways, proactive defense gateways have the ability to actively detect and monitor the user's operating environment, improving the accuracy of threat event detection and further enhancing security capabilities. Upon receiving an HTTP request from the user, the proactive defense gateway accurately locates each visitor by issuing cookies and collecting device information. Internally, a unique visitor identifier is generated for each visitor; this identifier is used to store basic visitor information, access logs, and for visitor access control.

[0003] Figure 1 This diagram illustrates the deployment of a proactive defense gateway cluster. The load balancer distributes HTTP requests to each gateway node according to certain rules (e.g., mapping source IPs or visitor identifiers to the gateway nodes of the proactive defense gateway). Each gateway node is independent and possesses complete gateway functionality. Upon receiving an HTTP request, it performs visitor identification, access control, and other operations before forwarding it to the backend website.

[0004] Existing proactive defense gateways have the following shortcomings in visitor data management: 1. After a visitor's HTTP request is scheduled to a specific gateway node, the resulting visitor data is only stored on that single gateway node, without any copies. 2. There is a lack of fault tolerance mechanisms; when a gateway node fails, there is no guarantee that requests can be processed normally after rescheduling. 3. After the load balancer schedules requests based on the source IP or other parameters, it cannot guarantee that the scheduled gateway node will have visitor data. A typical example is when a change in the source IP leads to a change in the scheduling result, making it impossible to retrieve the original visitor data. Summary of the Invention

[0005] Purpose of the invention: In view of the problems existing in the prior art, the purpose of this invention is to provide a proactive defense gateway visitor data management method and system, improve the visitor data backup mechanism, and enhance the availability and reliability of the gateway.

[0006] Technical solution: To achieve the above-mentioned objectives, the present invention adopts the following technical solution:

[0007] A method for managing visitor data in a proactive defense gateway includes the following steps:

[0008] Generate a visitor node table and synchronize it to all gateway nodes. The visitor node table is used to record the gateway node for the backup of visitor data corresponding to each visitor identifier. The visitor identifier is mapped to the location index of the visitor node table through a hash operation. R unique gateway node identifiers can be obtained from the location index, where R is the set number of replicas of visitor data, 2≤R≤Q, and Q is the number of gateway nodes in the gateway cluster.

[0009] Upon receiving an access request, the gateway node retrieves the visitor identifier and the visitor data update time in the request. It then searches for local visitor data based on the visitor identifier. If the update time of the local visitor data is not earlier than the visitor data update time carried in the request, the local visitor data is considered valid, and the business process is executed. If no visitor data is found locally or the validity of the local visitor data cannot be determined, the gateway node that backs up the visitor data is found from the visitor node table using the visitor identifier as the key, and the latest visitor data is retrieved to execute the business process. For new visitors, visitor data is created on the gateway node that processed the access request.

[0010] During the execution of the business process, if visitor data is created or updated, the creation or update time of the visitor data is fed back to the requesting end, and R unique gateway node identifiers are retrieved from the visitor node table using the visitor identifier as the key, and the latest visitor data is synchronized between the corresponding gateway nodes.

[0011] Preferably, the location index of visitor identifier A mapped to the visitor node table is k, and the R unique gateway node identifiers are stored in R consecutive entries containing the location index k.

[0012] Preferably, the consecutive R entries are entries with position indices from k to (k+R-1)%N, or entries with position indices from (k-R+1)%N to k, where N is the number of entries in the visitor node table, and % represents the modulo operation.

[0013] Preferably, the process of generating the visitor node table is as follows: starting from the first entry, a gateway node identifier from the gateway cluster is randomly selected and filled in; for subsequent entries, a gateway node identifier that is different from the previous R-1 entries is randomly selected and filled in. After all entries are filled in, it is ensured that the gateway node identifiers of the R consecutive entries in the circular table formed are not repeated.

[0014] Preferably, the location index of the visitor identifier A mapped to the visitor node table is k, and the R unique gateway node identifiers are stored in a list in the table entry with location index k.

[0015] As a preferred approach, the load balancer of the proactive defense gateway schedules the request to a gateway node in the gateway cluster based on the source IP address of the access request.

[0016] Furthermore, when the gateway cluster is expanded, a portion of the original gateway node identifiers in the original visitor node table are replaced with newly added gateway node identifiers to form a new visitor node table; all visitor data is scanned, and the visitor identifier is used to search in the new visitor node table. If the mapped gateway node identifier is new, the original gateway node that stores the visitor data is found from the original visitor node table and synchronized to the new gateway node.

[0017] A proactive defense gateway visitor data management system, comprising:

[0018] The visitor node table management module is used to generate a visitor node table and synchronize it to all gateway nodes. The visitor node table is used to record the gateway node for the backup of visitor data corresponding to each visitor identifier. The visitor identifier is mapped to the location index of the visitor node table through a hash operation. R unique gateway node identifiers can be obtained from the location index.

[0019] The visitor data acquisition module is used to obtain the visitor identifier and the visitor data update time in the request after the gateway node receives an access request. It then searches for local visitor data based on the visitor identifier. If the update time of the local visitor data is not earlier than the visitor data update time carried in the request, the local visitor data is considered valid, and the local visitor data is retrieved to execute the business process. If no visitor data is found locally or the validity of the local visitor data cannot be determined, the gateway node that backs up the visitor data is found from the visitor node table using the visitor identifier as the key, and the latest visitor data is retrieved to execute the business process. For new visitors, visitor data is created on the gateway node that processes the access request.

[0020] Additionally, the visitor data update module is used to, during the execution of business processes, if visitor data is created or updated, feed back the creation or update time of the visitor data to the requesting end, and retrieve R consecutive unique gateway node identifiers from the visitor node table using the visitor identifier as the key, and synchronize the latest visitor data among the corresponding gateway nodes.

[0021] Furthermore, the system also includes: a cluster expansion management module, used to replace a portion of the original gateway node identifiers in the original visitor node table with newly added gateway node identifiers when the gateway cluster is expanded, forming a new visitor node table; scan all visitor data, search for the new visitor node table using the visitor identifier, and if the mapped gateway node identifier is new, find the original gateway node that stores the visitor data from the original visitor node table and synchronize it to the new gateway node.

[0022] An active defense gateway system includes a load balancing device and multiple gateway nodes. The load balancing device schedules access requests to the gateway nodes. Each gateway node stores a visitor node table, which records the gateway node for the backup of visitor data corresponding to each visitor identifier. The visitor identifier is mapped to the location index of the visitor node table through a hash operation, and R unique gateway node identifiers can be obtained from the location index.

[0023] The gateway node, upon receiving an access request, obtains the visitor identifier and the visitor data update time in the request. It then searches for local visitor data based on the visitor identifier. If the update time of the local visitor data is not earlier than the visitor data update time carried in the request, the local visitor data is considered valid, and the business process is executed. If no visitor data is found locally or the validity of the local visitor data cannot be determined, the gateway node that backs up the visitor data is found from the visitor node table using the visitor identifier as the key, and the latest visitor data is retrieved to execute the business process. For new visitors, visitor data is created at the gateway node processing the access request. Furthermore, during the execution of the business process, if visitor data is created or updated, the visitor data creation or update time is fed back to the requesting end, and R unique gateway node identifiers are retrieved from the visitor node table using the visitor identifier as the key, and the latest visitor data is synchronized among the corresponding gateway nodes.

[0024] Beneficial effects: This invention constructs a visitor node table, which allows selection of gateway nodes for visitor data synchronization. When a scheduled gateway node lacks local visitor data or its local visitor data is invalid, the system can remotely retrieve visitor data from the selected gateway node table, ensuring normal business process handling. Compared to existing technologies, this invention adds visitor data backup capabilities to the gateway in a clustered deployment environment, improving gateway availability; it also ensures visitor data can be found even when client IPs change, enhancing the reliability of business logic. Attached Figure Description

[0025] Figure 1 This is a diagram illustrating the deployment method of a proactive defense gateway cluster.

[0026] Figure 2 This is a schematic diagram of the visitor data management process in an embodiment of the present invention.

[0027] Figure 3 This is an example diagram of the visitor node table structure in an embodiment of the present invention.

[0028] Figure 4 This is an example diagram of another visitor node table structure in an embodiment of the present invention.

[0029] Figure 5 This is a schematic diagram illustrating the process of a gateway node acquiring visitor data in an embodiment of the present invention. Detailed Implementation

[0030] The technical solution of the present invention will now be clearly and completely described in conjunction with the accompanying drawings and specific embodiments.

[0031] This invention discloses a proactive defense gateway visitor data management method. First, a visitor node table is generated to record the gateway node for each visitor identifier's visitor data backup, and this table is synchronized to all gateway nodes. Then, a hash operation is used to map the visitor identifier to a specific index in the visitor node table. From this index, R unique gateway node identifiers (the number of replicas of visitor data, typically between 2 and the number of gateway nodes Q in the cluster) can be obtained as data backup nodes. Figure 2 As shown, after receiving an access request, the gateway node obtains the visitor identifier and the visitor data update time in the request. It then searches for local visitor data based on the visitor identifier. If the update time of the local visitor data is not earlier than the visitor data update time carried in the request, the local visitor data is considered valid, and the business process is executed. If no visitor data is found locally or the validity of the local visitor data cannot be determined, the gateway node that backs up the visitor data is found from the visitor node table using the visitor identifier as the key, and the latest visitor data is retrieved to execute the business process. For new visitors, visitor data is created on the gateway node processing the access request. During the execution of the business process, if visitor data is created or updated, the visitor data creation or update time is fed back to the requesting end, and R unique gateway node identifiers are retrieved from the visitor node table using the visitor identifier as the key. The latest visitor data is then synchronized among the corresponding gateway nodes.

[0032] In this embodiment, the visitor identifier is mapped to a position index k=hash(visitor identifier) ​​in the visitor node table based on the consistent hashing algorithm. The entries in the visitor node table store gateway node identifiers (such as gateway node numbers). Using the visitor identifier as the key, the corresponding gateway node identifier (one or a group selected according to the set rules) can be obtained from the visitor node table.

[0033] Figure 3The diagram illustrates a feasible visitor node table structure. The visitor node table has N entries (e.g., 65536), forming a circular linked list, which can be implemented as an array. Each entry is a gateway node identifier. During cluster deployment, the visitor node table is generated. The generation process is as follows: starting with the first entry, a gateway node identifier is randomly selected and filled in; for subsequent entries, a gateway node identifier is randomly selected, and it is checked whether it is duplicated with the previous R-1 entries (where R is the number of replicas of visitor data). If duplicates are found, a new gateway node identifier is randomly selected, ensuring that the R consecutive entries filled in are not duplicates. After the visitor node table is generated, it is synchronized to all gateway nodes in the cluster. If the location index of visitor identifier A mapped to the visitor node table is k, then the gateway node containing the R consecutive entries with location index k (e.g., entries with indices from k to (k+R-1)%N or from (k-R+1)%N to k) can be selected as the visitor data backup node for visitor identifier A.

[0034] Of course, in practice, the gateway node identifiers can also be filled in sequentially in a loop. For example... Figure 4 As shown, each table entry can also correspond to a set of unique node identifiers, which can be used as backups of the same visitor data. The generation process of this two-dimensional table can be to first generate the first gateway node identifier randomly and then in sequence, and then generate another R-1 gateway node identifiers for each location index k, ensuring that the R identifiers are unique.

[0035] Configure a scheduling method on the load balancer. In this example, the source address is used as a parameter for selecting nodes, and HTTP requests are scheduled to a specific gateway node. The source address always exists and remains relatively stable, ensuring that the same visitor is always scheduled to the same gateway node within a certain period. This ensures that each visitor's HTTP requests are consistently scheduled to the corresponding gateway node, guaranteeing that the visitor data on the gateway node is up-to-date and avoiding the problem of reading old data due to incomplete visitor data synchronization in some extreme cases.

[0036] After receiving an HTTP request, the gateway node identifies the visitor who initiated the request using a pre-defined method (such as device fingerprint, cookie ID, etc.). It then attempts to retrieve the visitor data update time from the HTTP request (carried via a cookie) to check the validity of the locally stored visitor data. Next, it uses the visitor identifier to search for the local visitor data. If found, and the local visitor data's update time is not earlier than the update time carried in the HTTP request, the data is considered new and valid, and the visitor data can be retrieved to begin the business process. In exceptional cases, the HTTP request may not carry the visitor data update time, making it impossible to check the visitor data's validity; in such cases, the locally stored visitor data may be invalid by default. Regardless of whether the visitor data is not found locally or the visitor data is invalid, the gateway node must use the visitor identifier as the key to find the first gateway node (other gateway nodes, but not the current gateway node) in the visitor node table and attempt to remotely read the visitor data. Figure 5 As shown, if the gateway node is offline or fails to read data due to a malfunction, the next gateway node is found and the process continues. This process repeats until the latest visitor data is successfully found or the preset number of attempts is reached. For new visitors, when attempting to read data from the first gateway node, a message indicating that the data cannot be found should be displayed instead of a malfunction message, and the gateway node currently handling the HTTP request should create new visitor data. Alternatively, if visitor data has not been read from any of the gateway nodes with backup data, it can be considered a new visitor, and the current gateway node should create new visitor data. If a preset new visitor identification mechanism exists before retrieving visitor data (e.g., using a cookie to carry a visitor identifier; those without this identifier are considered new visitors), visitor data can be created directly on the current node.

[0037] During the execution of business processes, if important information in the visitor data is created or modified (such as identifying the visitor type), synchronization needs to be initiated. Simultaneously, the visitor data update time is sent to the browser via a cookie in the HTTP response message. The target gateway nodes for synchronization are the same as those involved in the remote visitor data reading process described above, taken from the visitor node table. Using the visitor identifier as the key, the first R gateway nodes are selected according to a preset number (R being the number of visitor data replicas), typically three. This node then synchronizes visitor data to these three selected gateway nodes. The protocol used for transmitting visitor data can be UDP, TCP, or HTTP; there are no restrictions. Specifically, if the selected gateway nodes include this node, then that node can be skipped.

[0038] When a gateway node fails (e.g., goes down), the load balancer detects the failure and forwards HTTP requests that should have been routed to that gateway node to other gateway nodes. These other gateway nodes may or may not store the relevant visitor data. If not, they need to look up the data in the visitor node table and remotely retrieve the visitor data.

[0039] Once the failed gateway node recovers and is detected by the load balancer, some visitor HTTP requests are rescheduled back to these gateway nodes. The load balancer compares the visitor data update time carried in the HTTP request with the local visitor data update time. If it finds that the local visitor data has expired, it will read the visitor data from other gateway nodes according to the aforementioned process and synchronize it to other gateway nodes if there are any modifications made locally.

[0040] When a browser's IP address changes, the load balancer may route its HTTP requests to a different gateway node than before. In this case, the local node may not be able to find visitor data and will need to retrieve it from other gateway nodes.

[0041] For gateway cluster expansion, we replaced some entries in the original visitor node table with new gateway node identifiers, creating a new visitor node table. However, the new gateway nodes do not have corresponding visitor data, which needs to be migrated from some of the original gateway nodes. We need to temporarily retain the old visitor node table, then scan all visitor data, and search for each visitor identifier in the new visitor node table. If the found gateway node is a new gateway node, then we find the original gateway node storing the visitor data in the old visitor node table and synchronize this visitor data to the new gateway node.

[0042] Based on the same inventive concept, this invention discloses an active defense gateway visitor data management system, comprising: a visitor node table management module, used to generate a visitor node table and synchronize it to all gateway nodes; a visitor data acquisition module, used to, after a gateway node receives an access request, acquire the visitor identifier and the visitor data update time in the request, search for local visitor data based on the visitor identifier, and if the update time of the local visitor data is not earlier than the visitor data update time carried in the request, then the local visitor data is considered valid, and the local visitor data is retrieved to execute the business process; if no visitor data is found locally or the validity of the local visitor data cannot be determined, then the gateway node that backs up the visitor data is found from the visitor node table using the visitor identifier as the key, and the latest visitor data is retrieved to execute the business process; for new visitors, visitor data is created on the gateway node that processes the access request; and a visitor data update module, used to, during the execution of the business process, if visitor data is created or updated, feed back the visitor data creation or update time to the requesting end, and retrieve R consecutive non-repeating gateway node identifiers from the visitor node table using the visitor identifier as the key, and synchronize the latest visitor data among the corresponding gateway nodes. Further, it also includes: a cluster expansion management module, which is used to replace part of the original gateway node identifiers in the original visitor node table with newly added gateway node identifiers when the gateway cluster is expanded, forming a new visitor node table; scan all visitor data, search for the new visitor node table using the visitor identifier, and if the mapped gateway node identifier is new, find the original gateway node that stores the visitor data from the original visitor node table and synchronize it to the new gateway node.

[0043] Based on the same inventive concept, this invention discloses an active defense gateway system, including a load balancing device and multiple gateway nodes. The load balancing device schedules access requests to the gateway nodes. Each gateway node stores a visitor node table. Upon receiving an access request, the gateway node obtains the visitor identifier and the visitor data update time in the request. It then searches for local visitor data based on the visitor identifier. If the update time of the local visitor data is not earlier than the visitor data update time carried in the request, the local visitor data is considered valid, and the local visitor data is retrieved to execute the business process. If no visitor data is found locally or the validity of the local visitor data cannot be determined, the gateway node that backs up the visitor data is found from the visitor node table using the visitor identifier as the key, and the latest visitor data is retrieved to execute the business process. For new visitors, visitor data is created at the gateway node processing the access request. During the execution of the business process, if visitor data is created or updated, the visitor data creation or update time is fed back to the requesting end, and R unique gateway node identifiers are retrieved from the visitor node table using the visitor identifier as the key, and the latest visitor data is synchronized among the corresponding gateway nodes.

Claims

1. A method for managing visitor data in a proactive defense gateway, characterized in that, Includes the following steps: Generate a visitor node table and synchronize it to all gateway nodes. The visitor node table is used to record the gateway node for the backup of visitor data corresponding to each visitor identifier. The visitor identifier is mapped to the location index of the visitor node table through a hash operation. R unique gateway node identifiers can be obtained from the location index, where R is the set number of replicas of visitor data, 2≤R≤Q, and Q is the number of gateway nodes in the gateway cluster. Upon receiving an access request, the gateway node retrieves the visitor identifier and the visitor data update time in the request. It then searches for local visitor data based on the visitor identifier. If the update time of the local visitor data is not earlier than the visitor data update time carried in the request, the local visitor data is considered valid, and the business process is executed. If no visitor data is found locally or the validity of the local visitor data cannot be determined, the gateway node that backs up the visitor data is found from the visitor node table using the visitor identifier as the key, and the latest visitor data is retrieved to execute the business process. For new visitors, visitor data is created on the gateway node that processed the access request. During the execution of the business process, if visitor data is created or updated, the creation or update time of the visitor data is fed back to the requesting end, and R unique gateway node identifiers are retrieved from the visitor node table using the visitor identifier as the key, and the latest visitor data is synchronized between the corresponding gateway nodes.

2. The method for managing visitor data in an active defense gateway according to claim 1, characterized in that, Let visitor identifier A be mapped to the location index k of the visitor node table, and let the R unique gateway node identifiers be stored in R consecutive entries containing the location index k.

3. The method for managing visitor data in an active defense gateway according to claim 2, characterized in that, The consecutive R entries are entries with position indices from k to (k+R-1)%N, or entries with position indices from (k-R+1)%N to k, where N is the number of entries in the visitor node table, and % represents the modulo operation.

4. The method for managing visitor data in an active defense gateway according to claim 1, characterized in that, The process of generating the visitor node table is as follows: starting from the first entry, randomly select a gateway node identifier from the gateway cluster and fill it in; for subsequent entries, randomly select a gateway node identifier that is different from the previous R-1 entries and fill it in. After all entries are filled in, ensure that the gateway node identifiers of the R consecutive entries in the circular table formed are not repeated.

5. The method for managing visitor data of an active defense gateway according to claim 1, characterized in that, Let visitor identifier A be mapped to the location index k of the visitor node table, and let the R unique gateway node identifiers be stored in a list in the table entry with location index k.

6. The method for managing visitor data of an active defense gateway according to claim 1, characterized in that, The load balancer of the proactive defense gateway schedules requests to a gateway node in the gateway cluster based on the source IP address of the access request.

7. The method for managing visitor data of an active defense gateway according to claim 1, characterized in that, When expanding the gateway cluster, a portion of the original gateway node identifiers in the original visitor node table are replaced with newly added gateway node identifiers to form a new visitor node table. All visitor data is scanned, and the new visitor node table is searched using the visitor identifier. If the mapped gateway node identifier is new, the original gateway node storing the visitor data is found from the original visitor node table and synchronized to the new gateway node.

8. A proactive defense gateway visitor data management system, characterized in that, include: The visitor node table management module is used to generate visitor node tables and synchronize them to all gateway nodes; The visitor node table is used to record the gateway node for the backup of visitor data corresponding to each visitor identifier. The visitor identifier is mapped to the location index of the visitor node table through a hash operation. R unique gateway node identifiers can be obtained from the location index, where R is the set number of replicas of visitor data, 2≤R≤Q, and Q is the number of gateway nodes in the gateway cluster. The visitor data acquisition module is used to obtain the visitor identifier and the visitor data update time in the request after the gateway node receives an access request. It then searches for local visitor data based on the visitor identifier. If the update time of the local visitor data is not earlier than the visitor data update time carried in the request, the local visitor data is considered valid, and the local visitor data is retrieved to execute the business process. If no visitor data is found locally or the validity of the local visitor data cannot be determined, the gateway node that backs up the visitor data is found from the visitor node table using the visitor identifier as the key, and the latest visitor data is retrieved to execute the business process. For new visitors, visitor data is created on the gateway node that processes the access request. Additionally, the visitor data update module is used to, during the execution of business processes, if visitor data is created or updated, feed back the creation or update time of the visitor data to the requesting end, and retrieve R consecutive unique gateway node identifiers from the visitor node table using the visitor identifier as the key, and synchronize the latest visitor data among the corresponding gateway nodes.

9. The proactive defense gateway visitor data management system according to claim 8, characterized in that, Also includes: The cluster expansion management module is used to replace a portion of the original gateway node identifiers in the original visitor node table with newly added gateway node identifiers when expanding the gateway cluster, forming a new visitor node table; scan all visitor data, search for the new visitor node table using the visitor identifier, and if the mapped gateway node identifier is new, find the original gateway node that stores the visitor data in the original visitor node table and synchronize it to the new gateway node.

10. A proactive defense gateway system, comprising a load balancing device and multiple gateway nodes, wherein the load balancing device schedules access requests to the gateway nodes; characterized in that, Each gateway node stores a visitor node table, which records the gateway node for the backup of visitor data corresponding to each visitor identifier. The visitor identifier is mapped to the location index of the visitor node table through a hash operation. R unique gateway node identifiers can be obtained from the location index, where R is the set number of replicas of visitor data, 2≤R≤Q, and Q is the number of gateway nodes in the gateway cluster. The gateway node, upon receiving an access request, obtains the visitor identifier and the visitor data update time in the request. It then searches for local visitor data based on the visitor identifier. If the update time of the local visitor data is not earlier than the visitor data update time carried in the request, the local visitor data is considered valid, and the business process is executed. If no visitor data is found locally or the validity of the local visitor data cannot be determined, the gateway node that backs up the visitor data is found from the visitor node table using the visitor identifier as the key, and the latest visitor data is retrieved to execute the business process. For new visitors, visitor data is created on the gateway node that processed the access request. In addition, during the execution of business processes, if visitor data is created or updated, the creation or update time of the visitor data is fed back to the requesting end, and R unique gateway node identifiers are retrieved from the visitor node table using the visitor identifier as the key, and the latest visitor data is synchronized between the corresponding gateway nodes.

Images