Mimicry defense driven network endogenous security protection method

Abstract

The invention discloses a mimicry defense driven network endogenous security protection method, which solves the problems of fixed attack surface, high key management risk and insufficient self-healing capability of the traditional network static architecture. The method comprises the steps that hardware, a system and an application layer multilevel heterogeneous execution body are constructed, a unique identifier is distributed, and the state is monitored through heartbeat; the heterogeneous requests are stored in a red-black tree cache after being subjected to standardization processing; performing dynamic voting based on weighted majority in a 100-millisecond window, and isolating an executor and recording a block chain log when the executor is abnormal; the response integrity is verified through ECDSA signature, if the response is greater than or equal to half of the execution bodies, the response is consistent, and otherwise, a rollback mechanism is triggered; and periodically or event-driven dynamically reconstructing an executor pool, and combining a two-stage key alternation system of a transmission private key and a root public key. According to the method, the network endogenous security is improved through dynamic heterogeneous redundancy and automatic closed-loop protection.

Description

Technical Field

[0001] The present invention relates to the field of network security technology, and in particular to a network endogenous security protection method based on mimicry defense theory. Background Art

[0002] Existing network security protection technologies have significant flaws in static architecture, key management, and self-healing capabilities, making the system vulnerable to attacks and lacking resilience. Specifically:

[0003] Static architecture solidifies the attack surface and lacks protection capabilities in heterogeneous environments:

[0004] Traditional network systems typically use a single hardware architecture (such as x86), operating system (such as Windows), and software version (such as Nginx1.18) to build executables. The attack surface is fixed and lacks a dynamic change mechanism. Attackers can use vulnerability scanning tools to quickly locate common vulnerabilities in the unified architecture (such as operating system kernel vulnerabilities or middleware logic flaws) and exploit these vulnerabilities to infiltrate the entire system. For example, a privilege escalation attack against a single Linux kernel version can lead to the collapse of all executables using that kernel. In addition, there is a lack of standardized mechanisms for request processing in heterogeneous environments. Requests of different protocols (such as HTTP and RedisRESP) and formats (such as JSON and binary) cannot be directly compared, making it difficult to effectively implement dynamic voting and anomaly detection, further weakening the system's ability to coordinate protection against heterogeneous executables.

[0005] The key management mechanism is static, resulting in high communication security risks:

[0006] The existing key system lacks a dynamic rotation mechanism, and transmission keys and root keys are used for a long time. Once leaked through vulnerabilities or obtained by attackers through brute force, communication data may be exposed to long-term risks of eavesdropping and tampering. For example, if a fixed DES private key is cracked through reverse engineering, an attacker can decrypt historical communication records and forge legitimate requests. At the same time, the traditional key switching process carries the risk of service interruption, and the transition from old to new keys cannot be smooth, which may cause business request processing failures. In addition, key legitimacy verification relies on static certificates and lacks dynamic verification methods, making it difficult to resist tampering with the key transmission process through man-in-the-middle attacks.

[0007] Anomaly detection rules are fixed, and the system's self-healing capabilities are weak:

[0008] Traditional anomaly detection relies on preset rules (such as blacklists or fixed thresholds) and is difficult to adapt to new attack methods (such as zero-day vulnerabilities or deformed malicious code), resulting in a high missed detection rate. For example, detection rules based on feature matching cannot effectively identify dynamically encrypted attack traffic. At the same time, the system lacks an automated self-healing mechanism. When response data tampering or executor anomalies are detected, it cannot be quickly rolled back to a legal state and manual intervention is required for recovery, resulting in long service interruptions (usually several hours). In addition, the executor pool lacks a dynamic reconstruction mechanism. When some nodes fail due to attacks or failures, heterogeneous nodes cannot be automatically replaced to maintain system performance and security, further reducing the system's resilience and reliability.

[0009] To this end, we propose a network endogenous security protection method driven by mimicry defense. Summary of the Invention

[0010] In view of the above deficiencies in the existing technology, the purpose of the present invention is to propose a network endogenous security protection method driven by mimicry defense, aiming to solve the problems in traditional network protection such as static architecture being vulnerable to single point vulnerability attacks, high key management risks, and insufficient system self-healing capabilities.

[0011] In order to achieve the above objectives, the present invention adopts the following technical solutions:

[0012] A network endogenous security protection method driven by mimicry defense includes the following steps:

[0013] S1. Dynamically deploy and initialize heterogeneous executors, building multiple functionally equivalent but structurally heterogeneous executors. Each executor uses a different hardware architecture, operating system, or software version to ensure inherent heterogeneity. Each executor is assigned a unique identifier and configured with a dynamic redundant communication mechanism. The executors register with the mimetic middleware through a heartbeat mechanism and report their operating status in real time.

[0014] S2. Request synchronization and data preprocessing: The mimicking middleware receives network requests from each executor, standardizes the request content, and temporarily stores the preprocessed requests in a red-black tree cache, using the request feature value as the key for fast retrieval.

[0015] S3. Dynamic voting and anomaly detection: dynamic voting and anomaly detection are performed based on the request data processed by S2;

[0016] S4. Security response and result distribution: Approved requests are forwarded by the mimic middleware to the target service. The response is verified by the mimic middleware and distributed to each executor. Verification includes response signature verification and consistency comparison. If response tampering is detected, a rollback mechanism is triggered to restore the previous legal state.

[0017] S5. Dynamic reconstruction and key rotation: Dynamically reconstruct the executor pool in a periodic or event-driven manner; at the same time, a two-level key rotation system is adopted to prevent the key from being cracked.

[0018] The execution body includes: hardware layer, system layer and application layer;

[0019] The hardware layer selects physical servers or virtual machines with different architectures such as x86, ARM, and RISC-V, and matches them with network cards and storage devices from different manufacturers;

[0020] The system layer is a heterogeneous operating system installed on each hardware node, and is configured with different kernel versions;

[0021] The application layer deploys functionally equivalent heterogeneous components for the same service, and the database uses one of MySQL8.0, PostgreSQL15, and MariaDB10.11.

