High-concurrency network security target range system and method based on container dynamic arrangement

Abstract

The application relates to the technical field of network security, in particular to a high-concurrency network security target range system and method based on container dynamic arrangement, which comprises an environment arrangement module, a network isolation module, a port mapping module and a security credential generation module. The environment arrangement module automatically starts multiple-node containers in sequence; the network isolation module realizes two-layer network isolation between target range instances; the port mapping module avoids port conflicts; the security credential generation module generates unique verification credentials and injects the container environment; and the authentication refresh module realizes non-susceptible Token refresh at the front end by using a mutual exclusion lock and a request queue, thereby guaranteeing uninterrupted long-period operation. The application can one-key deploy a complex vulnerability environment containing a database and a middleware, realizes absolute isolation under multi-user concurrency, prevents static credential cheating, guarantees operation continuity, and significantly improves the concurrency capability and teaching effect of the network target range.

Description

Technical Field

[0001] This invention relates to the field of network security technology, specifically to a high-concurrency network security test range system and method based on container dynamic orchestration. Background Technology

[0002] With the rapid development of information technology, cybersecurity issues are becoming increasingly serious. The traditional cybersecurity teaching model, which mainly relies on theoretical lectures, can no longer meet the needs of cultivating practical talents due to the lack of realistic and systematic training environments. To address this, cybersecurity test range platforms have emerged, aiming to construct simulated environments through virtualization technology to provide students with practical training in vulnerability discovery, penetration testing, and other skills.

[0003] However, existing technologies generally suffer from the following drawbacks in practical applications: Poor environmental isolation: For example, the network security training method and device based on the integration of virtual machines and containers provided in CN117591239A are based on virtual machine or static shared container technology. Virtual machine solutions have inherent defects such as slow startup, high resource consumption, and difficulty in agile orchestration; while simple container solutions are prone to environment reuse and port conflicts when multiple users practice the same problem concurrently, leading to "environment pollution" (such as the backdoor residue of the previous user affecting the next user) or lateral privilege escalation attacks, and cannot guarantee the pure isolation of "one problem, one environment".

[0004] Weak anti-cheating mechanisms: Traditional CTF (Capture The Flag) platforms (such as the open-source platform Hackergame) mostly use static flag mechanisms, hardcoding fixed flags into the environment. This allows users to directly score points by privately sharing flags (commonly known as "copying homework"), making it impossible for the platform to accurately assess the actual ability of learners. Although Announcement No. CN106874245B provides a dynamic flag generation method, it focuses on the algorithm itself and does not address how to automate injection and lifecycle management in complex multi-container target environments, making it difficult to systematically apply in teaching practice.

[0005] Insufficient orchestration capabilities for complex environments: Existing platforms (such as the open-source platform FlawPlatformMatch) often require administrators to manually write scripts to configure and start CVE vulnerabilities sequentially when reproducing CVE vulnerabilities involving multiple nodes such as web servers, databases, and middleware. This manual approach is not only inefficient and error-prone, but also prone to generating zombie containers that consume a large amount of server resources, lacking one-click dynamic orchestration capabilities based on dependencies.

[0006] There is a disconnect in the interactive experience: existing front-end and back-end separation testbeds typically use a single token authentication mechanism. During long-term security drills or code audits, once the token expires, the system will forcibly interrupt the user's operation and redirect to the login page, causing the user to lose their ongoing terminal input or code writing state, which greatly affects the immersive drill experience. Summary of the Invention

[0007] The purpose of this invention is to provide a high-concurrency network security range system and method based on container dynamic orchestration, so as to solve the problems of poor isolation of the range environment, weak anti-cheating ability, difficulty in orchestrating complex environments, and discontinuity in interactive experience.

