A dynamic dialing VPS node security protection method and system based on end-cloud cooperation

Abstract

This invention discloses a method and system for security protection of dynamically dialed VPS nodes based on end-to-cloud collaboration, belonging to the field of network security technology. It includes S1, where each time a dynamically dialed virtual private server node obtains a new public internet protocol address, it initiates a registration request carrying its device certificate to the cloud control center. After successful verification by the cloud control center, a dynamic security policy bound to the new public internet protocol address and a temporary service port is generated and distributed to the node's local firewall. This invention centrally manages fingerprint configurations through a cloud-based fingerprint emulation pool. Nodes dynamically pull fingerprints and execute them in temporary containers. After the task is completed, the containers are destroyed, allowing the same node to present different fingerprints in different tasks with complete isolation between tasks. This achieves task-level dynamic masquerading and environmental isolation of node behavioral fingerprints.

Description

Technical Field

[0001] This invention relates to the field of network security technology, specifically to a method and system for security protection of dynamic dial-up VPS nodes based on end-to-cloud collaboration. Background Technology

[0002] Dynamic dial-up Virtual Private Server (VPS) nodes periodically dial up to obtain dynamic public Internet Protocol (IP) addresses via Point-to-Point Protocol over Ethernet (PPPoE). This is widely used in business scenarios requiring a large number of outgoing IP addresses, such as network data collection and distributed web crawling. However, while the rapid changes in IP addresses enhance anonymity, they also pose challenges to node security. Traditional security strategies based on fixed IP addresses cannot dynamically adapt to these changes. Nodes expose their attack surface during dial-up transitions, and because nodes are deployed across a public network, cloud-based control centers struggle to implement effective proactive defenses when nodes are offline, especially in the event of intrusion or network failure.

[0003] Regarding security precautions in the context of dynamic Internet Protocol (TCP / IP) addresses, patent publication number CN113572868A discloses a dynamic dial-up internet access method and system. By providing a secure IP address and binding the uplink or downlink data stream to the secure IP address at the cloud gateway resource pool server, the cloud security resource pool server can identify different data streams by recognizing the secure IP address. This allows the server to identify the terminals corresponding to different data streams and determine the internet access requests of different terminals, thus avoiding the problem of not being able to distinguish different terminals when the IP address of the terminal changes dynamically during dynamic dial-up internet access.

[0004] However, the above and similar technical solutions still have the following shortcomings when applied to the security protection of dynamic dial-up VPS nodes: policy updates rely on passive detection after IP changes, and there is a time window from IP change to policy effectiveness, making instantaneous synchronization difficult; when a node is offline, the cloud can only passively mark it and cannot execute defense commands before it goes offline, allowing attackers to continue to lurk or steal data during the offline period; the node uses local static fingerprints, and the fingerprint characteristics of the same node are consistent in different tasks, making it easy for anti-crawling systems to associate and identify it, and frequent resets will reduce collection efficiency. Summary of the Invention

[0005] The purpose of this invention is to provide a method and system for security protection of dynamic dial-up VPS nodes based on end-to-cloud collaboration, so as to solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a method for security protection of dynamic dial-up VPS nodes based on end-to-cloud collaboration, comprising:

[0007] S1. After each successful dial-up connection and acquisition of a new public Internet Protocol (IP) address, the dynamic dial-up virtual private server node initiates a registration request with the device certificate to the cloud control center. After verification by the cloud control center, a dynamic security policy bound to the new IP address and temporary service port is generated and distributed to the node's local firewall.

[0008] S2. The node performs a data interaction task with the target server based on the dynamic security policy, while continuously collecting runtime context information and reporting it to the cloud control center; wherein, before performing the data interaction task, the node pulls the simulated fingerprint configuration specific to the current task from the fingerprint simulation pool of the cloud control center and loads it into a temporarily created container for execution, and destroys the container after the task is completed.

[0009] S3. The cloud control center assesses the risk of node disconnection based on the aforementioned runtime context information. When the risk of disconnection exceeds the threshold or an abnormal event is actively reported by the node, a defense instruction is generated and sent to the node. The node stores the defense instruction in a non-volatile secure storage area independent of the business operating system.

[0010] S4. When a node meets the preset abnormal offline triggering conditions, the bootloader reads and executes the defense instructions in the secure storage area before the business operating system starts.

[0011] Furthermore, the generation of the dynamic security policy includes:

[0012] The cloud control center verifies the legitimate identity of the node based on the device certificate and generates a unique session identifier for this dial-up call.

[0013] The cloud control center queries the task list for the current tasks associated with the node, and extracts the task identifier and the preset task lifecycle.

[0014] The cloud control center uses the new public Internet Protocol address as the source address and the temporary service port as the destination port to generate a firewall allow rule, and sets the validity period of the rule to be consistent with the life cycle of the task.

[0015] The cloud control center binds the firewall access rules with the session identifier and task identifier, and then distributes them to the local firewall of the node.

[0016] Furthermore, the method for constructing the fingerprint simulation pool includes:

[0017] The cloud control center deploys several independent fingerprint collection nodes, each configured with different user agent strings and transport layer security protocol parameters to simulate fingerprints from different client devices.

[0018] During the process of accessing the target server, the fingerprint collection node collects the transport layer security handshake fingerprint and the hypertext transfer protocol request fingerprint.

[0019] The collected transport layer security handshake fingerprints and hypertext transfer protocol request fingerprints are deduplicated, clustered, and validated to remove invalid fingerprints that are rejected by the target server or trigger anti-crawling verification.

[0020] The verified fingerprint configurations are categorized and stored according to the target website type and the strength of the anti-scraping strategy to form a fingerprint simulation pool, and a unique index identifier is assigned to each fingerprint configuration; the unique index identifier is used to establish a mapping relationship with the task identifier of the data collection task.

[0021] The cloud control center re-executes the above steps at a preset cycle to update the fingerprint simulation pool.

[0022] Furthermore, the dynamic retrieval and container isolation of the fingerprint simulation pool includes:

[0023] Before performing a data interaction task, a node sends a fingerprint configuration request to the cloud control center. The request includes at least a task identifier, a target server domain name, and a node identifier.