[0022] In S1, each execution body is assigned a unique identifier and the specific steps of configuring a dynamic redundant communication mechanism include:

[0023] Assign a UUID to each executable as a unique identifier, and associate the hardware fingerprint with the software hash value;

[0024] Each executor is assigned a primary address, a backup IP address, and an independent port range. The port range is limited to non-privileged ports between 1024 and 65535. Communication data is encrypted using the TLS 1.3 / DTLS 1.3 protocol, and the certificate is issued by the system's built-in CA.

[0025] The primary IP address is used for normal communication, and the backup IP address is used for failover.

[0026] The specific steps of registering the executor with the mimic middleware through the heartbeat mechanism and reporting the running status in real time include:

[0027] The executor sends heartbeat packets to the mimicking middleware via the UDP protocol at an interval of 5 seconds. The middleware maintains the executor status table, records the timestamps of the last three heartbeats, and marks it as "lost" if it times out for 15 seconds.

[0028] Prometheus Express collects metrics such as CPU load, memory usage, disk I / O throughput, and network bandwidth utilization, compresses them, and reports them to the mimetic middleware in real time using the gRPC protocol.

[0029] CPU load, calculated as the ratio of the average run queue length to the number of CPU cores over a 5-minute period, reflects the processor's busyness;

[0030] Memory usage is calculated as the difference between available memory and total memory using the formula: (1-available memory / total memory) × 100%;

[0031] Disk I / O and network bandwidth: Use system tools to obtain throughput and latency indicators, compress them, and report them to the middleware in real time through the gRPC protocol for dynamic evaluation of the executor's health status.

[0032] In S2, the specific steps of the standardization process include:

[0033] S211. HTTP / HTTPS request processing. For requests based on the Hypertext Transfer Protocol, the middleware first parses the request line to separate the request method, request path, and protocol version. It then parses the request header fields, extracting key information such as the "Host" field and the "Content-Type" field, and converts the message body into structured data according to the specified format or retains the original binary stream.

[0034] S212. Standardized processing flow:

[0035] Protocol parsing and unified modeling: converting requests from different protocols into a unified request model defined within the middleware, including fields such as method, path, header field, message body, and timestamp;

[0036] Data format conversion: For JSON-formatted message bodies, they are converted into compact byte streams through binary encoding, with a compression rate that is 40% to 60% higher than that of the original JSON.

[0037] Timestamp alignment: Synchronize the clocks of all executors and middleware based on the Network Time Protocol (NTP) and calculate the time difference between the client and the server:

[0038]

[0039] Among them, T1 is the time when the client sends the request; T2 is the time when the middleware receives it; T3 is the time when the middleware sends the response; T4 is the time when the client receives the response. After calibration, the error of the request timestamp is controlled within ±10 milliseconds to ensure timing consistency across execution bodies.

[0040] Data is processed in blocks. Messages exceeding 128KB are divided into data blocks of fixed size. The insufficient part is padded with 0x00 bytes to make the length of each block an integer multiple of 128KB.

[0041] In the above S2, the request after normalization is temporarily stored in a cache of a red-black tree structure, and a method for fast retrieval is implemented using the request feature value as a key:

[0042] S221. Cache data structure design:

[0043] Key-value storage uses feature values ​​as keys, and the stored values ​​include the normalized request data block, the unique identifier of the source executable, the calibrated timestamp, and the reference count;

[0044] The red-black tree maintains the balance of the tree structure through color marking and rotation operations, ensuring that the time complexity of insertion and query operations is O(logC) (C is the number of cache entries). O(logC) is a form of describing time complexity using big O notation, where O stands for "Order of"; it is used to describe the growth trend of resources such as algorithm running time or required space when the input scale tends to infinity. It focuses on the asymptotic behavior of algorithm performance as the input scale changes, ignoring constant coefficients and low-order terms, and only retaining the dominant term that best reflects the growth rate, in order to measure the efficiency characteristics of the algorithm under large-scale input; O(logC) means that as the number of cache entries C continues to increase, the growth rate of the time it takes to execute the algorithm operation is approximately the growth rate of the logarithmic function with C as the independent variable, which is a relatively efficient time complexity, indicating that the operation time grows slowly;

[0045] S221. Cache operation strategy:

[0046] Insertion logic: New requests are normalized and feature values ​​are generated. If there is no matching key in the cache, a new node is created and inserted into the red-black tree. If there is a matching key, the timestamp and reference count of the corresponding node are updated.

[0047] Elimination mechanism, when the cache space exceeds the preset bytes, traverse the nodes in the tree and delete the node with the smallest reference count and the longest unused node.

[0048] The S3 includes:

[0049] S311. Dynamic voting and weighting mechanism:

[0050] The mimicking middleware counts the number and set of source executables of the same request based on the request feature value within a sliding time window of seconds. If the number of non-homologous requests is ≥ 2 / 3 of the total number of executables and the content is the same as the hash value, the request is considered legitimate. A weighting mechanism is introduced, with a healthy executable weight of 1.2 and an abnormal executable weight of 0.8. The weighted count must reach the threshold for the request to pass the judgment.

[0051] S312. Dynamic threshold adaptive adjustment and exception handling:

[0052] The system calculates the voting success rate in the last five minutes in real time. If the success rate is >0.9, the threshold is lowered by 5%, and if it is <0.7, it is increased by 10%. When an abnormal request is detected, the abnormal executor's network communication is blocked by the firewall, marked as "isolated", and removed from the voting set. At the same time, a security log containing the timestamp, executor ID, and request feature value is generated and stored in the blockchain to ensure that it cannot be tampered with.

[0053] The calculation formula for the success rate S is:

[0054]

[0055] The S4 includes:

