A distributed verification node communication method supporting forward proxy and reverse proxy

Abstract

The application relates to the technical field of distributed network communication, and discloses a distributed verification node communication method supporting forward proxy and reverse proxy, which comprises the following steps: a bidirectional communication framework supporting three communication modes of forward proxy, reverse proxy and NAT penetration is constructed; each mode is automatically detected according to a priority order, and a connection is established in a usable mode; runtime communication mode switching is realized based on a health_counter; node states are monitored through a heartbeat mechanism, and a scheduling pool is updated in linkage; when the three direct connection modes all fail, a multi-hop relay path is calculated, a cascade encryption tunnel with layer-by-layer encryption is established, and task transmission is completed.

Description

Technical Field

[0001] This invention relates to the field of distributed network communication technology, and more specifically to a distributed verification node communication method that supports forward and reverse proxies. Background Technology

[0002] In enterprise network deployment scenarios of intrusion and attack simulation systems, verification nodes are distributed across various network topologies, including intranets, DMZ zones, cloud environments, and container clusters. Existing systems use a single fixed communication mode to establish communication links between the management terminal and the verification nodes. However, the network environments of each verification node vary significantly. Some nodes are located behind NAT devices, making them inaccessible to the management terminal directly, and network policies may also prevent the establishment of outbound connections to the management terminal. This single fixed communication mode cannot adapt to the diverse network topologies, resulting in communication links failing to be established or failing to automatically recover after interruptions in some deployment scenarios. Summary of the Invention

[0003] This invention provides a distributed verification node communication method that supports both forward and reverse proxies, solving the technical problems in related technologies where verification nodes, due to complex network topology and a single communication mode, cannot stably establish communication connections between the management end and verification nodes distributed in various network areas, task instruction issuance is interrupted, and communication data faces security risks.

[0004] This invention discloses a distributed verification node communication system supporting forward and reverse proxies, comprising: The communication framework building module is used to build a bidirectional communication framework between the management end and the verification node that supports three communication modes: forward proxy, reverse proxy and NAT traversal, and performs AES and RSA hybrid encryption on all communication data. The forward proxy communication module is used to process registration requests initiated by verification nodes, complete legality verification and node information persistence, maintain long connection heartbeats, and issue and receive task instructions and execution results. The reverse proxy communication module is used to handle the listening and starting of the verification node on the specified port, the storage and retrieval of the connection configuration information of the management end, the transmission of task instructions and the return of results after the management end actively initiates a connection; The NAT traversal communication module is used to handle the verification node obtaining public network NAT mapping information through the STUN protocol, reporting and persisting the NAT mapping information along with the registration request, and the management end establishing a communication connection using the NAT mapping information. The mode detection and switching module is used to detect the reachability of each communication mode in priority order and automatically select the available mode when the verification node starts. During runtime, it detects communication link abnormalities and triggers backup mode switching. During the switching process, it persists unfinished tasks through the task status table and reissues them after the new link is established. The node status monitoring module is used to maintain the status record objects of each verification node, perform timed heartbeat timeout detection, update the online status of nodes, and coordinate the addition and removal of nodes in the candidate pool.

[0005] Furthermore, during the communication connection establishment phase, the communication framework construction module completes the secure negotiation of the AES session key using the RSA asymmetric encryption algorithm: the verification node randomly generates the AES session key locally. The ciphertext is obtained by RSA encryption using the management public key. ,Will The node registration information is sent to the management terminal; the management terminal decrypts it using its own private key. Restore After that, both sides used All business data is encrypted and decrypted. The encryption process is as follows: ; in, The original data before encryption. For encrypted ciphertext data, For AES session key, To randomly initialize the vector, each communication message will... With ciphertext After being assembled and packaged, they are transmitted in a unified manner.

[0006] Furthermore, the node status monitoring module maintains a timestamp containing the most recent heartbeat received for each registered and verified node. and the number of consecutive periods without a heartbeat The status record object; when performing a scheduled check task, set the current system time to... For nodes The criteria for determining heart rate timeout are: ; in, , The threshold for the number of consecutive timeout periods. The interval between heartbeats. Index the node; when the timeout condition is met, the node will be indexed. of Increment by 1, when Exceed When the online status is updated to offline and removed from the scheduling candidate pool, upon receiving a valid heartbeat again, the status will be updated to offline and removed from the scheduling candidate pool. Reset to 0, update the online status to online, and re-include the node in the scheduling candidate pool.

[0007] Furthermore, the mode detection and switching module performs the detection in the following priority order: first, it sends a connectivity detection request to the management terminal address, assuming a connection timeout threshold of [value missing]. The response timeout threshold is If a valid response is received, a forward proxy mode is used; if the forward proxy probe fails, local listening is started and the management end is notified to initiate a reverse connection, waiting for a timeout threshold. If a valid connection request is received, the reverse proxy mode is used; if the reverse proxy probe fails, a STUN probe is performed and NAT traversal is attempted; if all three modes fail, the probe is re-initiated using an exponential backoff strategy, with an initial waiting time of [time missing]. The maximum waiting time is The retreat coefficient is 2, where , , , , These are the timeout or waiting time limits for the corresponding stages.

[0008] Furthermore, the NAT traversal communication module also includes: when direct traversal fails, switching to the TURN relay scheme, establishing relay connections between the management terminal and the verification node to the public network TURN server respectively, and having the TURN server forward communication data between the two parties.

