Export server address anti-breach method and device, computer device and medium

Abstract

The application relates to an export server address anti-blasting method and device, computer equipment and a medium. The method comprises the following steps: obtaining the risk control state of a client; when the risk control state is normal, sending a first distribution key to the client, so that the client periodically pulls an export server address from a server at a first time interval based on the first distribution key; when the risk control state is limited, sending a second distribution key to the client, so that the client periodically pulls the export server address from the server at a second time interval based on the second distribution key; the first time interval is smaller than the second time interval; when receiving a request for pulling the export server address from the client, if the request carries the first distribution key, a sample subset is generated by using a dynamic address generation strategy, if the request carries the second distribution key, a sample subset is generated by using a limited address generation strategy, and the sample subset is sent to the client after being encrypted. The application can effectively prevent malicious enumeration, grabbing and blasting attacks on the export IP.

Description

Technical Field

[0001] This application relates to the fields of network security and virtual private network technology, and in particular to a method, apparatus, computer equipment and medium for preventing the brute-force attack on an export server address. Background Technology

[0002] Virtual Private Network (VPN) technology has been widely used in scenarios such as privacy protection, cross-border access, and network interconnection. One of the core values ​​of VPN services is that their exit servers can provide users with alternative public IP addresses (Internet Protocol Addresses). However, these exit server IP addresses (also known as exit server addresses, exit IPs, or exit addresses) have become key targets for malicious attacks, commercial blocking, and resource abuse. Once exit server addresses are identified and blocked on a large scale, it will directly lead to a decrease in VPN service availability and a surge in operating costs.

[0003] Currently, the industry typically uses static or semi-static server list distribution mechanisms, security models that focus on post-connection protection, and decoupling risk control systems from resource distribution systems to protect egress server addresses. However, these methods have some shortcomings.

[0004] Regarding static or semi-static server list distribution mechanisms, many VPN services, in pursuit of ease of connection, directly embed the list of exit server addresses (or configuration files containing these addresses) within their client applications, or distribute it in plaintext through unencrypted or weakly encrypted communication channels. Attackers can easily obtain the complete set of exit server addresses at low cost by reverse engineering the client application or by listening to and parsing the initial network handshake traffic. This opens the door for subsequent targeted DDoS (Distributed Denial of Service) attacks, bulk blocking submissions, or automated abuse.

[0005] Regarding security models primarily focused on post-connection protection, existing protective measures are highly concentrated after a user connection is established. For example, implementing request frequency limits based on source IP, controlling the number of concurrent connections, or maintaining dynamic IP blacklists on the VPN server side. However, while these methods can mitigate attacks that have already occurred, they are reactive measures. Attackers can leverage the acquired IP list to continuously probe and attack using a slow-fast strategy (such as low-frequency, multi-IP source polling). The protection system remains in a reactive state and cannot protect the core asset—the list of exiting IPs—from being leaked.

[0006] Regarding the method of decoupling the risk control system from the resource distribution system, even if the VPN server's risk control system identifies abnormal behavior of a VPN client device or user account (such as frequent short connections or high failure rates), the current architecture struggles to effectively transmit the relevant risk status to the front-end stage of server address distribution. Clients in abnormal states can usually still request and obtain new, available exit server addresses without restriction, significantly reducing the effectiveness of risk control and allowing attackers to continuously acquire new attack resources.

[0007] Furthermore, to address the shortcomings of the aforementioned methods, some technical solutions introduce mandatory human-machine verification, frequent proactive connection interruptions, or complex manual review processes. While these measures increase the automation costs for attackers to some extent, they also severely disrupt the normal use by legitimate users, leading to decreased connection success rates, increased latency, and a degraded user experience. Summary of the Invention

[0008] In response to the above-mentioned deficiencies or disadvantages, this application provides a method, apparatus, computer equipment, and medium for preventing the export server address from being compromised.

[0009] This application provides a method for preventing brute-force attacks on exit server addresses according to a first aspect. The method includes: obtaining the risk control status of a VPN client; when the risk control status is normal, sending a first distribution key to the VPN client, causing the VPN client to periodically retrieve an exit server address from the VPN server at a first time interval based on the first distribution key; when the risk control status is restricted, sending a second distribution key to the VPN client, causing the VPN client to periodically retrieve an exit server address from the VPN server at a second time interval based on the second distribution key; the first time interval is less than the second time interval; upon receiving an exit server address retrieval request from the VPN client, if the request carries the first distribution key, generating a sample subset using a dynamic address generation strategy; if the request carries the second distribution key, generating a sample subset using a restricted address generation strategy; encrypting the sample subset and sending it to the VPN client.

[0010] In some embodiments, generating a sample subset using a dynamic address generation strategy includes: sampling from the set of egress server addresses according to a first specified information to obtain a sample subset; generating a sample subset using a restricted address generation strategy includes: detecting whether a cached sample subset corresponding to the VPN client exists in the cache; if it exists, using the cached sample subset as the sample subset; if it does not exist, sampling from the set of egress server addresses according to a second specified information to obtain a sample subset.

[0011] In some embodiments, before obtaining the risk control status of the VPN client, the method further includes: obtaining connection behavior data of the VPN client within a preset time period; performing aggregation processing on the connection behavior data to obtain aggregated data; performing risk assessment on the aggregated data to obtain a risk assessment result; setting the risk control status of the VPN client to normal when the risk assessment result is normal; and setting the risk control status of the VPN client to restricted when the risk assessment result is abnormal.

[0012] In some embodiments, the method further includes: when the risk control status of the VPN client is restricted, in response to receiving a risk control status update request sent by the VPN client, updating the risk control status of the VPN client to normal; the risk control status update request is a request sent by the VPN client when it detects that a preset trigger condition is met and performs a local human-machine verification process, and the verification result is passed.

[0013] In some embodiments, the preset triggering conditions include at least one of the following: the user actively triggers the connection operation; the number of connection triggers reaches a first preset threshold; the number of times the VPN client's risk assessment result shows abnormal behavior within a preset time period reaches a second preset threshold.

[0014] In some embodiments, the connection behavior data is aggregated to obtain aggregated data, including: within a preset statistical window, the connection behavior data is statistically summarized by account dimension and / or device dimension to obtain aggregated feature data; the aggregated feature data includes one or more of the following: number of connection triggers, number of connection failures, failure rate, number of short-term repeated connections, growth rate of the number of connections reached by different egress server addresses, and changes in the number of devices associated with the same account.