[0008] To achieve the above objectives, the present invention provides the following technical solution: a high-concurrency network security test range system based on container dynamic orchestration, comprising a test range management backend, a container scheduling engine, and a front-end interaction module. The container scheduling engine includes an environment orchestration module, a network isolation module, a port mapping module, and a security credential generation module. The front-end interaction module has a built-in authentication refresh module, which is used to maintain the session without interruption when the session credentials used to interact with the container scheduling engine are detected to have expired. The environment orchestration module parses the target range definition file containing multiple service nodes, extracts the dependencies between nodes and constructs a directed acyclic graph. It then determines the startup order of the service nodes using a topology sorting algorithm. Based on this startup order, it synchronously coordinates the following operations when starting the containers corresponding to each service node: The network isolation module is invoked so that when it receives a user's environment startup request for the target question, it generates a unique network identifier associated with the user and the target environment instance, creates an independent container network corresponding to the network identifier, and mounts the network interfaces of all service containers involved in the question requested by the user to the independent container network. The port mapping module is invoked to scan the available ports on the host machine before starting each service container that needs to expose a port to the outside world. It allocates an unused host machine port for the container from the available port pool and dynamically rewrites the static port mapping rules in the target range definition file to map the internal ports of the container to the allocated host machine port. The security credential generation module is invoked so that when the environment orchestration module starts the service container, it generates a verification credential associated with the user and the target instance based on the user identifier and the question identifier that initiated the request using a one-way encryption algorithm, and injects the verification credential into the runtime environment of at least one of the service containers. The authentication refresh module intercepts request failure events caused by expired session credentials at the front end, controls the refresh process through a mutex lock, suspends subsequent requests to the request queue, and obtains a new session credential in the background using the refresh credential, releases the lock, and replays the requests in the request queue in sequence.

[0009] Preferably, the environment orchestration module is specifically used for: Read the Docker Compose format target definition file and parse the depends_on field to obtain the dependency relationship between service nodes; Construct a directed acyclic graph by treating all service nodes as vertices and dependencies as directed edges, and check for circular dependencies. If a circular dependency exists, terminate the orchestration and return an exception message. Perform a depth-first search topological sort or Kahn algorithm on the directed acyclic graph to obtain a linear startup sequence. Call the container engine interface according to this sequence to create and start containers, where the dependent service nodes start before the nodes that depend on them.

[0010] Preferably, the unique network identifier generated by the network isolation module is composed of the user identifier, the question identifier, and the session identifier of the current target range instance.

[0011] Preferably, the port mapping module is configured to establish and update a port occupancy record table, which includes at least the allocated host port number, container identifier, user identifier, question identifier, port status, and expiration time fields; when allocating a port, the table is queried to ensure that the allocated port number is within the preset range of available ports and is not occupied; after the container stops or reaches its expiration time, the status of the corresponding record is updated to reclaim the port resources.

[0012] Preferably, the security credential generation module uses HMAC-SHA256 or HMAC-SM3 algorithm as the one-way encryption algorithm, takes the combination of user identifier, question identifier and current session identifier as the message, performs hash calculation with the platform preset key as the key, and extracts the hash value of a predetermined length as the verification credential content. The verification credentials are injected into the service node configured with credential placeholders via container environment variables. The security credential generation module is also used to regenerate the expected credential based on the same parameters and perform consistency verification with the submitted credential when the user submits the verification credential.

[0013] Preferably, the authentication refresh module is configured as follows: Capture session credential expiration responses in the front-end request interceptor; When the mutex variable isRefreshing is false, set it to true and initiate a session credential refresh request. At the same time, encapsulate the current request and subsequent concurrent requests into a Promise object and push it into the request queue. After the session credentials are successfully refreshed, the locally stored session credentials are updated, isRefreshing is set to false, and each request in the request queue is replayed in first-in-first-out order.

[0014] Preferably, it also includes a resource lifecycle management module, which is used to set a maximum survival time for each testbed instance and start timing; when the instance running time exceeds the maximum survival time or a user manual termination command is received, all containers corresponding to the instance are automatically stopped, and destruction operations are performed sequentially according to the order of containers and independent container networks.