[0009] Furthermore, the distributed verification node communication system supporting both forward and reverse proxies also includes: The reachability acquisition module is used to query the network location attributes and cross-partition routing reachability data of online nodes from the node management database after all three communication modes have failed to detect the network location attributes, and generate a set of online node network location attributes. ; Candidate path calculation module, used for directed graphs This represents the reachability relationship between nodes, where For including management nodes and The set of vertices of all online verification nodes in the network. Let be a set of directed edges, with directed edges Represents a node Actively connect nodes The breadth-first search algorithm is used to calculate the number of nodes from the management end. To the target verification node Candidate relay path set Sort by number of hops from smallest to largest; if the number of hops is the same, sort by average CPU utilization of each intermediate node from smallest to largest. hop-by-hop detection module, used for... The candidate paths in the process are sequentially tested for hop-by-hop connectivity. Each intermediate node sends a probe request to the next hop node and returns the result. If the probe of any hop of the current candidate path fails, the process switches to the next candidate path. The cascaded tunnel establishment module is used to complete the session key for each segment of the successfully detected relay path according to the forwarding order. The negotiation was completed, and the management terminal and the target verification node were connected on the established cascaded encrypted tunnel. End-to-end session keys between Negotiation, Only the management terminal and the target verification node hold; The relay transmission module is used for relaying task instruction data. Perform layer-by-layer encryption and encapsulation to generate multi-layered nested ciphertext data packets. It is transmitted via a cascaded encrypted tunnel. Each intermediate node only decrypts the routing header information belonging to its own layer before forwarding the inner ciphertext, as well as the multi-layered nested ciphertext data packets returned. After decrypting layer by layer, the task execution result is obtained and persisted. The tunnel maintenance module is used to maintain end-to-end heartbeat detection and round-trip delay calculation of cascaded encrypted tunnels, trigger alternative path reconstruction when a tunnel fails, and pre-build backup tunnels in parallel when the first heartbeat times out.

[0010] Furthermore, the candidate path calculation module constructs a directed graph. When CPU utilization exceeds the threshold Or memory usage exceeds the threshold Online nodes from vertex set Removed from the middle, among which This is the maximum CPU usage. This represents the maximum memory usage limit.

[0011] Furthermore, the tunnel maintenance module maintains an independent heartbeat detection task for each established cascaded encrypted tunnel, recording the heartbeat packet sending timestamp. With response receiving timestamp Calculate the end-to-end round-trip delay: ; When continuous Heartbeat response timeout, or exceeding the threshold continuously The number of times reached At this point, it is determined that the current cascaded encrypted tunnel has failed and an alternative path reconstruction is triggered. The threshold for the number of consecutive heartbeat timeouts. This is the maximum round-trip delay. The threshold for the number of consecutive round-trip delays exceeding the limit.

[0012] Furthermore, the cross-partition routing reachability data obtained by the reachability acquisition module comes from the node identifiers of the successfully probed nodes recorded by the partition detection module of each verification node after sending connectivity probe requests to other known nodes in the network partition where the node is located. This data is synchronously reported to the management end with each heartbeat packet and merged and updated to the node connection configuration table, reflecting the measured connectivity status of each verification node to other nodes in the current heartbeat cycle.

[0013] Furthermore, the cascaded tunnel establishment module processes task command data. When performing layer-by-layer encryption and encapsulation, the encapsulation order is from the innermost layer to the outermost layer, using the layers in the path sequentially. Session keys negotiated by each intermediate node The data is encrypted, with the innermost layer using an end-to-end session key. Encryption is performed, and after each layer of encryption, a routing header containing the cascading tunnel session identifier and the communication address of the next-hop node is appended to the ciphertext. As the first intermediate node directly accessible from the management end, For the final intermediate node that is directly reachable from the target node, This represents the number of hops along the path.

[0014] The beneficial effects of this invention are as follows: This invention addresses the technical problem of communication link failure caused by a single fixed communication mode being unable to adapt to diverse network topologies by constructing a bidirectional communication framework that simultaneously supports forward proxy, reverse proxy, and NAT traversal. It achieves the technical effect of establishing usable communication paths under various network topology conditions. An automatic detection mechanism based on priority order and a runtime switching mechanism based on health_counter solve the technical problem of communication interruption and failure to automatically recover when the network environment changes, achieving the technical effect of maintaining communication links continuously without manual intervention when network status changes. By calculating multi-hop relay paths and establishing cascaded encrypted tunnels using directed graphs and breadth-first search algorithms, it solves the technical problem of verification nodes becoming communication blind spots due to bidirectional access control policies, achieving the technical effect of including target verification nodes in unified scheduling even when there is no directly reachable path. Layer-by-layer encryption encapsulation and the introduction of end-to-end session keys solve the technical problem of intermediate nodes potentially accessing plaintext business data in relay forwarding scenarios, achieving the technical effect of maintaining end-to-end confidentiality of task data during relay transmission. Attached Figure Description

[0015] Figure 1 This is a flowchart illustrating the communication between distributed verification nodes that support forward and reverse proxies, as provided in an embodiment of the present invention. Figure 2 This is a sub-flowchart of the automatic detection and switching of communication modes in the distributed verification node communication method supporting forward and reverse proxies provided in the embodiments of the present invention. Figure 3 This is a flowchart of a cascaded encrypted tunnel communication method based on online node relay provided in an embodiment of the present invention. Detailed Implementation

[0016] The subject matter described herein will now be discussed with reference to exemplary embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and implement the subject matter described herein, and changes may be made to the function and arrangement of the elements discussed without departing from the scope of this specification. Various processes or components may be omitted, substituted, or added as needed in the examples. Furthermore, some features described in the examples may be combined in other examples.

[0017] Example 1 At least one embodiment of the present invention discloses a distributed verification node communication method supporting forward and reverse proxies, see [link to relevant documentation]. Figures 1-2 This includes the following steps: Step 1: Build a multi-mode communication framework.

[0018] A low-level framework supporting bidirectional communication is built between the management terminal and the verification node. This framework supports three communication modes: forward proxy mode (the verification node actively connects to the management terminal as a client), reverse proxy mode (the management terminal actively connects to the verification node as the connection initiator), and NAT traversal mode (suitable for scenarios where the verification node is located behind a NAT device). All three modes share a unified data serialization format and encrypted transport layer.

[0019] It should be noted that the encrypted transport layer uses a hybrid AES and RSA encryption method to protect all communication data during transmission. During the connection establishment phase, both communicating parties securely negotiate and exchange the AES session key using the RSA asymmetric encryption algorithm: the management terminal generates an RSA public-private key pair during system initialization, and the public key is published externally in the form of a certificate; the verification node obtains this public key when establishing the connection for the first time and randomly generates a 256-bit AES session key locally. The ciphertext is obtained by RSA encryption using the management public key. ,Will The node registration information is sent to the management terminal along with the data; the management terminal decrypts it using its own private key. Restore From then on, both parties used... All subsequent business data is encrypted and decrypted. The encryption process is represented as follows: ; The decryption process is represented as follows: ; in, The original data before encryption. For encrypted ciphertext data, A 256-bit AES session key. A 128-bit random initialization vector, and These represent the encryption and decryption functions in AES-256-CBC mode, respectively. Each communication message, when sent, will... With ciphertext After being concatenated and encapsulated, the messages are transmitted in a unified manner, and the receiver parses the data from the messages. and Then perform the decryption operation.