[0015] In some embodiments, risk assessment is performed based on aggregated data to obtain risk assessment results, including: calculating sub-risk scores for the VPN client across multiple risk dimensions based on aggregated feature data; assigning weights to each sub-risk score based on at least one of the following: VPN client account level, line country or region, historical reputation, and health status of the exit server address; weighted summing of each sub-risk score and its weight to obtain a comprehensive risk score for the VPN client; determining the risk assessment result as abnormal behavior when the comprehensive risk score exceeds a preset anomaly determination threshold; and determining the risk assessment result as normal behavior when the comprehensive risk score does not exceed the anomaly determination threshold.

[0016] This application provides a device for preventing the cracking of export server addresses according to a second aspect, the device comprising: The key distribution module is used to obtain the risk control status of the VPN client. When the risk control status is normal, a first distribution key is sent to the VPN client, enabling the VPN client to periodically retrieve the exit server address from the VPN server at a first time interval based on the first distribution key. When the risk control status is restricted, a second distribution key is sent to the VPN client, enabling the VPN client to periodically retrieve the exit server address from the VPN server at a second time interval based on the second distribution key. The first time interval is shorter than the second time interval. The address feedback module is used to generate a sample subset by using a dynamic address generation strategy when it receives a request to retrieve the exit server address from a VPN client. If the request carries a first distribution key, it generates a sample subset by using a restricted address generation strategy. The sample subset is then encrypted and sent to the VPN client.

[0017] According to a third aspect, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements any of the above-described methods for preventing brute-force attacks on an export server address.

[0018] According to a fourth aspect, this application provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executed, implements any of the above-described methods for preventing the brute-force attack on an export server address.

[0019] The embodiments described above effectively prevent malicious enumeration, capture, and brute-force attacks on the IP addresses of VPN egress servers, achieving proactive defense from the information distribution source. Specifically, the VPN server dynamically allocates different distribution keys and adopts different address update strategies based on the VPN client's risk control status. For VPN clients in a normal state, a first distribution key is distributed. Upon receiving an egress server address retrieval request, a dynamic address generation strategy is used to generate a sample subset, producing frequently updated and dynamically changing egress server address samples to ensure a smooth connection experience and success rate. For VPN clients in a restricted state, a restricted address generation strategy is used to generate a sample subset, achieving low-frequency updates and fixed sample address acquisition restrictions, significantly reducing the number of egress server addresses that can be detected per unit time, thereby suppressing automated brute-force attacks. Through the collaborative mechanism of key distribution, strategy execution, and sample generation, this application moves the traditional passive protection focused on the post-connection stage to the distribution and control of egress server IP addresses, significantly improving the overall anti-brute-force capability of the system while maintaining a seamless experience for normal users. Attached Figure Description

[0020] Figure 1This is a flowchart of an export server address anti-brute-force method in one or more embodiments of this application; Figure 2 This is a schematic diagram of the structure of the export server address anti-explosion device in one or more embodiments of this application; Figure 3 This is a schematic diagram of the internal structure of a computer device according to one or more embodiments of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings. It should be understood that the described embodiments are merely some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0022] In the following description, when referring to the accompanying drawings, the same numbers in different drawings denote the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0023] In the description of this application, it should be understood that the terms "first," "second," "third," etc., are used only to distinguish similar objects and are not necessarily used to describe a specific order or sequence, nor should they be construed as indicating or implying relative importance. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances. Furthermore, in the description of this application, unless otherwise stated, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0024] To address the shortcomings or defects of related technologies, this application provides a method for preventing brute-force attacks on exit server addresses. This method can intelligently control the information distribution source, proactively defend against the enumeration and brute-force attacks on exit server IP addresses, and accurately distinguish between normal users and abnormal behavior, thereby ensuring network security while maintaining the user experience of normal users.

[0025] like Figure 1 As shown, the method includes steps S110 to S120.

[0026] In some exemplary embodiments of this application, the method includes steps that can be found in [reference needed]. Figure 1 The following will use the application of this method to a VPN server as an example to illustrate the various steps involved. The VPN server is the core device providing virtual private network services, including an egress server cluster, key management module, risk control decision module, address sampling module, etc., responsible for maintaining egress server IP address resources, assessing the risk of each VPN client, distributing keys, and sampling egress server IP addresses.

[0027] S110: Obtain the risk control status of the VPN client. When the risk control status is normal, send a first distribution key to the VPN client, so that the VPN client periodically retrieves the exit server address from the VPN server at a first time interval based on the first distribution key. When the risk control status is restricted, send a second distribution key to the VPN client, so that the VPN client periodically retrieves the exit server address from the VPN server at a second time interval based on the second distribution key. The first time interval is shorter than the second time interval.

[0028] Risk control status is a security level status, which can be determined based on the VPN client's (hereinafter referred to as the client) historical connection behavior and / or real-time connection behavior (such as the number of connections per unit time, failure rate, device fingerprint changes, etc.) through a risk assessment model. Risk control status mainly includes normal status and restricted status. Normal status indicates that the VPN client's connection behavior has not triggered preset risk rules; restricted status indicates that the VPN client's connection behavior is abnormal (such as high-frequency failed connections, suspected automated script behavior, etc.), triggering at least one preset risk rule.

[0029] Traditional solutions often focus on rate limiting and blocking after connection establishment. The core of this embodiment lies in controlling which egress server addresses (i.e., the IP addresses of egress servers, also known as egress addresses or egress IPs) attackers can obtain. This prevents malicious devices from effectively acquiring new, usable lists of attack egress server IP addresses, thus depriving subsequent brute-force and enumeration attacks of their foundation. For example, the VPN server pre-determines the VPN client's risk control status based on the client's historical and / or real-time connection behavior, and then distributes different keys to VPN clients with different risk control statuses. Specifically, a first distribution key is sent to VPN clients with a normal risk control status, and a second distribution key is sent to VPN clients with a restricted risk control status.

[0030] Both the first and second distribution keys are digital tokens, typically with expiration dates. VPN clients cannot directly obtain the actual egress server address statically; instead, they need to use the key distributed by the VPN server to retrieve it. This allows the VPN server to identify the VPN client's risk control status (normal or restricted) based on the key type carried in the client's request, and to execute different sample subset generation strategies accordingly. Furthermore, the time interval for the VPN client to retrieve the egress server address is also related to the key type. If the received key is the first distribution key, the VPN client retrieves the egress server address from the VPN server based on the first time interval; if the received key is the second distribution key, it retrieves the egress server address from the VPN server based on the second time interval.

[0031] The first time interval is shorter than the second time interval. For example, the first time interval is typically configured to be in the minute range (e.g., 1 minute, 5 minutes, etc.) to ensure that VPN clients in normal state can obtain fresh and available egress IPs, while the second time interval is typically configured to be in the hour range (e.g., 2 hours, 12 hours, etc.) or longer (e.g., 1 day, 3 days, etc.), which can significantly reduce the rate at which VPN clients in restricted state probe egress server addresses.

