A network security target field competition environment unified scheduling method and system

Abstract

The application discloses a network security target range competition environment unified scheduling method and system, takes the scene demand declaration as input, carries out double re-inspection on files and namespaces of nodes, constructs a file system, a namespace and an SDN three-level isolation environment, verifies tentative features based on a submission time interval sequence, determines a token reissue range through an account association network, pre-pushes low-frequency template images to a server cache according to template calling heat to compress deployment time consumption, extracts and destroys a request before operation timing in the competition to carry out a silence period and active sudden drop evidence archiving, and finally, a resource allocation scheme and an audit archive are prepared into unified scheduling instructions by a final scheduling engine to be issued and executed, target range resource scheduling, cheating automatic evidence collection and cold template pre-acceleration are fused into a unified automatic system, the workload of post-competition manual log review is reduced, the safety of cross-scene resource recovery is improved through double residual re-inspection, and deployment delay of cold template accidental calling is reduced.

Description

Technical Field

[0001] This invention relates to the field of cybersecurity competition platform technology, and in particular to a unified scheduling method and system for a cybersecurity range competition environment. Background Technology

[0002] Cybersecurity attack and defense competitions are an important platform for cultivating and selecting information security talent. Each competition requires the simultaneous deployment of independent target machine environments for dozens to hundreds of participating teams. Traditional competition environment setup relies on operations and maintenance personnel manually creating virtual machines and configuring network topologies. A medium-sized competition can take several hours, and afterwards, scripts and backdoors left by participants must be cleaned up on each machine. Manual setup and cleanup become a bottleneck for operations and maintenance during seasons with multiple competitions scheduled intensively, especially in the window where the previous competition has not yet ended and the next one is about to start, forcing operations and maintenance teams to work overtime to compress the gap between competitions.

[0003] While existing competition platforms have shortened setup time per session through pre-built templates and scripted deployment, three shortcomings remain. First, node cleanup only removes surface-level files without systematically clearing namespace and flow table remnants, posing a risk of cross-session data leakage. Second, cheating behaviors involving obtaining flags through external channels lack automated detection and evidence solidification based on operational behavior, relying on manual reporting and log review for arbitration. Third, the lack of differentiated pre-scheduling between popular and unpopular templates means that unexpected calls to unpopular templates can result in cold starts taking several minutes, impacting competition fairness. Summary of the Invention

[0004] This invention provides a unified scheduling method and system for cybersecurity target range competition environments, aiming to solve the problems of incomplete resource recovery, lack of automatic evidence collection for cheating, and excessively long cold template startup times under multiple scheduling scenarios. The method takes the session requirement declaration as input, constructs a three-level isolation environment through double-checking at the node file layer and namespace layer, achieves cheating detection and dynamic protection by combining submission interval analysis, and shortens the deployment time of cold templates through template popularity pre-scheduling. This reduces the workload of manual review, improves the security of resource recovery, and eliminates interference with competition fairness.

[0005] The first aspect of this invention proposes a unified scheduling method for a cybersecurity test range competition environment, comprising the following steps: The request description set of the competition environment is obtained based on the scheduling engine. The historical unchecked residual nodes in the request description set are re-examined to determine the candidate resource list. The isolation level is evaluated and the isolation level parameter is obtained using the candidate resource list. Based on the isolation level parameters, file system layer isolation rules are constructed to form a file isolation unit. For the low-load namespace in the file isolation unit, an isolation policy is configured with equal weight to establish a namespace group. SDN traffic control layer instructions are issued through the namespace group to generate a three-level isolation environment. The target machine template is deployed using the three-level isolation environment to obtain the initial target machine image. The competition token is resent to determine the dynamic protection target machine based on the submission records in the initial target machine image that are suspected of leaking the problem-solving time cluster. The environment parameters of the dynamic protection target machine are randomly rearranged to obtain the randomly rearranged target range. Based on the statistical call heat distribution of the randomly rearranged target range, a heat level label is obtained. A pre-scheduled resource pool is formed by pre-scheduling low-frequency cold start templates in the heat level label. The resource allocation scheme is generated by adapting resources using the pre-scheduled resource pool. The resource allocation scheme involves delaying the delivery of core components to establish an online competition platform. Based on the online competition platform, applications for early destruction during the competition are submitted for evidence preservation to obtain cleanup audit files. Based on the cleanup audit files, hierarchical instructions are compiled to obtain unified scheduling instructions.

[0006] A second aspect of this invention proposes a unified scheduling system for a cybersecurity test range competition environment, comprising: The access evaluation module is used to obtain the request description set of the competition environment based on the scheduling engine, re-examine the historical inspection-free residual nodes in the request description set to determine the candidate resource list, and use the candidate resource list to evaluate the isolation level and obtain the isolation level parameters. The isolation construction module is used to construct file system layer isolation rules to form file isolation units based on the isolation level parameters, establish namespace groups for the low-load namespaces in the file isolation units with equal weight configuration isolation policies, and generate a three-level isolation environment by issuing SDN traffic control layer instructions through the namespace groups. Deploy the protection module to obtain the initial target machine image by deploying the target machine template in the three-level isolation environment, trigger the resending of the competition token to determine the dynamic protection target machine for the submission records in the initial target machine image that are suspected of leaking the problem-solving time cluster, and randomly rearrange the environment parameters from the dynamic protection target machine to obtain the randomly rearranged target field. The heat scheduling module is used to obtain heat classification labels based on the statistical call heat distribution of the randomly rearranged target range, pre-schedule low-frequency cold start templates in the heat classification labels to form a pre-scheduled resource pool, and use the pre-scheduled resource pool to adapt resources to generate a resource allocation scheme. The instruction output module is used to establish an online competition platform by delaying the delivery of core components of the resource allocation scheme, obtain cleanup audit files by submitting an application for early destruction of resources during the competition based on the online competition platform, and compile hierarchical instructions based on the cleanup audit files to obtain unified scheduling instructions.

[0007] The beneficial effects of this invention are reflected in the following points: 1. In existing solutions, post-competition cheating evidence collection relies on participants reporting each other and then manually reviewing operation logs. The window for detecting cheating behavior is limited by the randomness of the report and the upper limit of the review manpower of the referee group. This method uses Shell command frequency and network connection rate as continuous monitoring indicators. When both indicators decrease in the same step, it automatically determines the silent period and solidifies the complete operation command and network five-tuple evidence chain for that period. This makes the detection of cheating behavior no longer dependent on external reports but is triggered autonomously by the system based on abnormal operation behavior, with no missed detection windows across the entire competition. 2. By placing late write scanning at the file layer and background message capture at the namespace layer on the same node's recycling judgment with equal weight, a hard security gate that allows passage only with zero residue is constructed, blocking node recycling that detects residue in any dimension is established. A dual-criteria recycling verification mechanism independent of manual cleaning execution is established, realizing the transformation of cross-competition residue leakage protection from probabilistic avoidance to deterministic security conditions. For the first time, the namespace layer, a blind spot in the traditional recycling process, is included as a necessary condition for recycling judgment. 3. In the same competition, target machine templates for different problems exhibit uneven availability due to differences in historical call frequency: hot templates can be ready within seconds, while cold templates require a complete image fetch, which can take several minutes. This causes teams using cold templates to suffer additional waiting time due to non-problem-solving factors, resulting in unfairness. This method automatically selects image pre-caching or snapshot reuse strategies by analyzing the time consumption of each deployment stage of the cold template, compressing the deployment time of cold templates to be close to that of hot templates, thereby eliminating the interference of the difference in template availability on the fairness of the competition. Attached Figure Description

[0008] Figure 1 This is a flowchart illustrating a unified scheduling method for a cybersecurity test range competition environment according to the present invention.

[0009] Figure 2 This is a schematic diagram of the submission interval jump peak and periodic characteristics in the competition token leakage identification of the present invention. Figure 3 This is a structural block diagram of a unified scheduling system for a cybersecurity test range competition environment according to the present invention.

[0010] Among them: 1-Time interval sequence; 2-Basic line of team problem-solving rhythm; 3-Dense submission cluster; 4-Interval difference sequence; 5-Jump peak; 6-Fixed periodic trial section; 7-Periodic regularity level label; 8-Repeating rhythm segment; 9-Comprehensive risk score curve; 10-High risk threshold line; 11-Warning threshold line. Detailed Implementation

[0011] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0012] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0013] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0014] The technical solutions of the embodiments of this application will be described below.

[0015] like Figure 1 As shown, this embodiment of the invention provides a unified scheduling method for a cybersecurity test range competition environment, including the following steps S101-S105: Step S101: Obtain the request description set of the competition environment based on the scheduling engine, re-examine the historical exempted residual nodes in the request description set to determine the candidate resource list, and use the candidate resource list to evaluate the isolation level and obtain the isolation level parameters.

[0016] Specifically, the scheduling engine obtains the request description set for the competition environment. After the registration deadline for each cybersecurity competition, the scheduling engine receives the session requirement declaration submitted by the competition organizing committee. The requirement declaration includes the target machine operating system type and version number required for that competition, the network topology template number (one of three predefined networking modes: star, tree, or fully interconnected), the number of participating teams and the maximum number of CPU cores and memory allocated to each team, the question type tag (attack / defense, problem-solving speedrun, or comprehensive penetration testing), and whether internet access is required. The request description set, using the session number as the primary key, transforms the requirement declaration for each competition into a standardized resource request record. This record is the system's implementation of the session requirement declaration and includes the storage path of the operating system image, the number of network devices in the topology template and the interconnection link specifications, and a high availability constraint requiring all target machines for that competition to be deployed in a rack-distributed manner to avoid a single rack power failure causing the entire competition to become unavailable. The standardized format of the request description set eliminates the need for operations teams to manually parse heterogeneous requirement declarations submitted by different organizing committees. Regardless of whether the original requirement declaration is submitted in Excel spreadsheet or web form, the front-end adaptation layer converts it into a unified JSON record. Requirement declarations from previous sessions can thus be directly reused as the resource estimation baseline for the next similar competition. After receiving the request description set, the scheduling engine queries historical resource reclamation records based on the OS and topology combination requested in the requirement declaration. Nodes that were not reclaimed within 24 hours after the end of the previous session are marked as historically exempt residual nodes and added to the residual node sub-table of the request description set for retrieval in subsequent review processes.

[0017] In some embodiments, re-examining historical exempted residual nodes in the request description set to determine a candidate resource list includes: retrieving the associated historical exempted node set based on the request description set to obtain the complete set of nodes to be inspected; verifying the historical residual degree of the complete set of nodes to be inspected to form a file residual marker; verifying the residual status of the network namespace layer through the file residual marker to obtain the spatial residual result; and removing nodes that still contain residual characteristics based on the spatial residual result and the file residual marker to determine the candidate resource list.