[0056] S411. Response Verification Mechanism: The mimetic middleware uses cryptographic means to verify the integrity and consistency of the response data. First, the target service uses the secp256r1 elliptic curve private key to ECDSA-sign the response body. After receiving the response, the middleware verifies the validity of the signature using the public key to ensure that the response has not been tampered with by the middleman. At the same time, the response hash values ​​of all executables are collected and compared to see whether the responses of at least half of the executables are consistent. If so, the verification passes; otherwise, the response is determined to have been tampered with and the rollback mechanism is triggered.

[0057] S412. A rollback mechanism takes snapshots of the executable's memory state, file system, and network configuration every 15 minutes and stores them in a distributed storage system. The snapshot naming convention includes the executable ID and timestamp, and a total of 96 versions from the last 24 hours are retained. Once a response is detected as tampered, the middleware determines the timestamp of the last valid response based on the security log, loads the corresponding state snapshot, and restores the executable to its valid state. During this period, the rollback mechanism will notify the user that the service is temporarily unavailable. The entire recovery process is generally completed within 30 seconds.

[0058] S413. Results distribution: Verified responses are pushed to each executor in real time via the gRPC streaming protocol, with a 200-millisecond timeout to ensure transmission efficiency. If an executor does not receive a response within the timeout, it re-pulls data from S2's red-black tree cache by requesting feature values ​​to ensure consistency across all executors and avoid data inconsistencies caused by network latency.

[0059] The method for dynamically reconstructing the executor pool in a periodic or event-driven manner:

[0060] S511. Dynamic reconstruction of the executor pool. The mimic defense system dynamically updates the executor pool through two mechanisms: periodic triggering and event-driven triggering, to disperse the attack surface and replace failed nodes:

[0061] The periodic trigger reconstruction system is automatically triggered at a fixed time point every day, replacing 1 / 3 of the total number of nodes in the execution body each time;

[0062] Event-driven reconstruction: When the number of abnormal executables reaches or exceeds 1 / 3 of the total number (rounded up), or the abnormal request frequency exceeds the threshold, a full reconstruction is immediately triggered to replace all executables.

[0063] New node initialization:

[0064] Heterogeneous construction: New nodes must implement multi-level heterogeneity at the hardware, system, and application layers. The hardware layer uses a different architecture from existing nodes, with network cards and storage devices from different manufacturers; the system layer deploys heterogeneous operating systems and different kernel versions; the application layer deploys functionally equivalent but different components for the same service, and uses different compilers to compile.

[0065] Identity and communication configuration: assign a unique UUID to the new node, associate the hardware fingerprint with the software hash, configure the primary and backup IP addresses and random non-privileged ports, use the TLS1.3 protocol to encrypt communication, and the certificate is issued by the system's built-in CA;

[0066] The old node goes offline, is marked as "pending deletion", stops accepting new requests, allows existing requests to be processed, and is then removed from the state table of the mimic middleware, releasing hardware resources.

[0067] S512. Two-level key rotation and security maintenance: A two-level key system with a private key and a root public key is used, combined with a key rotation mechanism to prevent key leakage or cracking:

[0068] in:

[0069] The transmission private key (SK_trans) is used for request signatures and data encryption. It uses the DES algorithm (56-bit key) and is rotated every hour. After the new key is generated, it is sent to the executor through an AES-256 encrypted channel to ensure the security of the transmission process.

[0070] The root public key (PK_root) is used to verify the legitimacy of the transmitted private key. It uses the RSA-4096 algorithm and is updated once a quarter through an X.509 certificate. When the root public key is updated, the validity of the certificate is verified through the blockchain or a trusted third party to prevent man-in-the-middle attacks.

[0071] Key rotation mechanism design:

[0072] Parallel validation design: the old and new keys are valid for a period of time, during which the executor supports decryption with both keys to avoid service interruption. For example, the old key expires at time T0, and the new key expires at time T 0- It takes effect 10 minutes in advance to ensure seamless request processing;

[0073] The old key is revoked. After the parallel period ends, the old key is added to the certificate revocation list (CRL), the executor stops using the old key, and deletes it from the local secure storage.

[0074] Heterogeneity verification and feedback: When deploying new nodes, they must be verified using the heterogeneity formula to ensure that the average heterogeneity of the executor pool after reconstruction is greater than 0.8. The new state after reconstruction is fed back to the heterogeneous executor deployment process of S1, forming a closed loop of "detection-reconstruction-redeployment", continuously improving the system's ability to resist unknown attacks.

[0075] Among them, the heterogeneity formula is expressed as:

[0076] H=0.4ΔH+0.3ΔO+0.3ΔS≥0.7;

[0077] H represents the heterogeneity of the reconstructed executable pool, and ΔH, ΔO, and ΔS are the differences in hardware, system, and software, respectively.

[0078] In summary, due to the adoption of the above technical solution, the beneficial technical effects of the invention are:

[0079] The attack surface is dynamically dispersed to improve the system's anti-attack capabilities:

[0080] Through multi-level heterogeneity of the hardware layer, system layer, and application layer, the vulnerability spaces of different executables do not overlap; for example, a buffer overflow attack against the x86 architecture cannot take effect on the ARM executable, significantly reducing the possibility of an attacker exploiting a single vulnerability to infiltrate the entire system.

[0081] A dynamic reconfiguration mechanism periodically or event-drivenly replaces executor nodes, replacing 1 / 3 or all nodes each time, allowing the attack surface to continuously change. For example, if a certain type of attack is detected frequently targeting a specific operating system, a full reconfiguration can be performed to switch to a different type of system, forcing the attacker to re-explore the vulnerability and increasing the cost of the attack.

[0082] Efficient anomaly detection and self-healing capabilities:

[0083] A dynamic voting mechanism accurately identifies legitimate requests within a 100-millisecond window through weighted majority voting (number of non-homogeneous requests ≥ 2 / 3 of the executors and consistent content) and weight adjustment (healthy executors weigh 1.2, abnormal executors weigh 0.8). For example, a weighted count of two healthy executors out of three (1.2 + 1.2 = 2.4) can meet the threshold, improving detection efficiency while reducing false positives.