[0032] S120: When receiving a request from a VPN client to retrieve the exit server address, if the request carries the first distribution key, a sample subset is generated using a dynamic address generation strategy; if the request carries the second distribution key, a restricted address generation strategy is used to generate a sample subset, which is then encrypted and sent to the VPN client.

[0033] The VPN server executes different sample subset generation strategies based on the different risk control statuses of the VPN client. If the VPN client's egress server address retrieval request carries the first distribution key, it indicates that the VPN client's risk control status is normal, and a dynamic address generation strategy is used to generate the sample subset; if the VPN client's egress server address retrieval request carries the second distribution key, it indicates that the VPN client's risk control status is restricted, and a restricted address generation strategy is used to generate the sample subset.

[0034] The dynamic address generation strategy is an address sampling mechanism designed for VPN clients in normal operation. For example, this strategy can combine client attributes (such as account level, line type, and device type) and / or real-time system status (such as server load and IP health) to dynamically select a set of exit server addresses from the exit server address set, forming a sample subset. The VPN server assigns a unique identifier (referred to as an exit server identifier) ​​to each exit server and maintains a set of IP addresses for all available exit servers. The number of exit server addresses in each sample subset generated by the VPN server is less than the number of exit server addresses in the complete exit server address set.

[0035] The restricted address generation strategy is an address sampling mechanism designed for VPN clients in a restricted state. This strategy aims to limit the address changes that VPN clients can obtain. For example, cache reuse or fixed sampling methods can be used to make VPN clients repeatedly obtain the same or highly similar exit server addresses over a long period of time.

[0036] This embodiment can achieve an intelligent balance between security protection and user experience. Specifically, the above method can ensure that VPN clients in normal state always obtain high-quality, diverse, and low-latency exit server addresses, thus guaranteeing their connection experience; while VPN clients in restricted state are effectively limited to a fixed range of addresses with low update frequency, making it impossible to quickly enumerate new exit server addresses, thereby suppressing the efficiency and feasibility of brute-force attacks from the root.

[0037] In some embodiments, generating a sample subset using a dynamic address generation strategy includes: sampling from the set of egress server addresses based on first specified information to obtain a sample subset. Correspondingly, generating a sample subset using a restricted address generation strategy includes: detecting whether a cached sample subset corresponding to the VPN client exists in the cache; if it exists, using the cached sample subset as the sample subset; if it does not exist, sampling from the set of egress server addresses based on second specified information to obtain a sample subset.

[0038] In this embodiment, if the VPN client's request carries a first distribution key, the VPN server will directly run a sampling algorithm based on the first specified information to sample from the set of egress server addresses and obtain a sample subset. If the VPN client's request carries a second distribution key, the server will first check if there is a cached sample subset corresponding to the VPN client in the cache. If there is a cached sample subset corresponding to the VPN client in the cache, it will directly use the cached sample subset corresponding to the VPN client as the sample subset. If there is no cached sample subset corresponding to the VPN client in the cache, it indicates that the VPN client is pulling an egress server address for the first time after running, or that the sample subset pulled and stored in the previous cache period has expired. The VPN server will then run a sampling algorithm based on the second specified information to sample from the set of egress server addresses and obtain a sample subset. In this way, the sample subset pulled by the VPN client in a restricted state will be fixed or highly similar within a longer time window, thereby achieving the purpose of suppressing attacks.

[0039] The first specified information refers to a set of input parameters and policy rules used to guide the sampling algorithm during the dynamic address generation process. In some examples, the sample subset is associated with the VPN client's account level, line type, and / or device attributes. Accordingly, the first specified information may include account level (e.g., free user, VIP user, etc.), subscribed line type (e.g., game acceleration, streaming media unlock, etc.), and / or device attributes (e.g., operating system, network type, etc.). In other examples, based on the above examples, the sample subset may also be associated with the VPN client account, so that different VPN clients may not pull completely identical sample subsets within the same time period. In this case, the first specified information includes one or more of the account level, subscribed line type, and device attributes, as well as the VPN client's account identifier.

[0040] A cached sample subset refers to a subset of samples that a VPN client retrieves and stores in the VPN server's cache for the first time after entering a restricted state or within the previous cache cycle.

[0041] The second specified information refers to a set of input parameters and policy rules used to guide the sampling algorithm during the restricted address generation process. In some examples, the content of the second specified information can be the same as that of the first specified information. In other examples, the second specified information can be simplified and fixed policy information, without including VPN client-specific attributes (such as line type). Therefore, when sampling based on the second specified information, only unoptimized and easily reproducible samples can be generated. This allows the restricted VPN client to repeatedly face the same or highly similar sample subsets over hours or even longer, making the number of new targets that attackers can probe and try per unit time approach zero, thus reducing the efficiency of their automated enumeration and brute-force scripts to extremely low levels.

[0042] In some embodiments, to further refine the generation and control of sample subsets, the VPN server, when generating sample subsets, first parses the VPN client's account level (e.g., free, VIP), line type (distinguished by country or line pool, e.g., different IP sets corresponding to country A and country B pools), device attributes (e.g., the country or region of the device, which can be inferred from device reports or network identifiers), and the distribution key type (normal or restricted) carried in the current fetch request. Then, the VPN server matches the parsed combination of "account level + line type + device attribute + distribution key type" in a pre-stored policy configuration table to obtain the sample generation parameters corresponding to that combination. The sample generation parameters include: sample size, update time interval (TTL), candidate pool range, and filtering rules (e.g., removing recently blocked, high-load, or high-failure-rate addresses). Based on this, the VPN server generates a sampling seed based on the current time window number and the VPN client's account identifier or device identifier, and performs pseudo-random sampling from the candidate pool range according to this sampling seed to obtain a sample subset that meets the sample size requirements.

[0043] The VPN server can also pre-generate two sample subsets according to the normal policy and the restricted policy in the same match, and cache them as different cache keys so that the corresponding sample subset can be directly hit when the client state changes.

[0044] In some embodiments, VPN clients in a normal state and those in a restricted state differ in sample generation across three dimensions. Specifically, when a VPN client is in a normal state and using the first distribution key, the VPN server executes a dynamic address generation strategy: it disables sample caching reuse for that client, configures a shorter first time interval (e.g., 30 or 60 seconds), and samples a larger subset of samples (e.g., 200 addresses) from a larger candidate pool (e.g., 2000 IP addresses). When a VPN client is in a restricted state and using the second distribution key, the VPN server executes a restricted address generation strategy: it prioritizes returning the cached subset of samples, configures a significantly longer second time interval (e.g., 5 hours), and samples a subset of samples from a more rigorously filtered second candidate pool. The filtering rules for the second candidate pool include removing addresses suspected of being monitored, heavily blocked, with recent high failure rates, or located in sensitive geographical areas, and filling gaps from a backup pool. Thus, the restricted subset and the normal subset differ significantly in both set composition and update rhythm.