[0018] The complete set of nodes to be inspected is obtained by retrieving the associated historical exempt node set based on the request description set. The physical server IP and virtual machine instance ID are extracted from the residual node sub-table of the request description set one by one. For each record, a node liveness query request is sent to the cluster management platform to confirm whether the node is still online and not occupied by subsequent sessions. This step is the first action after the request description set is handed over for re-inspection. If the node is offline and the IPMI out-of-band management interface is reachable, the cluster management platform starts and loads a read-only detection image via the PXE network; if the IPMI is unreachable, the node is marked as an uninspectable node, skipping this round of re-inspection and requiring manual intervention to check its physical status. This read-only detection process is consistent with the high availability constraints agreed upon when the request description set was initiated. The image only contains file system mounting tools and network namespace scanning scripts and does not contain any persistent write capabilities to ensure that the detection process itself does not introduce new residual data to the members of the complete set of nodes to be inspected. Each record in the complete set of nodes to be inspected includes its physical location (rack number and slot number), virtualization type (KVM or Docker), session number and end timestamp, and exempt mark status. All nodes marked as exempt from inspection in all historical sessions within the cluster will be aggregated into a complete set of nodes awaiting inspection, which may number in the hundreds. With multiple sessions and dense scheduling, the number of exempt nodes can accumulate to hundreds. A single CTF competition typically has 100 to 300 teams, each with 1 to 3 target machines. After 5 to 10 competitions, the pool of exempt nodes can reach hundreds. The complete set of nodes awaiting inspection is sorted in descending order of the end time of the last session, so that the nodes of the most recently ended session are given priority to enter the re-inspection pipeline, thereby quickly releasing popular nodes with high turnover rates for the new round of request scheduling.

[0019] File residual markers are generated by verifying the residual status of historical sessions for the entire set of nodes to be inspected. The entire set of nodes to be inspected is scanned from a designated storage volume for all file directory paths written by participants during the previous competition. The scan scope is limited to the Home directory and all non-system files under / tmp and / var / tmp. This scan step must be completed for each node in the entire set of nodes to be inspected. For each participant's file scanned in the entire set of nodes to be inspected, the last modification timestamp is read and compared with the end time of the previous competition. Files whose last modification time is more than 30 minutes later than the competition end time are marked as late-written files. After excluding known system paths such as system logs and package management caches, and assuming that all user processes have terminated after the competition and there should be no further new writes to non-system paths, the remaining late writes are considered residual risk files, and are compiled into file residual markers. File remnant markers list the number of late-written files and their total bytes, a list of files delayed by more than one hour, and a top-level classification of these files based on whether their owner UID belongs to a participant's account. Nodes with more than 10MB of late-written files or more than 20 late-written files are marked as heavily remnant nodes. If the late writes of historically exempt nodes are concentrated within 2 hours after the end of the cleanup window, and happen to be outside the previous scan window, they are separately marked as periodic regeneration remnants in the file remnant markers and treated differently from ordinary heavy remnants. Such remnant sources are usually outside the coverage of the cleanup service, and the file remnant markers indicate that the problem needs to be eradicated at the node image template level rather than relying on a single file deletion.

[0020] Network namespace layer residual status is verified using file residual markers to obtain space residual results. For nodes marked with heavy residuals in the file residual markers and clean nodes without late file writes, network namespace layer verification is performed one by one. For sample nodes with Docker virtualization, the same virtual network interface as the previous round is created, and network traffic packets are captured for 60 seconds to detect unexpected background communication from the IP range of the previous participant. For nodes with KVM virtualization, since the network namespace is completely released when the Guest OS is destroyed under full virtualization, space residual results do not need to be verified for these nodes. Namespace destruction on containerized target machines using Docker with a shared kernel depends on whether the cleanup hooks are triggered normally during container runtime. Abnormal execution of cleanup hooks can cause iptables rules and traffic shaping queues to remain in the host kernel. This is why, in addition to file residual markers, network layer verification is required to form space residual results. The records for each node in the spatial remnant results list the number of source packets and destination port distribution of historical sessions captured within a 60-second window: if the destination ports are concentrated in 22 (SSH) or 3389 (RDP), the remnant packets are more likely to be TCP keep-alive heartbeats. SSH's default TCP KeepAlive interval is 7200 seconds, and heartbeats within 2 hours after the competition are legitimate remnants rather than backdoor communication; if the destination ports involve high-numbered ports above 8000 or show ICMP tunnel characteristics, the packets may originate from a backdoor process deployed by the participant. For clean nodes marked as file remnants, if the spatial remnant result is zero packets, it confirms that the node is completely clean from the file layer to the network layer, and can skip deep cleaning and directly enter the candidate resource list.

[0021] Based on the spatial remnant results and file remnant markers, nodes still containing remnant characteristics are removed to determine the candidate resource list. The remnant node set for this re-examination is formed by taking the union of the nodes with remnant packets in the network layer from the spatial remnant results and the nodes with severe remnants from the file remnant markers. Nodes in the remnant node set undergo a full deep cleanup process instead of simply deleting expired files. Deep cleanup includes forcibly terminating all processes in the process tree whose parent process is not in the system base image service whitelist. The whitelist is taken from the cgroup path prefixes corresponding to all service units under / usr / lib / systemd after the minimal installation of this OS version, unloading the temporary file system mounted by the contestant, clearing all iptables custom chains and restoring the default policy to ACCEPT before rebuilding the DROP rules required for isolation, and deleting the remnant reference entries of the network namespace under / proc / net on the host machine. Only nodes that have been processed will appear on the candidate resource list. The candidate resource list includes all nodes with no residual data. Each node is appended with its OS type, file system mount point list, available resource quota for the physical server, and earliest schedulable time (the time of cleanup completion plus a 60-second waiting window for system booting and necessary service startup). This waiting window value maintains the same time granularity as the 60-second network window for space residual verification to ensure consistent checking by operations personnel. Nodes with double clean data in the space residual results skip deep cleanup and are counted as ready-to-use nodes in the candidate resource list in their original state. This means that these nodes are immediately available for selection as target nodes by the scheduling engine in the next competition from the time of this re-examination, without waiting for the cleanup process to complete.

[0022] Isolation level parameters are obtained by assessing the isolation level using the candidate resource list. Nodes marked as ready to use in the candidate resource list can be immediately allocated to new sessions without waiting for the cleanup process. Based on this, the scheduling engine extracts the number of participating teams, whether internet access permissions are enabled, and the three session attributes (attack and defense, problem-solving speed, and comprehensive penetration) from the request description set for each competition. The comprehensive security risk score R is calculated as follows: R = 0.4 × team normalized value + 0.3 × internet access Boolean value + 0.3 × problem type coefficient. The number of teams is taken as the number of teams in this session divided by the historical maximum number of teams in a single session (range [0,1]). Internet access permissions are 0 (no) or 1 (yes). The problem type coefficient is 0.2 (problem-solving speed), 0.6 (comprehensive penetration), and 1.0 (attack and defense). A higher R value indicates that the session is more likely to have lateral attacks between teams or information leakage to outside the session. The original team and internet access permission data are all from the same session record attached to the candidate resource list allocation process. Thus, the isolation level parameters for this session are determined. Loose isolation eliminates the need for deep namespace cleanup and SDN flow table aging monitoring, making it suitable for small-scale problem-solving speed-competition sessions. Each session's isolation level parameter lists its R value, three isolation levels: R < 0.3 corresponds to loose isolation, 0.3 ≤ R < 0.7 corresponds to standard isolation, and R ≥ 0.7 corresponds to strict isolation, requiring full OverlayFS auditing and DPI deep packet inspection, along with the corresponding environment configuration level. When available nodes are sufficient in the candidate resource list, they are prioritized for high-R-value strict isolation sessions. If multiple teams are detected as engaging in high-risk cheating during a session, the isolation level parameter for that session can be upgraded online via YAML hot-loading by the scheduling engine without interrupting the competition, triggering an immediate switch in the SDN controller's flow table management rules.

[0023] Step S102: Based on the isolation level parameters, construct file system layer isolation rules to form file isolation units. Establish namespace groups by configuring isolation policies for low-load namespaces in the file isolation units with equal weights. Generate a three-level isolation environment by issuing SDN traffic control layer instructions through the namespace groups.

[0024] Specifically, file isolation units are formed by constructing file system layer isolation rules based on isolation level parameters. The required isolation strength level for each competition is extracted from the isolation level parameters, namely, loose isolation, standard isolation, and strict isolation. Simultaneously, the OS types and file system mount point lists of all nodes allocated to that competition are retrieved from the candidate resource list. All three levels are specified by the isolation level parameters. Loose isolation only imposes chroot restrictions on the participants' writable Home directory and mounts read-only / usr and / bin directories to prevent tampering with system binary files. Standard isolation, based on loose isolation, mounts the / tmp directory as an independent tmpfs and assigns each team a unique owner UID, making temporary files between different teams completely inaccessible. Strict isolation creates a completely independent OverlayFS file system layer for each team's target machine node and records all file write operations throughout the competition in the Upper layer of this layer for post-competition auditing and backtracking of complete operation traces for security incidents. The file isolation unit is divided into sessions and nodes, with each entry listing its isolation level, file system mount list, chroot enabled status, and OverlayFS Lower and Upper layer mirror paths. The chroot enabled status for each of the three levels is reflected in the file isolation unit node by node. For sessions with the strict isolation level, an audit log collection module is also added to the file isolation unit. This module monitors all file change events in real time through the inotify mechanism and writes them to a read-only log storage volume to ensure that post-competition security auditors can fully trace all file operations performed by participants on the target machine.

[0025] In some embodiments, establishing a namespace group for the low-load namespace in the file isolation unit by configuring an isolation policy with equal weights includes: generating a load classification marker by statistically analyzing the traffic occupancy ratio of each namespace through the file isolation unit; verifying low-load protocol layer traces using the load classification markers to determine a low-load list; detecting port listening status on the low-load list to obtain port verification results; and establishing a namespace group by configuring an isolation policy with equal weights based on the port verification results.