[0020] Step 2: Perform forward proxy communication.

[0021] The verification node reads the preset management terminal address field `server_host` and port field `server_port` from its local configuration file, constructs a registration request, and sends it to the management terminal's registration interface using an HTTP POST method. The registration request body is encapsulated in JSON format, carrying the node's unique identifier `node_id`, the node's current external communication IP address `node_ip`, the operating system type `os_type`, the operating system version number `os_version`, the client software version number `client_version`, and the registration request sending time `register_time` in millisecond-level Unix timestamp format. The registration request data is encrypted using the hybrid encryption scheme described in step 1 before being sent.

[0022] Upon receiving a registration request, the management system verifies its legitimacy. This verification includes validating the request signature, verifying the compliance of the node_id format, and confirming that the node_id is in the authorized node whitelist maintained by the management system. If the verification is successful, the management system persistently records the node's basic information and registration time in the node management database (node_registry table) and returns a registration success response to the verified node. The response body carries a communication token assigned to the node by the management system. All subsequent communication requests must include this token in the Authorization field of the HTTP request header to complete authentication.

[0023] After successful registration, the verification node sends heartbeat packets to the management interface at fixed time intervals. The heartbeat request body carries the node_id, the current heartbeat sending timestamp, the node's current running status (values ​​include running, idle, or error), CPU usage (cpu_usage, a floating-point number in percentage), and memory usage (mem_usage, a floating-point number in percentage). Upon receiving the heartbeat packet, the management end updates the last_heartbeat_time field in the corresponding node's node_registry table and updates the node status field to the current status value carried in the heartbeat packet.

[0024] When the management terminal needs to send test task instructions to a designated verification node, it sends the instructions in encrypted JSON format via an established long-lived connection. The task instruction body contains a unique task identifier (task_id), a task type (task_type), a set of task parameters (task_params), and a task timeout (task_timeout) in seconds. Upon receiving the task instruction, the verification node decrypts and parses the task content, executes the corresponding attack simulation operation, and asynchronously returns the execution result to the management terminal.

[0025] Step 3: Perform reverse proxy communication.

[0026] The verification node reads the communication mode configuration field comm_mode from the local configuration file. When the value of comm_mode is reverse, the verification node starts an HTTP listening service on the listening port listen_port specified in the local configuration file and waits for the management terminal to initiate a connection request.

[0027] It should be noted that the verification node must inform the management terminal of its listening address and port information through out-of-band channels. Specific forms of out-of-band channels include, but are not limited to: the system administrator manually entering the node's listening address and port in the management terminal console; transmitting the above information to the operations and maintenance personnel responsible for management terminal configuration via administrator email notification; or pre-setting the node's listening information in the management terminal's node configuration table through offline initialization configuration files during the verification node installation and deployment phase. The management terminal persistently stores the above information in the node connection configuration table (node_connection_config table), with corresponding fields including node_id, listening IP address or domain name listen_host, listening port number listen_port, and communication mode identifier comm_mode (with a value of reverse).

[0028] When the management terminal needs to communicate with the target verification node, it retrieves the connection configuration information of that node from the `node_connection_config` table and proactively initiates a connection request to the verification node's listening address using an HTTP client to establish a communication session. After the connection is established, both parties complete the session key negotiation using the hybrid encryption method described in step 1. Subsequently, the management terminal sends task instructions to the verification node through this connection, maintaining the same protocol format as in the forward proxy mode in step 2. The verification node returns the task execution result through the same connection.

[0029] In this embodiment of the application, in order to ensure communication security in the reverse proxy mode, the listening service of the verification node verifies the identity of the management terminal when accepting a connection request. Specifically, it verifies the management terminal identity token server_token carried in the connection request. The management terminal identity token server_token is generated by the management terminal during system initialization and pre-set in the verification node configuration file through out-of-band channels to ensure that unauthorized hosts cannot establish a connection.

[0030] Step 4: Perform NAT traversal communication.

[0031] The verification node reads the `comm_mode` field from its local configuration file. When the `comm_mode` value is `nat`, the verification node sends a Binding Request to the pre-configured public STUN server via the STUN protocol. The STUN server obtains the public IP address and port corresponding to the verification node after NAT mapping from the source address information of the request message, encapsulates this information in a Binding Response message, and returns it to the verification node. The verification node parses the public IP address `nat_public_ip` and public IP port `nat_public_port` from the response message and stores them in runtime memory.

[0032] When a verification node sends a registration request to the management terminal, it additionally includes a `nat_info` object in the JSON data of the registration request body. The `nat_info` object contains the public IP address after NAT mapping (`nat_public_ip`), the public port number after NAT mapping (`nat_public_port`), and the NAT type (`nat_type`), which can be one of Full Cone, Restricted Cone, Port Restricted Cone, or Symmetric NAT, inferred from the response results of multiple probe requests during the STUN protocol probe process. Upon receiving the registration request, the management terminal, while performing legality verification, persists the fields from the `nat_info` object to the NAT mapping information field of the corresponding node in the `node_connection_config` table.

[0033] When the management terminal needs to establish communication with the authentication node, it retrieves the NAT mapping information recorded in the node_connection_config table, uses nat_public_ip and nat_public_port as the target addresses, and sends a communication request to the NAT device where the authentication node is located. The NAT device then forwards the request to the target authentication node in the internal network through port mapping, thereby establishing a communication connection. The subsequent communication process after the connection is established is consistent with the forward proxy mode in step 2.

[0034] In this embodiment of the application, in order to address the problem that the reliability of direct traversal is reduced due to the dynamic change of NAT mapping ports caused by different target addresses in Symmetric NAT type network environments, a backup scheme based on a TURN relay server is introduced in the NAT traversal mode: when direct traversal fails, the system switches to the TURN relay scheme, and the management terminal and the verification node establish relay connections to the public network TURN server respectively. The TURN server forwards communication data between the two parties, thereby establishing a reliable communication link even in a strongly isolated network environment.

[0035] Step 5: Perform automatic detection and switching of communication modes.