[0015] A high-concurrency cybersecurity test range method based on container dynamic orchestration includes the following steps: S1. Environment orchestration steps: Receive the user's environment startup request for the target problem, read the target range definition file containing multiple service nodes, extract the dependencies between nodes and construct a directed acyclic graph, and determine the startup order of service nodes through a topology sorting algorithm. S2. Network isolation step: Obtain the user identifier and question identifier corresponding to the environment startup request, generate a unique network identifier associated with the user identifier and the question identifier, and create an independent container network corresponding to the network identifier; S3. Port mapping steps: Scan the available ports on the host machine, allocate unused host machine ports for each service container that needs to expose a port to the outside world in the target range definition file, dynamically rewrite the static port mapping rules in the target range definition file, and record the allocated port mapping relationship in the port occupancy record table. S4. Security Credential Generation and Injection Step: When starting each service container according to the startup order determined in step S1, the environment orchestration step coordinates the following synchronization operations: Obtain the user identifier and the question identifier, and generate a verification credential associated with the user and the target range instance through a one-way encryption algorithm; Mount the network interface of the currently started service container to the independent container network created in step S2, and map the host port allocated in step S3 to the internal port of the service container. For service containers configured with credential placeholders, the verification credentials are injected into the container's runtime environment via container environment variables; S5. Authentication refresh steps: During the operation of the test instance, the front end continuously intercepts request failure events caused by the expiration of session credentials, controls the refresh process through a mutex lock, suspends subsequent requests to the request queue, obtains a new session credential in the background using the refresh credential, releases the lock and replays the requests in the request queue in turn to maintain the persistent connection between the user and the test instance. S6. Resource Management Steps: Set a maximum survival time for the test range instance. When the instance runs for longer than the maximum survival time or is manually terminated by the user, automatically destroy the container and independent container network corresponding to the test range instance in the order of the container and the independent container network created in step S2.

[0016] Compared with the prior art, the beneficial effects of the present invention are: This invention effectively prevents operational interference and data pollution during multi-user concurrency by dynamically creating a dedicated Docker Bridge network and an independent port mapping pool, completely solving the environment isolation problem and ensuring the purity of the environment. Through a topology sorting and orchestration engine, it automatically builds and launches a complex multi-node CVE vulnerability environment containing databases, middleware, and application code in the correct order, successfully resolving the complex environment orchestration problem, achieving one-click deployment, and reducing operation and maintenance costs. Through a dynamic Flag generation and injection mechanism based on HMAC algorithm and user characteristics, it achieves "personalized results for each user," making Flags unpredictable and unshareable, effectively preventing cross-user cheating, greatly enhancing anti-cheating capabilities, and ensuring the fairness and seriousness of the assessment. By introducing a "mutex lock and suspend queue" session credential seamless refresh mechanism in the front-end design, it ensures the continuity of user operations during long-term penetration testing, effectively improving the interactive experience and enhancing learning efficiency. Simultaneously, through timeout settings and garbage collection mechanisms, it automatically destroys container instances and networks, ensuring system stability and resource utilization under high concurrency. Most importantly, the above effects are achieved through the collaborative work of technical solutions: topology sorting ensures the correctness of complex environment dependencies, enables dynamic port mapping to be carried out efficiently and without conflict, and precise resource scheduling and status feedback make it possible for the front end to refresh without being noticed. Each step is interconnected, resulting in the technical effect of stably supporting high-concurrency users to conduct multiple heterogeneous vulnerability practice exercises under limited resources. This collaboration enables the stable support of high-concurrency users to conduct multiple heterogeneous vulnerability practice exercises under limited resources. Attached Figure Description

[0017] Figure 1 This is a block diagram of the overall structure of the high-concurrency network security test range system based on container dynamic orchestration of the present invention. Detailed Implementation

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

[0019] It should be noted that, in this invention, the verification credential specifically refers to the dynamic credential (Flag) used to verify the user's solution results within the target range instance; the session credential specifically refers to the authentication credential (Token) used to maintain the uninterrupted interaction session between the user and the platform.