[0045] In some embodiments, when a dynamic address generation strategy or a restricted address generation strategy is used to generate a sample subset, the sample subsets obtained by different VPN clients within the same time period are not completely identical.

[0046] The sampling seed can be generated using the VPN client's account identifier, device identifier, account level, line type, device region, and current time window number. Based on the sampling seed, a deterministic sampling algorithm is used to select addresses from the candidate pool to form a sample subset. Since different VPN clients have different account identifiers or device identifiers, their sampling seeds will also be different, resulting in differences in the sample subsets obtained by VPN clients within the same time window.

[0047] Specifically, to ensure that different clients obtain different sample subsets within the same time period, the VPN server can perform controlled personalized processing when generating sampling seeds. Specifically, the VPN client's account identifier, device identifier, account level, line type, device region, and current time window number are used as factors in the generation of the sampling seed. The time window number is calculated as floor(current timestamp / TTL). Based on this sampling seed, the VPN server uses a deterministic sampling algorithm (such as pseudo-random shuffling and selecting the top N, hash sorting and selecting the Top-N, or consistent hashing) to select addresses from the candidate pool to form the sample subset. Because different VPN clients have different account identifiers or device identifiers, even within the same time window and the same line type, the generated sampling seeds will differ, resulting in different clients obtaining different sample subsets within the same time window.

[0048] Furthermore, in some embodiments, when generating sample subsets using a restricted address generation strategy, the sample subsets pulled by the VPN client multiple times during the restricted state are not completely identical but highly similar. Specific operations include: generating a core set on the first pull request or when the cache expires; binding and caching the core set with the VPN client; setting the cache validity period to a second time interval; simultaneously maintaining a perturbation candidate set; within the second time interval, returning the core set for each pull request, and extracting a small number of addresses from the perturbation candidate set as perturbation items based on a shorter sub-time window or the number of requests; merging the perturbation items with the core set and returning the result.

[0049] In this embodiment, to ensure that the sample subsets retrieved by VPN clients in a restricted state are highly similar but not completely identical during the restricted period, the VPN server can employ a return mechanism combining a core set and a small amount of perturbation. Specifically, when a VPN client first enters a restricted state or its cache expires, the VPN server generates a core set, denoted as S_core (this set constitutes the majority of the sample subset), binds this core set to the client identifier, and caches it, setting the cache expiration time to a second time interval (e.g., 5 hours). Simultaneously, the VPN server generates or maintains a perturbation candidate set, denoted as S_noise_pool. Within the second time interval, the VPN server consistently returns the core set S_core for each retrieval request, and extracts a small number of addresses (e.g., 1 to 2) from the perturbation candidate set as perturbation items based on a shorter sub-time window (e.g., 10 minutes) or the number of requests. These perturbation items are then merged with the core set and returned. When individual addresses in the core set need to be replaced due to being blocked or offline, the VPN server can select alternative addresses from the perturbation pool or a backup pool to update the core set and reset the cache expiration time. This mechanism ensures that the core address obtained by the restricted VPN client remains unchanged over a long period of time during multiple fetches, while the perturbation term changes slightly with each sub-time window, thus achieving a balance between suppressing brute-force enumeration and dealing with address failures.

[0050] In some embodiments, before obtaining the risk control status of the VPN client, the method further includes: (1) Obtain connection behavior data of VPN clients within a preset time period in the past; Connection behavior data refers to the raw event logs generated by VPN clients during connection attempts, connection establishment, and usage, reflecting their operational patterns and intentions. Connection behavior data can be collected locally by the VPN client and reported to the VPN server, or recorded by the VPN server during connection processing. Connection behavior data typically includes, but is not limited to, connection trigger frequency, connection failure indicators, account association changes, and short-term repeated connection information.

[0051] Connection trigger frequency refers to the number of connection attempts initiated by a VPN client within a unit of time (e.g., 1 minute). Connection failure metric refers to the absolute number of connection failures or the failure rate (i.e., number of failures, total number of attempts) within a specific time window. Account association change information refers to the number and changes of different devices bound to the same user account (distinguished by device fingerprints). Short-term repeated connection information refers to highly similar sequences of repeated connection operations initiated by the same device within a short period of time (e.g., durations in seconds, 3 seconds, 5 seconds, etc.).

[0052] The VPN server continuously receives connection behavior data streams from various VPN clients through client SDK reporting or server-side log collection. For any given VPN client, the VPN server extracts all relevant behavioral events generated within a preset time period (e.g., the past 10 minutes) from the client's connection behavior data stream. It then converts the extracted raw events into structured data records, such as [timestamp, client identifier, event type, event result, related device fingerprint], for subsequent processing.

[0053] (2) Aggregate the connection behavior data to obtain aggregated data; Aggregation processing refers to the computational process of statistically analyzing, summarizing, and extracting features from raw, discrete connected behavior data. It aims to transform a series of low-level events into high-level feature indicators that can reflect the overall behavioral pattern.

[0054] Aggregated data is a structured set of feature vectors or indicators that are output after aggregation processing and are used to characterize the behavior of VPN clients within a preset time period.

[0055] Regarding aggregation processing, VPN servers can perform grouped statistical calculations based on client identifiers (or account identifiers) and their behavioral data within a preset time period. Calculation dimensions can include frequency, failure, device, and behavior sequence dimensions. The frequency dimension calculates the total number of connection triggers and the average number of connections per minute. The failure dimension calculates the total number of connection failures and the failure rate (equal to the number of failures / total number of connections). The device dimension calculates the number of uniquely associated devices. The behavior sequence dimension counts short-term repeated connections (i.e., the number of times the short-term repeated connection behavior of successful connection-immediate disconnection-reconnection occurs). To further capture trends, metrics such as the "growth slope of the connection frequency in the last 2 minutes relative to the average of the previous 8 minutes" and the "rolling average of the failure rate" can be calculated.

[0056] Finally, the calculation results of each indicator are assembled into a fixed aggregated data feature vector, for example: {“client_id”:“xxx”,“window”:“last_10min”,“total_attempts”:150,“failure_rate”:0.68,“unique_devices”:3,“rapid_retry_count”:45}. `client_id` represents the client identifier, `window` represents the time window (i.e., the preset duration in the past), `total_attempts` represents the total number of connection triggers, `failure_rate` represents the failure rate, `unique_devices` represents the number of unique devices, and `rapid_retry_count` represents the number of short-term repeated connections.