[0036] When the verification node starts the program, if the `comm_mode` field in the configuration file is set to `auto`, it will perform reachability detection on each communication mode in a preset priority order. Step 5 may specifically include: Step 501: The verification node sends an HTTP connectivity probe request to the management terminal address preset in the configuration file and sets the connection timeout threshold. The response timeout threshold is 5 seconds. It lasts for 10 seconds, of which Maximum waiting time for connection establishment The maximum waiting time to receive a valid response; if a valid response is received from the management end within the timeout threshold, the forward proxy mode is determined to be available, a formal connection is established using the forward proxy mode, and the subsequent probing process is terminated.

[0037] Step 502: If the forward proxy probe in step 501 fails, the verification node starts listening on the local listen_port port and notifies the management end to initiate a reverse connection through the management end callback interface preset in the configuration file, waiting for the timeout threshold. It lasts for 30 seconds, of which This is the maximum waiting time for the management to initiate a reverse connection. If a valid connection request is received from the management within the waiting timeout threshold, the reverse proxy mode is deemed available, and a formal connection is established using the reverse proxy mode.

[0038] Step 503: If the reverse proxy probe in step 502 also fails, then execute the STUN probe process described in step 4 to obtain public network mapping information and attempt to establish a connection through NAT traversal.

[0039] Step 504: If all three detection modes fail, the verification node re-initiates the detection using an exponential backoff strategy, with an initial waiting time... The maximum waiting time is 60 seconds. The time limit is 600 seconds, and the retreat coefficient is 2. This is the waiting time before the first retry. This is the upper limit of the waiting time between two consecutive retries, until a connection is successfully established.

[0040] In this embodiment, to ensure automatic recovery when a communication link fails during system operation, a runtime switching mechanism is introduced based on step 5. The management terminal maintains a communication link health counter `health_counter` for each established verification node, with an initial value of 0. If a verification node fails continuously... If no valid heartbeat is received within a heartbeat cycle, or if the number of consecutive failures when the management terminal sends a task command to the node exceeds the threshold, the node will be affected. Then health_counter increments by 1, where The threshold for the number of consecutive timeout periods. This is a threshold for the number of consecutive failed delivery attempts; if health_counter exceeds a preset threshold... If the management determines that the current communication link has failed, it triggers a communication mode switching process for that node, attempting three communication modes sequentially until a valid connection is re-established, or marking the node as offline. This sets the upper limit for the health count that triggers link switching. When the verification node detects that the number of consecutive heartbeat request timeouts has reached the threshold, it also triggers the local communication mode detection process to attempt to reconnect to the management terminal through other available modes.

[0041] In this embodiment of the application, to ensure that task data is not lost due to communication interruption during the communication mode switching process, the following steps are also included: When the management terminal issues each task instruction to the verification node, it synchronously records the task_id, target node identifier target_node_id, dispatch timestamp dispatch_time, and task status field task_status (initial value dispatched) in the task status table (task_status table); when the communication link is switched, the management terminal retrieves all task records in the task_status table that match the target_node_id of the currently switched node and have a task_status value of dispatched or executing; after the new communication link is successfully established, the management terminal updates the task_status field of the above-mentioned incomplete tasks to pending_retry, and reissues the above-mentioned tasks in sequence through the new link according to the order of dispatch_time.

[0042] Step 6: Perform node status monitoring based on the heartbeat mechanism.

[0043] The management system maintains a status record object, NodeStatus, in memory for each registered verification node. The NodeStatus object contains the node identifier (node_id), the timestamp of the most recent valid heartbeat (last_heartbeat_time, a millisecond-level Unix timestamp), the online status (online_status, enumerated as online or offline), and the count of consecutive periods without a heartbeat (miss_count, initially 0). The management system runs a scheduled check task, HealthCheckTask, in the background. The execution cycle of HealthCheckTask is the same as the heartbeat sending interval of the verification nodes. To remain consistent, among which To verify the time interval (in milliseconds) between two consecutive heartbeats sent by a node, the following offline determination logic is executed by iterating through the NodeStatus objects of all registered nodes during each execution.

[0044] Let the current system time be (Millisecond-level Unix timestamp), node The most recent heartbeat reception time is Heartbeat timeout threshold is Then the node The criteria for determining heart rate timeout are: ; in, , The threshold for the number of consecutive timeout periods. The heartbeat sending interval (in milliseconds). This serves as a node index, used to distinguish different registered and verified nodes.

[0045] When the above timeout conditions are met, HealthCheckTask will... The miss_count field increments by 1; when miss_count exceeds... When the node is removed from the task scheduling candidate pool (SchedulableNodePool), the online_status field is updated to offline, and the node is removed from the task scheduling candidate pool. The task scheduling module on the management side will no longer include the node in the selection range of target nodes when issuing new tasks in the future. The above status change is synchronously persisted to the status field of the corresponding node in the node_registry table.

[0046] When the management terminal receives a valid heartbeat packet from the offline node again, HealthCheckTask detects that node. The timeout condition has been updated and is no longer met. The miss_count field of this node has been reset to 0, the online_status field has been updated to online, and the node has been reinstated into the ScheduledNodePool to restore its ability to accept new task assignments.

[0047] It should be noted that the cpu_usage and mem_usage fields in the heartbeat packet are obtained as follows: on Linux systems, they are calculated by reading the values ​​in the / proc / stat and / proc / meminfo files; on Windows systems, they are obtained by calling the Windows Management Instrumentation (WMI) interface to query the relevant system properties.

[0048] On the other hand, this invention also proposes a distributed verification node communication system that supports forward and reverse proxies, comprising: The communication framework building module is used to build a bidirectional communication framework between the management end and the verification node that supports three communication modes: forward proxy, reverse proxy and NAT traversal, and performs AES and RSA hybrid encryption on all communication data. The forward proxy communication module is used to process registration requests initiated by verification nodes, complete legality verification and node information persistence, maintain long connection heartbeats, and issue and receive task instructions and execution results. The reverse proxy communication module is used to handle the listening and starting of the verification node on the specified port, the storage and retrieval of the connection configuration information of the management end, the transmission of task instructions and the return of results after the management end actively initiates a connection; The NAT traversal communication module is used to handle the verification node obtaining public network NAT mapping information through the STUN protocol, reporting and persisting the NAT mapping information along with the registration request, establishing a communication connection with the management end using the NAT mapping information, and providing a backup solution for TURN relay in Symmetric NAT scenarios. The mode detection and switching module is used to detect the reachability of each communication mode in priority order and automatically select the available mode when the verification node starts up; detect communication link anomalies during runtime and trigger backup mode switching; persist unfinished tasks through the task_status table during the switching process and resend them after the new link is established. The node status monitoring module is used to maintain the NodeStatus object of each verification node, perform HealthCheckTask timed heartbeat timeout detection, update the online_status field of the node, and link the node addition and removal operations of ScheduledNodePool.