[0026] Load grading labels are generated by statistically analyzing the traffic occupancy ratio of each namespace within a file isolation unit. A 5-minute moving average is calculated for the inbound and outbound traffic of each namespace within the file isolation unit. This window is independent of the file isolation unit's mounting period. The traffic occupancy ratio is the ratio of the namespace's byte throughput within the current window to the total throughput of all namespaces on the same server, multiplied by the isolation level reduction factor for that namespace's session (1 for strict isolation, 0.8 for standard isolation, and 0.6 for loose isolation, with a maximum factor of 1 to ensure the weighted ratio does not exceed 100%). The stricter the isolation level, the less the namespace's traffic occupancy is reduced, as strict isolation sessions have more active network activity and greater security monitoring value. Load grading labels are assigned to each namespace as high, medium, or low load based on the reduced traffic occupancy ratio. The threshold for high load is a occupancy ratio exceeding 25%, and the threshold for low load is a occupancy ratio below 5%. The audit log module within the file isolation unit captures all file change events in real-time via inotify under strict isolation levels, independent of the load grading label's statistical period. The difference between the scanning traffic of the target machines used by the main attacking teams and the heartbeat signaling bandwidth requirements of idle target machines is several orders of magnitude. The load grading tag quantifies this difference into a grading label for subsequent low-load identification. If multiple namespaces within the same session are all classified as low-load in the load grading tag, it indicates that the participating teams in that session are generally in the stage of reading the questions or local debugging rather than interacting with the target machines. In this case, the bandwidth quota of the target machine's network card can be temporarily reduced, and the freed-up physical bandwidth can be transferred to high-load sessions on the same server that are busy scanning or transmitting data. When the session resumes interaction, the bandwidth can be dynamically adjusted back, allowing the bandwidth to be allocated according to the actual rhythm reflected by the load grading tag.

[0027] The low-load list is determined by verifying low-load protocol layer traces using load grading tags. All namespaces classified as low-load in the namespace grading results of the load grading tags are traversed. For each low-load namespace originating from the load grading tags, its protocol layer metadata is captured, including TCP handshake message frequency, UDP source port distribution range, and ICMP message type distribution. Truly idle namespaces typically only occasionally receive Type 8 Echo request probes in the ICMP dimension. If Type 0 Echo responses are continuously detected, it indicates that the namespace is still responding to external probes. Normally active target machines typically maintain dozens of concurrent TCP connections and continuously send UDP packets. Truly idle target machines have all TCP connections in the CLOSE_WAIT or TIME_WAIT state, and UDP packets drop sharply to zero, leaving only sporadic packets generated by automatic operating system behaviors such as DNS (port 53) and NTP (port 123). After joint determination with TCP state, the granularity of differentiation is improved to the second level. The idle namespaces identified in this way are summarized into a low-load list. The low-load list includes the ID, session information, and traffic percentage of each idle namespace. This traffic percentage field directly uses the reduced value given by the load grading flag without recalculation. If a namespace below the low-load threshold in the load grading flag still exhibits active TCP connection reconstruction behavior at the protocol layer (i.e., frequent SYN packets appearing in a short period of time), it indicates that although the overall traffic of the namespace is very low, the upper-layer application is still running. Such namespaces do not appear on the low-load list but are retained in the medium-load level to prevent inappropriate isolation and tightening operations from being performed on teams that are actually still participating due to misjudgment of idleness.

[0028] The port verification results are obtained by checking the port listening status of the low-load list. Port scans are performed one by one within the namespaces covered by the low-load list, checking whether there are still LISTEN TCP ports or bound UDP ports on the network interfaces of each namespace in the low-load list. The scan range is limited to well-known ports 1 to 1024 and the custom ports from the previous round. The liveness criterion is whether a TCP SYN half-open scan sends a SYN packet and receives a SYN-ACK. For UDP ports, due to the lack of a handshake mechanism, the liveness criterion is changed to checking whether the inode of the corresponding entry in / proc / net / udp is still held by the process. The result is one entry in the port verification results. The port verification results list the port number still in the LISTEN state, the corresponding process name, the idle time of the last connection establishment, and the original traffic percentage of the namespace to which the port belongs in the low-load list. Three consecutive windows in the low-load list that are all in the low-load level namespace are marked as consecutively low-load. A typical path for zombie ports is that a temporary HTTP proxy process is killed but the socket remains open, and the port remains in the LISTEN state. Subsequent new connection requests will trigger a kernel RST response instead of a normal SYN-ACK three-way handshake. Namespaces where all ports are closed, or where only the basic SSH and DNS ports are retained while the rest are in the CLOSED state, are considered cleaned up and marked as reclaimable in the port verification results. Ports that are LISTEN but whose corresponding PIDs have disappeared from / proc represent typical zombie port resource leaks. These zombie ports are marked with a forced cleanup flag in the port verification results, and a forced port reclamation command is sent to the initialization cleanup process of the server to which the namespace belongs.

[0029] Namespace groups are established based on the port verification results and the equal-weighted configuration isolation policy. Namespaces marked as recyclable and dead port namespaces marked as "forced cleanup" in the port verification results are grouped by their respective physical servers. Namespaces determined to be recyclable or subject to forced cleanup in the port verification results are grouped into the same namespace group as long as they belong to the same physical server. Within a group, there is no distinction between the competition round or isolation level of the namespaces; they are physically merged only by server to simplify the granularity of subsequent batch issuance of control commands at the SDN layer. Each namespace group is assigned a unified Virtual Network Function Label (VNF) label. This label is used as a source or destination matching field in the SDN controller's flow table rules, enabling the issuance of traffic control policies at the group level rather than the individual namespace level. For example, when a rate-limiting command is issued to a VNF label, the controller automatically expands it into an OpenFlow rate-limiting rule corresponding to each member namespace under that label and issues it one by one, eliminating the need to issue commands to each namespace individually. Namespaces marked as recyclable in the port verification results have been confirmed to be completely free, and their network interface bandwidth and SDN flow table entries can be safely migrated to high-load namespaces. If the number of namespaces in a group is less than 30% of the total number of namespaces on the server, it indicates that most of the namespaces on the server are still active. In this case, the creation of namespace groups is temporarily suspended until the proportion of namespaces in the group exceeds 50% to reduce the overhead of SDN flow table updates caused by frequent group creation and destruction.

[0030] In some embodiments, generating a three-level isolation environment by issuing SDN traffic control layer instructions through the namespace group includes: generating a traffic distribution spectrum by statistically analyzing the flow table connection target distribution of each tenant in the namespace group; establishing a key control list by verifying the aging anomaly characteristics of the flow table based on the traffic distribution spectrum; issuing SDN control rules using the key control list to obtain control execution results; and generating a three-level isolation environment by encapsulating the file isolation unit, namespace group, and control execution results across layers.

[0031] Traffic distribution spectra are generated by statistically analyzing the flow table connection target distribution of each tenant within a namespace group. VNF tags are used as source-destination matching fields in the SDN controller's flow table rules to enable batch control commands to be issued at the namespace group level. Using the member namespace IDs within each namespace group as filtering conditions, the SDN controller's OpenFlow flow table database queries all flow table matching records for each group within the last 10 minutes. Aggregation statistics are then performed based on the network segment to which the destination IP address of the flow table belongs, yielding the flow table connection target distribution for that group. These statistical results constitute the traffic distribution spectra. When the proportion of east-west traffic is high, but the proportion of north-south traffic is also high and significantly greater than the former, it indicates that participants within the group are simultaneously conducting external penetration and internal scanning. This is a typical traffic characteristic of red team collaborative attack and defense, rather than simple cheating internal network probing. The key to distinguishing between the two lies in whether the destination ports of the east-west traffic are concentrated within the target machine port range reserved by the competition platform, rather than being randomly scattered. The traffic distribution spectrum is expanded by group, with each group listing its target network segment distribution vector, east-west traffic percentage, and north-south traffic percentage. Groups with north-south traffic exceeding 80% indicate that participants within that group are primarily conducting penetration tests on external targets. Groups with east-west traffic exceeding 30% indicate lateral movement or internal network scanning behavior among participants within that group. Under normal circumstances, the traffic distribution in the idle reclamation group within the namespace group should be close to zero. If an idle reclamation group still exhibits abnormal non-zero traffic, it indicates that namespace reclamation operations within that group have not been fully completed. This should be marked as an abnormal reclamation in the traffic distribution spectrum to alert operations personnel for investigation.

[0032] A key control list is established by verifying the abnormal characteristics of flow table aging based on the traffic distribution spectrum. Based on the connection target distribution and traffic direction ratio of each group in the traffic distribution spectrum, the SDN flow tables are checked group by group to verify whether there are any over-aged but not aged flow table entries. This verification is based on the connection target distribution given by the traffic distribution spectrum. The SDN controller's flow table aging mechanism relies on the idle_timeout and hard_timeout timers in the OpenFlow protocol to control the lifespan of each flow table entry. Under normal circumstances, idle flow table entries with no traffic are automatically removed from the hardware flow table by the SDN controller after the idle_timeout period, which is usually set to 30 seconds. Entries that are not removed after the expiration date appear on the key control list. The key control list lists all over-aged flow table entries, with each entry including its matching fields, actual idle time, and over-aging multiple. The east-west and north-south traffic ratios of each group after the traffic distribution spectrum is expanded by group are also presented in a statistical table for cross-referencing during the verification of the key control list. Flow table entries with an actual idle time exceeding three times the `idle_timeout` value are identified as aging-out aberration entries. Aging-out aberrations are usually caused by the SDN controller's aging timer scanning thread getting stuck or the keep-alive connection between the OpenFlow switch and the controller being interrupted, resulting in the failure to successfully issue flow table deletion commands. These entries are marked with a forced clearing flag in the key management list. A large number of short-lived flow table entries are not reclaimed in a timely manner. The root cause is that port scanning and batch probing behaviors generate independent flow tables for each brief handshake. These entries should be cleared by the aging timer, but if the number of deletion requests pending on the switch at the same time exceeds the control plane processing rate, the undeletable entries continue to accumulate. If groups with a high proportion of north-south traffic also detect aging-out aberrations, it indicates that the clearing speed is not keeping up.

[0033] SDN control rules are issued using a key control list to obtain control execution results. For each record in the key control list, a RESTful API call command corresponding to the key control list is sent to the northbound interface of the SDN controller. The command includes a forced deletion operation for all aged and abnormal flow table entries in the group, i.e., issuing an OFPFFC_DELETE command to the corresponding OpenFlow switch, and a proportional reduction of the idle_timeout value of the remaining normal flow table entries in the group, reducing the original default 30 seconds to 15 seconds to accelerate the recycling of inactive traffic flow table entries, thereby reserving more TCAM space for traffic in the high-activity group. The execution status is thus reflected in the control execution results. Each control execution command includes its type (DELETE or MODIFY), target DPID, matching field, and switch response status code (0 indicates successful execution). For flow table entries marked for mandatory removal in the key control list, a second query of the same switch's flow table is required after the deletion command is executed to confirm that the entry has indeed disappeared from the hardware flow table. If the entry is still detected in the second query, it indicates that there is a data plane and control plane asynchrony issue in the connection between the switch and the controller. This needs to be escalated to a controller channel anomaly event in the control execution result and trigger a keep-alive probe of the control link for that switch. Control commands are issued in batches by server group within a single issuance cycle to avoid congestion of the switch's flow table hardware write channel caused by sending too many FlowMod messages in a short period on the same switch. When more than 100 flow table entries need to be deleted on the same switch, the deletion operation will be executed in segments, with each segment spaced 200 milliseconds apart, to control the switch's CPU load. The success or failure of each step of the segmented execution is recorded in the control execution result for subsequent verification.