[0057] (3) Conduct a risk assessment based on the aggregated data to obtain the risk assessment results; Risk assessment can be performed by analyzing aggregated data based on pre-defined risk assessment rules or models. The risk assessment result is a binary judgment (i.e., normal behavior or abnormal behavior). For example, risk assessment rules might include: "If the total number of connection triggers is greater than 100 and the failure rate is greater than 0.6, then mark it as abnormal behavior," or "If the number of short-term repeated connections is greater than 50, then mark it as abnormal behavior." The risk assessment model can be a pre-trained classification model (such as a logistic regression model, an isolated forest model, etc.). The model outputs the probability or classification result of abnormal behavior based on the input aggregated data.

[0058] In some examples, a VPN server can invoke a risk assessment module that has already deployed risk assessment rules or models to perform risk assessment operations. In this case, the VPN server inputs the generated aggregated data into the risk assessment module.

[0059] (4) When the risk assessment result is that the behavior is normal, set the risk control status of the VPN client to normal; when the risk assessment result is that the behavior is abnormal, set the risk control status of the VPN client to restricted.

[0060] When the VPN client's risk assessment result is normal behavior, the VPN server sets the client's risk control status to normal. When the VPN client's risk assessment result is abnormal behavior, the VPN server sets the client's risk control status to restricted. The final risk control status is then bound to the client's client identifier and stored in the VPN server's status management service or database, which can be queried and used in subsequent processes such as step S110.

[0061] This embodiment replaces manual guessing or simple thresholds with intelligent analysis based on multi-dimensional behavioral characteristics, which can more accurately identify malicious behaviors such as automated scripts and brute-force scanning, while reducing false positives on normal users.

[0062] In some embodiments, the connection behavior data is aggregated to obtain aggregated data, including: within a preset statistical window, the connection behavior data is statistically summarized by account dimension and / or device dimension to obtain aggregated feature data; the aggregated feature data includes one or more of the following: number of connection triggers, number of connection failures, failure rate, number of short-term repeated connections, growth rate of the number of connections reached by different egress server addresses, and changes in the number of devices associated with the same account.

[0063] The preset statistical window refers to the length of the time interval used when aggregating and statistically analyzing connection behavior data. This window can be a sliding or fixed time range, and can be configured with different granularities, such as 30 seconds, 1 minute, or 5 minutes, depending on the risk control sensitivity requirements. The shorter the window, the more timely the response to sudden behaviors; the longer the window, the more stable the statistical characteristics.

[0064] Account-based analysis refers to the aggregation and analysis of connection behavior data from all devices belonging to the same user account, using the user account (such as login name or user ID) as the statistical subject. Account-based analysis is suitable for detecting account-level anomalies, such as a single account initiating a large number of connections from multiple locations and devices within a short period of time.

[0065] Device dimension refers to analyzing connection behavior data generated only by the device itself, using device fingerprints (such as device ID, hardware feature combinations, client instance identifiers, etc.) as the statistical subject. Device dimension is suitable for detecting device-level anomalies, such as a device experiencing high-frequency failed reconnections or mechanically repetitive operations.

[0066] Aggregated feature data refers to a set of quantitative indicators output after statistically summarizing raw connection behavior events. These indicators transform discrete event logs into numerical features that can be directly processed by risk models. For example, aggregated feature data includes one or more of the following: connection trigger count, connection failure count, failure rate, short-term repeated connection count, growth rate of the number of connections reached from different egress server addresses, and changes in the number of devices associated with the same account. Connection trigger count refers to the total number of connection attempts initiated by a VPN client within a statistical window; this indicator reflects the activity level of the VPN client. Connection failure count refers to the number of connection attempts that failed (e.g., timeout, rejection, protocol error) within a statistical window; typically, a high failure count is related to invalid IP enumeration or credential probing. Failure rate is the ratio of connection failure count to connection trigger count, used to eliminate the bias caused by the time length of the absolute number, and better characterizes the stability of connection quality. Short-term repeated connection count refers to the number of consecutive connection attempts initiated against the same or similar targets within a very short time interval (e.g., less than 1 or 2 seconds). The growth rate of the number of different exit server addresses reached refers to the rate at which the number of different exit IP addresses successfully connected to or attempted to connect to by a VPN client changes over time within the statistical window. Normal users typically connect to only a few nodes, while brute-force attackers quickly traverse a large number of different IPs; therefore, this metric is a key characteristic for identifying brute-force attacks. The change in the number of devices associated with the same account refers to the number of different device fingerprints bound to the same account and their changing trend within the statistical window. Generally, if an account is associated with a large number of different devices in a short period, it may indicate that the account credentials have been leaked and used by distributed scripts.

[0067] In this embodiment, the VPN server first filters out all event records related to the current client to be evaluated (using account identifier or device identifier as the key) from the original connection behavior data. The filtering scope can be limited to a preset statistical window, such as obtaining data from the past minute.

[0068] Secondly, the VPN server selects to perform statistics by account, device, or both, depending on the requirements of the risk control strategy. If the account dimension is selected, events belonging to all devices under the same account will be aggregated and calculated; if the device dimension is selected, only the current device will be calculated independently; when both are used simultaneously, aggregated features at the account level and device level can be generated respectively.

[0069] Then, the VPN server performs statistical summary calculations on the filtered event records.

[0070] Specifically, the VPN server can calculate each indicator in the above aggregated feature data item by item, including the following operations: The number of connection triggers is obtained by counting the number of events. The number of events with a "failed" field in the statistics results in the number of connection failures. The failure rate is obtained by dividing the number of failures by the number of triggers. Identify sequences of adjacent events with an interval of less than a preset threshold (e.g., 1 second) and the same or continuously increasing target address, and count the number of short-term repeated connections. Extract the exit server address accessed in each successful connection or connection attempt, calculate the number of duplicates for different addresses within the window, and divide by the window duration to obtain the reach growth rate. At the account level, query the list of device fingerprints bound to the account, and calculate the number of newly appearing device fingerprints in the window and the change in the total number of associated devices.

[0071] Finally, the VPN server organizes all the calculated indicator values ​​into a structured aggregated feature data object, such as JSON format or feature vector, thus obtaining aggregated feature data.

[0072] This embodiment, through the aforementioned aggregation process, can compress massive, discrete connection events into a small number of quantifiable features with clear behavioral semantics. This significantly reduces the dimensionality of input data and computational complexity for subsequent risk assessment operations, enabling VPN servers to complete risk control judgments on a large number of VPN clients within milliseconds. Furthermore, by introducing features such as "growth rate of the number of connections reached from different exit server addresses" and "number of short-term repeated connections," automated enumeration brute-force behavior can be accurately identified. Normal users typically connect to only a small number of stable nodes, while attackers rapidly traverse a large number of different IPs. This difference is clearly distinguishable in the aggregated features, effectively reducing the false positive rate. Finally, this embodiment supports dual-track statistics by account and device dimensions, enabling the system to both capture multi-device abuse caused by leaked account credentials and locate malicious behavior on a single device, achieving a more granular risk profile.