[0024] The cloud control center queries the corresponding simulated fingerprint configuration from the fingerprint simulation pool based on the task identifier. The simulated fingerprint configuration includes at least the transport layer security handshake fingerprint, user agent string, and session identifier chain.

[0025] After receiving the simulated fingerprint configuration, the node creates a temporary container locally and injects the simulated fingerprint configuration into the network stack and Hypertext Transfer Protocol client of the container.

[0026] The node performs data interaction tasks within the container. After the task is completed, the container process is forcibly terminated and all residual data is cleared.

[0027] Furthermore, the node disconnection risk assessment and defense command issuance in S3 includes:

[0028] The cloud control center inputs the runtime context information reported by the nodes into the pre-trained loss-of-connection risk prediction model and outputs the probability value of the nodes losing contact within a future preset time window;

[0029] The cloud control center determines whether the probability of loss of contact exceeds a preset threshold;

[0030] If the probability of losing contact exceeds a preset threshold, at least one defense command will be selected from the command library based on the node's current status and risk level; the defense commands include data destruction commands, network reset commands, or account locking commands.

[0031] The cloud control center will issue the selected defense commands to the nodes and record the relevant information of this command issuance for subsequent auditing.

[0032] Furthermore, the method for constructing the loss-of-contact risk prediction model includes:

[0033] The cloud control center extracts the runtime context information and corresponding real disconnection event records of several dynamic dial-up virtual private server nodes in the historical running cycle;

[0034] The extracted runtime context information is processed by sliding window to extract statistical and trend features within each time window, and a special feature combination for loss of connection prediction is constructed. The special feature combination includes the CPU fluctuation ratio, network latency autocorrelation coefficient, and the product of abnormal login and runtime.

[0035] The features extracted in each time window are used as input vectors, and whether a loss of contact event occurs within a future time window is used as a label to construct a training sample set; the future time window is dynamically adjusted according to the average dialing cycle of the dynamic dialing virtual private server node.

[0036] Based on the training sample set, an ensemble learning algorithm is used to train a model for predicting the risk of losing contact, and the model outputs the probability value of losing contact of the dynamic dialing virtual private server node within a future preset time window.

[0037] The cloud control center collects new data according to a preset cycle and performs incremental training on the model.

[0038] Furthermore, the abnormal offline triggering conditions include at least one of the following: network interface disconnection duration exceeds a preset value, the number of service process heartbeat loss exceeds a preset value, a forced restart or shutdown signal of the operating system is detected, the node's local security agent continuously reports failures and determines that the cloud control center is unreachable, or the node or the node's local security agent actively triggers an offline command.

[0039] Furthermore, the bootloader reads and executes defense instructions including:

[0040] When a node restarts or powers on, the bootloader reads the offline status flag in the secure storage area before loading the business operating system kernel; if the flag is abnormal, it checks whether there are any defense instructions with an execution status of not executed.

[0041] If there are any unexecuted defense instructions, the bootloader will read and parse them.

[0042] The bootloader calls the corresponding underlying execution interface to execute the defense command based on the command type;

[0043] After the defense command is executed, the execution status of the command is updated to executed. If there are still other defense commands that have not been executed, the above steps are repeated.

[0044] After all defense commands have been executed, the node's offline status flag is reset to normal, and the business operating system kernel is loaded again.

[0045] A dynamic dial-up VPS node security protection system based on end-to-cloud collaboration uses any one of the aforementioned methods for dynamic dial-up VPS node security protection.

[0046] Compared with the prior art, the beneficial effects of the present invention are:

[0047] A method and system for protecting the security of dynamic dial-up VPS nodes based on end-cloud collaboration is proposed. The system enables centralized management and unified policy distribution of multiple nodes through a cloud control center, eliminating the need for individual configuration and maintenance of each node. As the number of nodes increases, the load on the cloud control center grows linearly rather than exponentially, reducing the operational complexity in large-scale node deployment scenarios.

[0048] Meanwhile, by having nodes report to the cloud control center after dialing and verifying their identity before issuing policies bound to the current address and task lifecycle, policies take effect before ports are opened, eliminating the time window between address changes and policy activation. This achieves instantaneous synchronization between dynamic security policies and Internet Protocol address changes. Defense commands are pre-issued and stored in an independent security zone through a loss-of-connection risk prediction model. These commands are then executed by the bootloader after node restart and before the business system starts, enabling proactive defense capabilities in offline node states. Fingerprint configurations are centrally managed through a cloud-based fingerprint simulation pool. Nodes dynamically pull fingerprints and execute them in temporary containers, destroying the containers after task completion. This allows the same node to present different fingerprints in different tasks, with complete isolation between tasks, achieving task-level dynamic masquerading and environmental isolation of node behavioral fingerprints. Attached Figure Description

[0049] Figure 1 This is a schematic diagram of the dynamic security policy generation and distribution process of the present invention;

[0050] Figure 2 This is a schematic diagram of the fingerprint simulation pool construction method of the present invention;

[0051] Figure 3 This is a schematic diagram of the dynamic retrieval and container isolation process of the fingerprint simulation pool according to the present invention;

[0052] Figure 4 This is a schematic diagram of the loss of contact risk assessment and defense command issuance process of the present invention;

[0053] Figure 5This is a schematic diagram of the offline self-execution process of the present invention;

[0054] Figure 6 This is a schematic diagram of the dynamic dial-up VPS node security protection system architecture of the present invention. Detailed Implementation

[0055] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0056] This invention provides a technical solution: a method for security protection of dynamic dial-up VPS nodes based on end-to-cloud collaboration, comprising:

[0057] S1. Each time a Dynamic Dial-up Virtual Private Server Node (hereinafter referred to as "Node") completes a Point-to-Point Protocol (PPPoE) dial-up on Ethernet to obtain a new public Internet Protocol address, it initiates a registration request with the device certificate to the Cloud Control Center. After the Cloud Control Center verifies the request, it generates a dynamic security policy bound to the new public Internet Protocol address and the temporary service port, and sends it to the local firewall of the Node.

[0058] like Figure 1 As shown, the present invention provides a method for generating and distributing dynamic security policies;