[0020] Please see Figure 1 This invention provides a technical solution: a high-concurrency network security range system based on container dynamic orchestration, including a range management backend, a container scheduling engine, and a front-end interaction module. The container scheduling engine includes an environment orchestration module, a network isolation module, a port mapping module, and a security credential generation module. The front-end interaction module has a built-in authentication refresh module, which is used to maintain the session without interruption when the session credentials used to interact with the container scheduling engine are detected to have expired. The environment orchestration module is used to parse the target range definition file containing multiple service nodes, extract the dependencies between nodes and construct a directed acyclic graph, determine the startup order of service nodes through a topology sorting algorithm, and start the containers corresponding to each service node by coordinating the following operations based on the startup order. The environment orchestration module is specifically used for: Read the Docker Compose format target definition file and parse the depends_on field to obtain the dependency relationship between service nodes; Construct a directed acyclic graph by treating all service nodes as vertices and dependencies as directed edges, and check for circular dependencies. If a circular dependency exists, terminate the orchestration and return an exception message. Perform a depth-first search topological sort or Kahn algorithm on the directed acyclic graph to obtain a linear startup sequence. Call the container engine interface according to this sequence to create and start containers, where the dependent service nodes start before the nodes that depend on them.

[0021] The network isolation module is used to generate a unique network identifier associated with the user and the target environment instance when it receives a user's request to start the environment for the target question, and to create an independent container network corresponding to the network identifier, and to mount the network interfaces of all service containers involved in the question requested by the user to the independent container network. The unique network identifier generated by the network isolation module is composed of the user identifier, the question identifier, and the session identifier of the current test range instance. The independent container network it creates is a Docker Bridge network. The independent container networks of different test range instances are isolated at the data link layer, and network communication and lateral scanning are prohibited by default.

[0022] The port mapping module is used to scan the available ports on the host machine before starting each service container that needs to expose a port to the outside world, allocate an unused host machine port for the container from the available port pool, and dynamically rewrite the static port mapping rules in the target range definition file to map the internal ports of the container to the allocated host machine port. The port mapping module is configured to create and update a port occupancy record table, which includes at least the allocated host port number, container identifier, user identifier, question identifier, port status, and expiration time fields. When allocating a port, the table is queried to ensure that the allocated port number is within the preset range of available ports and is not occupied. After the container stops or reaches its expiration time, the status of the corresponding record is updated to reclaim the port resources.

[0023] The security credential generation module is used to generate a verification credential associated with the user and the target instance based on the user identifier and the challenge identifier that initiated the request, using a one-way encryption algorithm, when the environment orchestration module starts the service container, and inject the verification credential into the runtime environment of at least one of the service containers. The security credential generation module uses HMAC-SHA256 or HMAC-SM3 algorithm as the one-way encryption algorithm, takes the combination of user identifier, question identifier and current session identifier as the message, performs hash calculation with the platform preset key as the key, and extracts the hash value of a predetermined length as the verification credential content. The verification credentials are injected into the service node configured with credential placeholders via container environment variables. The security credential generation module is also used to regenerate the expected credential based on the same parameters and perform consistency verification with the submitted credential when the user submits the verification credential.

[0024] The authentication refresh module is used to intercept request failure events caused by session credential expiration on the front end, control the refresh process through a mutex lock, suspend subsequent requests to the request queue, obtain a new session credential using the refresh credential in the background, release the lock and replay the requests in the request queue in sequence. The authentication refresh module is configured as follows: Capture the HTTP 401 status code in the front-end request interceptor; When the mutex variable isRefreshing is false, set it to true and initiate a token refresh request. At the same time, encapsulate the current request and subsequent concurrent requests into a Promise object and push it into the request queue. After the token is successfully refreshed, the locally stored session credentials are updated, isRefreshing is set to false, and each request in the request queue is replayed in first-in-first-out order.

[0025] It also includes a resource lifecycle management module, which is used to set a maximum survival time for each testbed instance and start a timer; when the instance running time exceeds the maximum survival time or a user manual termination command is received, all containers corresponding to the instance are automatically stopped, and destruction operations are performed sequentially according to the order of containers and independent container networks.

[0026] This invention completely solves the environmental isolation problem. By dynamically creating a dedicated Docker Bridge network and an independent port mapping pool, it ensures that each user has a dedicated sandbox environment completely isolated from the host machine and other users every time they reproduce a vulnerability. This effectively prevents operational interference and data pollution during multi-user concurrency, ensuring the purity of the environment. Simultaneously, this invention successfully resolves the challenge of complex environment orchestration. Through a topology sorting orchestration engine based on the dependency graph parsing algorithm of docker-compose.yml, it can automatically and correctly build and launch a complex multi-node CVE vulnerability environment containing databases, middleware, and application code, achieving one-click deployment, reducing operational costs, and expanding the platform's capabilities. Furthermore, through a resource governance mechanism, it ensures the system's stability and resource utilization under high concurrency. After a user manually closes a challenge or target instance and the timeout period expires, the container instance and network are automatically destroyed, releasing resources and preventing zombie processes.