[0049] By way of example, the system proposed in this invention may also include various features and combinations thereof in the method embodiments, which will not be elaborated here.

[0050] In step 1, this invention constructs a bidirectional communication framework that simultaneously supports three communication modes: forward proxy, reverse proxy, and NAT traversal. This ensures that the management terminal and the verification node have corresponding available communication paths in three typical network topologies: nodes that are directly reachable, nodes that can only be actively accessed by the management terminal, and nodes that are behind NAT devices. This overcomes the limitation that a single fixed communication mode cannot adapt to diverse network topologies, thus solving the problem of communication links failing to be established in complex network environments. In step 5, the automatic detection mechanism based on priority order and the runtime switching mechanism based on health_counter enable the system to automatically reselect the communication mode without manual intervention when the network environment changes. This overcomes the factor that communication cannot be automatically recovered after communication interruption when the network changes, thereby ensuring the continuous stability of the communication link. The persistent task status in the task_status table allows for the retrieval and re-issuance of unfinished tasks after the switch is completed, overcoming the factor that task status is lost when communication is interrupted. In step 6, HealthCheckTask maintains the miss_count and online_status fields, enabling the management end to promptly detect offline nodes and remove them from the ScheduledNodePool. At the same time, it automatically reinstates nodes into the scheduling candidate pool after they resume heartbeats. This overcomes the problem of not being able to automatically detect and recover from node status changes, thus solving the problem of ensuring the continuous availability of distributed verification node clusters.

[0051] Example 2 In the BAS system described in Example 1, when all three communication modes between the verification node and the management terminal fail to detect, the verification node will be marked as offline, and the management terminal will be unable to issue any task instructions to it. This scenario occurs when there is a strict bidirectional access control policy between the network partition where the target verification node resides and the management terminal: the forward proxy mode fails because the management terminal cannot actively reach the target node; the reverse proxy mode fails because the target node cannot establish an outbound connection to the management terminal; and NAT traversal detection also fails to establish a reliable communication path due to the limitations of the bidirectional access control policy. After all three modes fail, the verification node within that network partition becomes a communication blind spot that cannot be included in unified scheduling, thus limiting the attack simulation coverage of the management terminal.

[0052] Based on Embodiment 1, this implementation provides a cascaded encrypted tunnel communication method based on online node relay. By using other online verification nodes as intermediate forwarding nodes, a multi-hop relay path from the management terminal to the target verification node is calculated and established, enabling verification nodes that cannot be directly connected under the bidirectional access control policy to be indirectly included in the unified scheduling scope of the management terminal through intermediate nodes.

[0053] This implementation runs on the BAS system described in Example 1. The communication framework between the management terminal and each verification node has been initialized according to the hybrid encryption scheme described in step 1 of Example 1. The registration information, network location attributes and communication status of each online verification node have been persisted to the node management database (node_registry table and node_connection_config table).

[0054] At least one embodiment of the present invention discloses a cascaded encrypted tunnel communication method based on online node relay, see [link to relevant documentation]. Figure 3 This includes the following steps: Step 2-1: Obtain network reachability data for online nodes.

[0055] After the management terminal performs forward proxy probing, reverse proxy probing, and NAT traversal probing on the target verification node in sequence according to steps 501 to 503 of Embodiment 1, and all three probings return a failure status, it queries the node management database for all verification node records with the online_status field value of online. It then extracts the network location attributes of each online node, including the network zone identifier net_zone_id, the IP address range information ip_subnet, and the cross-zone route reachability relationship data reachability_map recorded in the node connection configuration table, and generates a set of online node network location attributes. ,in This is a collection of network location attributes for all verification nodes whose online_status is currently set to online.

[0056] It's important to note that the cross-partition routing reachability recorded in the `reachability_map` field refers to the connectivity probes sent by each validator node to the listening addresses of other known nodes within its network partition via its embedded partition probing module when sending heartbeats or registration requests to the management system. The nodes whose probes are successful are recorded in their `reachability_map` field along with their network partition identifiers. This `reachability_map` data is then synchronously reported to the management system with each heartbeat, and the management system merges and updates the `reachability_map` field of the corresponding node in the `node_connection_config` table. Therefore, the `reachability_map` field reflects the measured connectivity status of each validator node to other nodes within the current heartbeat cycle, rather than statically configured network topology information.

[0057] Step 2-2: Calculate the set of candidate relay paths.

[0058] Based on the set of location attributes of online nodes The reachability data of each node in the directed graph. The data structure represents the reachability relationships between nodes, where A set of vertices, including the managing node. and All online verification nodes, Let be a set of directed edges, with directed edges Represents a node Actively connect nodes The reachability of edges is populated based on the reachability_map field data. For management node, and Identify the nodes. Use a breadth-first search (BFS) algorithm to manage the end nodes. Starting point, verifying nodes with objectives As the endpoint, in a directed graph The above calculation is from arrive All candidate paths, of which Identify the target verification node; each candidate path A sequence of intermediate verification nodes arranged in forwarding order Composition, in which As the first intermediate node directly accessible from the management end, For the final intermediate node that is directly reachable from the target node, For path index, This represents the hop count of the path. The candidate path set. Based on the number of hops on each path Sort by number from smallest to largest. For paths with the same number of hops, sort by the average CPU usage of each intermediate node from smallest to largest.

[0059] In this embodiment of the application, in order to reduce the computational overhead of breadth-first search, when constructing a directed graph... Prune nodes when their cpu_usage value exceeds a threshold. Or the value of the mem_usage field exceeds the threshold. Online nodes from vertex set Removed from the middle, among which This is the maximum CPU usage. This sets a memory usage limit to prevent nodes with excessively high resource loads from being included in candidate relay paths, thereby reducing the probability of data forwarding delays or failures due to insufficient node resources during relay transmission.

[0060] Steps 2-3: Perform hop-by-hop connectivity detection of candidate relay paths.