[0084] The rollback mechanism generates a status snapshot every 15 minutes and stores 96 versions within 24 hours. When response tampering is detected, it will be restored to the most recent legal state within 30 seconds to avoid service interruption or data loss caused by data tampering.

[0085] Strengthening communication security and key management:

[0086] ECDSA signature verification: This uses elliptic curve cryptography to verify the integrity of the response, ensuring that the data has not been tampered with during transmission. For example, if the target service uses a secp256r1 private key signature, and the middleware verifies the public key, the response is considered legitimate if the horizontal coordinates of the elliptic curve points match.

[0087] Two-level key rotation combines the transmission private key with the root public key, with the old and new keys taking effect in parallel for 10 minutes, preventing service interruptions and shortening key exposure. For example, the transmission private key is updated every hour. Even if the current key is cracked, an attacker can only access communication data within one hour, significantly reducing the risk of key leakage.

[0088] System elasticity and automated operation and maintenance:

[0089] Real-time health status monitoring: Through the heartbeat mechanism and Prometheus to collect indicators such as CPU load and memory usage, the health status of the executor is evaluated in real time and potential fault nodes are identified in advance.

[0090] The closed-loop protection system forms a complete closed loop from heterogeneous deployment (S1), request processing (S2), voting detection (S3), security response (S4) to dynamic reconstruction (S5). It can realize the automated process of attack detection, response, recovery and architecture optimization without human intervention, thereby improving the efficiency and security of system operation and maintenance.

[0091] In summary, the present invention constructs an endogenous security protection system with dynamic, heterogeneous and redundant characteristics through the multiple mechanisms of "heterogeneous redundancy + dynamic voting + key rotation + self-healing reconstruction". Compared with the traditional static architecture, the probability of successful attack can be greatly reduced, and the risk of key leakage is also reduced. The system recovery time is shortened to minutes, which significantly improves the network system's defense capabilities against unknown attacks and continuous service capabilities. BRIEF DESCRIPTION OF THE DRAWINGS

[0092] Figure 1 This is a flowchart of a network endogenous security protection method driven by mimicry defense. DETAILED DESCRIPTION

[0093] In order to make the purpose, technical solutions and advantages of the invention more clear, the invention is further described in detail below in conjunction with the embodiments. It should be understood that the specific embodiments described here are only used to explain the invention and are not used to limit the invention.

[0094] like Figure 1 As shown, a network endogenous security protection method driven by mimicry defense includes the following steps:

[0095] S1. Dynamic deployment and initialization of heterogeneous executors. Multiple functionally equivalent but structurally heterogeneous executors are constructed. Each executor uses a different hardware architecture, operating system, or software version to ensure inherent heterogeneity. During initialization, each executor is assigned a unique identifier and a dynamic redundant communication mechanism is configured, including IP address, port, and security protocol. Executors register with the mimetic middleware through a heartbeat mechanism and report their operating status (such as CPU load and memory usage) in real time.

[0096] By constructing heterogeneous executors and completing dynamic deployment and initialization, a heterogeneous foundation is provided for the subsequent voting mechanism. Executors with different structures disperse the attack surface, preventing security issues in the entire system caused by the exploitation of single-point vulnerabilities, and laying the foundation for the safe operation of the system. At the same time, the operating status data reported by the executors will serve as an important basis for judging the health of the executors and adjusting processing strategies in subsequent steps, naturally transitioning to the stage of processing the data and requests generated by the executors.

[0097] The execution body includes: hardware layer, system layer and application layer;

[0098] The hardware layer selects physical servers or virtual machines with different architectures such as x86, ARM, and RISC-V, and matches them with network cards and storage devices (such as SSD / HDD) from different manufacturers;

[0099] The system layer is a heterogeneous operating system installed on each hardware node, such as Windows Server 2022, Ubuntu 22.04 LTS, CentOS 8, FreeBSD 13.1, etc., and is configured with different kernel versions (such as Linux 5.15 vs 6.1);

[0100] The application layer deploys functionally equivalent heterogeneous components for the same service, for example, the web server uses Nginx1.23, Apache2.4.57, and Lighttpd1.4.59, and the database uses MySQL8.0, PostgreSQL15, and MariaDB10.11.

[0101] The specific steps of assigning a unique identifier to each execution body and configuring a dynamic redundant communication mechanism include:

[0102] Assign a UUID to each executable as a unique identifier, linking hardware fingerprints (such as MAC address, CPU serial number) with software hash values ​​(such as OS image checksum, application binary hash);

[0103] Each executor is assigned a primary and backup IP address and an independent port range. The port range is limited to non-privileged ports between 1024 and 65535. Communication data is encrypted using the TLS1.3 / DTLS1.3 protocol, and the certificate is issued by the system's built-in CA.

[0104] The dual IP addresses include a primary address and a backup address, the primary IP address is used for normal communication, and the backup IP address is used for fault switching.

[0105] The specific steps of registering the executor with the mimic middleware through the heartbeat mechanism and reporting the running status in real time include:

[0106] The executor sends a heartbeat packet (including UUID, timestamp, and status code) to the mimicking middleware via the UDP protocol at an interval of 5 seconds. The middleware maintains the executor status table, records the timestamps of the last three heartbeats, and marks it as "lost" if it times out for 15 seconds.

[0107] Prometheus Express collects metrics such as CPU load (5-minute average), memory usage, disk I / O throughput, and network bandwidth utilization, compresses them, and reports them to the mimetic middleware in real time using the gRPC protocol.

[0108] CPU load, calculated as the ratio of the average run queue length to the number of CPU cores over a 5-minute period, reflects the processor's busyness;

[0109] Memory usage is calculated as the difference between available memory and total memory using the formula: (1-available memory / total memory) × 100%;

[0110] Disk I / O and network bandwidth: Use system tools (such as iostat and nstat) to obtain throughput and latency indicators. After compression, these indicators are reported to the middleware in real time through the gRPC protocol for dynamic evaluation of the executor's health status.