[0034] After encapsulating the cross-layer linkage of file isolation units, namespace groups, and management execution results, a three-level isolation environment is generated. The execution status of instructions at each level in the management execution results is summarized: all three levels' statuses are based on the acknowledgment signals received from the management execution results. The file isolation unit at the file system layer provides the mount and chroot status of each node; the namespace group at the namespace layer provides the resource reclamation and process cleanup status of the network stack; and the management execution results at the SDN traffic management layer provide the flow table cleanup and aging correction status. After summarizing the three levels' statuses, three sets of environment startup configuration files (YAML format manifest files) are output according to three isolation levels: loose, standard, and strict. These files together constitute the three-level isolation environment. The loose level of the three-level isolation environment only includes chroot restrictions at the file system layer and basic network namespace isolation, without involving deep flow table management at the SDN layer. The standard level adds port cleanup of the namespace group and basic flow table isolation rules at the SDN layer on top of the loose level. The strict level adds full auditing of OverlayFS, deep aging control of SDN flow tables, and mandatory verification of the key control list for east-west traffic on top of the standard level. Each session automatically matches the corresponding environment configuration level within the Level 3 isolation environment according to the level specified in its isolation level parameters, without requiring manual selection. If a security event occurs during the competition in a session, i.e., a participant is detected to have accessed resources from other sessions on the same server by exceeding the current isolation level's restrictions, the isolation level of that session can be upgraded online to a higher level by the scheduling engine without interrupting the competition. This triggers a hot reload of the corresponding Level 3 isolation environment configuration file without restarting the target machine nodes.

[0035] Step S103: Deploy the target machine template using the three-level isolation environment to obtain the initial target machine image. Trigger the resending of the competition token to determine the dynamic protection target machine based on the suspected leak of the submission records in the initial target machine image where the problem-solving time is clustered. Obtain the randomly rearranged target field from the environment parameters of the dynamic protection target machine.

[0036] Specifically, the initial target machine image is obtained by deploying a target machine template in a three-level isolation environment. After performing joint parsing on the isolation configuration files matched to each session in the three-level isolation environment, the base system image of the corresponding OS version is pulled from the image repository. Based on the network topology template of that session, the MAC addresses and IP addresses of the network interfaces of the base images of multiple target machine nodes are pre-configured and written. All specific parameters of the pre-configuration come from this joint parsing result. After completion, a complete system boot process is executed on each node to confirm that the sshd and competition-dedicated scorebot agent processes start normally within the 60-second boot timeout. scorebot is the service process deployed within the target machine used to receive the Flag strings submitted by the participants and automatically verify and score them. After passing the verification, the node is officially counted as a member of the initial target machine image. The initial target machine image assigns a unique session-sequence identifier to each node. Each identifier lists its SHA256 digest, IP-MAC binding pair, boot completion timestamp, and first SSH login timestamp. The environment configuration files of the three-level isolation environment can be hot-loaded online by the scheduling engine to upgrade the isolation level during the competition. To prevent brute-force SSH scans from obtaining other teams' IPs, under strict isolation, the target machine IPs of each team are discontinuous and unpredictable; under loose isolation, IPs of different teams belong to the same large subnet, but mutual access is blocked using iptables rules. If the boot process of any node in the initial target machine image fails, i.e., sshd or scorebot fails to start successfully within 60 seconds, that node is automatically marked as a deployment failure node by the scheduling engine, and a backup node is triggered to be reallocated and redeployed from the candidate resource list according to the same level-three isolation environment configuration.

[0037] In some embodiments, triggering the resending of competition tokens to determine dynamic protection target machines for suspected leaks of problem-solving time aggregation in the initial target machine image includes: calculating the submission time interval of the same competition token based on the initial target machine image to obtain a time interval sequence; using the time interval sequence to verify fixed-period trial characteristics to generate risk submission markers; analyzing the submission account association characteristics through the risk submission markers to establish an account association network; and determining the scope of competition token resending from the account association network to determine dynamic protection target machines.

[0038] The time interval sequence is obtained by calculating the submission interval of the same competition token based on the initial target machine image. Only nodes that have completed registration in the initial target machine image can proceed to this step. The competition token is the Flag string itself, which is pre-installed in the Flag file path of the target machine for that problem and needs to be obtained by the participant and submitted to scorebot for verification. The same competition token refers to the same Flag string corresponding to the same problem in the same session. All Flag submission records under the same competition token are collected from the scorebot submission database. Each record includes a timestamp of the submission time accurate to milliseconds, the submitter's team number, and the target machine node sequence number corresponding to that submission. The source node must be registered in the initial target machine image before it can be accepted. The SHA256 digest value in the initial target machine image is registered in the scorebot's trusted image whitelist as a unique identifier for subsequent target machine integrity verification. The millisecond-level precision of the time interval sequence is sufficient to distinguish the granularity of manual operation and script submission. The interval of manual submission is usually not less than 500 milliseconds due to the neuromuscular delay of the keyboard and mouse, while the interval of script submission can be as low as tens of milliseconds with extremely small variance. Figure 2 As shown, the time interval sequence (1) is the Δt_i vector of each team × each question. When solving problems independently, it fluctuates irregularly around the team's problem-solving rhythm baseline (2). After the question flag is leaked, the typical behavior of multiple teams passing answers to each other is a dense submission cluster (3). That is, the submission interval of the receiving team is suddenly shortened after receiving the answer, which is in stark contrast to the previous independent problem-solving rhythm. This contrast is the core basis for the time interval sequence to be used for subsequent risk assessment.

[0039] For example, using the time interval sequence to verify the fixed-period trial characteristics to generate a risk submission marker includes: calculating the difference between adjacent intervals based on the time interval sequence to obtain an interval difference sequence; analyzing the periodic fluctuation amplitude of the interval difference sequence to obtain a periodic regularity level; verifying the repetition of submission intervals through the periodic regularity level and the interval difference sequence to form a comprehensive risk spectrum; and determining a graded disposal strategy through the comprehensive risk spectrum to generate a risk submission marker.

[0040] An interval difference sequence is obtained by calculating the difference between adjacent intervals based on the time interval sequence. After taking the submission interval vector for each team on each problem in the time interval sequence, the absolute difference between two adjacent intervals is calculated item by item along the vector: ΔΔt_i = |Δt_(i+1) - Δt_i|, where Δt_(i+1) is the next submission interval immediately following Δt_i in the vector. ΔΔt_i reflects the degree of abrupt change in the team's submission rhythm between two adjacent submissions, i.e., the amplitude of the rhythm jump. These items are accumulated to form the interval difference sequence. Teams solving problems independently typically exhibit a slow trend in their problem-solving rhythm, meaning ΔΔt_i fluctuates within a relatively small range. However, after receiving external flag information, the team suddenly switches from autonomous thinking mode to rapid submission mode, causing ΔΔt_i to experience a surge peak at the moment of reception that far exceeds the background level. The abrupt change in the interval between adjacent submissions in the time interval sequence reflects a switch in information acquisition channels rather than a natural increase in problem-solving speed. In normal competitions, this jump is limited by the cognitive switching speed of the problem solver and rarely exceeds twice the historical fluctuation range of the team. The absolute value corresponding to the historical fluctuation range of ΔΔt for most teams rarely exceeds 30 seconds. Once the jump reaches twice the aforementioned historical fluctuation range, it strongly suggests a switch in information acquisition channels. The interval difference sequence (4) is expanded by team and problem. Each entry lists the time and magnitude of its entire ΔΔt_i sequence and jump peak (5). The jump peak, along with its time, is reflected in the interval difference sequence and marked as the candidate time point of the rhythm pattern change of the team on this problem. It can be corroborated with the original submission record corresponding to the time interval sequence. Its cause may be the continuous rapid submission triggered by the Flag information being transmitted through external channels.

[0041] The periodicity level is obtained by analyzing the periodic fluctuation amplitude of the interval difference sequence. The entire ΔΔt_i sequence of each team and each question in the interval difference sequence is remapped onto an equally spaced time grid according to the actual time of each submission, and then interpolated and padded. Then, a Fourier transform is performed to convert the resampled time-domain rhythm jump signal to the frequency domain and extract all frequency components except the zero-frequency component. A significant frequency peak is defined as an amplitude that exceeds three times the median amplitude of all frequency components excluding the zero frequency in the frequency domain. The median is used to avoid zero frequency or a single strong peak from raising the mean and causing the effective periodic signal to be missed. Once a significant frequency peak is detected, it indicates that the submission rhythm of the team is modulated by an external clock signal with a fixed period. This judgment is entirely based on the rhythm fluctuations presented by the interval difference sequence. The period corresponding to the significant frequency peak is T_cycle=1 / f, where f is the frequency value corresponding to the significant frequency peak, and T_cycle is the main fluctuation period of the team's submission rhythm on this problem. If T_cycle is exactly equal to a fixed duration such as every 60 seconds or every 120 seconds, it falls into the fixed period trial zone (6), indicating that the submission behavior is driven by an external timing mechanism rather than the random rhythm of autonomous problem solving. This Fourier transform of the interval difference sequence transforms the submission rhythm from the time domain to the frequency domain, revealing the hidden periodic modulation signal, thereby evaluating the team's periodicity level. The periodicity level classifies each team into three levels: no periodicity, weak periodicity, and strong periodicity. No periodicity corresponds to the normal competitive behavior of independent problem solving, weak periodicity means that the ratio of T_cycle to the average interval between two natural submissions of the team exceeds 0.5, and strong periodicity means that the ratio is less than 0.3. The strong periodicity level corresponds to the periodicity level label (7), and such teams are recorded as periodic risk teams.

[0042] A comprehensive risk spectrum is formed by verifying the repetition rate of submission intervals using periodicity level and interval difference sequence. For each level of periodicity, the repetition patterns contained in the ΔΔt_i sequence of the interval difference sequence are statistically analyzed for each team. That is, whether a specific ΔΔt_i subsequence appears repeatedly in multiple submissions of the same team for the same problem or different problems. Repetition rate is one of the constituent indicators of the comprehensive risk spectrum. The normalization and fusion of the three indicators avoids over-reliance on any single indicator. Teams with high jump peak density but no abnormalities in periodicity and repetition rate may simply have an aggressive problem-solving strategy rather than cheating. The comprehensive score only exceeds the high-risk threshold when multiple indicators point to anomalies simultaneously, thereby compressing the probability of misjudgment from about 5% for a single indicator to less than 1% for joint judgment. The repetitive rhythm segments are further divided into two categories on the timeline: continuous repetition and interval repetition. Continuous repetition is more likely to correspond to script-automated submission, while interval repetition may correspond to participants switching between different problems and reusing the same probing strategy. The repetition rate is calculated by taking the frequency of occurrence of continuous subsequences with a length of more than 3 elements in the global sequence of all ΔΔt_i sequences on which the team's periodicity level is based. Subsequences with a frequency of more than 2 occurrences are marked as repetitive rhythm segments (8). The comprehensive risk spectrum integrates the three risk indicators of periodicity level, number of repetitive rhythm segments and jump peak density according to the team dimension and normalizes them to the interval of 0 to 1 to obtain the comprehensive risk score curve (9). Teams with a score of more than 0.7 are judged as high-risk groups and are highlighted in red in the comprehensive risk spectrum. Scores between 0.4 and 0.7 are yellow warnings, and scores below 0.4 are green normal.