[0061] For candidate path set The current candidate paths are retrieved in order of sorting. The management terminal sends data to the first intermediate verification node in the path. A relay probe command is issued. The relay probe command is encapsulated in encrypted JSON format. The encryption method adopts the hybrid encryption scheme described in step 1 of embodiment one. The command body carries the unique identifier relay_probe_id of this relay probe, the listening IP address of the next hop node next_hop_host, the listening port number of the next hop node next_hop_port, and the sequence number hop_index of the current hop in the path.

[0062] Intermediate verification node After receiving and decrypting the relay probe command, proceed to the next hop node based on the next_hop_host and next_hop_port fields. Send connectivity probe request, connection timeout threshold is The response timeout threshold is (The value is consistent with the value defined in step 501 of Example 1), where This is the path number of the current hop. If a valid response is received, then... The successful detection result and next-hop node information are encapsulated and sent back to the management terminal hop by hop; if no valid response is received, then... The failed detection result is sent back to the management terminal. The above hop-by-hop detection process follows the path. Execute sequentially until the target verification node at the end of the path is reached. The response indicates that the connectivity probe was successful, or that a hop probe in the path failed.

[0063] If the current candidate path If any hop detection fails, switch to the candidate path set. The next path Re-execute the above hop-by-hop detection process; if the candidate path set If all paths fail to be detected, then steps 2-1 to 2-3 are re-executed according to the exponential backoff strategy described in step 504 of Example 1, with the waiting time parameter remaining the same as defined in step 504 of Example 1. , and the retreat coefficient.

[0064] Steps 2-4: Establish a cascaded encrypted tunnel.

[0065] For the relay paths successfully detected in steps 2-3 The management terminal forwards data according to the forwarding order of nodes in the path. to Relay session establishment instructions are sequentially sent to each intermediate verification node. The instruction body carries the unique identifier of this cascaded tunnel session: `relay_session_id`, `next_hop_host`, `next_hop_port`, and `hop_index` fields. After receiving the relay session establishment instructions, each intermediate verification node performs session key negotiation with its adjacent next-hop node. The negotiation process adopts the hybrid encryption scheme described in step 1 of Example 1. The session key obtained from each negotiation is denoted as... The encryption and decryption methods follow the formula defined in step 1 of embodiment one: ; ; in, For the first Skip to the original data before encryption. For the first Skip to encrypted ciphertext data, For the first The 256-bit AES session key is skipped. For the first A 128-bit random initialization vector for jumping. This represents the hop number for the corresponding path segment. The independent encrypted forwarding channels for each segment are concatenated to form a connection between the management terminal and the target verification node. An end-to-end cascaded encrypted tunnel, identified by relay_session_id.

[0066] The management terminal sends task instruction data to the target verification node. At that time, Perform layer-by-layer encryption and encapsulation, with the encapsulation order from the innermost layer to the outermost layer, and use them sequentially in the path. Session keys negotiated by each intermediate node The data is encrypted, and after each layer of encryption, the routing header information of the current hop (including relay_session_id and the communication address of the next hop node) is appended to the ciphertext, ultimately generating a multi-layered nested ciphertext data packet. Each intermediate verification node uses only the credentials held by its own node when forwarding. After decrypting the routing header information belonging to its own layer and obtaining the next-hop communication address, the inner encrypted data packet is forwarded to the next-hop node as is, and intermediate nodes cannot obtain the plaintext content of the inner business instruction data.

[0067] It should be noted that the key used for the innermost encryption layer in the layered encryption encapsulation is shared between the management terminal and the target verification node. The end-to-end session key obtained by the end-to-end session key negotiation process executed separately when establishing a cascaded tunnel. The end-to-end session key negotiation process transmits negotiation messages through an established cascaded encrypted tunnel, and the negotiation process is transparent to each intermediate node. Only the management terminal and the target verification node Holding. Therefore, task instruction data. use The encrypted content forms the innermost ciphertext, which is never exposed in plaintext form to any intermediate verification node during the entire relay forwarding process.

[0068] Steps 2-5 involve relaying task instructions and sending back results.

[0069] The management terminal will store multi-layered nested encrypted data packets. Send via cascaded encrypted tunnel to the first intermediate verification node The routing header information is decrypted hop-by-hop by each intermediate node, and the inner ciphertext is forwarded before finally reaching the target verification node. Target verification node Use end-to-end session keys Decrypt the innermost ciphertext to obtain task instruction data. It parses and executes the corresponding attack simulation operations, and generates task execution result data. .

[0070] Target verification node Data of task execution results use After encryption, according to the multi-layered nested ciphertext data packets A layer-by-layer encryption encapsulation method with reverse encapsulation order, using the following steps sequentially. The data is encapsulated to generate multi-layered nested encrypted data packets for transmission. The data is forwarded hop-by-hop in reverse through a cascaded encrypted tunnel to the management terminal. The management terminal decrypts the data layer by layer. Then, obtain the task execution result data. The task execution result data With target verification node identifier The node_id, the corresponding task_id, and the result receiving timestamp are associated and stored in the result database (task_result table), and the task_status field of the corresponding task_id in the task_status table is updated to completed.

[0071] Steps 2-6: Maintain heartbeat detection and relay path recovery for the cascaded encrypted tunnel.

[0072] The management console maintains an independent tunnel heartbeat detection task, RelayHeartbeatTask, for each established cascaded encrypted tunnel (identified by relay_session_id). RelayHeartbeatTask is set at intervals... To the target verification node via a cascaded encrypted tunnel Send end-to-end heartbeat packets, in which Heartbeat transmission interval for cascaded encrypted tunnels (in milliseconds); heartbeat packets use Encrypted and encrypted with multi-layered nested ciphertext data packets Transmitted using the same layer-by-layer encapsulation method, target verification node After decryption, a heartbeat response is returned.

[0073] The management console records the heartbeat packet sending timestamp during each execution of the RelayHeartbeatTask. With heartbeat response received timestamp Calculate the end-to-end round-trip delay: ; in, For end-to-end round-trip time, Send a timestamp to the heartbeat packet. This is the timestamp for receiving the heartbeat response. When consecutive... The heartbeat response timeout (i.e., in) No valid response received within the specified time), or exceeding the threshold continuously The number of times reached At this point, the management system determines that the current cascaded encrypted tunnel has failed. The threshold for the number of consecutive heartbeat timeouts that triggers tunnel failure detection. This is the maximum round-trip delay. To trigger the tunnel failure determination, the management terminal sets the tunnel status corresponding to relay_session_id as inactive and re-executes steps 2-1 to 2-4 to calculate and establish an alternative relay path, restoring access to the target verification node. Communication connection.