[0073] In some embodiments, risk assessment is performed based on aggregated data to obtain risk assessment results, including: calculating sub-risk scores for the VPN client across multiple risk dimensions based on aggregated feature data; assigning weights to each sub-risk score based on at least one of the following: VPN client account level, line country or region, historical reputation, and health status of the exit server address; weighted summing of each sub-risk score and its weight to obtain a comprehensive risk score for the VPN client; determining the risk assessment result as abnormal behavior when the comprehensive risk score exceeds a preset anomaly determination threshold; and determining the risk assessment result as normal behavior when the comprehensive risk score does not exceed the anomaly determination threshold.

[0074] Sub-risk scores are quantitative scores calculated based on relevant indicators in aggregated feature data for a specific risk dimension (such as connection frequency risk, failure rate risk, device migration risk, address enumeration risk, etc.). Each sub-risk score is a normalized numerical value (e.g., between 0 and 100) used to characterize the suspiciousness of client behavior in that dimension. For example, a sub-score for "high-frequency attack risk" can be calculated based on "number of connection triggers" and "number of short-term repeated connections"; a sub-score for "enumeration brute-force risk" can be calculated based on "failure rate" and "growth rate of the number of addresses reached by different exit servers".

[0075] Risk dimensions refer to the different independent aspects used when assessing client behavior risk, including but not limited to connection frequency (assessing whether the connection rate far exceeds that of normal users), failure rate (assessing whether a large number of failures are caused by blind probing), device association (assessing whether accounts are abnormally migrating between multiple devices), and address enumeration (assessing whether different exit IPs are traversed at high speed). Each dimension corresponds to a sub-risk score.

[0076] Weights are coefficients assigned to each sub-risk score when calculating the overall risk score. The magnitude of the weight reflects the importance or credibility of that risk dimension in the current client context. Weights can be dynamically configured, ranging from 0 to 1, with the sum of all weights being 1. For example, for a high-reputation account, the weight of the "failure rate risk" dimension can be lowered because the account has a good historical behavior, and occasional failures are more likely to be due to network issues than attacks.

[0077] Weighted summation is a mathematical operation that multiplies each sub-risk score by its corresponding weight, then sums the products to obtain a single overall risk score. The calculation formula can be: Overall Risk Score = Σ(Sub-risk score_i × Weight_i).

[0078] Account level refers to the paid or credit level of a user account (such as free, basic, VIP, enterprise), which is used for differentiated security strategies.

[0079] The country or region of the route refers to the country or region where the exit server requested by the VPN client is located (such as the United States, Japan, Singapore).

[0080] Historical reputation refers to a reputation score accumulated based on a VPN client's long-term past behavior (e.g., whether it has been marked as restricted in the past 7 days, whether it has passed human verification, etc.). A client with a good reputation can reduce the sensitivity of its current abnormal behavior.

[0081] The health status of the exit server address refers to the health score of the exit server address that the VPN client is currently connecting to or frequently trying to access (such as whether the address has been heavily blocked recently, whether it is under high load, or whether it has been marked as suspicious). If the health status of the exit server address itself is poor, the high failure rate of the VPN client may not be due to abnormal behavior on its own.

[0082] The anomaly detection threshold is a preset critical value (e.g., 70 points) used to determine whether the overall risk score meets the standard for "abnormal behavior". This threshold can be configured differently for different account levels or network regions. For example, the threshold for VIP accounts can be set to 80, and the threshold for free accounts can be set to 60, in order to achieve refined management.

[0083] In this embodiment, the VPN server first calculates the sub-risk score of the VPN client on multiple preset risk dimensions based on aggregated feature data (including indicators such as the number of connection triggers, failure rate, number of short-term repeated connections, growth rate of the number of connections reached by different exit server addresses, and changes in the number of devices associated with the same account). For example: (1) Calculate the high-frequency attack sub-risk score based on the "number of connection triggers" and the "number of short-term repeated connections". Specifically, the number of triggers can be compared with a preset baseline (e.g., a maximum of 10 times per minute for normal users), and the excess part can be linearly mapped to 0-100 points; then the penalty score of the number of short-term repeated connections is added to obtain the high-frequency attack sub-risk score. (2) Calculate the risk score of the brute force based on the "failure rate" and the "growth rate of the number of addresses reached by different exit server addresses". Specifically, when the failure rate exceeds 50% and the address growth rate exceeds 5 per minute, the score approaches 100; otherwise, it is reduced proportionally. (3) Calculate the account abuse sub-risk score based on the "change in the number of devices associated with the same account". Specifically, if more than 3 new devices are added in a short period of time, the score is set to 100; otherwise, it is positively correlated with the change.

[0084] The calculation of each sub-risk score can use a pre-trained piecewise function or a lightweight regression model to ensure computational efficiency.

[0085] Secondly, the VPN server obtains the VPN client's contextual information, such as account level (queried from the user database), the country or region of the currently requested route (extracted from the request parameters), historical reputation (read from the risk control storage of the number of restricted records in the past 7 days), and the health status of the exit server address attempted by the client (obtained from the IP monitoring service). Based on at least one of these pieces of information, the VPN server assigns weights to each sub-risk dimension. For example: For high-reputation VIP accounts, the weight of the "failure rate risk" dimension is set to 0.1 (low), the weight of the "account abuse risk" dimension is set to 0.05 (very low), the weight of the "high-frequency attack risk" dimension is set to 0.2, and the weight of the "enumeration brute force risk" dimension is set to 0.65. For free accounts located in areas with unstable networks (such as developing countries): the weight of the "failure rate risk" dimension will be reduced to 0.15, while the weight of the "high-frequency attack risk" dimension will remain at 0.4, and the weight of the "enumeration brute-force risk" dimension will be 0.45.

[0086] If the health status of the export server address shows that the address has a high recent blocking rate, considering that the failure may be due to the IP itself rather than the client's behavior, the weight of the "failure rate risk" dimension can be appropriately reduced.

[0087] Weight allocation can be achieved through table lookup or a lightweight rule engine, ensuring real-time performance for each evaluation.

[0088] Then, the VPN server performs a weighted summation operation, for example: Overall Risk Score = (Sub-risk score_frequency × weight_frequency) + (Sub-risk score_failure rate × weight_failure rate) + (Sub-risk score_enumeration × weight_enumeration) + (Sub-risk score_device × weight_device). This score is a value between 0 and 100.