[0027] This invention significantly enhances anti-cheating capabilities. Through a dynamic Flag mechanism, employing an HMAC-based algorithm and user-feature-driven generation and injection method, a unique dynamic Flag, obfuscating the user ID and question ID, is injected into the host container's environment variables, achieving a personalized experience for each user. The Flag is unpredictable and cannot be shared, effectively preventing cross-user cheating and ensuring the fairness and seriousness of the assessment. This invention also effectively improves the user experience. Through a seamless refresh mechanism, a "mutex lock and suspend queue" mechanism is designed in the front-end Axios interceptor. When a token expires, it does not immediately redirect to the login page; instead, concurrent requests are pushed into a queue, asynchronously exchanged for new credentials, and automatically replayed. This ensures the continuity of user operations during long-term penetration testing, improving user experience and learning efficiency. Crucially, the above effects are not simply the sum of the effects of the five steps, but a systemic effect resulting from their synergistic work: topological sorting ensures the correctness of complex environmental dependencies, enabling efficient and conflict-free dynamic port mapping; while precise resource scheduling and status feedback make seamless front-end refresh possible. This combination of technologies produces a technical effect that cannot be achieved by a single technical means—stable support for high-concurrency users to conduct practical exercises on multiple heterogeneous vulnerabilities simultaneously with limited resources.

[0028] Example 1 The target environment definition file (docker-compose.yml) is located in the / docker_environments / spring4shell / directory. The core configuration includes the spring-app service and the h2-database service, where the depends_on field of spring-app indicates that it depends on h2-database.

[0029] The specific core configuration is as follows: version: '3' services: spring-app: build: . container_name: spring4shell-lab environment: - SPRING_DATASOURCE_URL=jdbc:h2:mem:testdb - SPRING_DATASOURCE_USERNAME=sa - SPRING_DATASOURCE_PASSWORD= - FLAG=${FLAG} # <-- Placeholder for the Flag that the platform will dynamically inject. ports: - "8080:8080" # Port 8080 inside the container, the host port is to be dynamically allocated. depends_on: - h2-database # Define dependencies: Start the database first h2-database: image: oscarfonts / h2 container_name: h2-db environment: - H2_OPTIONS=-ifNotExists ports: - "1521:1521" # H2 database console port.

[0030] When user_123 clicks "Start Spring4Shell Vulnerability Environment" on the front-end interface, the container-dynamically orchestrated high-concurrency network security test range system performs the following steps: S1. Environment Orchestration Steps: The environment orchestration module reads the docker-compose.yml configuration file, parses the depends_on field, and extracts the dependencies: spring-app depends on h2-database. The environment orchestration module constructs a directed acyclic graph (DAG) using service names as vertices and dependencies as directed edges, and performs a depth-first search (DFS) topological sort. After confirming that there are no circular dependencies through dependency verification, a linear startup sequence [h2-database, spring-app] is obtained, meaning that the dependent h2-database starts before the dependent spring-app. The key code is shown below: # Key Algorithm: Obtaining the Dependency Topology Order (api / docker_utils.py - get_service_dependencies) dependencies = {'spring-app': ['h2-database'], 'h2-database': []} # Result of performing topological sort: ['h2-database', 'spring-app'].