[0059] Specifically:

[0060] After obtaining a new public Internet Protocol (IP) address, the node constructs a registration request carrying its device certificate and sends the registration request to the cloud control center via a Transport Layer Security (TLS) encrypted channel. The device certificate contains the node's unique identifier, which is generated by hashing the network interface card (NIC) address, CPU serial number, and disk serial number.

[0061] After receiving the registration request, the cloud control center performs the following operations:

[0062] Verify the signature validity and expiration date of the device certificate to ensure that the certificate has not been tampered with and has not expired;

[0063] Check whether the node's unique identifier in the certificate is in the cloud control center's whitelist of legitimate nodes;

[0064] Verify that the timestamp is within the allowable deviation range (e.g., ±5 minutes) to prevent replay attacks;

[0065] Check if the node currently has any tasks running. If there are tasks, proceed to the next step of the dynamic security policy generation process. If there are no tasks, only record the Internet Protocol address change but do not issue a security policy. The dynamic security policy generation process includes:

[0066] The first step is to generate a unique session identifier for this dialing; the session identifier is used to uniquely identify the entire lifecycle of the node from this dialing to the next dialing.

[0067] The second step is for the cloud control center to query the current tasks associated with the node from the task management module, and extract the task identifier and the preset task lifecycle.

[0068] Third, the cloud control center uses the new public Internet Protocol address as the source address and the temporary service port as the destination port to generate a firewall allow rule, allowing the node to initiate an outbound connection to the target server from the source port, and sets the validity period of the rule to be consistent with the life cycle of the task, which greatly reduces the attack window of the node.

[0069] Step 4: The cloud control center binds the firewall allow rules with the session identifier and task identifier, and sends them to the local firewall of the node; at the same time, a complete dynamic security policy record is formed and persistently stored locally in the cloud control center for subsequent auditing and tracing.

[0070] It is important to note that the cloud control center distributes dynamic security policies to the policy execution modules of the nodes via a TLS encrypted channel. Upon receiving the policy, the node invokes the operating system firewall configuration interface to write the firewall allow rule into its local firewall rule chain. After the rule is successfully written, the node opens a temporary service port and begins waiting for or actively initiating data interaction tasks with the target server.

[0071] S2. The node performs a data interaction task with the target server based on the dynamic security policy, while continuously collecting runtime context information and reporting it to the cloud control center. Before performing the data interaction task, the node retrieves the simulated fingerprint configuration specific to the current task from the fingerprint simulation pool of the cloud control center and loads it into a temporarily created container for execution. After the task is completed, the container is destroyed.

[0072] It should be noted that the runtime context information includes performance metrics (such as CPU utilization and memory utilization), network metrics (such as network latency and packet loss rate), and security metrics (such as the number of abnormal login attempts).

[0073] The node encapsulates the above metrics into runtime context information messages according to a preset format. Each message contains a collection timestamp and a node identifier. The reporting frequency is once every 5 seconds. When an abnormal event is detected (such as a sudden increase in the number of abnormal login attempts), the node immediately and proactively reports it.

[0074] like Figure 2 As shown, the present invention provides a method for constructing a fingerprint simulation pool;

[0075] Specifically:

[0076] The first step is to deploy several fingerprint collection nodes in the cloud control center. Each fingerprint collection node is configured with different user agent strings and transport layer security protocol parameters to simulate fingerprints from different client devices.

[0077] It is important to note that each fingerprint collection node simulates a different client environment through a configuration file. The parameters in the configuration file include the operating system type and version, browser type and version, user agent string, and transport layer security protocol parameters. Each fingerprint collection node is configured with one or more different fingerprint configuration files, and these are rotated according to a preset period (e.g., every 6 hours).

[0078] The second step involves the fingerprint collection node collecting the transport layer security handshake fingerprint and the hypertext transfer protocol request fingerprint during the process of accessing the target server.

[0079] It is important to note that each fingerprinting node uses the aforementioned configuration file to launch a corresponding browser instance and initiates real Hypertext Transfer Protocol (HTTP) requests to a pre-defined list of target websites (e.g., 1000 commonly used websites selected by industry). During the transport layer security handshake phase, the fingerprinting node records the following fields in the client handshake request using the browser's built-in developer protocol or proxy interception tools: a 32-byte random number, a list of supported cipher suites, and the types and order of extended fields (including server name indication, supported elliptic curves, and session tickets). During the HTTP request phase, the fingerprinting node records the following fields and their order in the request header: user agent, receive encoding, receive language, connection method, referrer, and session identifier. Each collection node performs a collection task once a day, collecting data from no fewer than 1000 different target websites each time. The collected fingerprint data is stored in the cloud control center's database.

[0080] The third step is to deduplicatize, cluster, and validate the collected transport layer security handshake fingerprints and hypertext transfer protocol request fingerprints, and remove invalid fingerprints that are rejected by the target server or trigger anti-crawling verification.

[0081] It is important to note that deduplication uses a hash comparison method. The transport layer security parameter field and the hypertext transfer protocol header field of each fingerprint record are concatenated into a string, and a hash value is calculated. If the hash values ​​are the same, it is considered a duplicate fingerprint, and only one record is retained. Cluster analysis uses an unsupervised learning algorithm (such as K-means). The feature vector consists of one-hot encoding of the transport layer security cipher suite set and serialized encoding of the order of the hypertext transfer protocol header fields. Fingerprints with a similarity higher than a preset threshold (e.g., cosine similarity > 95%) are grouped into the same category, and a representative fingerprint configuration is retained for each category. Validity verification methods include: randomly selecting 3 to 5 fingerprint configurations from each cluster, using an automated browser framework to simulate a request to a test server using that fingerprint; if the response status code is 200 and the response message does not contain CAPTCHA keywords or blocked keywords, the verification is considered successful. If the pass rate is less than the preset threshold (e.g., 80%), the entire cluster is marked as unavailable and fingerprint re-collection is triggered; if the pass rate is greater than or equal to the preset threshold, all fingerprint configurations in the cluster are marked as valid and stored in the cache and relational database of the cloud control center.