[0089] Finally, the VPN server obtains the anomaly detection threshold corresponding to the current VPN client's account level or the country or region of the connection (e.g., a threshold of 80 for VIP accounts and 60 for free accounts), and compares the overall risk score with this anomaly detection threshold: If the overall risk score is greater than or equal to the anomaly detection threshold, the VPN client is determined to have abnormal behavior in the risk assessment.

[0090] If the overall risk score is less than the anomaly determination threshold, the behavior is judged to be normal.

[0091] This embodiment introduces multi-dimensional sub-risk scores and a dynamic weighting mechanism into the aforementioned fine-grained risk assessment operation. This allows the risk assessment to adaptively adjust its sensitivity based on client context (such as account level and regional network quality), thereby reducing the false positive rate for high-reputation users or users in unstable network areas, while maintaining strict monitoring of low-reputation, high-risk groups. Furthermore, by incorporating the health status of the egress server address into the weighting adjustment factors, it can effectively distinguish between "failures caused by server malfunctions" and "failures caused by malicious client behavior," avoiding incorrectly penalizing normal users due to server-side issues and improving the fairness and accuracy of the risk control system.

[0092] In some embodiments, the method further includes: when the risk control status of the VPN client is restricted, in response to receiving a risk control status update request sent by the VPN client, updating the risk control status of the VPN client to normal; the risk control status update request is a request sent by the VPN client when it detects that a preset trigger condition is met and performs a local human-machine verification process, and the verification result is passed.

[0093] This embodiment provides a mechanism for lifting the restricted status. This mechanism provides a self-help recovery path for genuine users who have been misjudged or whose behavior has been temporarily abnormal, while maintaining a high barrier against automated attacks.

[0094] The VPN client that receives the second distribution key will check whether the preset triggering conditions are met.

[0095] Preset trigger conditions are a series of rules that are pre-configured locally on the VPN client to determine whether the human verification process should be initiated. The purpose of setting these conditions is to capture proactive user behavior attempting to restore the connection or signals of persistent abnormalities.

[0096] Preset trigger conditions may include at least one of the following: a. User actively triggers the connection operation; for example, the user manually clicks the "Reconnect" or "Refresh Node" buttons on the front-end interface; b. The number of connection triggers reaches the first preset threshold; for example, the number of times the VPN client retryes the connection reaches the preset limit (e.g., 5 times). c. If the number of times the VPN client's risk assessment results show abnormal behavior within a preset time period reaches the second preset threshold, then the risk assessment results will continue to indicate abnormal behavior.

[0097] When any of the triggering conditions are met, the VPN client executes a local human verification process. This process distinguishes human users from automated programs. For example, the VPN client loads pre-set verification challenges (such as image puzzles, text selection, simple logic problems, etc.) from local resource files and displays them to the user in the application interface. The user completes the interactive operation according to the prompts. Afterwards, the VPN client compares the user's input with the pre-set correct answer (or the hash value of the answer) locally. If the comparison is successful, a "verification passed" result is generated, and a recovery credential is generated locally. This credential can consist of a client identifier, a timestamp, and a verification result signature, used to prove to the VPN server that the VPN client has passed the local human verification. If the comparison fails, the user can be prompted to retry, or a cooldown period can be entered after accumulating a number of failures. The human verification process does not require sending additional network requests to the VPN server.

[0098] After the VPN client passes local human verification, it proactively sends a risk control status update request to the VPN server. This request, carrying a recovery credential, requests the VPN server to update the client's risk control status from restricted to normal. Upon receiving the request, the VPN server verifies the recovery credential, checking its signature validity, expiration date (e.g., within 5 minutes of generation), and whether it has been previously used (to prevent replay attacks). Next, it checks if the client's risk control status, as declared in the recovery credential, is currently recorded as restricted in the server's records. If so, the VPN server determines that the client has undergone manual intervention, its risk has been temporarily mitigated, and updates its risk control status from restricted to normal. If not, the request is rejected, and the client's risk control status remains unchanged. After updating the client's risk control status, the VPN server can synchronize the updated status to relevant systems and return the request processing result to the client. This can also trigger subsequent processes, such as distributing a new first distribution key to the client.

[0099] This embodiment allows VPN clients in a restricted state to independently complete human verification without relying on potentially blocked network channels. Furthermore, the entire verification process, including computation and interaction, is completed locally on the VPN client; the VPN server bears no load from verification requests, completely eliminating the possibility of attackers launching DDoS attacks by triggering massive verifications. This embodiment also forms a complete "detection -> restriction -> challenge -> recovery" closed loop with previous restriction mechanisms. This means the VPN server doesn't permanently block the VPN client but provides an outlet for modifying its risk control status, which better aligns with actual operational needs and avoids the long-term impact of misjudgments. For attackers, restoring their automated scripts to risk control status requires the scripts to automatically pass local human verification, raising the attack cost from the network layer to the machine vision and interaction simulation layer, effectively suppressing the persistence of large-scale automated attacks.

[0100] It should be noted that, regarding the steps included in the brute-force prevention method for the export server address provided in any of the above embodiments, unless explicitly stated herein, there is no strict order restriction on the execution of these steps; they can be executed in other orders. Furthermore, at least some of these steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps.

[0101] Based on the same inventive concept, this application also provides an anti-explosive device for export server addresses. In some embodiments, such as Figure 2 As shown, the anti-explosion device for the export server address includes the following modules: The key distribution module 110 is used to obtain the risk control status of the VPN client. When the risk control status is normal, it sends a first distribution key to the VPN client, enabling the VPN client to periodically retrieve the exit server address from the VPN server at a first time interval based on the first distribution key. When the risk control status is restricted, it sends a second distribution key to the VPN client, enabling the VPN client to periodically retrieve the exit server address from the VPN server at a second time interval based on the second distribution key. The first time interval is shorter than the second time interval. The address feedback module 120 is used to generate a sample subset by using a dynamic address generation strategy when it receives a request to retrieve the exit server address from a VPN client. If the request carries a first distribution key, it generates a sample subset by using a restricted address generation strategy. The sample subset is then encrypted and sent to the VPN client.

[0102] In some embodiments, the device further includes a risk control status setting module. The risk control status setting module is configured to: acquire connection behavior data of the VPN client over a preset time period before acquiring the risk control status of the VPN client; aggregate the connection behavior data to obtain aggregated data; perform risk assessment based on the aggregated data to obtain a risk assessment result; set the risk control status of the VPN client to normal when the risk assessment result is normal; and set the risk control status of the VPN client to restricted when the risk assessment result is abnormal.

[0103] In some embodiments, the apparatus further includes a risk control status update module. The risk control status update module is used to update the risk control status of the VPN client to normal in response to receiving a risk control status update request from the VPN client when the risk control status of the VPN client is restricted. The risk control status update request is a request sent by the VPN client when it detects that a preset trigger condition is met, executes a local human-machine verification process, and the verification result is successful.