[0074] In this embodiment of the application, to reduce the task interruption time during the relay path reconstruction process, in addition to steps 2-6, the following steps are also included: When RelayHeartbeatTask detects the first heartbeat response timeout in the current cascaded encrypted tunnel, the management terminal executes steps 2-1 to 2-4 in parallel without interrupting the current tunnel, pre-calculates the backup relay path, and pre-establishes the backup cascaded encrypted tunnel after successful detection, but does not set it as an active tunnel for the time being; when the current tunnel reaches a certain number of consecutive timeouts... When a tunnel is deemed invalid, the management system directly switches the pre-established backup cascaded encrypted tunnel to the active tunnel, without waiting for the detection and establishment process of the new path to be completed, thereby shortening the duration of communication interruption.

[0075] On the other hand, the present invention also proposes a cascaded encrypted tunnel communication system based on online node relay, comprising: The reachability acquisition module is used to query the network location attributes and reachability_map field data of online nodes from the node management database after all three direct communication modes fail to detect, and generate a set of online node network location attributes. The candidate path calculation module is used to represent the reachability relationship between nodes in a directed graph, calculate the set of candidate relay paths from the management terminal to the target verification node using the breadth-first search algorithm, and sort them by hop count and resource load. The hop-by-hop detection module is used to perform hop-by-hop connectivity detection on the paths in the candidate path set in turn. It sends detection requests to the next hop node through intermediate nodes and returns the results to determine the available relay paths. The cascade tunnel establishment module is used to complete the session key negotiation for each segment of the successfully detected relay path according to the forwarding order, establish an end-to-end cascade encrypted tunnel, and complete the end-to-end session key negotiation between the management end and the target verification node. The relay transmission module is used to perform layer-by-layer encryption and encapsulation of task instruction data to generate multi-layer nested ciphertext data packets and send them through a concatenated encrypted tunnel, as well as to decrypt the returned multi-layer nested ciphertext data packets layer by layer to obtain the task execution results and persist them. The tunnel maintenance module is used to maintain the end-to-end heartbeat detection and round-trip delay calculation of the RelayHeartbeatTask for the cascaded encrypted tunnel, as well as to trigger alternative path reconstruction when the tunnel fails, and to pre-build a backup tunnel in parallel when the first heartbeat times out in order to shorten the handover interruption time.

[0076] By way of example, the system proposed in this invention may also include various features and combinations thereof in the method embodiments, which will not be elaborated here.

[0077] In the case where all three communication modes in Embodiment 1 fail to detect, this invention extracts network reachability data of online nodes from the node management database in step 2-1. In step 2-2, a set of candidate relay paths is calculated using a directed graph and breadth-first search algorithm. This overcomes the limitation that there is no direct reachable path between the management terminal and the target verification node, allowing the target verification node to be indirectly included in the unified scheduling scope of the management terminal through forwarding from other online nodes. This solves the problem of verification nodes becoming communication blind spots due to bidirectional access control policies. In step 2-4, layer-by-layer encryption and encapsulation are performed by independently negotiating session keys for each relay path segment. And introduces an end-to-end session key in the innermost layer that is held only by the management terminal and the target verification node. This ensures that each intermediate verification node can only decrypt routing header information belonging to its own layer during forwarding, and cannot obtain the plaintext content of task instruction data. This overcomes the factor that intermediate nodes may access the plaintext of business data in relay forwarding scenarios, thus maintaining end-to-end confidentiality of task data while relying on intermediate node forwarding. In steps 2-6, RelayHeartbeatTask independently maintains the active state of the cascaded encrypted tunnel and triggers the reconstruction process of the alternative path when a tunnel failure is detected. This overcomes the factor that communication cannot be automatically restored when any intermediate node or path segment in the relay path fails, thus solving the problem of continuous availability guarantee of relay communication links. The pre-establishment of the backup tunnel shortens the duration of communication interruption during tunnel switching by calculating and establishing the backup path in parallel when the heartbeat timeout occurs for the first time.

[0078] The embodiments of the present invention have been described above. However, the embodiments are not limited to the specific implementation methods described above. The specific implementation methods described above are merely illustrative and not restrictive. Those skilled in the art can make more equivalent embodiments under the guidance of the present embodiments, and all of them are within the protection scope of the present embodiments.

Claims

1. A distributed verification node communication system supporting forward and reverse proxy, wherein the system operates within an intrusion and attack simulation system comprised of a management terminal and verification nodes distributed across various network areas, characterized in that, The system includes: The communication framework building module is used to build a bidirectional communication framework between the management end and the verification node that supports three communication modes: forward proxy, reverse proxy and NAT traversal, and performs AES and RSA hybrid encryption on all communication data. The forward proxy communication module is used to process registration requests initiated by verification nodes, complete legality verification and node information persistence, maintain long connection heartbeats, and issue and receive task instructions and execution results. The reverse proxy communication module is used to handle the listening and starting of the verification node on the specified port, the storage and retrieval of the connection configuration information of the management end, the transmission of task instructions and the return of results after the management end actively initiates a connection; The NAT traversal communication module is used to handle the verification node obtaining public network NAT mapping information through the STUN protocol, reporting and persisting the NAT mapping information along with the registration request, and the management end establishing a communication connection using the NAT mapping information. The mode detection and switching module is used to detect the reachability of each communication mode in priority order and automatically select the available mode when the verification node starts. During runtime, it detects communication link abnormalities and triggers backup mode switching. During the switching process, it persists unfinished tasks through the task status table and reissues them after the new link is established. The node status monitoring module is used to maintain the status record objects of each verification node, perform timed heartbeat timeout detection, update the online status of nodes, and coordinate the addition and removal of nodes in the candidate pool.