[0082] The fourth step is to classify and store the verified fingerprint configurations according to the target website type and the strength of the anti-crawling strategy to form a fingerprint simulation pool, and assign a unique index identifier to each fingerprint configuration; the unique index identifier is used to establish a mapping relationship with the task identifier of the collection task.

[0083] It is important to note that the classification rules include: based on the target website's domain suffix and the server type field in the Hypertext Transfer Protocol (HTTP) response header, fingerprint configurations are divided into different categories such as search engine, social media, e-commerce, and government.

[0084] Methods for determining the strength of anti-scraping strategies include: using the same fingerprint configuration to continuously access the same target website a preset number of times (e.g., 10 times), recording the number of times CAPTCHAs or interceptions are triggered, and dividing them into three levels: weak, medium, and strong based on the trigger ratio (e.g., 0-2 triggers are weak, 3-6 triggers are medium, and 7-10 triggers are strong).

[0085] Each fingerprint configuration is assigned a globally unique identifier. When a task is created, the cloud control center selects a matching fingerprint configuration from the fingerprint simulation pool based on the target website type and the anti-scraping strength requirements set by the user, and binds and stores its identifier with the task identifier.

[0086] Step 5: The cloud control center re-executes steps 1 to 4 according to the preset cycle to update the fingerprint simulation pool.

[0087] It's important to note that the cloud control center deploys a scheduled task that triggers an update process every 24 hours. The update uses an incremental approach, only collecting fingerprints for mainstream browsers that have released new versions within the past 24 hours. Specifically, it obtains the latest version number from the browser vendor's official release page. If the version number is higher than the highest version recorded in the fingerprint simulation pool, a new fingerprint collection node configuration is created for collection, and the newly collected and verified fingerprint configuration is added to the fingerprint simulation pool. Simultaneously, the cloud control center performs a full validity verification weekly, re-executing the aforementioned validity verification process for existing fingerprint configurations in the fingerprint simulation pool. Fingerprint configurations that fail verification three consecutive times are marked as invalid and removed from the fingerprint simulation pool to maintain the overall validity of the pool.

[0088] like Figure 3 As shown, the present invention provides a method for dynamic retrieval and container isolation of fingerprint simulation pools;

[0089] Specifically:

[0090] The first step is for the node to send a fingerprint configuration request to the cloud control center before executing the data interaction task. The request includes at least the task identifier, the target server domain name, and the node identifier.

[0091] It is important to note that the fingerprint configuration request uses an application programming interface (API) call, and the request message must include at least the task identifier, the target server domain name, and the node identifier. The node sets a request timeout of 5 seconds; if a timeout occurs, it will retry a preset number of times. For example, it will retry 3 times: after the first timeout, it will wait 1 second before retrying; after the second timeout, it will wait 2 seconds before retrying; and after the third timeout, it will wait 4 seconds before retrying. If the retry still fails, a default fingerprint configuration pre-cached locally on the node will be used as a backup. This default fingerprint configuration is a general fingerprint configuration marked as medium strength in the fingerprint simulation pool, issued by the cloud control center during the node's initial registration and updated periodically.

[0092] The second step is for the cloud control center to query the corresponding simulated fingerprint configuration from the fingerprint simulation pool based on the task identifier. The simulated fingerprint configuration includes at least the transport layer security handshake fingerprint, the user agent string, and the session identifier chain.

[0093] It is important to note that after receiving a request, the cloud control center queries the task configuration table based on the task identifier to obtain the pre-bound fingerprint configuration unique identifier. If the identifier is not found, the cloud control center performs dynamic matching based on the target server domain name. This dynamic matching specifically involves:

[0094] a. Extract the top-level domain or second-level domain from the target server domain, and query the website type to which the domain belongs using a domain classification table. This domain classification table is pre-configured by the cloud control center and contains mappings between common website domains and website types.

[0095] b. Query the fingerprint configuration list of the website type with anti-scraping policy strength in the fingerprint simulation pool.

[0096] c. Randomly select a fingerprint configuration from the query results, encapsulate its unique identifier and configuration content into a response message, and return it to the node. If there is no medium-strength fingerprint configuration for this website type, use a weak-strength configuration; if there is also no weak-strength configuration, use any valid fingerprint configuration from the fingerprint simulation pool.

[0097] The cloud control center encrypts the response message using a transport layer security protocol and returns it. The response message contains a unique identifier for the fingerprint configuration, transport layer security handshake fingerprint parameters, user agent string, and session identifier chain. The cloud control center also records the fingerprint configuration distribution log, including the distribution timestamp, node identifier, task identifier, and fingerprint configuration identifier, for subsequent auditing and fingerprint usage frequency analysis.

[0098] Third, after receiving the simulated fingerprint configuration, the node creates a temporary container locally and injects the simulated fingerprint configuration into the network stack and Hypertext Transfer Protocol client of the container.

[0099] It is important to note that after the node receives and successfully parses the response message, it performs the following operations:

[0100] Create a temporary container. The node calls the host machine's container management application interface (e.g., the Docker engine's application interface for Linux systems) to create a new temporary container. The container image is based on a lightweight operating system (e.g., Alpine Linux), with an image size not exceeding 100 megabytes, and comes pre-installed with a scripting language runtime environment (e.g., Python 3.14.4) and a custom transport layer security protocol modification module. Container configuration parameters include: the container name uses the format tmp_container_ followed by the last four digits of the node identifier and a timestamp to ensure uniqueness; the container lifecycle is set to one-time use; the container is not configured for networking initially, but will be connected after fingerprint injection is complete.

[0101] Injecting a transport layer security handshake fingerprint. The node copies the fingerprint configuration file to a specified path within the container using the file copy function of the container management interface. The fingerprint configuration file is stored in key-value pair format, and its fields include at least: a list of cipher suites, the order of extended fields, and whether session tickets are enabled. The initialization script within the container reads this configuration file at startup and calls the transport layer security protocol context configuration interface to replace the default cipher suite list with the list in the configuration file. This runtime modification changes the default parameters of the transport layer security protocol module, ensuring that subsequent transport layer security protocol calls use the specified cipher suite order and extended field order.