[0043] The risk submission markers are generated by determining the graded handling strategy through the comprehensive risk spectrum. The risk scores of each risk score in the comprehensive risk spectrum are mapped to the three-level handling strategy by comparing them with the high-risk threshold line (10) and the warning threshold line (11): Red high-risk teams trigger the highest level of handling, that is, the target machine node currently operated by the team is automatically triggered by the scheduling engine to perform a hot migration, and the target machine is migrated online to a newly deployed sandbox node and the original token is replaced with a newly generated competition token. The IP address of the sandbox node is different from that of the original node, thus cutting off the physical Flag leakage path; Yellow warning teams trigger secondary handling, that is, the Flag of the team's current target machine is replaced with a new value by online update while the original target machine IP remains unchanged, and the submission behavior within the next 30 minutes is marked as a key observation window. The execution record of the graded handling and the change in the comprehensive risk spectrum score of the team recalculated on each question after the handling are all left in the handling log of the risk submission marker. The hot migration and token replacement described in this section are immediate responses triggered on a team-by-team basis, based on a comprehensive risk spectrum of red, yellow, and green scores. The resend lists triggered on a question-by-question basis and according to the proportion of the leaked impact, as described in the account-associated network section and dynamic protection target machine section below, constitute another independent and parallel handling mechanism. The same question may be triggered by both mechanisms sequentially, and the triggering results are recorded in the risk submission marker. If a team's score drops from red to green after handling, it indicates that the handling was effective; if the score increases instead of decreasing, it indicates that the team may still have backup flag acquisition channels. In this case, a persistent marker is added to the risk submission marker, triggering a secondary handling, i.e., restricting the team's internet outbound access.

[0044] An account association network is established by analyzing the association characteristics of submitting accounts through risk submission marker analysis. All team and question information involved in each record of the risk submission marker is used as nodes, and the condition for connecting two teams on the same question both being marked as risk submissions is used to construct an undirected account association network graph. Each connection simultaneously retains the risk submission marker record number that triggered the connection and the specific question number, for subsequent statistical use by question. The weight of the connection is the overlap of the time windows of the two teams' risk submissions on the question. The overlap is calculated as the length of the time intersection of the two teams' risk submissions divided by the harmonic mean of the lengths of the risk submission windows of the two teams. The closer the ratio is to 1, the more intensively the two teams made exploratory submissions to the question within the same time interval. The account association network organizes the edge weights of each team's nodes into an adjacency matrix. Louvain community detection is used to segment account communities based on submission behavior coupling. Physically, this means automatically identifying groups of teams sharing the same Flag leak source. For example, if teams A, B, and C are all flagged for risky submissions on the same question with highly overlapping submission times, they will be clustered into one community, indicating that Flags may be being passed between them privately. Backtracking risky submission flags reveals that high-risk leak recipient teams typically appear as high-level nodes in the account association network, meaning their number of neighboring nodes is significantly higher than the community average. The community size, geographical distribution of source IPs, and a list of questions involved in risky submissions by each team within that community are appended as supplementary information to the community overview table of the account association network. This data can be directly retrieved when calculating the Flag leak impact for each question, without needing to look up specific questions involved in a particular community.

[0045] The scope of competition token reissue is determined by analyzing the account association network to identify dynamic protection target machines. Within the account association network topology, all teams and problem combinations involved in each account's community are extracted. For each problem in that community, the Flag leakage impact surface is calculated—the percentage of high-risk submission teams within that community out of all participating teams for that problem. This result determines whether the problem is covered by the dynamic protection target machines. The calculation scope is based on the community boundaries defined by the account association network. Problems with a leakage impact surface exceeding 30% will have their corresponding competition tokens added to the mandatory reissue list because the Flag for that problem has been disseminated among at least 30% of the participating teams. Problems with a leakage impact surface between 10% and 30% will have their tokens added to the recommended reissue list, with the competition organizing committee deciding whether to implement a reissue. During the hot swap, participants only perceive a brief interruption in the target machine's SSH connection. The old target machine continues processing unfinished requests in established connections after the pause signal is issued. The new target machine, after taking over the old IP address, broadcasts Gratuitous ARP with its own MAC address to refresh the ARP cache of surrounding devices and the MAC forwarding table of the switch, automatically routing subsequent traffic to the new target machine's network card without requiring any manual intervention from the participants. The dynamic protection target machine lists the token number, resend level (mandatory or recommended), and deployment requirements of the new target machine for each challenge requiring retransmission. Teams identified as high-risk recipients of leaks in the account-associated network in the previous step are marked as key monitoring targets in the dynamic protection target machine. In the retransmission of new challenges, their target machine network traffic will be fully forwarded to the security analysis node by the SDN controller using mirrored ports.

[0046] The randomized target range is obtained by randomly rearranging the environment parameters of the dynamic protection target machines. For each newly deployed target machine node in each problem that has triggered token resending in the dynamic protection target machine list, the environment parameters are randomly rearranged. The environment parameters that can be randomly rearranged include the target machine's SSH port number (offset from the default port 22 to a randomly selected high-order port), the storage path of the Flag file on the target machine (randomly changed from the default path to another non-explicit path in the file system), and the process name of the competition service (the scorebot agent) (randomly replaced from the default name to a disguised name that imitates a common system process). These three parameters are combined into the content of the randomized target range. Problems not included in the dynamic protection target machines are not included in this step. The randomized target range records the rearranged SSH port, the new Flag path, and the fake scorebot process name for each problem. These parameters are pushed to each participating team individually via encrypted notification through the competition platform frontend before the start of the competition to prevent secondary leakage of parameters. The random offset of the SSH port renders automated tools that rely on port scanning to locate target machines ineffective. Target machines on the default port 22 can be located by Nmap's full port scan in just one second, while the average discovery time for higher-order random ports extends to several minutes. Furthermore, the scan traffic itself triggers IDS alerts first, exposing the scanning activity to attackers before they can even attack the target machine. Looking back at the dynamic protection target machine scenario where multiple teams have target machine nodes for the same challenge, each team generates its own independent parameters in the randomly rearranged target environment. Even if the random parameters of one team are leaked, it will not cause all target machines for that challenge to simultaneously lose their protection.

[0047] Step S104: Based on the statistical call heat distribution of the random rearranged target range, a heat level label is obtained. A pre-scheduled resource pool is formed by pre-scheduling low-frequency cold start templates in the heat level label. A resource allocation scheme is generated by adapting resources from the pre-scheduled resource pool.

[0048] Specifically, a popularity grading is obtained based on the call popularity distribution of the random reordered test range. After the random reordered test range is put into use, the scheduling engine extracts the total number of times each type of test machine template (OS type plus topology template combination) has been selected by the scheduling engine in the past 30 days from the test machine deployment records accumulated continuously since the initial test machine image stage. This number is used as the call popularity value of the template. At the same time, the average cold start time experienced by the template after being selected, from pulling the image from the image repository to the test machine completing booting and entering the online accessible state, is calculated. This statistic does not distinguish between the initial deployment and the redeployment triggered by the random reordered test range. The resulting statistical results are the popularity grading: the templates are sorted in descending order of call popularity, and the top 30% are hot templates, the middle 40% are warm templates, and the bottom 30% are cold templates. Each grade includes the average cold start time, the standard deviation of the cold start time, and the daily call details for the past 30 days. There are many duplicate common dependency layers between image layers of templates of the same OS type but different versions, such as the same libc and OpenSSL libraries. When the scheduling engine calculates the pull time, it marks the common layers as cached and only estimates the time of the differentiated image layers. The estimated results are also reflected in the popularity rating tag. The essence of popularity rating is resource prediction. The scheduling engine needs to make a decision on whether to pre-cache based solely on historical call data before deployment at each stage, such as random reordering of the target field, occurs. Therefore, the quantification of cold start time differences becomes the key bridge connecting historical statistics and scheduling decisions: a cold start of 5 to 8 minutes for a cold template means that teams using the problem will have to wait for the target machine to be ready for several minutes after the start of the competition and will not be able to start solving the problem. This delay is precisely the significance of popularity rating tagging to complete the prediction before the intervention of stages such as random reordering of the target field.

[0049] In some embodiments, the pre-scheduled resource pool for low-frequency cold start templates in the heat level classification marks includes: statistically analyzing the historical call distribution of each template to form a call frequency spectrum; analyzing the cold start correlation of low-frequency templates through the call frequency spectrum to obtain a low-frequency candidate set; verifying the cold start time consumption period of the low-frequency candidate set to obtain the scenario matching result; and determining the low-frequency cold start templates to form a pre-scheduled resource pool based on the scenario matching result.

[0050] A call frequency spectrum is generated by statistically analyzing the historical call distribution of each template based on its popularity grading. For each type of template in the popularity grading, daily call frequency statistics are calculated based on the number of calls made daily over the past 30 days, and the call popularity change curve for each template is plotted on a timeline. The peak of the curve typically occurs on the competition start day and the problem update day, as these two time points trigger a large number of participating teams to simultaneously request the target machine deployment instance of that template. Each template's call frequency spectrum is listed in a row, showing its daily frequency vector, popularity fluctuation amplitude (standard deviation), and the number of days since the most recent call. The distinction between pulse-type and continuous templates implies drastically different preprocessing paths in resource scheduling strategies. The call peak of pulse-type templates is predictable, and since their usage time is already scheduled in the competition schedule, the scheduling engine only needs to trigger pre-scheduling once 30 minutes before the start time marked in the schedule, rather than occupying long-term cache space to continuously store their images. If the cold start time between hot and cold templates in the popularity grading differs by more than double, a pre-scheduling decision is triggered. Templates whose daily frequency vector standard deviation exceeds their mean indicate a significant pulse-like characteristic in their call activity. These templates are marked with a pulse-type marker in the call frequency spectrum to distinguish them from templates that are truly consistently low in call frequency during subsequent screening of the low-frequency candidate set. Among the three-tiered popularity classifications, templates with an interval exceeding 7 days and a total daily frequency vector sum lower than one-tenth of the median daily average call volume of all hot templates in all versions of the OS type to which the template belongs are initially included in the low-frequency observation list after dual-condition filtering by the scheduling engine, thus forming the call frequency spectrum.