[0031] S2. Network Isolation Steps: After receiving the environment startup request from user_123 for the target question, the network isolation module obtains the user ID "123", the question ID "spring4shell", and the current session ID "sess_1234", and generates a unique network identifier "challenge_spring4shell_user123_sess_1234". An independent Bridge network is created via the Docker SDK. The naming convention for this network is challenge_{question ID}{user ID}{first 8 digits of session ID}, ensuring that it corresponds only to the current user's current question target instance. The key code is shown below: # Key code: Dynamically creating isolated networks (api / docker_utils.py) network_name = f"challenge_spring4shell_user123_{session_id[0:8]}" client.networks.create(name=network_name, driver="bridge", check_duplicate=True) # Result generated: network_name = "challenge_spring4shell_user123_sess_1234"; S3. Port Mapping Steps: The port mapping module scans the host machine for TCP port occupancy within the range of 30000-32767. It locks available host port 32568 (8080 / tcp port) for spring-app and available host port 32569 (1521 / tcp port) for h2-database. After locking the ports, the port mapping module uses the unique constraint in the ContainerPortUsage table of the database to mark the occupancy, preventing duplicate port allocation. The port mapping module then rewrites the static port mapping rules in docker-compose.yml, replacing "8080:8080" with "32568:8080" and "1521:1521" with "32569:1521". The key code is shown below: # Key parameter: Port mapping rules allocated_ports = { 'spring-app': {'8080 / tcp': 32568}, # Map port 8080 inside the container to port 32568 on the host machine. 'h2-database': {'1521 / tcp': 32569} # Maps port 1521 inside the container to port 32569 on the host machine. } .

[0032] Simultaneously, the security credential generation module uses the HMAC-SHA256 algorithm to take the combination of user ID "123", question ID "spring4shell", and session ID "sess_1234" as the message, and performs hash calculation using the platform's preset key (length ≥ 16 characters) as the key. The hash value of the first 20 characters is extracted to generate the unique verification credential "flag{a3d5f8c12b0e9d7f6a54}" for this user in this target range instance. The key code is: # Key Algorithm: Generating User-Specific Flags Based on HMAC-SHA256 (api / views.py) secret_key = "my_s3cr3t_k3y_2024" # Platform default key raw_data = f"user_123:spring4shell:{session_id}" dynamic_flag = "flag{" + hmac.new(secret_key.encode(), raw_data.encode(), 'sha256').hexdigest()[0:20] + "}" # Result generated: dynamic_flag = "flag{a3d5f8c12b0e9d7f6a54}".

[0033] S4. Security Credential Generation and Injection Steps: In this step, the environment orchestration module acts as the central controller, coordinating the network, ports, and authentication modules to synchronously complete the following operations during the atomic task of starting each container: Following the startup sequence determined in step S1, the environment orchestration module first calls the Docker SDK to create and start the h2-database container, mounting it to the dedicated isolated network created in step S2 and applying the port mapping (1521 / tcp→32569) allocated in step S3. After the h2-database container reaches the running status, the spring-app container is then created and started, similarly mounted to the dedicated isolated network and applying the port mapping (8080 / tcp→32568). When starting the spring-app container, the security credential generation module 40 injects the verification credential "flag{a3d5f8c12b0e9d7f6a54}" into the service node configured with the FLAG placeholder via Docker environment variables. The application within the spring-app container can obtain this verification credential by reading the environment variables. The verification credential within the container only exists in the runtime memory environment variables and is not persisted to the container image. Thus, container startup, network isolation, port mapping, and credential injection are completed synchronously, constituting an atomic deployment process. The key code is shown below: # Start the database container h2_container = client.containers.run( image="oscarfonts / h2", name=f"h2-db_{session_id[0:8]}", network=network_name, ports={'1521 / tcp': 32569}, detach=True ) # Start the Spring application container (wait for the database to be ready). spring_container = client.containers.run( image="spring4shell-lab:latest", name=f"spring-app_{session_id[0:8]}", network=network_name, environment={ 'SPRING_DATASOURCE_URL': 'jdbc:h2:tcp: / / h2-db:1521 / mem:testdb', # Use network alias to connect 'FLAG': dynamic_flag # Inject dynamically generated flags }, ports={'8080 / tcp': 32568}, detach=True.

[0034] S5. Authentication Refresh Steps: The platform returns dynamically allocated resource information to the front end, including the access address "http: / / host-ip:32568" and the instance validity period of 3600 seconds. User user_123 can then access the dedicated vulnerability environment through this address to conduct drills.