[0102] Inject the Hypertext Transfer Protocol (HTTP) request fingerprint. The node transfers the user agent string and session identifier chain to the specified path within the container using the same file copy function. When constructing the HTTP request, the scripting language runtime environment within the container rearranges the fields in the request header according to the field order specified in the fingerprint configuration, replacing the value of the user agent field with the user agent string in the fingerprint configuration, and replacing the value of the session identifier field with the session identifier chain in the fingerprint configuration.

[0103] Configure the network and start the container. The node executes the container network connection command to connect the container to the node's business network, assigns an independent network protocol address, and sets the container's network mode to bridged mode, so that network traffic inside the container is output through the node's physical network interface. After the network configuration is complete, the node starts the main process inside the container, namely the data acquisition script.

[0104] The total time for container creation and fingerprint injection is typically kept under 2 seconds. If any injection step fails, the node will terminate the container creation process and revert to using the node's local default environment to perform the data collection task. At the same time, it will report the injection failure event to the cloud control center, which will record the event for fault analysis.

[0105] Fourth step: The node performs a data interaction task within the container. After the task is completed, the container process is forcibly terminated and all residual data is cleared.

[0106] It's important to note that the node executes the data acquisition script within the container. The acquisition script sends requests to the target server via a Hypertext Transfer Protocol (HTTP) client started within the container. The execution of the acquisition script is subject to timeout control: if the execution time exceeds 80% of the task's lifecycle, the node sends a soft interrupt signal to the script, indicating that the script is about to terminate; if the execution time exceeds the task's lifecycle, the node forcibly terminates the container process.

[0107] Upon completion of the task, regardless of success or failure, the node performs a destruction operation. This destruction operation includes: stopping the container process, deleting the container, and removing its associated anonymous storage volume. For container storage directories storing sensitive data, multiple overwrite deletion operations are performed to ensure the data is unrecoverable.

[0108] After the destruction operation is completed, the node reports the task completion status to the cloud control center through the Hypertext Transfer Protocol Application Programming Interface. The reported content includes: task identifier, node identifier, task execution result (success or failure), actual task execution time, and fingerprint configuration identifier used.

[0109] After receiving the report, the cloud control center records the execution result of the fingerprint configuration and accumulates the number of uses. The accumulated number of uses is used for: quality assessment: when the number of uses of a fingerprint configuration reaches a preset threshold (e.g., 100 times) and the success rate is lower than a preset threshold (e.g., 80%), it is marked as low quality and will be re-verified first during the next fingerprint simulation pool update. Load balancing: when multiple fingerprint configurations are applicable to the same type of target website, the one with the fewest uses is prioritized for allocation to avoid identification due to excessive use of a single fingerprint. Anomaly detection: when the number of uses of a fingerprint configuration within a preset time window (e.g., 1 hour) exceeds a preset multiple (e.g., 10 times) of the historical average, it is determined to be potentially leaked, immediately temporarily disabled, and an emergency verification is triggered. Rapid response: when a fingerprint configuration is used multiple times consecutively (e.g., 3 times) and causes the task to fail, it is directly marked as suspected invalid and will be verified first during the next fingerprint simulation pool update; if verification passes, the mark is cleared; otherwise, it is removed from the fingerprint simulation pool.

[0110] S3. The cloud control center assesses the risk of node disconnection based on the aforementioned operating context information. When the risk of disconnection exceeds the threshold or an abnormal event is actively reported by the node, a defense command is generated and sent to the node.

[0111] The cloud control center pre-builds and trains a model to predict the risk of loss of contact. The method for building the model includes:

[0112] The first step is for the cloud control center to extract the runtime context information and corresponding real disconnection event records of several dynamic dial-up virtual private server nodes during their historical operating cycles.

[0113] It is important to note that the cloud control center extracts historical operational context information of several nodes from the database over the past 30 days, along with corresponding records of actual out-of-connection events. These out-of-connection event records include offline events caused by network failures, resource exhaustion, or intrusion, along with the timestamps of the offline occurrences. The historical data for each node is arranged chronologically to form a time-series dataset.

[0114] The second step is to perform sliding window processing on the extracted runtime context information, extract the statistical and trend features within each time window, and construct a special feature combination for connection loss prediction. The special feature combination includes the central processing unit fluctuation ratio, network latency autocorrelation coefficient, and the product term of abnormal login and runtime.

[0115] It is important to note that the sliding window width is set to 60 seconds, and the sliding step size is 10 seconds. The statistical features include the mean, variance, maximum, minimum, kurtosis, and skewness for each category of indicators. For example, the mean of CPU utilization reflects the average load of the node, and the variance reflects the degree of load fluctuation. The trend features include the first-order difference, second-order difference, and local slope (obtained by linearly fitting the most recent 10 data points) for each category of indicators, thereby capturing precursory signals of indicator changes before connection loss.

[0116] To address node disconnection scenarios, the following specialized feature combinations are constructed: CPU fluctuation ratio (the ratio of CPU utilization variance to mean), used to measure the relative fluctuation of load; a larger ratio indicates more unstable node load and a higher risk of disconnection. Network latency autocorrelation coefficient, calculated for network latency sequences at lags of 1 second, 2 seconds, and 5 seconds, used to determine if there are periodic fluctuations in network latency; a high autocorrelation coefficient indicates a persistent decline in network quality. The product of abnormal login attempts and runtime, multiplied by the node's continuous runtime, is used to identify high-risk patterns of sudden abnormal logins after prolonged operation. Furthermore, the number of abnormal login attempts is independently encoded as an event-type feature (using one-hot encoding, encoding 0, 1-2, and more than 3 attempts into different feature vectors), and the node's continuous runtime is normalized as a state-type feature.

[0117] The third step is to construct a training sample set by using the features extracted from each time window as the input vector and whether a loss of contact event occurs within a future time window as the label.

[0118] It is important to note that the size of the future time window is dynamically adjusted based on the node's average dialing cycle: for nodes with a short average dialing cycle (e.g., <5 minutes), the future time window is set to 300 seconds; for samples with neither lost contact events nor normal offline records, they are marked as not lost contact and treated as negative samples. The ratio of positive to negative samples is controlled at approximately 1:5 to avoid sample imbalance that could cause the model to favor predicting those not lost contact.