[0051] Low-frequency candidate templates were obtained by analyzing their cold-start correlation through call frequency spectrum analysis. The daily frequency vector and the number of days since the last call were traversed for each template in the call frequency spectrum. Templates with an interval exceeding 14 days (i.e., not called by any participating team for two consecutive weeks) were included in the low-activity candidate pool. After filtering the candidate pool from the call frequency spectrum, cold-start correlation analysis was performed on templates with at least 8 historical calls. Eight calls were the minimum sample size threshold for the Spearman rank correlation coefficient to reach statistical significance (α=0.05). Spearman rank correlation was chosen instead of Pearson linear correlation because the relationship between cold-start time and cache hit rate is not strictly linear. Rank correlation is invariant to nonlinear monotonic relationships, thus more accurately capturing the essential characteristics of this saturation curve. The cold start correlation is calculated using the rank correlation coefficient between the cold start time of each call to the template and the cluster image cache hit rate at the corresponding moment. If the absolute value of the correlation coefficient is greater than 0.6, meaning the higher the cache hit rate and the shorter the cold start time, it indicates that the bottleneck of the template's cold start is mainly in the image transfer process rather than the pre-configuration complexity of the template itself. Templates that meet this threshold are included in the low-frequency candidate set. In other words, the low-frequency candidate set includes templates that can accelerate the most important process of pulling the image to the local cache to shorten the cold start time. Templates marked with pulses in the call frequency spectrum, even if their recent call interval is long, will be removed from the low-activity candidate pool and excluded from the low-frequency candidate set if they have been scheduled for a certain session in the upcoming competition schedule, even if they have been recorded as having long intervals in the call frequency spectrum.

[0052] The cold start time consumption period of the low-frequency candidate set is verified to obtain scenario matching results. Within the template range covered by the low-frequency candidate set, a complete cold start process is simulated for each template. This involves randomly selecting a physical server in the cluster where the base image for that template is not yet cached locally, triggering a complete cold start operation from pulling the image from the image repository to booting the target machine, and recording the precise time consumption of each stage. This data is then aggregated into the scenario matching results. Each template in the low-frequency candidate set completes this cold start process, which is divided into four stages: image pulling time, image decompression time, system boot time, and network configuration time. After the time consumption of these four stages is decomposed, the templates in the low-frequency candidate set are assigned to the corresponding pre-scheduled strategy paths based on whether they are bottlenecks in transmission or decompression. The scenario matching results are sorted in descending order of total cold start time, and the top 50% of the templates are entered into the pre-scheduled list. The cold start simulation randomly selects a server in the cluster where the image cache is not hit to trigger the complete process, ensuring that the measured values ​​reflect the actual cold start time under worst-case conditions. OverlayFS decompression bottlenecks are jointly affected by CPU single-core frequency and compression algorithm type. Gzip image layer decompression cannot utilize multi-core parallelism, while ZSTD image layer decompression can be split into multiple threads. Under the same number of cores, the decompression time is only one-third of that of Gzip. Scenario matching results are used to distinguish the actual decompression efficiency of the two algorithms. The breakdown of the four-stage time consumption also reveals hidden bottlenecks in cold starts. Templates with system boot time accounting for more than 20% usually have too many pre-installed auto-start services. The race-state initialization of each service during the boot phase prolongs the SSHD's ready waiting time. Such templates do not enter the pre-scheduled resource pool because caching acceleration is ineffective. The optimization direction is to simplify the list of auto-start services rather than increase caching.

[0053] Based on the scenario matching results, low-frequency cold start templates are determined to form a pre-scheduled resource pool. The top 50% of templates, representing the slowest cold start times, are selected from the matching entries in the scenario matching results, sorted in descending order of total cold start time. This constitutes the pre-scheduled template list. For each template in the list, the corresponding pre-scheduling operation is performed based on whether it is identified as a transmission bottleneck or a decompression bottleneck, and the results are recorded in the pre-scheduled resource pool. For the top 50% of templates given by the scenario matching results, the pre-scheduling operation for transmission bottleneck templates involves the scheduling engine selecting at least three physical servers in the cluster whose current CPU and memory loads are below 50% and whose local disk space is sufficient to hold the complete image of the template. Image pre-pull instructions are sent to these servers to pre-transfer the target template's base image to the server's local image cache. The pre-scheduling completion status of each template in the pre-scheduled resource pool is verified by the scheduling engine before the resource allocation scheme is generated. The image pre-pull instructions for transmission bottleneck templates are sent to the target servers by the scheduling engine at least 30 minutes before the start of the competition. Templates already scheduled for the next competition in the scenario matching results have their pre-scheduling priority in the pre-scheduled resource pool increased to the highest level. The pre-scheduled idle deployment process only starts the sshd service and the scorebot agent process, skipping the application layer configuration of the competition problem. The pre-scheduling operation for decompression bottleneck templates involves the scheduling engine selecting the three servers with the most idle CPU cores to pre-execute an idle deployment of the template, i.e., deploying empty target machine instances for testing purposes, completing a real decompression to write the decompressed file system layer to the local disk cache in advance. The ready state of this cache is registered in the pre-scheduled resource pool; when the formal deployment request arrives, OverlayFS directly mounts this cache layer as the Lower layer, skipping the re-decompression step and reusing it directly.

[0054] Resource allocation schemes are generated by adapting resources from the pre-scheduled resource pool. Templates that have completed pre-scheduling operations and their corresponding target server IP lists are extracted from the pre-scheduled resource pool. A comprehensive resource score is calculated based on each server's current remaining CPU cores, available memory, and available disk space. Servers are then sorted in descending order of score to form a candidate server priority queue. Target machine deployment requests for each template are processed in a first-in, first-out order based on request arrival time. Candidate servers are retrieved sequentially from the head of the queue for resource adaptation checks, confirming whether the server's CPU and memory reserves still meet the minimum deployment requirements of the target template. Successful checks are reflected in the resource allocation scheme. The resource allocation scheme is expanded by template × server, with each allocation entry listing its binding pair, resource reserves before and after allocation, pre-scheduling type, and the server's rack number and rack location number. This constraint shares the same rack topology information with the server set selected in the pre-scheduled resource pool phase. The multi-instance distributed deployment strategy of the same template not only considers server-level fault redundancy but also incorporates rack-level physical isolation into the allocation constraint. The high availability constraint requires that key target machine nodes in the same session be deployed across at least two racks to prevent a single rack power failure or ToR switch failure from causing all target machines in that session to go offline. Templates marked as incomplete or failed in the pre-scheduled resource pool are deployed according to the normal cold start process in the resource allocation scheme and do not enjoy the acceleration benefits of pre-scheduling. The scheduling engine sends deployment instructions to each server through the cluster management platform's API, waiting for each server to return a confirmation signal that the target machine deployment is complete.

[0055] Step S105: Delay delivery of core components of the resource allocation plan to establish an online competition platform; obtain cleanup audit files by submitting an application for early destruction of resources during the competition based on the online competition platform; and compile hierarchical instructions based on the cleanup audit files to obtain unified scheduling instructions.

[0056] Specifically, the resource allocation scheme involves delayed delivery of core components to establish an online competition platform. The cluster management platform issues deployment instructions according to the bindings of each node in the resource allocation scheme. After each node completes its bootstrapping, it sends a ready signal back to the scheduling engine. Once all nodes are ready, the scheduling engine pushes a competition environment ready notification to the competition management frontend and activates the "Start Competition" button for that session on the competition control panel, marking the official opening of the online competition platform. The online competition platform generates a competition management page for each session on the competition management frontend. This page displays each participating team's target machine SSH connection information (IP address and port number), the team's current score and ranking, the Flag submission status for each problem (not attempted, passed, or failed), and a "Destroy" button for participants to request the rebuilding of the target machine environment. This page is the first publicly visible interface after the resource allocation scheme is implemented as a runnable environment. Real-time score rankings are pushed via WebSocket long-connection rather than HTTP polling. Changes in each team's score are immediately broadcast to the browsers of all online teams via a message queue after scorebot verifies the Flag, with a delay of no more than one second. In scenarios where the same template is allocated to multiple servers in the resource allocation scheme, the online competition platform includes the rack number and rack location number of the server where the target machine is located in the target machine information of each team, so that the competition operation and maintenance personnel can quickly locate the physical device. After the online competition platform is started, the scheduling engine continuously monitors the progress of each competition. When all problems in a certain competition have been solved by all participating teams or the competition countdown reaches zero, it automatically triggers the competition end process for that competition and broadcasts the competition end signal to all target machine nodes, triggering the forced disconnection of the participants' SSH connections.

[0057] In some embodiments, obtaining a cleanup audit file by storing evidence of an early destruction application during the competition based on the online competition platform includes: generating an operation sequence record based on the operation sequence before the destruction request extracted from the online competition platform; verifying the abnormal exit characteristics of resources using the operation sequence record to obtain a quiet period marker; archiving the operation sequence record associated with the quiet period marker to form a log evidence package; and generating a destruction delay approval instruction through the log evidence package to obtain a cleanup audit file.

[0058] An operation sequence record is generated based on the operation sequence prior to the destruction request extracted from the online competition platform. The online competition platform provides participants with a target machine destruction button on the competition management page. This is the only entry point on the online competition platform that allows participants to actively request the destruction of target machines. Participants can proactively initiate destruction requests to rebuild the target machine environment. However, in actual competitions, some teams have exploited this mechanism to destroy old target machines after the Flag has been leaked, in order to cover up their access traces of obtaining the Flag from external sources. All such requests must be fully recorded in the operation sequence record as original material for subsequent verification during the quiet period. Each destruction request in the operation sequence record is archived independently, containing the request time, the shell command history with timestamps for the previous 60 minutes, external connection records with timestamps (including a list of destination IPs), and the Flag submission time sequence. Shell command history is collected by a pre-installed auditd daemon on the target machine, which writes each execve system call record to a remote log storage in read-only mode. Even if a participant gains root privileges on the target machine, they cannot tamper with or delete log entries already written to the remote storage because the network link between the target machine and the log storage is unidirectional and write-only. The choice of this window length also serves the post-competition arbitration needs of the online competition platform and is not arbitrary. 60 minutes corresponds to the median time from the start of most CTF competition problems to the first team solving them. Within this window, the complete operation trajectory of the participant from the start of problem analysis to successful flag submission can be fully covered. If the destruction request happens to occur within a few minutes after the flag submission in this window, its temporal correlation constitutes the first layer of evidence of suspected cheating and is left in the operation sequence record for further verification.