[0035] During the runtime of the test instance, the authentication refresh module continuously operates on the front end. The front-end request interceptor sets a mutex variable `isRefreshing` (initially false) and a request queue. When an HTTP 401 Unauthorized response is captured, if `isRefreshing` is false, it is set to true, and a token refresh request is initiated. Simultaneously, the current request and subsequent concurrent requests are encapsulated as Promise objects and pushed into the request queue. After a successful token refresh, the locally stored session credentials are updated, `isRefreshing` is set to false, and requests in the queue are replayed sequentially in a first-in, first-out order. This maintains a persistent connection between the user and the test instance during long-term penetration testing, ensuring uninterrupted user operations. S6. Resource Management Steps: The resource lifecycle management module sets a default maximum survival time of 3600 seconds for this testbed instance and starts a timer. When the instance runs for more than 3600 seconds or the user manually clicks "Stop Container," the resource lifecycle management module automatically destroys the containers and independent container networks corresponding to this testbed instance in the order of containers and independent container networks, thus releasing the host machine resources.

[0036] User user_123 successfully obtained the unique verification credential "flag{a3d5f8c12b0e9d7f6a54}" from the environment variables and submitted it by executing commands using the Spring4Shell vulnerability. When the user submits the verification credential, the security credential generation module regenerates the expected credential based on the same parameters (user ID, question ID, session ID, and platform preset key) and the same HMAC-SHA256 algorithm. The module then compares the user-submitted credential with the expected credential to complete the consistency check, and the verification passes.

[0037] Meanwhile, when user_456 initiates a request for the same question, the system will assign him a completely isolated independent container network, a different host port (such as 32570), and a different verification credential (such as "flag{b7e2a9d14f3c8a6e5b21}"), effectively preventing possible cheating. The key code for steps S5 and S6 is shown below: The key code is: { "status": "success", "access_url": "http: / / host-ip:32568", / / User access point "flag": "flag{a3d5f8c12b0e9d7f6a54}", / / The unique flag for this example "expires_in": 3600 / / The instance will be automatically destroyed after 1 hour. }

[0038] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

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

Claims

1. A high-concurrency cybersecurity test range system based on container dynamic orchestration, comprising a test range management backend, a container scheduling engine, and a front-end interaction module, characterized in that: The container scheduling engine includes an environment orchestration module, a network isolation module, a port mapping module, and a security credential generation module; the front-end interaction module has a built-in authentication refresh module, which is used to maintain the session without interruption when the session credentials used to interact with the container scheduling engine are detected to have expired. The environment orchestration module parses the target range definition file containing multiple service nodes, extracts the dependencies between nodes and constructs a directed acyclic graph. It then determines the startup order of the service nodes using a topology sorting algorithm. Based on this startup order, it synchronously coordinates the following operations when starting the containers corresponding to each service node: The network isolation module is invoked so that when it receives a user's environment startup request for the target question, it generates a unique network identifier associated with the user and the target environment instance, creates an independent container network corresponding to the network identifier, and mounts the network interfaces of all service containers involved in the question requested by the user to the independent container network. The port mapping module is invoked to scan the available ports on the host machine before starting each service container that needs to expose a port to the outside world. It allocates an unused host machine port for the container from the available port pool and dynamically rewrites the static port mapping rules in the target range definition file to map the internal ports of the container to the allocated host machine port. The security credential generation module is invoked so that when the environment orchestration module starts the service container, it generates a verification credential associated with the user and the target instance based on the user identifier and the question identifier that initiated the request using a one-way encryption algorithm, and injects the verification credential into the runtime environment of at least one of the service containers. The authentication refresh module intercepts request failure events caused by expired session credentials at the front end, controls the refresh process through a mutex lock, suspends subsequent requests to the request queue, and obtains a new session credential in the background using the refresh credential, releases the lock, and replays the requests in the request queue in sequence.

2. The high-concurrency network security test range system based on container dynamic orchestration according to claim 1, characterized in that: The environment orchestration module is specifically used for: Read the Docker Compose format target definition file and parse the depends_on field to obtain the dependency relationship between service nodes; Construct a directed acyclic graph by treating all service nodes as vertices and dependencies as directed edges, and check for circular dependencies. If a circular dependency exists, terminate the orchestration and return an exception message. Perform a depth-first search topological sort or Kahn algorithm on the directed acyclic graph to obtain a linear startup sequence. Call the container engine interface according to this sequence to create and start containers, where the dependent service nodes start before the nodes that depend on them.