[0111] S2. Request synchronization and data preprocessing: The mimicking middleware receives network requests from each executor and standardizes the request content. The standardized requests are temporarily stored in a red-black tree cache, using the request feature value as the key for fast retrieval.

[0112] After S1 establishes a heterogeneous executor environment, S2 takes over processing network requests generated by each executor. Due to the heterogeneity of the executors, the requests they generate vary in protocol and format. Standardization ensures that these heterogeneous requests are comparable, enabling the subsequent voting mechanism to operate effectively. The red-black tree cache improves voting efficiency and provides a consistent baseline for anomaly detection, ensuring accurate and efficient data processing and paving the way for the next step of request voting and anomaly detection.

[0113] The specific steps of the standardization process include:

[0114] S211. HTTP / HTTPS request processing. For requests based on the Hypertext Transfer Protocol, the middleware first parses the request line, extracting the request method (e.g., get, submit, delete), request path, and protocol version. It then parses the request headers, extracting key information such as the "Host" field (identifying the request target) and the "Content-Type" field (determining the message body format, such as application / JSON), and converts the message body into structured data according to the specified format (e.g., JSON) or retains the original binary stream.

[0115] S212. Standardized processing flow:

[0116] Protocol parsing and unified modeling: converting requests from different protocols into a unified request model defined within the middleware, including fields such as method, path, header field, message body, and timestamp;

[0117] Data format conversion: For JSON-formatted message bodies, they are converted into compact byte streams through binary encoding, with a compression rate that is 40% to 60% higher than that of the original JSON.

[0118] Timestamp alignment: Synchronize the clocks of all executors and middleware based on the Network Time Protocol (NTP) and calculate the time difference between the client and the server:

[0119]

[0120] Among them, T1 is the time when the client sends the request; T2 is the time when the middleware receives it; T3 is the time when the middleware sends the response; T4 is the time when the client receives the response. After calibration, the error of the request timestamp is controlled within ±10 milliseconds to ensure timing consistency across execution bodies.

[0121] Data is divided into blocks. Messages larger than 128KB are divided into data blocks of fixed size. Insufficient blocks are padded with 0x00 bytes to make each block an integer multiple of 128KB. For example, a 256KB message is divided into two blocks, and a 300KB message is divided into three blocks (the first two blocks are 128KB, and the third block is 44KB and padded with zeros to 128KB).

[0122] The method of temporarily storing the standardized request in a red-black tree structure cache and realizing fast retrieval using the request feature value as the key is as follows:

[0123] S221. Cache data structure design:

[0124] Key-value storage uses the characteristic value (the hash value calculated by the SHA-256 algorithm for the data block) as the key. The stored value includes the normalized request data block, the unique identifier of the source executable, the calibrated timestamp, and the reference count.

[0125] The red-black tree maintains the balance of the tree structure through color marking (red / black) and rotation operations, ensuring that the time complexity of insertion and query operations is O(logC) (C is the number of cache entries). O(logC) is a form of describing time complexity using big O notation, where O stands for "Order of magnitude". It is used to describe the growth trend of resources such as algorithm running time or required space when the input scale tends to infinity. It focuses on the asymptotic behavior of algorithm performance as the input scale changes, ignoring constant coefficients and low-order terms, and only retaining the dominant term that best reflects the growth rate, in order to measure the efficiency characteristics of the algorithm under large-scale input. O(logC) means that as the number of cache entries C continues to increase, the growth rate of the time it takes to execute the algorithm operation is approximately the growth rate of the logarithmic function with C as the independent variable. It is a relatively efficient time complexity, indicating that the operation time grows slowly.

[0126] S221. Cache operation strategy:

[0127] Insertion logic: New requests are normalized and feature values ​​are generated. If there is no matching key in the cache, a new node is created and inserted into the red-black tree. If there is a matching key, the timestamp and reference count of the corresponding node are updated.

[0128] Elimination mechanism: When the cache space exceeds the preset bytes (10 megabytes), the nodes in the tree are traversed and the nodes with the smallest reference count and the longest unused time are deleted; for example, each time a new record is inserted, the current cache capacity is checked, and if it exceeds the threshold, the earliest inserted node is eliminated.

[0129] S3. Dynamic voting and anomaly detection: Based on the request data processed in S2, dynamic voting and anomaly detection are performed within a preset sliding time window (100 milliseconds). The specific steps include:

[0130] S311. Dynamic voting and weighting mechanism:

[0131] The mimicking middleware counts the number and set of source executables of the same request based on the request feature value within a sliding time window of seconds. If the number of non-homologous requests is ≥ 2 / 3 of the total number of executables (rounded up) and the content is the same as the hash value, the request is considered legitimate. A weighting mechanism is introduced: healthy executables (CPU load <80%, memory usage <90%) are weighted 1.2, and abnormal executables are weighted 0.8. The weighted count must reach the threshold for the request to pass the judgment.

[0132] S312. Dynamic threshold adaptive adjustment and exception handling:

[0133] The system calculates the voting success rate in the last five minutes in real time. If the success rate is >0.9, the threshold is lowered by 5%, and if it is <0.7, it is increased by 10%. When an abnormal request is detected, the abnormal executor's network communication is blocked by the firewall, marked as "isolated", and removed from the voting set. At the same time, a security log containing the timestamp, executor ID, and request feature value is generated and stored in the blockchain to ensure that it cannot be tampered with.

[0134] The calculation formula for the success rate S is:

[0135]

[0136] After S2 synchronizes and preprocesses the request, S3 performs dynamic voting and anomaly detection based on the processed request data. Dynamic weighting and threshold adjustment enable the system to enhance its adaptability to unknown attacks and promptly identify anomalous requests based on actual conditions and historical experience. Upon detecting an anomaly, the feedback mechanism isolates the problematic executor, enabling self-purification of the executor pool and ensuring the system's continued stable operation. This also provides reliable request processing results for subsequent security response steps, driving the process to the next stage.