[0104] In some embodiments, the preset triggering conditions include at least one of the following: the user actively triggers the connection operation; the number of connection triggers reaches a first preset threshold; the number of times the VPN client's risk assessment result shows abnormal behavior within a preset time period reaches a second preset threshold.

[0105] In some embodiments, the risk control status setting module is further used to statistically summarize connection behavior data by account dimension and / or device dimension within a preset statistical window to obtain aggregated feature data; the aggregated feature data includes one or more of the following: connection trigger count, connection failure count, failure rate, short-term repeated connection count, growth rate of the number of connections reached by different egress server addresses, and changes in the number of devices associated with the same account.

[0106] In some embodiments, the risk control status setting module is further configured to calculate sub-risk scores of the VPN client on multiple risk dimensions based on aggregated feature data; assign weights to each sub-risk score according to at least one of the following: VPN client account level, line country or region, historical reputation, and health status of the exit server address; perform weighted summation of each sub-risk score and its weight to obtain the comprehensive risk score of the VPN client; when the comprehensive risk score exceeds a preset anomaly judgment threshold, the risk assessment result is determined to be abnormal behavior; when the comprehensive risk score does not exceed the anomaly judgment threshold, the risk assessment result is determined to be normal behavior.

[0107] Specific limitations regarding the anti-bombing device for export server addresses can be found in the limitations on the anti-bombing method for export server addresses mentioned above, and will not be repeated here. Each module in the aforementioned anti-bombing device for export server addresses can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0108] This application also provides a computer device. In some embodiments, the computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it can implement the export server address anti-crash method provided in any of the above embodiments.

[0109] In some embodiments, the internal structure diagram of a computer device may be as follows: Figure 3As shown. The computer device includes a processor, memory, and network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage medium. The database stores data such as a complete set of export server addresses; the specific data stored can be further specified in the above method embodiments. The network interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a method for preventing the brute-force attack of export server addresses.

[0110] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0111] This application also provides a computer-readable storage medium, in some embodiments of which a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, it implements the exit server address anti-brute-force method provided in any of the above embodiments.

[0112] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0113] Those skilled in the art will understand that implementing all or part of the processes in the above method embodiments can be accomplished by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), Synchlink, DRAM (SLDRAM), memory bus, direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0114] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0115] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A method for preventing brute-force attacks on export server addresses, characterized in that, The method includes: The system obtains the risk control status of the VPN client. When the risk control status is normal, it sends a first distribution key to the VPN client, causing the VPN client to periodically retrieve the exit server address from the VPN server at a first time interval based on the first distribution key. When the risk control status is restricted, it sends a second distribution key to the VPN client, causing the VPN client to periodically retrieve the exit server address from the VPN server at a second time interval based on the second distribution key. The first time interval is shorter than the second time interval. When a VPN client receives a request to retrieve the exit server address, if the request carries a first distribution key, a sample subset is generated using a dynamic address generation strategy; if the request carries a second distribution key, a restricted address generation strategy is used to generate a sample subset. The sample subset is then encrypted and sent to the VPN client.

2. The method according to claim 1, characterized in that, The method of generating a sample subset using a dynamic address generation strategy includes: Based on the first specified information, a sample subset is obtained by sampling from the set of export server addresses. The method of generating a sample subset using a restricted address generation strategy includes: Check if a subset of cached samples corresponding to the VPN client exists in the cache; If it exists, the cached sample subset will be used as the sample subset; If it does not exist, sample from the set of export server addresses according to the second specified information to obtain a sample subset.

3. The method according to claim 1, characterized in that, Before obtaining the risk control status of the VPN client, the method further includes: Obtain connection behavior data of the VPN client over a preset period of time; The connection behavior data is aggregated to obtain aggregated data; A risk assessment is performed based on the aggregated data to obtain the risk assessment results. When the risk assessment result is that the behavior is normal, the risk control status of the VPN client is set to normal. When the risk assessment result indicates abnormal behavior, the risk control status of the VPN client will be set to restricted.

4. The method according to claim 3, characterized in that, The method further includes: When the risk control status of the VPN client is restricted, in response to receiving a risk control status update request sent by the VPN client, the risk control status of the VPN client is updated to normal; The risk control status update request is a request sent by the VPN client when it detects that a preset trigger condition is met, executes a local human-machine verification process, and the verification result is successful.

5. The method according to claim 4, characterized in that, The preset triggering condition includes at least one of the following: The user actively triggers the connection operation; The number of connection triggers has reached the first preset threshold; Within a preset time period, the risk assessment result of the VPN client shows that the number of times the abnormal behavior reaches a second preset threshold.

6. The method according to claim 3, characterized in that, The aggregation process based on the connection behavior data to obtain aggregated data includes: Within a preset statistics window, the connection behavior data is statistically summarized by account dimension and / or device dimension to obtain aggregated feature data; the aggregated feature data includes one or more of the following: connection trigger count, connection failure count, failure rate, short-term repeated connection count, growth rate of the number of connections reached by different egress server addresses, and changes in the number of devices associated with the same account.

7. The method according to claim 6, characterized in that, The step of performing a risk assessment based on the aggregated data to obtain a risk assessment result includes: Based on the aggregated feature data, calculate the sub-risk scores of the VPN client across multiple risk dimensions; Weights are assigned to each of the sub-risk scores based on at least one of the following: VPN client account level, line country or region, historical reputation, and health status of the exit server address. The comprehensive risk score of the VPN client is obtained by weighted summation of the sub-risk scores and their weights. When the comprehensive risk score exceeds the preset anomaly determination threshold, the risk assessment result is determined to be abnormal behavior; When the comprehensive risk score does not exceed the anomaly determination threshold, the risk assessment result is determined to be normal behavior.

8. An anti-explosion device for export server addresses, characterized in that, The device includes: A key distribution module is used to obtain the risk control status of a VPN client. When the risk control status is normal, a first distribution key is sent to the VPN client, causing the VPN client to periodically retrieve the exit server address from the VPN server at a first time interval based on the first distribution key. When the risk control status is restricted, a second distribution key is sent to the VPN client, causing the VPN client to periodically retrieve the exit server address from the VPN server at a second time interval based on the second distribution key. The first time interval is shorter than the second time interval. The address feedback module is used to generate a sample subset using a dynamic address generation strategy when it receives a request from the VPN client to retrieve the exit server address. If the request carries a first distribution key, the module generates a sample subset using a restricted address generation strategy. The module then encrypts the sample subset and sends it to the VPN client.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

10. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method according to any one of claims 1 to 7.

Images