[0059] For example, using the operation timing record to verify the abnormal exit characteristics of resources to obtain the quiet period marker includes: calculating the activity drop rate before the quiet period based on the operation timing record to obtain the activity drop spectrum; using the activity drop spectrum to analyze the switching characteristics of unconventional access channels to form an activity drop list; performing integrity verification on the access records associated with the activity drop list to generate a complete session result; and determining the key evidence storage objects through the complete session result to obtain the quiet period marker.

[0060] The activity drop spectrum is obtained by calculating the rate of activity drop before the silence based on the operation sequence records. On the timeline of each team in the operation sequence records, a statistical window is set at one minute. The frequency of Shell command inputs (number of commands per minute) and the rate of new network connections (number of new TCP connections per minute) are calculated within each window. After arranging these two indicators along the timeline, the rate of change between adjacent windows is taken as Δrate_j = rate_j - rate_(j-1), where rate_j is the value of the command frequency or connection rate in the j-th window, and j is the window number. Δrate is calculated independently for each indicator as an activity change indicator. Drop event determination: A drop event is defined as when the command frequency and new connection rate both drop below 30% of the average of the indicators in the six windows (i.e., the first six minutes) before the drop occurs within three consecutive windows, and this state must remain unchanged for three minutes. The start and end intervals are thus determined, becoming a record in the activity drop spectrum. This derivation uses only a 60-minute window of data extracted from the operation timeline, anchored at the time of the destruction request. Without this operation timeline, the starting point cannot be located. The activity drop spectrum is updated sequentially for each team and window. The gradient change of Δrate distinguishes between gradual and abrupt drops: when thinking slows down, Δrate is continuously slightly negative, indicating natural decay; in an abrupt drop, the absolute value of Δrate within a single window exceeds the average of the previous window by three times, corresponding to a sudden change in behavior pattern. Two indicators dropping simultaneously, but the meaning of a single indicator dropping is different. A drop in command frequency alone might only be due to participants switching to scripting, while a drop in new connection rate alone might be due to the problem entering the offline reverse engineering phase. Only when both indicators drop simultaneously is it determined and reflected in the activity drop spectrum, eliminating misjudgments.

[0061] An activity drop list is generated by analyzing the characteristics of unconventional access channel switching using the activity drop spectrum. Based on the timeline of drop events for each team in the activity drop spectrum, the target machine access logs of each team after the drop event are examined to determine whether the team switched access methods after the drop, such as switching from direct SSH connection to accessing the target machine via HTTP proxy or SOCKS tunnel. The results are then compiled into the activity drop list. The detection of access method switching closely follows the drop window marked by the activity drop spectrum, relying on the source IP change pattern recorded in the target machine's SSH service log. When a participant switches from direct SSH to an HTTP proxy, the source IP changes from a single public IP to the proxy server's exit IP, and this IP usually belongs to a known public proxy or VPN service provider address range. The scheduling engine completes the switch identification within milliseconds by comparing it in real time with the public proxy IP blacklist database. Teams marked with encoded transmission flags in the activity drop list because their access IP matches a known IM server address range or protocol fingerprint are directly upgraded to the highest level of suspicion. The timeline of sudden activity drops for each team in the activity drop spectrum is the precise starting point for determining whether the access method has been switched; without this time anchor, it would be impossible to trace the source. Communication matching with known IM server IPs utilizes a regularly updated, third-party-maintained database of public communication platform IP ranges. Platforms like WeChat and Telegram use fixed AS numbers and BGP prefixes to declare their IP ranges. The matching process also checks the protocol fingerprint of the communication port, specifically whether the SNI extension field in the TLS handshake contains the domain name of a known IM platform. The comparison result determines whether a team in the activity drop list points to an external communication channel.

[0062] The access records associated with the activity drop list are verified for integrity to generate a complete session result. The activity drop list is traversed team by team, and all SSH session records of each team that switched access methods after the activity drop are retrieved. For each session, a TCP flow integrity verification is performed, checking whether the TCP three-way handshake is complete, whether the TCP sequence numbers during the session are consecutive, and whether the four-way handshake at the end of the session is completed correctly. These three verification results together constitute the complete session result. Sessions not appearing in the activity drop list are not included in this verification. A complete three-way handshake scores 0.3 points (0 points for missing any SYN / SYN-ACK / ACK step), consecutive sequence numbers throughout the process score 0.4 points (0 points for any gap), and a correctly completed four-way handshake scores 0.3 points (0 points for any RST or single-sided FIN). The sum of these three scores is the completeness score [0,1]. In forensic analysis, the reasons for discontinuous TCP sequence numbers need to be distinguished between active injection and passive packet loss. Active injection of RST or forged packets will cause a single point of jump in the sequence number, with the window size remaining consistent before and after the jump. Passive packet loss, on the other hand, will cause discontinuous sequence numbers accompanied by a halving of the TCP window and exponential backoff behavior due to retransmission timeouts. Sessions with an integrity score below 0.5 are considered suspicious because the probability of a normal TCP connection exhibiting significant anomalies in at least two of the three dimensions simultaneously is extremely low. All SSH sessions of teams marked with encoded transmission in the activity drop list are upgraded to key audit targets in the session complete results. The session complete results list the integrity score, the start and end time periods of the drop, and details of the access method switch, categorized by session number. This information can be directly referenced in subsequent quiet period marking stages without requiring re-verification or review of earlier data structures.

[0063] The quiet period is marked by identifying key evidence targets based on the complete session results. Evidence is prioritized by ranking teams in descending order of suspicion in the complete session results, with the top 20% registered as key evidence targets. This percentage is based on the total number of suspicious sessions in the complete session results, not the total number of teams in the entire competition. The total amount of SSH session records can reach hundreds of gigabytes. Post-competition manual analysis must concentrate evidence-gathering resources on the most suspicious teams. This cutoff point ensures that highly suspicious teams are not overlooked and keeps the workload of manual review to within one-fifth of the total number of suspicious sessions in the complete session results. The progressively increasing three-tier penalty recommendations correspond to the disciplinary system of the competition rules. Sentencing also considers the team's recorded periodicity level evidence in the comprehensive risk spectrum. Warnings apply to teams with a weak periodicity in the comprehensive risk spectrum evidence strength. Point deductions apply to teams with a strong periodicity or repetitive rhythm in the comprehensive risk spectrum evidence strength and a limited impact. Disqualification applies to situations where both the quiet period mark and the comprehensive risk spectrum evidence strength are the highest, resulting in a zero score and a one-year ban. The silent period marker establishes a record for each key evidence object: the start and end time of the silent period, details of the access method switch, and the lowest TCP session integrity score (all three are taken from the records associated with the session integrity results by session number), as well as the magnitude of the drop and the penalty recommendation level. After the competition ends, the scheduling engine sends the complete evidence chain and penalty recommendation for the key evidence objects marked in the silent period marker, along with the post-competition arbitration report for that question, to the competition's judging panel. The judging panel makes a final ruling based on the competition rules and the strength of the evidence. The ruling result is ultimately reflected in the post-ruling status field of the silent period marker for archiving and querying.

[0064] The operation sequence records associated with the silent period markers are archived to form a log evidence package. For each marked team included in the silent period markers, the operation sequence records of each destruction request are first verified for integrity. All command history logs, network connection logs, and Flag commit log triples of the team in this competition are packaged into an independent evidence file, and the operation logs on other target machine nodes of the team that have not been destroyed are also archived together to form a complete operation behavior evidence chain of the team in this competition, which are then compiled into the log evidence package. The log evidence package is organized into a JSON document by team and request number. The evidence file contains the timestamp range of the evidence, the line-by-line original record of the Shell command history within the range, the network connection five-tuple information, and the timestamps and commit results of all Flag commit events within the range. The log evidence package is securely transferred to the audit server for archiving via SFTP after the competition and can be quickly retrieved by team number during arbitration review. The triplet structure of the evidence storage file uses the integrity of the timeline as the core verification dimension of the evidence chain. This integrity is also the most important criterion for selecting key evidence storage objects during the quiet period. Command history and network connections must corroborate each other on the timeline; that is, the TCP connection corresponding to the execution time of a certain command should have a corresponding entry in the network five-tuple record. Breaks or inconsistencies in timestamps will directly weaken the evidentiary strength of the evidence chain, and these breaks are marked with timeline break markers in the log evidence package for the arbitrator's awareness. The use of JSON format balances the machine readability and human readability of the evidence data, allowing arbitrators to directly view the contents of the log evidence package without the need for dedicated evidence collection software. Teams whose penalty recommendation during the quiet period is disqualification will have their log evidence packages retrieved and reviewed first during post-match arbitration.