[0137] S4. Security response and result distribution: Approved requests are forwarded by the mimic middleware to the target service. The response is verified by the mimic middleware and distributed to each executor. Verification includes response signature verification and consistency comparison. If response tampering is detected, a rollback mechanism is triggered to restore the previous legal state.

[0138] The S4 includes:

[0139] S411. Response Verification Mechanism: The mimetic middleware uses cryptographic means to verify the integrity and consistency of the response data. First, the target service uses the secp256r1 elliptic curve private key to ECDSA-sign the response body. After receiving the response, the middleware verifies the validity of the signature using the public key to ensure that the response has not been tampered with by the middleman. At the same time, the response hash values ​​of all executables are collected and compared to see whether the responses of at least half of the executables are consistent. If so, the verification passes; otherwise, the response is determined to have been tampered with and the rollback mechanism is triggered.

[0140] S412. Rollback mechanism: Every 15 minutes, a snapshot of the executable's memory state, file system, and network configuration is taken and stored in a distributed storage system. The snapshot naming convention includes the executable ID and timestamp, and a total of 96 versions within the last 24 hours are retained. Once a response is detected as tampered, the middleware determines the timestamp of the last valid response based on the security log, loads the corresponding state snapshot, and restores the executable to its valid state. During this period, a prompt is displayed to the user indicating that the service is temporarily unavailable. The entire recovery process is generally completed within 30 seconds.

[0141] S413. Results are distributed. Verified responses are pushed to each executor in real time via the gRPC streaming protocol. A 200-millisecond timeout is set to ensure transmission efficiency. If an executor does not receive a response within the timeout, data is re-pulled from the red-black tree cache in step S2 by requesting feature values ​​to ensure consistency across all executors and avoid data inconsistencies caused by network latency.

[0142] After S3 completes request voting and anomaly detection, S4 securely responds to and distributes results for legitimate requests that have passed the vote. Response validation ensures data integrity during transmission and processing, preventing data tampering. The rollback mechanism provides fault tolerance, restoring the system to a normal state when problems arise, forming a closed-loop protection loop and ensuring system security and reliability. Furthermore, the processed results are fed back to the executor, providing data support for the dynamic reconstruction of the executor pool and establishing a logical connection with the next step.

[0143] S5. Dynamic reconstruction and key rotation: Dynamic reconstruction of the executor pool through periodic or event-driven methods can replace failed nodes in a timely manner to ensure system performance and security; at the same time, a two-level key rotation system is adopted to prevent keys from being cracked.

[0144] The method for dynamically reconstructing the executor pool in a periodic or event-driven manner:

[0145] S511. Dynamic reconstruction of the executor pool. The mimic defense system dynamically updates the executor pool through two mechanisms: periodic triggering and event-driven triggering, to disperse the attack surface and replace failed nodes:

[0146] The periodic trigger reconstruction system is automatically triggered at a fixed time point every day, replacing 1 / 3 of the total number of nodes of the executable each time (rounded down);

[0147] Event-driven reconstruction: When the number of abnormal executables reaches or exceeds 1 / 3 of the total number (rounded up), or the abnormal request frequency exceeds the threshold, a full reconstruction is immediately triggered to replace all executables.

[0148] New node initialization:

[0149] Heterogeneous construction: New nodes must implement multi-level heterogeneity at the hardware, system, and application layers. The hardware layer uses a different architecture from existing nodes, with network cards and storage devices from different manufacturers; the system layer deploys heterogeneous operating systems and different kernel versions; the application layer deploys functionally equivalent but different components for the same service, and uses different compilers to compile.

[0150] Identity and communication configuration: assign a unique UUID to the new node, associate the hardware fingerprint with the software hash, configure the primary and backup IP addresses and random non-privileged ports, use the TLS1.3 protocol to encrypt communication, and the certificate is issued by the system's built-in CA;

[0151] The old node goes offline, is marked as "pending deletion", stops accepting new requests, allows existing requests to be processed, and is then removed from the state table of the mimic middleware, releasing hardware resources.

[0152] S512. Two-level key rotation and security maintenance: A two-level key system with a private key and a root public key is used, combined with a key rotation mechanism to prevent key leakage or cracking:

[0153] in,

[0154] The transmission private key (SK_trans) is used for request signatures and data encryption. It uses the DES algorithm (56-bit key) and is rotated every hour. After the new key is generated, it is sent to the executor through an AES-256 encrypted channel to ensure the security of the transmission process.

[0155] The root public key (PK_root) is used to verify the legitimacy of the transmitted private key. It uses the RSA-4096 algorithm and is updated once a quarter through an X.509 certificate. When the root public key is updated, the validity of the certificate is verified through the blockchain or a trusted third party (CA) to prevent man-in-the-middle attacks.

[0156] Key rotation mechanism design:

[0157] Parallel validation design: The old and new keys take effect in parallel for a period of time (e.g., 10 minutes). During this period, the executor supports decryption with both keys simultaneously to avoid service interruption. For example, if the old key expires at time T0, the new key will take effect in advance at T0-10 minutes, ensuring seamless request processing.

[0158] The old key is revoked. After the parallel period ends, the old key is added to the certificate revocation list (CRL), the executor stops using the old key, and deletes it from the local secure storage.

[0159] Heterogeneity verification and feedback: When deploying new nodes, they must be verified using the heterogeneity formula to ensure that the average heterogeneity of the executor pool after reconstruction is greater than 0.8. The reconstructed new state is fed back to the heterogeneous executor deployment process in step S1, forming a closed loop of "detection-reconstruction-redeployment" to continuously improve the system's ability to resist unknown attacks.

[0160] Among them, the heterogeneity formula is expressed as:

[0161] H=0.4ΔH+0.3ΔO+0.3ΔS≥0.7;

[0162] H represents the heterogeneity of the reconstructed executable pool, and ΔH, ΔO, and ΔS are the differences in hardware, system, and software, respectively.

[0163] The above description is a preferred embodiment of the invention and is not intended to limit the invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the invention should be included in the scope of protection of the invention.

Claims