2. The distributed verification node communication system supporting forward and reverse proxies according to claim 1, wherein, During the communication connection establishment phase, the communication framework module uses the RSA asymmetric encryption algorithm to securely negotiate the AES session key: the verification node randomly generates the AES session key locally. The ciphertext is obtained by RSA encryption using the management public key. ,Will The node registration information is sent to the management terminal; the management terminal decrypts it using its own private key. Restore After that, both sides used All business data is encrypted and decrypted. The encryption process is as follows: ； in, The original data before encryption. For encrypted ciphertext data, For AES session key, To randomly initialize the vector, each communication message will... With ciphertext After being assembled and packaged, they are transmitted in a unified manner.

3. The distributed verification node communication system supporting forward and reverse proxies according to claim 1, wherein, The node status monitoring module maintains a timestamp of the most recent heartbeat received for each registered and verified node. and the count of consecutive periods without a heartbeat The status record object; when performing a scheduled check task, set the current system time to... For nodes The criteria for determining heart rate timeout are: ； in, , The threshold for the number of consecutive timeout periods. The interval between heartbeats. Index the node; when the timeout condition is met, the node will be indexed. of Increment by 1, when Exceed When the online status is updated to offline and removed from the scheduling candidate pool, upon receiving a valid heartbeat again, the status will be updated to offline and removed from the scheduling candidate pool. Reset to 0, update the online status to online, and re-include the node in the scheduling candidate pool.

4. The distributed verification node communication system supporting forward and reverse proxies according to claim 1, wherein, The mode detection and switching module performs detection in the following priority order: First, it sends a connectivity probe request to the management terminal address, assuming a connection timeout threshold of [value missing]. The response timeout threshold is If a valid response is received, a forward proxy mode is used; if the forward proxy probe fails, local listening is started and the management end is notified to initiate a reverse connection, waiting for a timeout threshold. If a valid connection request is received, reverse proxy mode is used; if reverse proxy probe fails, STUN probe is performed and NAT traversal is attempted; if all three modes fail, probe is re-initiated using an exponential backoff strategy, with an initial waiting time of [time period missing]. The maximum waiting time is The retreat coefficient is 2, where , , , , These are the timeout or waiting time limits for the corresponding stages.

5. The distributed verification node communication system supporting forward and reverse proxies according to claim 1, wherein, The NAT traversal communication module further includes: when direct traversal fails, switching to the TURN relay scheme, establishing relay connections between the management terminal and the verification node to the public network TURN server respectively, and having the TURN server forward communication data between the two parties.

6. The distributed verification node communication system supporting forward and reverse proxies according to any one of claims 1 to 5, further comprising: The reachability acquisition module is used to query the network location attributes and cross-partition routing reachability data of online nodes from the node management database after all three communication modes have failed to detect the network location attributes, and generate a set of online node network location attributes. ; Candidate path calculation module, used for directed graphs This represents the reachability relationship between nodes, where For including management nodes and The set of vertices of all online verification nodes in the network. Let be a set of directed edges, with directed edges Represents a node Actively connect nodes The breadth-first search algorithm is used to calculate the number of nodes from the management end. To the target verification node Candidate relay path set Sort by number of hops from smallest to largest; if the number of hops is the same, sort by average CPU utilization of each intermediate node from smallest to largest. hop-by-hop detection module, used for... The candidate paths in the process are sequentially tested for hop-by-hop connectivity. Each intermediate node sends a probe request to the next hop node and returns the result. If the probe of any hop of the current candidate path fails, the process switches to the next candidate path. The cascaded tunnel establishment module is used to complete the session key for each segment of the successfully detected relay path according to the forwarding order. The negotiation was completed, and the management terminal and the target verification node were connected on the established cascaded encrypted tunnel. End-to-end session keys between Negotiation, Only the management terminal and the target verification node hold; The relay transmission module is used for relaying task instruction data. Perform layer-by-layer encryption and encapsulation to generate multi-layered nested ciphertext data packets. It is transmitted via a cascaded encrypted tunnel. Each intermediate node only decrypts the routing header information belonging to its own layer before forwarding the inner ciphertext, as well as the multi-layered nested ciphertext data packets returned. After decrypting layer by layer, the task execution result is obtained and persisted. The tunnel maintenance module is used to maintain end-to-end heartbeat detection and round-trip delay calculation of cascaded encrypted tunnels, trigger alternative path reconstruction when a tunnel fails, and pre-build backup tunnels in parallel when the first heartbeat times out.

7. The distributed verification node communication system supporting forward and reverse proxies according to claim 6, wherein, The candidate path calculation module constructs a directed graph. When CPU utilization exceeds the threshold Or memory usage exceeds the threshold Online nodes from vertex set Removed from the middle, among which This is the maximum CPU usage. This represents the maximum memory usage limit.

8. The distributed verification node communication system supporting forward and reverse proxies according to claim 6, wherein, The tunnel maintenance module performs an independent heartbeat detection task for each established cascaded encrypted tunnel, recording the heartbeat packet sending timestamp. With response receiving timestamp Calculate the end-to-end round-trip delay: ； When continuous Heartbeat response timeout, or exceeding the threshold continuously The number of times reached At this point, it is determined that the current cascaded encrypted tunnel has failed and an alternative path reconstruction is triggered. The threshold for the number of consecutive heartbeat timeouts. This is the maximum round-trip delay. The threshold for the number of consecutive round-trip delays exceeding the limit.

9. The distributed verification node communication system supporting forward and reverse proxies according to claim 6, wherein, The cross-partition routing reachability data obtained by the reachability acquisition module comes from the node identifiers of the successfully probed nodes recorded by the partition detection module of each verification node after sending connectivity probe requests to other known nodes in the network partition where the node is located. This data is synchronously reported to the management terminal with each heartbeat packet and merged and updated to the node connection configuration table, reflecting the measured connectivity status of each verification node to other nodes in the current heartbeat cycle.

10. The distributed verification node communication system supporting forward and reverse proxies according to claim 6, wherein, The cascaded tunnel establishment module processes task command data. When performing layer-by-layer encryption and encapsulation, the encapsulation order is from the innermost layer to the outermost layer, using the layers in the path sequentially. Session key negotiated by each intermediate node The data is encrypted, with the innermost layer using an end-to-end session key. Encryption is performed, and after each layer of encryption, a routing header containing the cascading tunnel session identifier and the communication address of the next-hop node is appended to the ciphertext. As the first intermediate node directly accessible from the management end, For the final intermediate node that is directly reachable from the target node, This represents the number of hops along the path.

Images