3. The high-concurrency network security test range system based on container dynamic orchestration according to claim 1, characterized in that: The unique network identifier generated by the network isolation module is composed of the user identifier, the question identifier, and the session identifier of the current target range instance.

4. The high-concurrency network security test range system based on container dynamic orchestration according to claim 1, characterized in that: The port mapping module is configured to establish and update a port occupancy record table, which includes at least the allocated host port number, container identifier, user identifier, question identifier, port status, and expiration time fields. When allocating a port, the table is queried to ensure that the allocated port number is within the preset range of available ports and is not occupied. After the container stops or reaches its expiration time, the status of the corresponding record is updated to reclaim the port resources.

5. The high-concurrency network security test range system based on container dynamic orchestration according to claim 1, characterized in that: The security credential generation module uses HMAC-SHA256 or HMAC-SM3 algorithm as the one-way encryption algorithm, takes the combination of user identifier, question identifier and current session identifier as the message, performs hash calculation with the platform preset key as the key, and extracts the hash value of a predetermined length as the verification credential content. The verification credentials are injected into the service node configured with credential placeholders via container environment variables. The security credential generation module is also used to regenerate the expected credential based on the same parameters and perform consistency verification with the submitted credential when the user submits the verification credential.

6. The high-concurrency network security test range system based on container dynamic orchestration according to claim 1, characterized in that: The authentication refresh module is configured as follows: Capture session credential expiration responses in the front-end request interceptor; When the mutex variable isRefreshing is false, set it to true and initiate a session credential refresh request. At the same time, encapsulate the current request and subsequent concurrent requests into a Promise object and push it into the request queue. After the session credentials are successfully refreshed, the locally stored session credentials are updated, isRefreshing is set to false, and each request in the request queue is replayed in first-in-first-out order.

7. The high-concurrency network security test range system based on container dynamic orchestration according to claim 1, characterized in that: It also includes a resource lifecycle management module, which is used to set a maximum survival time for each testbed instance and start a timer; when the instance running time exceeds the maximum survival time or a user manual termination command is received, all containers corresponding to the instance are automatically stopped, and destruction operations are performed sequentially according to the order of containers and independent container networks.

8. A high-concurrency network security test range method based on container dynamic orchestration, characterized in that: Includes the following steps: S1. Environment orchestration steps: Receive the user's environment startup request for the target problem, read the target range definition file containing multiple service nodes, extract the dependencies between nodes and construct a directed acyclic graph, and determine the startup order of service nodes through a topology sorting algorithm. S2. Network isolation step: Obtain the user identifier and question identifier corresponding to the environment startup request, generate a unique network identifier associated with the user identifier and the question identifier, and create an independent container network corresponding to the network identifier; S3. Port mapping steps: Scan the available ports on the host machine, allocate unused host machine ports for each service container that needs to expose a port to the outside world in the target range definition file, dynamically rewrite the static port mapping rules in the target range definition file, and record the allocated port mapping relationship in the port occupancy record table. S4. Security Credential Generation and Injection Step: When starting each service container according to the startup order determined in step S1, the environment orchestration step coordinates the following synchronization operations: Obtain the user identifier and the question identifier, and generate a verification credential associated with the user and the target range instance through a one-way encryption algorithm; Mount the network interface of the currently started service container to the independent container network created in step S2, and map the host port allocated in step S3 to the internal port of the service container. For service containers configured with credential placeholders, the verification credentials are injected into the container's runtime environment via container environment variables; S5. Authentication refresh steps: During the operation of the test instance, the front end continuously intercepts request failure events caused by the expiration of session credentials, controls the refresh process through a mutex lock, suspends subsequent requests to the request queue, obtains a new session credential in the background using the refresh credential, releases the lock and replays the requests in the request queue in turn to maintain the persistent connection between the user and the test instance. S6. Resource Management Steps: Set a maximum survival time for the test range instance. When the instance runs for longer than the maximum survival time or is manually terminated by the user, automatically destroy the container and independent container network corresponding to the test range instance in the order of the container and the independent container network created in step S2.

Images