[0119] Step 4: Based on the training sample set, use an ensemble learning algorithm to train a model for predicting the risk of losing contact, and output the probability value of the dynamic dialing virtual private server node losing contact within a future preset time window.

[0120] It is important to note that gradient boosting decision tree algorithms (such as XGBoost) can be used to train the loss-of-connection risk prediction model. During model training, five-fold cross-validation is used to evaluate model performance, with the area under the curve (AUC) as the primary evaluation metric; an AUC > 0.85 is sufficient for deployment. After training, the model is serialized into a binary file and deployed in the risk prediction module of the cloud control center.

[0121] Step 5: The cloud control center collects newly added runtime context information and disconnection event records at a preset cycle (such as every 24 hours) and performs incremental training on the model.

[0122] It is important to note that the incremental training method is as follows: New data is merged with existing training data, and gradient updates are performed iteratively (e.g., 10 epochs) based on the original model parameters. After incremental training is completed, the area under the curve (AUC) of the new model and the old model are compared. If the AUC of the new model is greater than or equal to the AUC of the old model, the old model is replaced; if the performance of the new model degrades, the old model is retained and the anomaly is recorded for manual analysis.

[0123] like Figure 4 As shown, the present invention provides a method for assessing the risk of loss of contact and issuing defense commands;

[0124] Specifically:

[0125] The first step is for the cloud control center to input the runtime context information reported by the nodes into the pre-trained loss-of-connection risk prediction model, and output the probability value of the nodes losing connection within a preset time window in the future; the runtime context information includes performance, network and security indicators.

[0126] It is important to note that the risk prediction module of the cloud control center receives runtime context information reported by nodes in real time. Each time a report is received, the risk prediction module extracts the feature vector within the current time window, inputs it into the pre-trained loss-of-connection risk prediction model, and the model outputs the probability value of the node losing contact within a future preset time window (default 60 seconds, which can be configured according to the node type in specific implementations).

[0127] The second step is for the cloud control center to determine whether the probability of loss of connection exceeds a preset threshold.

[0128] It should be noted that the initial default value of the threshold is set to 0.7 based on operational experience. When the probability of loss of connection is ≥0.7, the node is determined to have a high risk of loss of connection; when the probability of loss of connection is ≥0.9, the node is determined to be in a state of extremely high risk of loss of connection.

[0129] The threshold supports dynamic adaptive adjustment. The cloud control center calculates the actual disconnection probability of each node daily and compares it with the model's predicted disconnection probability. If the actual disconnection event rate of a node in the past 24 hours is higher than 1.2 times the model's predicted disconnection probability, it indicates that the current false alarm rate is too high, and the cloud control center automatically lowers the judgment threshold for that node by 0.05 to improve prediction sensitivity. Conversely, if the actual disconnection event rate is lower than 0.8 times the model's predicted disconnection probability, it indicates that the current false negative rate is too high, and the cloud control center automatically raises the judgment threshold for that node by 0.05. The threshold adjustment range is from 0.5 to 0.9; if it exceeds this range, the adjustment stops and manual review is triggered.

[0130] Third, if the probability of losing contact exceeds a preset threshold, at least one defense instruction is selected from the instruction library based on the node's current status and risk level; the defense instructions include data destruction instructions, network reset instructions, or account locking instructions.

[0131] It is important to note that the data destruction commands include destroying the data disk partition table, encrypting and erasing storage media, and deleting all files in a specified directory; these commands are suitable for scenarios where nodes may be compromised, preventing data leakage. The network reset commands include triggering a forced disconnection of the network interface followed by a re-establishment of the PPPoE protocol and temporarily disabling the network interface; these commands are suitable for scenarios where nodes are under network attack, mitigating attacks by changing the Internet Protocol address. The account locking commands include disabling specified operating system accounts and changing access passwords for critical services; these commands are suitable for scenarios where node authentication credentials may be compromised.

[0132] The cloud control center selects defense commands based on the probability of connection loss: when the probability of connection loss is 0.7 < 0.8, network reset commands are selected; when the probability of connection loss is 0.8 < 0.9, both network reset and account locking commands are selected; when the probability of connection loss is greater than 0.9, all three types of defense commands are selected. If the abnormal events actively reported by the node include serious security events such as privilege escalation attacks, the cloud control center directly selects data destruction commands, regardless of the probability of connection loss.

[0133] Step 4: The cloud control center will issue the selected defense commands to the nodes and record the relevant information of this command issuance for subsequent auditing; the nodes will store the defense commands in a secure storage area independent of the business operating system.

[0134] It should be noted that the relevant information includes node identifier, issuance timestamp, probability of loss of connection, selected defense command type and specific parameters, and triggering method.

[0135] In addition to model prediction triggers, nodes can proactively report local anomalies to the cloud control center and request defense instructions when they detect them. The node's local security agent continuously monitors the following anomalies: abnormal login attempts (e.g., more than 10 failed login attempts within 5 minutes); privilege escalation attacks (non-privileged processes attempting to call programs that set the user identifier to superuser or network service processes to execute suspicious commands); abnormal process injection (system service processes creating child processes whose executable files are located in a temporary directory or whose parent process in the process creation event is the source of the anomaly); and critical file tampering (the hash value of a critical file is inconsistent with the baseline value). When a node detects any of the above anomalies, it immediately sends an anomaly report message to the cloud control center. Upon receiving the message, the cloud control center skips the model prediction step and directly selects and issues the appropriate defense instructions based on the anomaly type.

[0136] The secure storage area is implemented using non-volatile storage media, independent of the node's business operating system, ensuring that data is not lost after power failure and that the business operating system cannot directly access it. For example, it can be a reserved partition of an embedded multimedia card, the non-volatile memory of a trusted platform module, or the embedded flash memory of an independent secure microcontroller. Each defense command is stored in the secure storage area as a structured record, including command type (data destruction, network reset, or account lockout), command parameters (such as target disk device, network interface name, and account name to be locked), command execution status (not executed or executed), and a cyclic redundancy check field.