1. A network endogenous security protection method driven by mimicry defense, characterized in that: The following steps are involved: S1. Dynamic deployment and initialization of heterogeneous executors. This allows for the construction of multiple functionally equivalent but structurally heterogeneous executors. Each executor uses a different hardware architecture, operating system, or software version to ensure inherent heterogeneity. Assign a unique identifier to each executor and configure a dynamic redundant communication mechanism. The executor registers with the mimic middleware through the heartbeat mechanism and reports its running status in real time. S2. Request synchronization and data preprocessing: The mimicking middleware receives network requests from each executor, standardizes the request content, and temporarily stores the preprocessed requests in a red-black tree cache, using the request feature value as the key for fast retrieval. S3. Dynamic voting and anomaly detection: dynamic voting and anomaly detection are performed based on the request data processed by S2; S4. Security response and result distribution: Approved requests are forwarded by the mimic middleware to the target service. The response is verified by the mimic middleware and distributed to each executor. Verification includes response signature verification and consistency comparison. If response tampering is detected, a rollback mechanism is triggered to restore the previous legal state. S5. Dynamic reconstruction and key rotation: Dynamically reconstruct the executor pool in a periodic or event-driven manner; at the same time, a two-level key rotation system is adopted to prevent the key from being cracked.

2. A network endogenous security protection method driven by mimicry defense according to claim 1, characterized in that: The execution body includes: hardware layer, system layer and application layer; The hardware layer selects physical servers or virtual machines with different architectures such as x86, ARM, and RISC-V, and matches them with network cards and storage devices from different manufacturers; The system layer is a heterogeneous operating system installed on each hardware node and configured with different kernel versions; The application layer deploys functionally equivalent heterogeneous components for the same service, and the database uses one of MySQL8.0, PostgreSQL15, and MariaDB10.

11.

3. The network endogenous security protection method driven by mimicry defense according to claim 1 is characterized in that: In S1, each execution body is assigned a unique identifier and the specific steps of configuring a dynamic redundant communication mechanism include: Assign a UUID to each executable as a unique identifier, and associate the hardware fingerprint with the software hash value; Each executor is assigned a primary address, a backup IP address, and an independent port range; the port range is limited to non-privileged ports between 1024 and 65535, and the communication data is encrypted using the TLS1.3 / DTLS1.3 protocol. The certificate is issued by the system's built-in CA.

4. A network endogenous security protection method driven by mimicry defense according to claim 3, characterized in that: The primary IP address is used for normal communication, and the backup IP address is used for failover.

5. The network endogenous security protection method driven by mimicry defense according to claim 1 is characterized in that: The specific steps of registering the executor with the mimic middleware through the heartbeat mechanism and reporting the running status in real time include: The executor sends heartbeat packets to the mimicking middleware via the UDP protocol at an interval of 5 seconds. The middleware maintains the executor status table, records the timestamps of the last three heartbeats, and marks a timeout of 15 seconds as "lost connection". Prometheus Express collects CPU load, memory usage, disk I / O throughput, and network bandwidth utilization metrics, compresses them, and reports them to the mimetic middleware in real time using the gRPC protocol. CPU load, calculated as the ratio of the average run queue length to the number of CPU cores over a 5-minute period, reflects the processor's busyness; Memory usage is calculated as the difference between available memory and total memory using the formula: (1-available memory / total memory) × 100%; Disk I / O and network bandwidth: Use system tools to obtain throughput and latency indicators, compress them, and report them to the middleware in real time through the gRPC protocol for dynamic evaluation of the executor's health status.

6. The network endogenous security protection method driven by mimicry defense according to claim 1 is characterized in that: In S2, the specific steps of the standardization process include: S211. HTTP / HTTPS request processing. For requests based on the Hypertext Transfer Protocol, the middleware first parses the request line to separate the request method, request path, and protocol version. It then parses the request header fields, extracting key information such as the "Host" field and the "Content-Type" field, and converts the message body into structured data according to the specified format or retains the original binary stream. S212. Standardized processing flow: Protocol parsing and unified modeling: converting requests from different protocols into a unified request model defined within the middleware, including method, path, header field, message body, and timestamp fields; Data format conversion: for a message body in JSON format, it is converted into a compact byte stream through binary encoding; Timestamp alignment: synchronize the clocks of all executors and middleware based on the Network Time Protocol and calculate the time difference between the client and the server: Among them, T1 is the time when the client sends the request; T2 is the time when the middleware receives it; T3 is the time when the middleware sends the response; T4 is the time when the client receives the response. After calibration, the error of the request timestamp is controlled within ±10 milliseconds to ensure timing consistency across execution bodies. Data is processed in blocks. Messages exceeding 128KB are divided into data blocks of fixed size. The insufficient part is padded with 0x00 bytes to make the length of each block an integer multiple of 128KB.

7. The network endogenous security protection method driven by mimicry defense according to claim 1 is characterized in that: In the above S2, the request after normalization is temporarily stored in a cache of a red-black tree structure, and a method for fast retrieval is implemented using the request feature value as a key: S221. Cache data structure design: Key-value storage uses feature values ​​as keys, and the stored values ​​include the normalized request data block, the unique identifier of the source executable, the calibrated timestamp, and the reference count; The red-black tree maintains the balance of the tree structure through color marking and rotation operations, ensuring that the time complexity of insertion and query operations is O(logC), where C is the number of cache entries. O(logC) is a form of time complexity described in big O notation, where O stands for "Order of". It is used to describe the growth trend of algorithm running time or required space resources when the input scale tends to infinity. It focuses on the asymptotic behavior of algorithm performance with changes in input scale, ignoring constant coefficients and low-order terms, and only retaining the dominant term that best reflects the growth rate, in order to measure the efficiency characteristics of the algorithm under large-scale input. O(logC) means that as the number of cache entries C continues to increase, the growth rate of the algorithm execution time is approximately the growth rate of the logarithmic function with C as the independent variable. It is a relatively efficient time complexity, indicating that the operation time grows slowly. S221. Cache operation strategy: Insertion logic: New requests are normalized and feature values ​​are generated. If there is no matching key in the cache, a new node is created and inserted into the red-black tree. If there is a matching key, the timestamp and reference count of the corresponding node are updated. Elimination mechanism, when the cache space exceeds the preset bytes, traverse the nodes in the tree and delete the node with the smallest reference count and the longest unused node.