[0065] The cleanup audit file is obtained by generating a delayed approval instruction for destruction through the log evidence package. After each evidence entry in the log evidence package is summarized by team, the scheduling engine performs delayed approval on the team's target machine destruction request. That is, the target machine destruction operation, which should have been executed immediately, is suspended and placed in the approval waiting queue. In the waiting queue, the scheduling engine automatically compares the severity level marked by the quiet period in the team's log evidence package with the team's penalty records in the current competition to decide whether to approve the destruction (execute target machine reconstruction), refuse destruction (lock the target machine's current state), or conditionally approve the destruction (approve destruction but require a full dd image backup of the target machine's disk to a dedicated forensic storage volume before destruction). The result is reflected in the cleanup audit file. The essence of delayed approval is to strike a balance between the efficiency of target machine resource recovery and the integrity of forensic evidence protection. Immediate recovery of the target machine can release its CPU and memory resources, but for conditionally approved targets, immediate recovery means the permanent loss of disk evidence. After the cleanup audit file is compiled, the scheduling engine categorizes each target machine into a recovery, backup, or lock group according to the processing results of each team, for batch execution in the subsequent unified scheduling instruction phase. The log evidence package, serving as original evidence for post-competition arbitration, will be archived for at least 12 months. The audit files for each team will list the processing results and the basis for their decisions, allowing post-competition auditors to review each team individually. The dd image backup uses byte-by-byte copying instead of file-level copying. File-level copying can be manipulated by participants by modifying file system metadata such as inode timestamps or hard link redirections, while byte-by-byte copying preserves the original bit sequence of the disk. This allows tools like extundelete to recover files deleted by participants but whose underlying data blocks have not been overwritten from the backup image, providing complete file-level evidence for arbitration.

[0066] A unified scheduling instruction was derived from the hierarchical instructions compiled based on the cleanup audit files. From the destruction request processing results and post-match penalty recommendations of each team in the cleanup audit files, the unified scheduling requirements for all teams in each competition were extracted. Specifically, target machines approved for destruction needed to trigger a resource reclamation process; target machines conditionally approved for destruction needed to undergo a full disk image backup before triggering the reclamation process; and target machines refused destruction needed to remain locked pending post-match manual verification. All these conclusions were summarized to form the unified scheduling instruction. Each competition session had one YAML instruction file, arranging the scheduling operations for all target machine nodes in that session into three groups: reclamation, backup, and locking. The reclamation group executed `docker container stop` and the cleanup process; the backup group first performed a `dd` disk image backup to the audit storage volume before executing the reclamation process; and the locking group maintained the current running state and cut off network access, retaining only local console access. This grouping logic is entirely based on the processing results given in the cleanup audit files. The three groups are arranged in an ordered manner, not in parallel. The backup group must be executed before the reclaim group because the source data for the backup operation will no longer exist after the reclaim operation. The lock group is executed independently of the first two groups because it does not involve any changes to the resource state; it only requires disconnecting the network access. For example, in YAML, a field declares that a backup group task must wait for the corresponding reclaim group task to be marked as waiting before it can be executed. The scheduling engine automatically arranges the execution order according to this dependency. Teams marked as high-priority evidence in the cleanup audit files have their corresponding target machines marked with a priority arrangement tag in the backup group of the unified scheduling instruction, and are executed at the front of the backup group queue. The scheduling engine distributes the unified scheduling instructions to all relevant physical servers for execution at once through the batch instruction API of the cluster management platform.

[0067] To implement the above-described method embodiments, a unified scheduling method for a cybersecurity test range competition environment is proposed to achieve the corresponding functionalities and technical effects. See also... Figure 3 , Figure 3 This diagram illustrates a structural block diagram of a unified scheduling system 300 for a cybersecurity range competition environment according to an embodiment of this application. For ease of explanation, only the parts relevant to this embodiment are shown. The unified scheduling system 300 for a cybersecurity range competition environment provided in this embodiment includes: The access evaluation module 301 is used to obtain the request description set of the competition environment based on the scheduling engine, re-examine the historical inspection-free residual nodes in the request description set to determine the candidate resource list, and use the candidate resource list to evaluate the isolation level and obtain the isolation level parameters. The isolation construction module 302 is used to construct file system layer isolation rules to form a file isolation unit based on the isolation level parameters, establish a namespace group for the low-load namespace equal weight configuration isolation policy in the file isolation unit, and generate a three-level isolation environment by issuing SDN traffic control layer instructions through the namespace group. Deploy protection module 303, which is used to deploy target machine templates in the three-level isolation environment to obtain an initial target machine image, trigger competition token resending to determine dynamic protection target machine based on the suspected leakage of submission records with problem-solving time aggregation in the initial target machine image, and obtain a randomly rearranged target field from the environment parameters of the dynamic protection target machine. The heat scheduling module 304 is used to obtain heat classification labels based on the heat distribution of the random rearranged target range statistics, pre-schedule low-frequency cold start templates in the heat classification labels to form a pre-scheduled resource pool, and use the pre-scheduled resource pool to adapt resources to generate a resource allocation scheme. The instruction output module 305 is used to establish an online competition platform by delaying the delivery of core components of the resource allocation scheme, obtain cleanup audit files by submitting an application for early destruction of the resource allocation scheme during the competition based on the online competition platform, and compile hierarchical instructions based on the cleanup audit files to obtain unified scheduling instructions.

[0068] The aforementioned unified scheduling system 300 for a cybersecurity range competition environment can implement the unified scheduling method for a cybersecurity range competition environment described in the above-described method embodiments. The options in the above method embodiments are also applicable to this embodiment and will not be detailed here. The remaining content of this application's embodiments can be referred to the content of the above method embodiments, and will not be repeated in this embodiment.

[0069] The above embodiments are not an exhaustive list based on the present invention, and there may be many other embodiments not listed. Any substitutions and improvements made without departing from the concept of the present invention are within the protection scope of the present invention.

Claims

1. A unified scheduling method for a cybersecurity test range competition environment, characterized in that, include: The request description set of the competition environment is obtained based on the scheduling engine. The historical unchecked residual nodes in the request description set are re-examined to determine the candidate resource list. The isolation level is evaluated and the isolation level parameter is obtained using the candidate resource list. Based on the isolation level parameters, file system layer isolation rules are constructed to form a file isolation unit. For the low-load namespace in the file isolation unit, an isolation policy is configured with equal weight to establish a namespace group. SDN traffic control layer instructions are issued through the namespace group to generate a three-level isolation environment. The target machine template is deployed using the three-level isolation environment to obtain the initial target machine image. The competition token is resent to determine the dynamic protection target machine based on the submission records in the initial target machine image that are suspected of leaking the problem-solving time cluster. The environment parameters of the dynamic protection target machine are randomly rearranged to obtain the randomly rearranged target range. Based on the statistical call heat distribution of the randomly rearranged target range, a heat level label is obtained. A pre-scheduled resource pool is formed by pre-scheduling low-frequency cold start templates in the heat level label. The resource allocation scheme is generated by adapting resources using the pre-scheduled resource pool. The resource allocation scheme involves delaying the delivery of core components to establish an online competition platform. Based on the online competition platform, applications for early destruction during the competition are submitted for evidence preservation to obtain cleanup audit files. Based on the cleanup audit files, hierarchical instructions are compiled to obtain unified scheduling instructions.

2. The method according to claim 1, characterized in that, The process of re-examining historical exempted residual nodes in the request description set to determine the candidate resource list includes: Based on the request description set, retrieve the associated historical exempt node set to obtain the complete set of nodes to be inspected; For the nodes to be inspected, the historical session residuals are verified to generate file residual markers; The spatial remnant result is obtained by verifying the remnant status of the network namespace layer through the file remnant marker. Based on the spatial residual results and the file residual markers, nodes that still contain residual characteristics are removed to determine the candidate resource list.

3. The method according to claim 1, characterized in that, The step of establishing a namespace group for the low-load namespace equal-weight configuration isolation policy in the file isolation unit includes: The file isolation unit is used to calculate the traffic usage ratio of each namespace and generate a load classification label. The low-load list is determined by verifying low-load protocol layer traces using the load classification markers. The port verification results are obtained by detecting the port listening status of the low-load list; Namespace groups are established based on the port verification results and the equal-weight configuration isolation policy.

4. The method according to claim 1, characterized in that, The process of generating a three-level isolation environment by issuing SDN traffic control layer instructions through the namespace group includes: For the namespace group, the flow table connection target distribution of each tenant is statistically analyzed to generate a flow distribution spectrum; Based on the aforementioned flow distribution spectrum, verify the aging abnormal characteristics of the flow meter and establish a key control list; The SDN control rules are issued using the aforementioned key control list to obtain control execution results; The file isolation unit, the namespace group, and the control execution result are encapsulated and linked across layers to form a three-level isolation environment.

5. The method according to claim 1, characterized in that, The step of triggering a resend of the competition token to determine the dynamic protection target machine based on the suspected leakage of submission records in the initial target machine image where the problem-solving time is clustered includes: The time interval sequence is obtained by calculating the submission time interval of the same competition token based on the initial target machine image; The time interval sequence is used to verify the fixed-period trial characteristics and generate a risk submission marker; An account association network is established by analyzing the associated characteristics of submitted accounts using the risk submission markers; The dynamic protection target machine is determined by judging the resend range of the competition token from the account association network.

6. The method according to claim 1, characterized in that, The pre-scheduled resource pool is formed by pre-scheduling low-frequency cold start templates in the heat level classification markers, including: The call frequency spectrum is formed by statistically analyzing the historical call frequency distribution of each template based on the popularity grading markers. The low-frequency candidate set is obtained by analyzing the low-frequency template cold start correlation through the call frequency spectrum analysis. The scene matching results are obtained by verifying the cold start consumption period of the low-frequency candidate set; Based on the scenario matching results, a low-frequency cold start template is determined to form a pre-scheduled resource pool.

7. The method according to claim 1, characterized in that, The process of obtaining cleanup and audit files by submitting an application for early destruction of evidence during the competition through the online competition platform includes: An operation sequence record is generated based on the operation sequence before the destruction request extracted from the online competition platform. The quiet period marker is obtained by verifying the abnormal exit characteristics of the resource using the operation timing record; The operation timing records associated with the silent period marker are archived to form a log evidence package; The log storage package generates a destruction delay approval instruction to obtain the cleanup audit file.

8. The method according to claim 5, characterized in that, The step of generating a risk submission marker by verifying the fixed-period trial features using the time interval sequence includes: Based on the time interval sequence, the interval difference value sequence is obtained by calculating the difference between adjacent intervals; The periodicity level is obtained by analyzing the periodic fluctuation amplitude of the interval difference sequence. A comprehensive risk spectrum is formed by verifying the interval repeatability through the periodicity level and the interval difference sequence. The risk submission marker is generated by determining the graded disposal strategy based on the comprehensive risk spectrum.

9. The method according to claim 7, characterized in that, The step of using the operation timing record to verify the abnormal exit characteristics of resources to obtain the silent period marker includes: The activity drop spectrum is obtained by calculating the rate of activity drop before silence based on the operation timing record. The activity drop spectrum analysis is used to analyze the switching characteristics of unconventional access channels and generate an activity drop list; Perform integrity verification on the access records associated with the activity drop list to generate a complete session result; The key evidence-keeping objects are identified by the complete results of the session, and a silent period marker is obtained.

10. A unified scheduling system for a cybersecurity test range competition environment, characterized in that, include: The access evaluation module is used to obtain the request description set of the competition environment based on the scheduling engine, re-examine the historical inspection-free residual nodes in the request description set to determine the candidate resource list, and use the candidate resource list to evaluate the isolation level and obtain the isolation level parameters. The isolation construction module is used to construct file system layer isolation rules to form file isolation units based on the isolation level parameters, establish namespace groups for the low-load namespaces in the file isolation units with equal weight configuration isolation policies, and generate a three-level isolation environment by issuing SDN traffic control layer instructions through the namespace groups. Deploy the protection module to obtain the initial target machine image by deploying the target machine template in the three-level isolation environment, trigger the resending of the competition token to determine the dynamic protection target machine for the submission records in the initial target machine image that are suspected of leaking the problem-solving time cluster, and randomly rearrange the environment parameters from the dynamic protection target machine to obtain the randomly rearranged target field. The heat scheduling module is used to obtain heat classification labels based on the statistical call heat distribution of the randomly rearranged target range, pre-schedule low-frequency cold start templates in the heat classification labels to form a pre-scheduled resource pool, and use the pre-scheduled resource pool to adapt resources to generate a resource allocation scheme. The instruction output module is used to establish an online competition platform by delaying the delivery of core components of the resource allocation scheme, obtain cleanup audit files by submitting an application for early destruction of resources during the competition based on the online competition platform, and compile hierarchical instructions based on the cleanup audit files to obtain unified scheduling instructions.

Images