[0137] S4. When a node meets the preset abnormal offline triggering conditions, the bootloader reads and executes the defense instructions in the secure storage area before the business operating system starts.

[0138] It is important to note that the node's local security agent maintains an offline status flag (normal or abnormal, initially defaulting to normal) in the secure storage area. The bootloader can be any one of the following: Unified Extensible Firmware Interface Boot Manager, Basic Input / Output System Bootloader, GRUB Bootloader, or U-Boot Bootloader.

[0139] like Figure 5 As shown, the present invention provides an offline self-executing defense command method;

[0140] Specifically:

[0141] The local security agent continuously monitors the node status and sets the offline status flag to abnormal when any of the following abnormal offline trigger conditions are met: checking the carrier detection status of the network interface every 1 second and being in a disconnected state for 30 consecutive seconds; the business process sends a heartbeat message every 5 seconds and fails to receive it for 3 consecutive times (approximately 15 seconds); capturing a forced restart or shutdown signal by registering the shutdown notification callback function of the operating system; sending a heartbeat to the cloud control center every 5 seconds and failing to receive an acknowledgment response for 5 consecutive times (approximately 25 seconds).

[0142] When a node powers on or restarts, the bootloader performs the following steps before loading the business system kernel:

[0143] The first step is to check the offline status flag. The bootloader reads the offline status flag from the secure storage area. If the flag is normal, the subsequent steps are skipped, and the business operating system kernel is loaded directly.

[0144] The second step is to read and parse the defense instructions. If the offline status flag is abnormal, the bootloader traverses the instruction records in the secure storage area, searching for defense instructions whose execution status is not executed. If found, the first defense instruction is read and its type and parameters are parsed.

[0145] The third step is to execute the defense commands. The bootloader calls the corresponding underlying execution interface to execute the defense commands based on the command type.

[0146] It is important to note that the data destruction class sends an erase command to the target disk device, overwriting all data blocks (by default, it overwrites 3 times); the network reset class closes and reopens the network interface, calls the PPPoE protocol dial-up client to redial, and obtains a new public Internet protocol address; the account lock class mounts the root file system of the business operating system (read-only mode), modifies the password field in the account configuration file to an invalid value, and then unmounts the file system.

[0147] Fourth, after the defense instruction is executed, the bootloader updates the execution status of the instruction to "executed". If there are other unexecuted defense instructions in the secure storage area, steps two and three are repeated.

[0148] Step 5: After all defense commands have been executed, the bootloader will reset the offline status flag to normal and continue loading the business operating system kernel.

[0149] like Figure 6 As shown, the present invention provides a dynamic dial-up VPS node security protection system based on end-cloud collaboration, which uses any of the above-mentioned methods for dynamic dial-up VPS node security protection based on end-cloud collaboration, including a cloud control center and several dynamic dial-up VPS nodes that are communicatively connected to the cloud control center.

[0150] The dynamic dial-up VPS node includes:

[0151] The dial-up module is used to complete PPPoE protocol dialing and obtain a new public Internet Protocol address;

[0152] The registration module is used to initiate a registration request with the device certificate to the cloud control center after obtaining the new public Internet of Things protocol address;

[0153] The policy execution module is used to receive dynamic security policies issued by the cloud control center and configure the local firewall of the node;

[0154] The task execution module is used to perform data interaction tasks with the target server based on the dynamic security policy; the task execution module includes a container management submodule, which is used to create a temporary container before executing the data interaction task and destroy the container after the task is completed;

[0155] The context collection module is used to continuously collect the running context information of the dynamically dialed VPS node and report it to the cloud control center.

[0156] The secure storage module, independent of the node's business operating system, is used to store defense commands issued by the cloud control center;

[0157] The offline execution module, coupled with the bootloader, is used to read and execute the defense instructions in the security storage module before the business operating system starts when the dynamically dialed VPS node meets the preset abnormal offline triggering conditions.

[0158] The cloud control center includes:

[0159] The task management module is used to create and manage data acquisition tasks, assign a unique task identifier and task lifecycle to each task (the value ranges from 30 seconds to 3600 seconds, and the specific value is determined by the business requirements of the task), maintain the mapping relationship between dynamic dial-up VPS nodes and tasks, and track task status.

[0160] The registration verification module is used to receive and verify the registration request of the dynamic dial-up VPS node. After the verification is successful, a dynamic security policy is generated that is bound to the node's current public Internet Protocol address and temporary service port.

[0161] A fingerprint emulation pool is used to store and manage simulated fingerprint configurations;

[0162] The fingerprint distribution module is used to respond to the fingerprint configuration request of the dynamically dialed VPS node, match the simulated fingerprint configuration specific to the current task from the fingerprint simulation pool and send it to the node;

[0163] The risk prediction module is used to assess the risk of node disconnection based on the runtime context information reported by the dynamic dial-up VPS node and a pre-trained disconnection risk prediction model. When the threshold is exceeded or an abnormal event is actively reported by the node, a defense command is generated and sent to the node.

[0164] The update and maintenance module is used to update the loss of contact risk prediction model and fingerprint simulation pool according to a preset cycle.

[0165] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended embodiments and their equivalents.

Claims

1. A method for security protection of dynamic dial-up VPS nodes based on end-to-cloud collaboration, characterized in that, include: S1. After each successful dial-up connection and acquisition of a new public Internet Protocol address, the dynamic dial-up virtual private server node sends a registration request with the device certificate to the cloud control center. After the cloud control center verifies the information, it generates a dynamic security policy that is bound to the new public Internet Protocol address and temporary business port, and sends it to the local firewall of the node. S2. The node performs a data interaction task with the target server based on the dynamic security policy, while continuously collecting runtime context information and reporting it to the cloud control center; wherein, before performing the data interaction task, the node pulls the simulated fingerprint configuration specific to the current task from the fingerprint simulation pool of the cloud control center and loads it into a temporarily created container for execution, and destroys the container after the task is completed. S3. The cloud control center assesses the risk of node disconnection based on the aforementioned runtime context information. When the risk of disconnection exceeds the threshold or an abnormal event is actively reported by the node, a defense instruction is generated and sent to the node. The node stores the defense instruction in a non-volatile secure storage area independent of the business operating system. S4. When a node meets the preset abnormal offline triggering conditions, the bootloader reads and executes the defense instructions in the secure storage area before the business operating system starts.