8. The network endogenous security protection method driven by mimicry defense according to claim 1 is characterized in that: The S3 includes: S311. Dynamic voting and weighting mechanism: The mimicking middleware counts the number and set of source executables of the same request based on the request feature value within a sliding time window of seconds. If the number of non-homologous requests is ≥ 2 / 3 of the total number of executables and the content is the same as the hash value, the request is considered legitimate. A weighting mechanism is introduced, with a healthy executable weight of 1.2 and an abnormal executable weight of 0.

8. The weighted count must reach the threshold for the request to pass the judgment. S312. Dynamic threshold adaptive adjustment and exception handling: The system calculates the voting success rate over the last five minutes in real time. If the success rate is >0.9, the threshold is lowered by 5%, and if it is <0.7, it is raised by 10%. When an abnormal request is detected, the firewall blocks the abnormal executor's network communication, marks it as "isolated," and removes it from the voting set. A security log containing a timestamp, executor ID, and request feature values ​​is generated and stored on the blockchain to ensure it cannot be tampered with. The calculation formula for the success rate S is:

9. The network endogenous security protection method driven by mimicry defense according to claim 1 is characterized in that: The S4 includes: S411. Response Verification Mechanism: The mimetic middleware uses cryptographic means to verify the integrity and consistency of the response data. First, the target service uses the secp256r1 elliptic curve private key to ECDSA-sign the response body. After receiving the response, the middleware verifies the validity of the signature using the public key to ensure that the response has not been tampered with by the middleman. At the same time, the response hash values ​​of all executables are collected and compared to see whether the responses of at least half of the executables are consistent. If so, the verification passes; otherwise, the response is determined to have been tampered with and the rollback mechanism is triggered. S412. A rollback mechanism takes snapshots of the executable's memory state, file system, and network configuration every 15 minutes and stores them in a distributed storage system. The snapshot naming convention includes the executable ID and timestamp, and a total of 96 versions from the last 24 hours are retained. Once a response is detected as tampered, the middleware determines the timestamp of the last valid response from the security log, loads the corresponding state snapshot, and restores the executable to its valid state. S413. Results distribution: Verified responses are pushed to each executor in real time via the gRPC streaming protocol, with a 200-millisecond timeout to ensure transmission efficiency. If an executor does not receive a response within the timeout, it re-pulls data from S2's red-black tree cache by requesting feature values ​​to ensure consistency across all executors and avoid data inconsistencies caused by network latency.

10. The network endogenous security protection method driven by mimicry defense according to claim 1 is characterized in that: The method for dynamically reconstructing the executor pool in a periodic or event-driven manner: S511. Dynamic reconstruction of the executor pool. The mimic defense system dynamically updates the executor pool through two mechanisms: periodic triggering and event-driven triggering, to disperse the attack surface and replace failed nodes: The periodic trigger reconstruction mechanism is automatically triggered at a fixed time point every day, replacing 1 / 3 of the total number of nodes in the execution body each time; The event-driven reconstruction mechanism is that when the number of abnormal executables reaches or exceeds 1 / 3 of the total, or the abnormal request frequency exceeds the threshold, a full reconstruction is immediately triggered to replace all executables; New node initialization: Heterogeneous construction: New nodes must implement multi-level heterogeneity at the hardware, system, and application layers. The hardware layer must use a different architecture from existing nodes, with network cards and storage devices from different manufacturers. The system layer must deploy heterogeneous operating systems and different kernel versions. The application layer must deploy functionally equivalent but different components for the same service, compiled using different compilers. Identity and communication configuration: assign a unique UUID to the new node, associate the hardware fingerprint with the software hash, configure the primary and backup IP addresses and random non-privileged ports, use the TLS1.3 protocol to encrypt communication, and the certificate is issued by the system's built-in CA; The old node is offline, marked as "pending deletion", stops accepting new requests, allows existing requests to be processed, and then is removed from the state table of the mimic middleware, releasing hardware resources; S512. Two-level key rotation and security maintenance: A two-level key system with a private key and a root public key is used, combined with a key rotation mechanism to prevent key leakage or cracking: in: The private key is used for request signatures and data encryption. It uses the DES algorithm and is rotated every hour. After the new key is generated, it is sent to the executor through an AES-256 encrypted channel to ensure the security of the transmission process. The root public key is used to verify the legitimacy of the transmitted private key. It uses the RSA-4096 algorithm and is updated once a quarter through an X.509 certificate. When the root public key is updated, the validity of the certificate is verified through the blockchain or a trusted third party to prevent man-in-the-middle attacks. Key rotation mechanism design: Parallel validation design: The old and new keys take effect in parallel for a period of time. During this period, the executor supports decryption with both keys simultaneously to avoid service interruption. For example, if the old key expires at time T0, the new key will take effect at T0-10 minutes in advance, ensuring seamless request processing. After the old key is revoked, the old key is added to the certificate revocation list after the parallel period ends. The executor stops using the old key and deletes it from the local secure storage. Heterogeneity verification and feedback: When deploying new nodes, they must be verified using a heterogeneity formula to ensure that the average heterogeneity of the executor pool after reconstruction is greater than 0.

8. The reconstructed new state is fed back to the heterogeneous executor deployment process of S1, forming a closed loop of "detection-reconstruction-redeployment" to continuously improve the system's ability to resist unknown attacks. Among them, the heterogeneity formula is expressed as: H=0.4ΔH+0.3ΔO+0.3ΔS≥0.7; H represents the heterogeneity of the reconstructed executable pool, and ΔH, ΔO, and ΔS are the differences in hardware, system, and software, respectively.

Images