2. The method for security protection of dynamic dial-up VPS nodes based on end-to-cloud collaboration according to claim 1, characterized in that: The generation of the dynamic security policy includes: S11. The cloud control center verifies the legitimate identity of the node based on the device certificate and generates a unique session identifier for this dial-up call. S12. The cloud control center queries the task list for the current task associated with the node, and extracts the task identifier and the preset task lifecycle. S13. The cloud control center uses the new public Internet Protocol address as the source address and the temporary service port as the destination port to generate a firewall allow rule, and sets the validity period of the rule to be consistent with the life cycle of the task. S14. The cloud control center binds the firewall access rules with the session identifier and task identifier, and sends them to the local firewall of the node.

3. The method for security protection of dynamic dial-up VPS nodes based on end-to-cloud collaboration according to claim 1, characterized in that: The method for constructing the fingerprint simulation pool includes: S21. The cloud control center deploys several independent fingerprint collection nodes. Each fingerprint collection node is configured with different user agent strings and transport layer security protocol parameters to simulate fingerprints of different client devices. S22. During the process of accessing the target server, the fingerprint collection node collects the transport layer security handshake fingerprint and the hypertext transfer protocol request fingerprint. S23. Perform deduplication, clustering, and validity verification on the collected transport layer security handshake fingerprints and hypertext transfer protocol request fingerprints, and remove invalid fingerprints that are rejected by the target server or trigger anti-crawling verification. S24. The verified fingerprint configurations are classified and stored according to the target website type and anti-crawling strategy strength to form a fingerprint simulation pool, and a unique index identifier is assigned to each fingerprint configuration; the unique index identifier is used to establish a mapping relationship with the task identifier of the collection task. S25. The cloud control center re-executes S21 to S24 according to the preset cycle to update the fingerprint simulation pool.

4. The method for security protection of dynamic dial-up VPS nodes based on end-to-cloud collaboration according to claim 1, characterized in that: The dynamic retrieval and container isolation of the fingerprint simulation pool includes: S26. Before executing the data interaction task, the node sends a fingerprint configuration request to the cloud control center. The request includes at least the task identifier, the target server domain name, and the node identifier. S27. The cloud control center queries the corresponding simulated fingerprint configuration from the fingerprint simulation pool based on the task identifier. The simulated fingerprint configuration includes at least the transport layer security handshake fingerprint, the user agent string, and the session identifier chain. S28. After receiving the simulated fingerprint configuration, the node creates a temporary container locally and injects the simulated fingerprint configuration into the network stack and Hypertext Transfer Protocol client of the container. S29. The node performs a data interaction task within the container. After the task is completed, the container process is forcibly terminated and all residual data is cleared.

5. The method for security protection of dynamic dial-up VPS nodes based on end-to-cloud collaboration according to claim 1, characterized in that: The S3 node disconnection risk assessment and defense command issuance includes: S31. The cloud control center inputs the running context information reported by the node into the pre-trained loss of connection risk prediction model and outputs the probability value of the node losing connection within a future preset time window. S32. The cloud control center determines whether the probability of loss of contact exceeds a preset threshold. S33. If the probability of losing contact exceeds a preset threshold, then select at least one defense instruction from the instruction library based on the current status and risk level of the node; the defense instruction includes data destruction instructions, network reset instructions, or account locking instructions. S34. The cloud control center will issue the selected defense instructions to the nodes and record the relevant information of this instruction issuance for subsequent auditing.

6. The method for security protection of dynamic dial-up VPS nodes based on end-to-cloud collaboration according to claim 5, characterized in that: The method for constructing the loss of contact risk prediction model includes: S311. The cloud control center extracts the running context information and corresponding real disconnection event records of several dynamic dial-up virtual private server nodes in the historical running cycle. S312. Perform sliding window processing on the extracted runtime context information, extract statistical features and trend features within each time window, and construct a special feature combination for connection loss prediction. The special feature combination includes the central processing unit fluctuation ratio, network latency autocorrelation coefficient, and the product term of abnormal login and runtime. S313. Using the features extracted from each time window as the input vector, and using whether a loss of contact event occurs within a future time window as the label, a training sample set is constructed; the future time window is dynamically adjusted according to the average dialing cycle of the dynamic dialing virtual private server node. S314. Based on the training sample set, an ensemble learning algorithm is used to train a loss of contact risk prediction model, and the loss of contact probability value of the dynamic dialing virtual private server node within a future preset time window is output. S315. The cloud control center collects new data according to a preset cycle and performs incremental training on the model.

7. The method for security protection of dynamic dial-up VPS nodes based on end-to-cloud collaboration according to claim 1, characterized in that: The abnormal offline triggering conditions include at least one of the following: network interface disconnection duration exceeds a preset value, the number of business process heartbeat loss exceeds a preset value, a forced restart or shutdown signal of the operating system is detected, the node's local security agent continuously reports failures and determines that the cloud control center is unreachable, or the node or the node's local security agent actively triggers an offline command.

8. The method for security protection of dynamic dial-up VPS nodes based on end-to-cloud collaboration according to claim 1, characterized in that: The bootloader reads and executes defense instructions, including: S41. When a node restarts or powers on, the bootloader reads the offline status flag in the secure storage area before loading the business operating system kernel; if the flag is abnormal, it checks whether there are any defense instructions with an execution status of not executed. S42. If there are any unexecuted defense instructions, the bootloader reads and parses the instructions. S43. The bootloader calls the corresponding underlying execution interface to execute the defense instruction based on the instruction type; S44. After the defense command is executed, update the execution status of the command to executed. If there are still other defense commands that have not been executed, repeat S42 to S43. S45. After all defense commands have been executed, reset the node's offline status flag to normal and continue loading the business operating system kernel.

9. A dynamic dial-up VPS node security protection system based on end-to-cloud collaboration, characterized in that... The method for protecting the security of a dynamic dial-up VPS node based on end-to-cloud collaboration, as described in any one of claims 1-8, is used.

Images