Security defense method, device and system, storage medium and product

Abstract

The invention discloses a security defense method, device and system, a storage medium and a product, and the method comprises the steps that a first server receives a request message, copies the request message to generate a plurality of first request message copies, and processes the first request message copies through corresponding executors to obtain second request message copies; the first server votes the second request message copy, and if the voting is abnormal, an abnormal executor is removed; if the voting is normal, any normal second request message copy is sent; receiving a response message, copying to generate a plurality of first response message copies, and processing the first response message copies through corresponding executors to obtain second response message copies; the first server votes the second response message copy, and if the voting is abnormal, an abnormal executor is removed; and if the voting is normal, sending any normal second response message copy. According to the invention, bidirectional defense across the flow direction is realized.

Description

A security defense method, device, system, storage medium, and product. Technical Field

[0001] This invention belongs to the field of network and information security technology, and particularly relates to a security defense method, device, system, storage medium and product. Background Technology

[0002] As a critical boundary device between users and target servers, reverse proxy servers undertake important functions such as request forwarding, load balancing, and security filtering. However, unlike ordinary servers or network devices, reverse proxies need to handle bidirectional and asymmetric data flows. They need to handle both forward requests from clients and backward responses from servers. This unique architectural feature leads to the following severe security challenges for traditional reverse proxies: (1) Bidirectional attack surface distribution: Attackers can attack backend services by tampering with client requests, and they can also attack frontend users by polluting the server. (2) Session state dependency: Reverse proxies need to maintain complex session state consistency, while traditional single-point defenses cannot guarantee the security consistency of bidirectional data flows. (3) Performance and security balance: Under the requirements of high concurrency and low latency, the introduction of security mechanisms cannot significantly affect the business performance of reverse proxies. (4) Their own security vulnerabilities: Vulnerabilities cannot be avoided during the development of reverse proxies. In addition to using code security detection methods to discover potential vulnerabilities, there are no good vulnerability mining and elimination techniques, and the risk of vulnerabilities being exploited is high.

[0003] Existing research on mimicry security defenses largely focuses on unidirectional data processing or endpoint defense, failing to effectively address the security challenges of reverse proxies, which involve bidirectional data flow and middleware characteristics. Directly applying general dynamic heterogeneous redundancy architectures to reverse proxies presents technical challenges such as separate request and response processing, maintaining session state consistency, and voting latency under high-performance requirements. Furthermore, the adjudication units in mimicry defense systems are typically relatively isolated, making independent decisions based on a single request-response cycle, lacking collaborative defense capabilities across requests and data flow directions. Advanced persistent threats (APTs) and complex attack chains often employ multi-stage, slow-moving, and chronic attack methods. For example, an attacker might first contaminate a reverse proxy with one request, then trigger malicious code execution with another. Such collaborative attacks across multiple request-response cycles pose a significant challenge to existing isolated, single-vote-based defense architectures. Therefore, existing reverse proxy security solutions and general mimicry defense technologies have the following limitations: (1) Passivity of traditional security solutions: passive defense that relies on vulnerability patches and rule updates, strong dependence on external technology, and the lag in vulnerability repair, resulting in high defense costs and inability to cope with unknown vulnerabilities and zero-day attacks; (2) Business incompatibility of general mimicry architecture: existing mimicry defense solutions are mostly designed for network devices or computing terminals, lacking special optimization for bidirectional business flow and middleware features of reverse proxies; (3) Limitations of single-direction protection: existing technologies mostly focus on security in a single direction of request or response, and cannot provide bidirectional, full-link collaborative protection; (4) Challenges of transparency requirements: as middleware, reverse proxies need to ensure complete transparency to the client and server, while existing solutions often require the cooperation and modification of one end, resulting in high implementation costs; (5) Isolation of adjudication components: existing security solutions adopt systems based on the concept of mimicry defense, and there is a lack of effective information sharing and collaboration mechanisms between the adjudication components (single or two) within them. They cannot detect attack characteristics in one data flow direction and apply them in real time to predictive defense in another data flow direction, resulting in a delayed response to complex coordinated attacks and an inability to form a systematic defense capability. Summary of the Invention

[0004] Purpose of the invention: The purpose of this invention is to provide a security defense method, device, system, storage medium, and product that achieves bidirectional defense across traffic flow directions.

[0005] Technical Solution: The security defense method of the present invention is applied to a first server comprising a plurality of heterogeneous executors. The method includes the following steps: The first server receives a request message, and generates multiple copies of the first request message according to the number of executors in the online executor list. Each copy of the first request message is processed by a corresponding executor to obtain a corresponding second request message copy. The first server votes on the second request message copies of all online executors. If the vote is abnormal, the executor that processed the abnormal second request message copy is determined to be an abnormal executor and removed from the online executor list. If the vote is normal, any... A normal second request message copy is sent to the second server; a response message responding to the normal second request message copy is received, and multiple first response message copies are generated according to the number of executors in the online executor list. Each first response message copy is used to process the corresponding executor to obtain the corresponding second response message copy; the first server votes on the second response message copies of all online executors. If the vote is abnormal, the executor that processed the abnormal second response message copy is determined to be an abnormal executor and removed from the online executor list; if the vote is normal, any normal second response message copy is selected and sent to the client.

[0006] Optionally, the first server's voting on the second request message copies of all online executors further includes: the first server querying the attack fingerprint database to check whether the current second request message copy matches a known attack fingerprint; if it matches, the request message is intercepted and an abnormal result is returned; if it does not match, the second request message copy is voted on; if the vote is abnormal, attack features are extracted from the abnormal second request message copy, an attack fingerprint is generated, and stored in the attack fingerprint database, wherein the attack fingerprint is set with a lifespan time.

[0007] The first server's voting on the second response message copies of all online executors further includes: the first server querying the attack fingerprint database to check whether the current second response message copy matches a known attack fingerprint; if it matches, the response message is intercepted and an abnormal result is returned; if it does not match, the second response message copy is voted on; if the vote is abnormal, attack features are extracted from the abnormal second response message copy, an attack fingerprint is generated, and stored in the attack fingerprint database, wherein the attack fingerprint is set with a lifespan.

[0008] Optionally, the second response message copy includes a response line, a response header, and a response body. The first server uses either consensus voting or majority voting at three voting levels—response line, response header, and response body—for all second response message copies. Consistency voting means that if there is inconsistency at any voting level, all second response message copies are considered abnormal and an abnormal result is returned. If all voting levels are consistent, all second response message copies are considered normal. Majority voting means that if a second response message copy corresponding to an executor is inconsistent with the majority of other executors at any voting level, that second response message copy is considered abnormal, the corresponding executor is considered abnormal, and the second response message copies of the remaining majority of executors are considered normal. If all second response message copies are inconsistent at any voting level, all second response message copies are considered abnormal, all executors are considered abnormal, and an abnormal result is returned. If all second response message copies are consistent at all voting levels, all second response message copies are considered normal.

[0009] Optionally, the second request message copy includes a request line and a request header. The first server uses either consistent voting or majority voting at two voting levels—the request line and the request header—for all second request message copies. Consistent voting means that if there is inconsistency at any voting level, all second request message copies are considered abnormal and an abnormal result is returned. If all voting levels are consistent, all second request message copies are considered normal. Majority voting means that if a second request message copy corresponding to an executor is inconsistent with the majority of other executors at any voting level, that second request message copy is considered abnormal, the corresponding executor is considered abnormal, and the second request message copies of the remaining majority of executors are considered normal. If all second request message copies are inconsistent at any voting level, all second request message copies are considered abnormal, all executors are considered abnormal, and an abnormal result is returned. If all second request message copies are consistent at all voting levels, all second request message copies are considered normal.

[0010] Optionally, the second request message copy also includes a request body, and the first server uses consensus voting or majority voting at three voting levels—request line, request header, and request body—for all second request message copies.

[0011] Optionally, the first server performs a unique vote on all copies of the second request message belonging to the same request message. After the first response message copy is processed by the corresponding executor to obtain the corresponding second response message copy, all copies of the second request message and all copies of the first response message belonging to the same request message are deleted.

[0012] Optionally, the process of the last second request message copy belonging to the same request message in the first server creates a voting lock. The voting lock is used by the process that created the voting lock to read all second request message copies belonging to the same request message and perform a unique vote. After the last first response message copy belonging to the same request message is processed by the corresponding executor to obtain the corresponding second response message copy, the process of the last first response message copy creates a deletion lock. The deletion lock is used by the process that created the deletion lock to read all second request message copies and all first response message copies and perform deletion.

[0013] Optionally, the first server includes a client security gateway, a server security gateway, several heterogeneous executors, and a scheduler. The client security gateway receives request messages, generates multiple copies of the first request message based on the number of executors in the online executor list, and synchronously distributes them to the corresponding executors. The executor processes the first request message copy, obtains a second request message copy, and forwards it to the server security gateway. The server security gateway votes on the second request message copies of all online executors. If the vote is abnormal, the executor processing the abnormal second request message copy is determined to be an abnormal executor, and the corresponding abnormal executor identifier is transmitted to the scheduler. If the vote is normal, any normal second request message copy is selected and sent to the second server. The server receives responses to the normal second request message. The response message of the first response message is copied to generate multiple copies based on the number of executors in the online executor list, and synchronously distributed to the corresponding executors one by one. The executor processes the first response message copy, obtains the second response message copy, and forwards it to the client security gateway. The client security gateway votes on the second response message copies of all online executors. If the vote is abnormal, the executor that processed the abnormal second response message copy is determined to be an abnormal executor, and the corresponding abnormal executor identifier is transmitted to the scheduler. If the vote is normal, any normal second response message copy is selected and sent to the client. The scheduler dynamically manages the executors and maintains the online executor list. Based on the abnormal executor identifier, the abnormal executor is removed from the online executor list, and a new executor is reconstructed and added to the online executor list.

[0014] Optionally, the client security gateway configures and queries the attack fingerprint database to check whether the current second response message copy matches a known attack fingerprint. If it matches, the response message is intercepted, and an exception result is returned to the client. If it does not match, the second response message copy is voted on. If the vote is abnormal, attack features are extracted from the abnormal second response message copy, an attack fingerprint is generated, stored in the attack fingerprint database, and the attack fingerprint is synchronized to the attack fingerprint database of the server security gateway. The server security gateway configures and queries the attack fingerprint database to check whether the current second request message copy matches a known attack fingerprint. If it matches, the request message is intercepted, and an exception result is returned to the client. If it does not match, the second request message copy is voted on. If the vote is abnormal, attack features are extracted from the abnormal second request message copy, an attack fingerprint is generated, stored in the attack fingerprint database, and the attack fingerprint is synchronized to the attack fingerprint database of the client security gateway.

[0015] In one embodiment, the electronic device of the present invention includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the security defense method as described above.

[0016] In one embodiment, the security defense system of the present invention includes a client, a first server, and a second server. The first server includes a client security gateway, a server security gateway, several heterogeneous executors, and a scheduler. The client security gateway receives request messages, generates multiple copies of the first request message based on the number of executors in the online executor list, and synchronously distributes them to the corresponding executors. It votes on the second response message copies of all online executors. If the vote is abnormal, the executor handling the abnormal second response message copy is determined to be an abnormal executor, and the corresponding abnormal executor identifier is transmitted to the scheduler. If the vote is normal, any normal second response message copy is selected and sent to the client. The executors process the first request message copies, obtain second request message copies, and forward them to the server security gateway. The server-side security gateway processes the first response message copy to obtain the second response message copy and forwards it to the client security gateway. The server-side security gateway votes on the second request message copies of all online executors. If the vote is abnormal, the executor that processed the abnormal second request message copy is determined to be an abnormal executor, and the corresponding abnormal executor identifier is transmitted to the scheduler. If the vote is normal, any normal second request message copy is selected and sent to the second server. The server receives the response message in response to the normal second request message copy, generates multiple first response message copies according to the number of executors in the online executor list, and synchronously distributes them to the corresponding executors. The scheduler dynamically manages the executors and maintains the online executor list. According to the abnormal executor identifier, the abnormal executor is removed from the online executor list, and a new executor is reconstructed and added to the online executor list.

[0017] In one embodiment, the present invention provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the security defense method described above.

[0018] In one embodiment, the computer program product of the present invention includes a computer program that, when executed by a processor, implements the security defense method described above.

[0019] Beneficial effects: Compared with the prior art, the present invention has the following significant advantages: The present invention, targeting the business characteristics of bidirectional data flow of reverse proxy, constructs a first server containing several heterogeneous execution entities. By bidirectional voting on request and response messages, it achieves bidirectional, full-link security protection for client requests and server responses, solving the problem that a single voting point cannot cover the security of bidirectional business flow. Attached Figure Description

[0020] Figure 1 is a system architecture diagram of the present invention; Figure 2 is a configuration diagram of the client security gateway component of the present invention; Figure 3 is a configuration diagram of the heterogeneous execution pool and scheduler component of the present invention; Figure 4 is a configuration diagram of the server security gateway component of the present invention; Figure 5 is an architecture diagram of cross-plane collaborative active defense in the present invention; Figure 6 is a pre-interception runtime sequence diagram of the server security gateway in the present invention; Figure 7 is a pre-interception runtime sequence diagram of the client security gateway in the present invention. Detailed Implementation

[0021] The technical solution of the present invention will be further described below with reference to the accompanying drawings.

[0022] In one embodiment, the present invention provides a mimicry security defense architecture that can establish a security association between forward request flow and backward response flow, and realize cross-flow direction collaborative perception and joint defense. The security defense method of the present invention is applied to a first server comprising a plurality of heterogeneous executors. The method includes the following steps: The first server receives a request message and generates multiple copies of the first request message according to the number of executors in the online executor list. Each copy of the first request message is processed by a corresponding executor to obtain a corresponding second request message copy. The first server votes on the second request message copies of all online executors. If the vote is abnormal, the executor that processed the abnormal second request message copy is determined to be an abnormal executor and removed from the online executor list. If the vote is normal, any normal second request message copy is selected and sent to the second server. The first server receives a response message in response to the normal second request message copy and generates multiple copies of the first response message according to the number of executors in the online executor list. Each copy of the first response message is processed by a corresponding executor to obtain a corresponding second response message copy. The first server votes on the second response message copies of all online executors. If the vote is abnormal, the executor that processed the abnormal second response message copy is determined to be an abnormal executor and removed from the online executor list. If the vote is normal, any normal second response message copy is selected and sent to the client.

[0023] In one embodiment, the voting process by the first server on the second request message copies of all online executors further includes: the first server querying an attack fingerprint database to check whether the current second request message copy matches a known attack fingerprint; if it matches, the request message is intercepted and an exception result is returned; if it does not match, the second request message copy is voted on, and if the vote is abnormal, attack features are extracted from the abnormal second request message copy, an attack fingerprint is generated, and stored in the attack fingerprint database, with the attack fingerprint having a lifespan time. The voting process by the first server on the second response message copies of all online executors further includes: the first server querying an attack fingerprint database to check whether the current second response message copy matches a known attack fingerprint; if it matches, the response message is intercepted and an exception result is returned; if it does not match, the second response message copy is voted on, and if the vote is abnormal, attack features are extracted from the abnormal second response message copy, an attack fingerprint is generated, and stored in the attack fingerprint database, with the attack fingerprint having a lifespan time.

[0024] In one embodiment, the second response message copy includes a response line, a response header, and a response body. The first server uses either consensus voting or majority voting to evaluate all second response message copies across three voting levels: response line, response header, and response body. Consistency voting means that if any voting level is inconsistent, all second response message copies are considered abnormal and an abnormal result is returned; if all voting levels are consistent, all second response message copies are considered normal. Majority voting means that if a second response message copy corresponding to an executor is inconsistent with the majority of other executors at any voting level, that second response message copy is considered abnormal, the corresponding executor is considered abnormal, and the second response message copies of the remaining majority of executors are considered normal. If all second response message copies are inconsistent at any voting level, all second response message copies are considered abnormal, all executors are considered abnormal, and an abnormal result is returned. If all second response message copies are consistent at all voting levels, all second response message copies are considered normal.

[0025] In one embodiment, the second request message copy includes a request line and a request header. The first server uses either consensus voting or majority voting at two voting levels—the request line and the request header—for all second request message copies. Consistency voting means that if there is inconsistency at any voting level, all second request message copies are considered abnormal and an abnormal result is returned. If all voting levels are consistent, all second request message copies are considered normal. Majority voting means that if a second request message copy corresponding to an executor is inconsistent with the majority of other executors at any voting level, that second request message copy is considered abnormal, the corresponding executor is considered abnormal, and the second request message copies of the remaining majority of executors are considered normal. If all second request message copies are inconsistent at any voting level, all second request message copies are considered abnormal, all executors are considered abnormal, and an abnormal result is returned. If all second request message copies are consistent at all voting levels, all second request message copies are considered normal.

[0026] In one embodiment, the second request message copy further includes a request body, and the first server adopts consensus voting or majority voting on all second request message copies from three voting levels: request line, request header, and request body.

[0027] In one embodiment, the first server performs a unique vote on all copies of the second request message belonging to the same request message. After the first response message copy is processed by the corresponding executor to obtain the corresponding second response message copy, all copies of the second request message and all copies of the first response message belonging to the same request message are deleted.

[0028] In one embodiment, the process of the last second request message copy belonging to the same request message in the first server creates a voting lock. The voting lock is used by the process that created the voting lock to read all second request message copies belonging to the same request message and perform a unique vote. After the last first response message copy belonging to the same request message is processed by the corresponding executor to obtain the corresponding second response message copy, the process of the last first response message copy creates a deletion lock. The deletion lock is used by the process that created the deletion lock to read all second request message copies and all first response message copies and perform deletion.

[0029] In one embodiment, the first server includes a client security gateway, a server security gateway, several heterogeneous executors, and a scheduler. The client security gateway receives request messages, generates multiple copies of the first request message based on the number of executors in the online executor list, and synchronously distributes them to the corresponding executors. Each executor processes a copy of the first request message, obtains a copy of the second request message, and forwards it to the server security gateway. The server security gateway votes on the copies of the second request messages from all online executors. If the vote is abnormal, the executor processing the abnormal copy of the second request message is determined to be an abnormal executor, and the corresponding abnormal executor identifier is transmitted to the scheduler. If the vote is normal, any normal copy of the second request message is selected and sent to the second server. The server receives responses to the normal second request message... The response message of the first response message is copied to generate multiple copies based on the number of executors in the online executor list, and synchronously distributed to the corresponding executors. The executor processes the first response message copy, obtains the second response message copy, and forwards it to the client security gateway. The client security gateway votes on the second response message copies of all online executors. If the vote is abnormal, the executor that processed the abnormal second response message copy is determined to be an abnormal executor, and the corresponding abnormal executor identifier is transmitted to the scheduler. If the vote is normal, any normal second response message copy is selected and sent to the client. The scheduler dynamically manages the executors and maintains the online executor list. Based on the abnormal executor identifier, the abnormal executor is removed from the online executor list, and a new executor is rebuilt and added to the online executor list.

[0030] In one embodiment, the client security gateway configures and queries the attack fingerprint database to check whether the current second response message copy matches a known attack fingerprint. If it matches, the response message is intercepted, and an exception result is returned to the client. If it does not match, the second response message copy is voted on. If the vote is abnormal, attack features are extracted from the abnormal second response message copy, an attack fingerprint is generated, stored in the attack fingerprint database, and the attack fingerprint is synchronized to the attack fingerprint database of the server security gateway. The server security gateway configures and queries the attack fingerprint database to check whether the current second request message copy matches a known attack fingerprint. If it matches, the request message is intercepted, and an exception result is returned to the client. If it does not match, the second request message copy is voted on. If the vote is abnormal, attack features are extracted from the abnormal second request message copy, an attack fingerprint is generated, stored in the attack fingerprint database, and the attack fingerprint is synchronized to the attack fingerprint database of the client security gateway.

[0031] In one embodiment, the attack fingerprint database in the server-side security gateway and the client-side security gateway can be initially configured to be empty or can also include some default malicious fingerprint databases, such as fingerprints of malicious browser extensions or fingerprints of malicious cookie theft.

[0032] In one embodiment, the process of the last second request message copy belonging to the same request message in the first server creates a voting lock. The process that creates the voting lock reads all second request message copies, votes on them, and locks the voting lock. The process of the last first response message copy belonging to the same request message in the first server creates a deletion lock. After the first response message copy is processed by the corresponding executor to obtain the corresponding second response message copy, the process that creates the deletion lock reads all second request message copies and all first response message copies, deletes them, and locks the deletion lock. Finally, the voting lock and the deletion lock are unlocked.

[0033] In one embodiment, the security defense system of the present invention includes a client, a first server, and a second server. The first server includes a client security gateway, a server security gateway, several heterogeneous executors, and a scheduler. The client security gateway receives request messages, generates multiple copies of the first request message based on the number of executors in the online executor list, and synchronously distributes them to the corresponding executors. It votes on the second response message copies of all online executors. If the vote is abnormal, the executor that processes the abnormal second response message copy is determined to be an abnormal executor, and the corresponding abnormal executor identifier is transmitted to the scheduler. If the vote is normal, any normal second response message copy is selected and sent to the client. The executors process the first request message copies, obtain the second request message copies, and forward them to the server security gateway. The first response message copy is obtained, and the second response message copy is forwarded to the client security gateway. The server security gateway votes on the second request message copies of all online executors. If the vote is abnormal, the executor that processed the abnormal second request message copy is determined to be an abnormal executor, and the corresponding abnormal executor identifier is transmitted to the scheduler. If the vote is normal, any normal second request message copy is selected and sent to the second server. The server receives the response message in response to the normal second request message copy, and generates multiple first response message copies according to the number of executors in the online executor list, and synchronously distributes them to the corresponding executors. The scheduler dynamically manages the executors and maintains the online executor list. According to the abnormal executor identifier, the abnormal executor is removed from the online executor list, and a new executor is reconstructed and added to the online executor list.

[0034] Specifically, the client security gateway receives client request messages, which include a request line, request headers, and a request body. For GET method requests, the request body is empty. It generates copies of the request messages based on the number of executors in the online executor list and synchronously distributes them to the corresponding executors. Each request message copy includes a request line, request headers, request body, request ID, and executor identifier. It receives and caches all online executor response message copies, queries the attack fingerprint database, and checks if the current response message copy matches a known attack fingerprint. If it matches, it intercepts the response and returns an exception result to the client. If it doesn't match, it votes on the response line, response headers, and response body in sequence. If the voting fails, it transmits the corresponding exception executor identifier to the scheduler and returns the exception result to the client. Simultaneously, it extracts attack features from the exception response message copy, generates an attack fingerprint, stores it in the attack fingerprint database, and synchronizes the attack fingerprint to the server security gateway's attack fingerprint database. If the voting is successful, it randomly selects a response message copy and sends it to the client. The server security gateway receives and caches all online executor request message copies, queries the attack fingerprint database, and checks if the current request message copy matches a known attack fingerprint. If a match is found, the request is intercepted, and an exception result is returned to the client. If no match is found, the request line, request headers, and request body are voted on sequentially. If the vote fails, the corresponding exception execution body identifier is transmitted to the scheduler, and the exception result is returned to the client. Simultaneously, attack features are extracted from the copy of the exception request message, an attack fingerprint is generated, stored in the attack fingerprint database, and synchronized to the attack fingerprint database of the client's security gateway. If the vote succeeds, a copy of the request message is randomly selected and sent to the second server. The response from the second server is received, and a response message is generated, including a response line, response headers, and... The response body copies the response message and synchronously distributes it to the corresponding execution body. The response message copy includes the response line, response header, response body, request ID, and execution body identifier. The execution body receives the corresponding request message copy and the corresponding response message copy, processes and forwards the request message copy to the server-side security gateway, and processes and forwards the response message copy to the client-side security gateway. The scheduler dynamically manages the execution bodies and maintains the online execution body list. It performs self-cleaning based on the abnormal execution body identifier, removes the abnormal execution body from the online execution body list, and reconstructs a new execution body to add to the online execution body list.

[0035] This invention presents a bidirectional voting-based mimicry-based security defense architecture. Targeting the business characteristics of bidirectional data flow in reverse proxies, it constructs a security defense architecture consisting of a client security gateway, a heterogeneous execution entity scheduling center, and a server-side security gateway. This architecture achieves bidirectional, end-to-end security protection for client requests and server responses. The client security gateway focuses on protecting against malicious requests from clients and attacks targeting the execution entity itself; the server-side security gateway focuses on protecting against malicious responses from the server and data leakage risks; collaborative protection involves the two security gateways working in conjunction with the execution entity scheduling module through a negative feedback mechanism to achieve immediate detection and handling of bidirectional attacks. This bidirectional, end-to-end voting design is a key architectural innovation of mimicry-based security defense in the reverse proxy field, solving the problem that a single voting point cannot cover the security of bidirectional business flows.

[0036] This invention addresses the unique characteristics of bidirectional data flow in reverse proxy services by constructing a mimicry-based security defense architecture. This architecture comprises a client-side security gateway, several heterogeneous execution entities, a scheduler, and a server-side security gateway, achieving bidirectional, end-to-end security protection for client requests and server responses. The client-side security gateway focuses on protecting against malicious requests from clients and attacks targeting the execution entities themselves. The server-side security gateway focuses on protecting against malicious responses from a second server and data leakage risks. Collaborative protection involves the two security gateways working in conjunction with the scheduler through a negative feedback mechanism to achieve immediate detection and handling of bidirectional attacks. The invention's bidirectional, end-to-end voting design solves the problem that a single voting point cannot cover the security of bidirectional business flows. This invention, applied to reverse proxy business scenarios, addresses the unique challenges of bidirectional data flow, collaborative defense, high concurrency, and business transparency.

[0037] As the system's traffic inlet and outlet, the client security gateway interacts directly with the client, is responsible for the multi-path replication and distribution of requests, performs consistency adjudication on multi-path responses, and combines the voted multi-path responses into a single secure response to return to the client; in abnormal scenarios, it sends an abnormal execution body cleaning signal to the scheduler, and extracts, manages and synchronizes attack fingerprints from abnormal responses.

[0038] Several heterogeneous executors and schedulers serve as the core processing engine of the system, managing and scheduling multiple heterogeneous reverse proxy executors; they are responsible for the dynamic management of the lifecycle and configuration policies of the executors, receiving negative feedback instructions from two security gateways and performing the cleaning and recovery of abnormal executors.

[0039] The server-side security gateway acts as a bridge between the system and backend services. It receives multiple requests from heterogeneous executors and uses request / response caching and concurrency control mechanisms under high concurrency to achieve consistent adjudication of multiple requests. It combines the multiple requests that pass the vote into a single security request and sends it to the second server. It also replicates the response from the second server multiple times and distributes it to each executor. In case of abnormal scenarios, it sends an abnormal executor cleaning signal to the scheduler and extracts, manages, and synchronizes attack fingerprints from abnormal responses.

[0040] The collaborative control bus is a high-speed information channel connecting the client and the server security gateway. It is implemented based on message middleware and is responsible for the real-time and reliable transmission of security intelligence such as attack fingerprints and status information. It is the foundation of cross-surface collaborative defense.

[0041] This invention achieves intrinsic security protection throughout the entire lifecycle of reverse proxy services through a two-way voting mechanism, a collaborative defense mechanism, and a negative feedback cleaning mechanism. The system architecture diagram is shown in Figure 1.

[0042] The specific client security gateway includes a multi-path request distributor, a multi-path response voter, a secure response combiner, a first negative feedback communicator, and an attack fingerprint manager. The multi-path request distributor receives client request messages, which include a request line, request headers, and a request body; it injects a globally unique request ID (X-Mimic-Request-ID) and an execution identifier (X-Mimic-Executor-Index) into each message, generates a copy of the request message, and performs multi-path replication and synchronous distribution. The multi-path response voter receives multiple responses from various heterogeneous executors; it employs a multi-level voting strategy to sequentially compare and decide on the consistency of the status code, response headers, and response body content (or hash value). The secure response combiner, after the voter confirms that a majority of responses are consistent, randomly selects one and assembles it into a standard response to return to the client. The first negative feedback communicator, once the voter detects an abnormal executor, immediately sends a cleanup signal to the scheduler, triggering the cleanup process. The first attack fingerprint manager extracts attack features from abnormal responses, generates fingerprints, and synchronizes them via the collaborative control bus. In subsequent traffic processing, it matches the attack fingerprints synchronized by the server-side security gateway, achieving pre-interception of cross-request traffic attacks. The component structure is shown in Figure 2.

[0043] The processing flow of the multi-path request dispatcher is as follows: (1) Request marking and tracing processing The client security gateway initializes and updates the accurate system time to generate a globally unique request ID X-Mimic-Request-ID for each inbound request. This request ID is generated by mixing nanosecond-level timestamps, process IDs and random numbers to ensure its uniqueness and traceability in a distributed environment. The execution identifier X-Mimic-Executor-Index field is injected into the request header to clearly identify which specific execution body should process the copy of the request message. For example, index 1 represents the Nginx execution body, 2 represents the Caddy execution body, and 3 represents the Traefik execution body. The three reverse proxy heterogeneous execution bodies in the heterogeneous execution body pool are Nginx, Caddy and Traefik, which are deeply heterogeneous from the perspective of technology stack, runtime module and configuration. This combination provides the best security gain in general Web scenarios. As an alternative, the following combination can also be selected: (1) High performance and customization combination: Nginx, Apache, Openresty. This combination focuses on high performance and flexible script extension capabilities, which is suitable for scenarios that require deep customization of business logic. (2) Cloud-native combination: Envoy, Caddy, Traefik. This combination provides good support for cloud-native environments and microservice architectures, and is suitable for dynamic container orchestration environments.

[0044] (2) Intelligent dispatch processing based on request method For GET method requests, due to their idempotency and no request body, the multi-way request dispatcher only copies the request line (such as request method, URL and version information) and request headers; this optimization reduces network overhead and memory copying, and improves system throughput; For POST and PUT method requests, given that they may carry important form data or API parameters, the multi-way request dispatcher will completely copy the request line, request headers and request body; to ensure consistency, the multi-way request dispatcher will first read the request body into the internal buffer and then perform multi-way copying and dispatching to avoid data inconsistency caused by different network stream reading positions.

[0045] (3) Synchronous distribution mechanism: All request message copies utilize kernel-level epoll heterogeneous I / O model and high-precision time lock to be sent to each heterogeneous execution body within microseconds, ensuring that the time difference of the execution body receiving the request is minimized, laying the foundation for subsequent voting consistency; at the same time, the module log records use cached timestamps to reduce the call to the system time and achieve performance optimization.

[0046] The multi-way response voter receives multiple copies of response messages from various heterogeneous executors and uses a multi-level voting strategy to compare and decide the consistency of the response line, response header, and response body in sequence. The secure response combiner, after the multi-way response voter confirms that the majority of responses are consistent, randomly selects one normal response message copy from them, assembles it into a standard response, and returns it to the client.

[0047] The processing flow of the multi-way response voter and the secure response combiner is as follows: (1) Multi-level voting processing The responses returned by the multi-way executors adopt a multi-level voting strategy to improve voting efficiency. The first level adopts the status code voting of the response line to vote on the HTTP status codes returned by each executor. The consistency voting principle is adopted, and the vote is considered to have passed only when all executors return the same status code. The second level adopts the key field voting of the response header to perform consistency comparison on the response header fields (e.g., Content-Length, Content-Type, Set-Cookie, etc.). The third level adopts the response body voting. For large response bodies (files exceeding 1MB), in order to improve voting performance, a hash comparison algorithm is adopted to calculate and compare the SHA-256 hash values ​​of each executor's response; for small response bodies or in the case of hash comparison failure, a full content comparison is adopted to perform a full comparison of the binary content at the memory level.

[0048] (2) Anomaly Detection and Negative Feedback Processing: Once a response message copy of an executor is inconsistent with that of the majority of executors at any voting layer, it is marked as an "abnormal executor". The multi-way response voter immediately sends a cleaning signal to the scheduler through the first negative feedback communicator. The cleaning signal contains the executor identifier index X-Mimic-Executor-Index and the abnormal request ID X-Mimic-Request-ID of the abnormal executor. At the same time, the client security gateway returns any one of the correct response message copies of the majority of executors to the client through the secure response combiner. This ensures that even if an attack occurs, the service to normal users is completely unaffected and uninterrupted.

[0049] Once the multi-channel response voter detects an abnormal executor, the first negative feedback communicator immediately sends a cleaning signal to the scheduler, triggering the cleaning process.

[0050] The first attack fingerprint manager extracts attack features from copies of abnormal response messages, generates attack fingerprints, and synchronizes them through the collaborative control bus. In subsequent request and response traffic processing, it matches the attack fingerprints synchronized by the server-side security gateway to achieve pre-interception of cross-request traffic attacks.

[0051] Several heterogeneous executors and a scheduler form the system's intrinsic security core. The scheduler consists of three modules: a dynamic executor manager, an adaptive cleaning engine, and a third negative feedback communicator. These heterogeneous executors form a heterogeneous executor pool, containing a collection of reverse proxy instances using various technology stacks (such as Nginx, Caddy, and Traefik), each running in a containerized, isolated environment. The dynamic executor manager is responsible for orchestrating the executor pool, injecting configurations (to achieve heterogeneous configuration), and performing dynamic scheduling. The adaptive cleaning engine receives negative feedback signals from the client and server security gateways and automatically performs the isolation, destruction, reconstruction, and verification processes for abnormal executors, enabling system self-recovery. The third negative feedback communicator receives cleaning instructions from the client and server security gateways. The component structure is shown in Figure 3.

[0052] This invention transcends simple software selection, achieving a defense-in-depth system comprised of multiple software instances with differentiated security strategies, encompassing heterogeneous dimensions such as technology stack, runtime environment, and configuration strategies. The deep heterogeneity and dynamic scheduling of this invention realize multi-layered deep heterogeneity in technology stack, runtime environment, and security configuration strategies, constructing a defense-in-depth system. Through a negative feedback mechanism and an adaptive cleaning engine, dynamic scheduling and proactive cleaning of abnormal execution entities are achieved.

[0053] The multi-dimensional deep heterogeneous implementation process is as follows: (1) Basic software heterogeneous execution entities are software instances developed in different languages. In this invention, execution entity A uses the Nginx software instance, which is developed in C language and is based on an event-driven, multi-process model, with high performance and high stability. Execution entity B uses the Caddy software instance, which is developed in Go language and is based on a coroutine model, with built-in automated HTTPS and modern configuration syntax. Execution entity C uses the Traefik software instance, which is developed in Go language and focuses on cloud-native and dynamic service discovery. The three software instances are developed by different teams and have completely different architectures, processing logics, and vulnerability databases, which makes it possible to use different business processing logics for the same request, thereby greatly enhancing heterogeneity.

[0054] (2) Heterogeneous runtime environment: Each executor runs in an independent, minimal Docker container. Each container uses a different base image (e.g., Alpine, Linux, Debian, etc.) and employs differentiated security policies (e.g., Seccomp, AppArmor, etc.). The heterogeneity of the runtime environment increases the complexity of the attack surface, making it extremely difficult for an attacker to exploit a vulnerability in one executor to work in another environment with different system calls and permission constraints.

[0055] (3) Heterogeneous Security Configuration: Different security filtering rules and log formats are adopted for the three software instances based on their configuration characteristics. The Nginx executor is configured with strict location path filtering and complex rewrite rules. The Caddy executor enables a unique log format and configures expression-based request assertions for primary filtering. The Traefik executor is configured with a tag-based intermediate chain to modify and verify requests. This heterogeneous security configuration means that the same attack may be bypassed by the security rules of one executor, but will be intercepted by the differentiated rules of another executor, thus being exposed during the voting phase.

[0056] The dynamic scheduling and cleaning mechanism works as follows: When the scheduler receives a negative feedback signal from the client or server security gateway, it initiates the "cleaning-restarting-verification" process for the execution unit. First, the execution unit is isolated; the abnormal execution unit is immediately removed from the online execution unit list, and new traffic no longer passes through it. Second, the execution unit is destroyed, terminating its container process. Third, the execution unit is rebuilt; a new container instance is quickly started from a preset image template. Fourth, the execution unit is verified; traffic is redirected to the new instance, and after verifying its normal response, it is re-added to the online execution unit list. The entire cleaning process is completed within seconds; its dynamic nature makes it impossible for attackers to maintain persistent attack sessions, increasing the cost of attacks.

[0057] The server-side security gateway is the system's arbitration center. Its core function is to process out-of-order copies of request messages from multiple executors, and it consists of six modules. The server-side security gateway includes a multi-way request voter, a secure request combiner, a request / response cache manager, a multi-way response dispatcher, a second negative feedback communicator, and a second attack fingerprint manager.

[0058] The system comprises several components: a multi-path request voter, which performs consensus voting on normalized preprocessed requests sent asynchronously by multiple executors; a secure request combiner, which, after a vote is passed, randomly selects a copy of a normal request message and forwards it to the second backend server; a request / response cache manager, the core component for high-concurrency voting, which uses a high-performance cache (such as Redis) to temporarily store copies of asynchronously arriving requests and implements a distributed lock-based voting triggering mechanism to ensure that the same group of requests is voted on only once, resolving concurrency contention issues; a multi-path response dispatcher, which, after receiving a response from the second backend server, replicates it to generate multiple copies of the response message and distributes them to each executor; a second negative feedback communicator, which sends a cleanup signal to the scheduler when an abnormal executor is detected during the request voting phase; and a second attack fingerprint manager, which extracts attack features from abnormal request message copies, generates attack fingerprints, synchronizes them through the cooperative control bus, and performs predictive interception based on known attack fingerprints. The component structure of the server-side security gateway is shown in Figure 4.

[0059] The request grouping-based caching mechanism works as follows: Due to the asynchronous nature of sending request message copies by multiple execution entities, the server-side security gateway adopts a grouping caching mechanism, using a Redis cluster as a high-performance cache backend. The key design is MimicReq:{X-Mimic-Request-ID}:{X-Mimic-Executor-Index}. When a request message copy is received, its X-Mimic-Request-ID is used as the grouping basis, and the normalized request header and request body of the request message copy are stored in the cache.

[0060] The request normalization preprocessing flow is as follows: Before voting, the server-side security gateway normalizes all request message copies to avoid meaningless differences. First, it parses the request header field X-Mimic-Request-ID, classifying requests with the same X-Mimic-Request-ID and marking them as a group to be voted on; it also parses the request header field X-Mimic-Executor-Index, which identifies the specific executor. Second, it parses the remaining fields in the request header and sorts them alphabetically by field name in the format "field name: field value"; it normalizes parameters and sorts and re-encodes query parameters in the URL. Third, it parses the request body, removing irrelevant whitespace from JSON or XML formatted data; this step ensures that minor, harmless formatting changes due to differences in executor implementation will not cause misjudgments.

[0061] The voting triggering and control process based on distributed locks is the core innovation in solving the problem of duplicate voting under high concurrency. While a request-grouping-based caching mechanism solves the problem of out-of-order arrival of multiple request replicas, the voting triggering issue remains unresolved. Traditional methods using timers to trigger voting based on timeouts impact voting efficiency and are prone to false positives due to network fluctuations and response delays. This invention employs a distributed lock based on shared memory to achieve efficient voting triggering and control processing for multiple request replicas.

[0062] This invention defines two independent shared memory spaces, accessible to the working processes of the server-side security gateway. One is a voting lock, indicating that voting is allowed, ensuring that voting on the same request message copy is performed only once, avoiding duplicate processing; the other is a deletion lock, indicating that post-voting cleanup is allowed, ensuring that data cleanup is performed only after all voting work is completed, preventing data races. This dual guarantee mechanism of two dictionary locks solves the problem of voting consistency in high-concurrency environments and improves voting efficiency. The specific execution process is as follows: First, whenever a request message copy arrives, the server-side security gateway checks whether the number of request message copies under the X-Mimic-Request-ID group in Redis has reached the total number of online execution bodies, thereby determining whether the voting is ready.

[0063] Second, once the voting is ready, the server-side security gateway acquires the voting lock and uses the Redis SETNX command to attempt to set a key MimicVoteLock:{X-Mimic-Request-ID}. Only one worker process can successfully set this key, meaning only one process has the right to vote on this request group, fundamentally preventing duplicate voting.

[0064] Third, the process that acquires the voting lock retrieves copies of all request messages in the group from Redis and votes on the request line, request header, and request body in sequence.

[0065] Fourth, after the vote is passed, a copy of a normal request message is randomly selected and sent to the actual second backend server.

[0066] Fifth, the server-side security gateway performs response caching and distribution. It first stores the response returned by the second server in `MimicResp:{X-Mimic-Request-ID}`. Then, when each execution entity retrieves the response through the server-side security gateway, the gateway retrieves the response from Redis and returns it to each execution entity. This ensures that all normal execution entities receive consistent response data.

[0067] Sixth, the last executor to receive a response is responsible for triggering the cleanup process. The server-side security gateway acquires the deletion lock, and the worker process uses the Redis SETNX command to attempt to set a key MimicDeleteLock:{X-Mimic-Request-ID}, and then performs cleanup processing, deleting the request and response data related to the X-Mimic-Request-ID in Redis.

[0068] Finally, unlock the voting right lock and the delete right lock.

[0069] Unlike traditional independent voting based on a single request-response cycle, this invention introduces for the first time a collaborative proactive defense mechanism between client-side and server-side security gateways, enhancing the system's ability to combat complex and persistent attacks. The cross-faceted collaborative defense is implemented jointly by the collaborative control bus component and the attack fingerprint management module.

[0070] The collaborative control bus serves as the communication foundation connecting the two attack fingerprint management modules in the client security gateway and the server security gateway. This bus is implemented based on the high-performance, low-latency message middleware Redis Pub / Sub mechanism and is responsible for transmitting security information between the two attack fingerprint management modules in real time and reliably.

[0071] The first and second attack fingerprint management modules are built into the client security gateway and the server security gateway, respectively. They primarily perform three functions: 1) Attack signature extraction: When the proxy plane detects an abnormal execution body during the voting process, it extracts key features from the abnormal request or response to generate an attack fingerprint. 2) Attack fingerprint storage: The generated attack fingerprints are written to an "attack fingerprint database" and an expiration time is set (e.g., 1 hour). 3) Attack fingerprint query: When processing traffic, the synchronized "attack fingerprint database" is queried to check if the current traffic matches a known attack fingerprint.

[0072] The attack fingerprint database is a Redis repository established in both the client-side and server-side security gateways. Its keys are attack characteristics, including but not limited to malicious domains, malicious URLs, malicious IPs, payload patterns, and attack vector classifications. The values ​​are structured data objects with core fields including fingerprint ID, generation time, validity period, attack type, the source of the attack fingerprint (client-side or server-side security gateway), and the abnormal executable from which it originated. Attack fingerprint synchronization and matching are illustrated in Figure 5.

[0073] The attack fingerprint generation and synchronization process is as follows: (1) Trigger fingerprint generation and feature extraction In the client security gateway, when its multi-way response voter determines that an execution body returns an abnormal response (e.g., containing malicious scripts, phishing links, etc.), the attack fingerprint generation process is started at the same time as triggering execution body cleaning. The extracted attack features include: the Location value of redirection to malicious domain in the response header, the malicious domain appearing in the response body, and specific malicious strings or script fragments appearing in the response body.

[0074] In the server-side security gateway, when its multi-way request voter determines that an executor has issued an abnormal request (e.g., a request header used for cache poisoning, an SQL injection payload, etc.), an attack fingerprint is also generated during the cleanup process. The extracted attack features include: malicious field values ​​in the request header, malicious payloads in the request parameters, and malicious patterns in the request path.

[0075] (2) The attack fingerprint generated by real-time fingerprint synchronization is published in real time through the collaborative control bus. The security gateway on the other side receives the fingerprint within a millisecond delay through a subscription mechanism and updates its local fingerprint cache.

[0076] After receiving the attack fingerprint synchronized from the other side, any security gateway can use it for pre-security checks of its own traffic. The active defense process based on attack fingerprint matching is as follows: (1) Pre-interception of the server-side security gateway When the server-side security gateway receives an attack fingerprint about "response pollution" from the client-side security gateway, it adds a related processing procedure: Before the multi-way request voting module formally votes on the request message copy, a "fingerprint matching check" step is added. This step checks whether the request message copy sent by all executors contains the malicious features recorded in the attack fingerprint. As long as the request message copy of any executor is found to match the attack features, the server-side security gateway can determine that the request is a malicious request and does not need to enter the voting process. The server-side security gateway will not only discard the request, but also immediately mark the executor as abnormal and trigger the second negative feedback communicator to send a cleaning instruction to the scheduler. This process can nip an attack in the 'request phase', prevent it from reaching the second server in the backend and causing cache pollution, and realize cross-face collaborative active defense from "response-side insight" to "request-side interception". The runtime sequence is shown in Figure 6.

[0077] (2)Pre-interception of the client security gateway After the client security gateway receives the attack fingerprints of "request injection" synchronized by the server security gateway, it adds relevant processing procedures: before the multi-path response voting module formally votes on the response message copies, it adds a "fingerprint matching check" step. This step checks whether the response message copies sent by all executors contain the malicious features recorded in the attack fingerprints. As long as it is found that the response message copy of any executor matches the attack feature, the client security gateway can determine that the response is a malicious response and does not need to enter the voting process. The client security gateway will not only discard the response, but also immediately mark the executor as abnormal and trigger the first negative feedback communicator to send a cleaning instruction to the scheduler. The client security gateway can impose stricter checks (such as deep scanning of the response content) on the responses from the corresponding historical abnormal executors in its multi-path response voting module, so as to discover potential subsequent attacks caused by previous request injection in advance. This cross-plane collaborative active defense mechanism advances the defense timing from "detection after the attack takes effect" to "interception before the attack occurs", greatly shortening the attack window. It breaks the independent adjudication between the client and server security gateways and realizes the real-time sharing and linkage of two-way security threat intelligence. It forms a horizontally collaborative defense system that can effectively cope with modern complex and multi-stage collaborative network attacks and significantly enhances the overall security capabilities of the system. The running time sequence is shown in Figure 7.

[0078] The present invention first creates a cross-plane collaborative active defense mechanism. Based on a two-way architecture, it first creates a cross-plane collaborative mechanism based on a collaborative control bus and an attack fingerprint manager. This mechanism allows the security gateway on either side to immediately generate attack fingerprints (such as malicious domain names, attack payload features, etc.) after detecting an attack and synchronize them to the security gateway on the other side. The security gateway on the other side can use this fingerprint to perform real-time pre-interception before the voting in the attack chain, realizing the active defense against cross-request and cross-traffic direction collaborative attacks.

[0079] The system of the present invention is transparent to both the client and the server, and no existing business code needs to be modified; aiming at the requirements of high concurrency and low latency of the reverse proxy, key technical points are designed including: a cache mechanism based on Redis and a voting trigger mechanism based on distributed locks to solve the problem of voting consistency under high concurrency; ensuring that the system can still work stably and correctly in the case of large request traffic and uneven executor performance. The difference from the traditional mimic security defense architecture is that the present invention does not simply apply the dynamic heterogeneous redundancy architecture to the reverse proxy, but reconstructs and deepens the mimic security defense architecture for the unique challenges of the two-way business flow, middleware characteristics, high-performance requirements, and collaborative active defense of the reverse proxy, and solves the applicability problem of the general dynamic heterogeneous redundancy architecture in the reverse proxy scenario.

[0080] Under normal circumstances without attacks, the security defense method of this invention is applied to a client, a first server, and a second server. The first server includes a client security gateway, a server security gateway, several heterogeneous executors, and a scheduler. The method includes the following steps: The client security gateway receives a client request message, which includes a request line, a request header, and a request body; it generates a copy of the request message based on the number of executors in the online executor list and synchronously distributes it to the corresponding executor, where the copy includes a request line, a request header, a request body, a request ID, and an executor identifier; the executor receives the corresponding copy of the request message, processes it, and forwards it to the server security gateway; the server security gateway receives and caches all copy of the request messages from online executors, queries the attack fingerprint database, and checks if the current copy of the request message belonging to the same request ID is... If a match is found with a known attack fingerprint, the request line, headers, and body are voted on sequentially. If the vote is successful, a copy of the request message is randomly selected and sent to the second server. The server receives the response from the second server and generates a response message, which includes a response line, headers, and body. Copies of the response message are copied and synchronously distributed to the corresponding execution entities. Each copy of the response message includes a response line, headers, body, request ID, and execution entity identifier. The execution entity receives the corresponding copy of the response message, processes it, and forwards it to the client security gateway. The client security gateway receives and caches the response message copies of all online execution entities, queries the attack fingerprint database, and checks whether the current response message copy matches a known attack fingerprint. If a match is found, the response line, headers, and body are voted on sequentially. If the vote is successful, a copy of the response message is randomly selected and sent to the client.

[0081] In the event of an anomaly such as a request attack, the security defense method of this invention is applied to a client, a first server, and a second server. The first server includes a client security gateway, a server security gateway, several heterogeneous executors, and a scheduler. The method includes the following steps: the client security gateway receives a client request message, which includes a request line, a request header, and a request body; copies of the request message are generated according to the number of executors in the online executor list and synchronously distributed to the corresponding executors one by one; the request message copy includes a request line, a request header, a request body, a request ID, and an executor identifier; the executor receives the corresponding request message copy, processes it, and forwards the request message copy to... The server-side security gateway receives and caches copies of request messages from all online executors. It queries the attack fingerprint database and checks if copies of current request messages with the same request ID match known attack fingerprints. If a match is not found, it sequentially votes on the request line, request header, and request body. If a voting anomaly occurs, the corresponding abnormal executor identifier is transmitted to the scheduler, and the anomaly result is returned to the client. Simultaneously, it extracts attack features from the abnormal request message copy, generates an attack fingerprint, stores it in the attack fingerprint database, and synchronizes the attack fingerprint to the client's security gateway's attack fingerprint database. The scheduler dynamically manages executors and maintains a list of online executors, executing requests based on abnormal executor identifiers. The process involves cleaning up and removing abnormal executors from the online executor list, then rebuilding new executors and adding them to the list. The client security gateway receives client request messages again, which include a request line, request headers, and a request body. Based on the number of executors in the online executor list, it generates duplicate request message copies and synchronously distributes them to the corresponding executors. Each duplicate request message includes a request line, request headers, request body, request ID, and executor identifier. Each executor receives its corresponding duplicate request message, processes it, and forwards it to the server security gateway. The server security gateway receives and caches all duplicate request messages from online executors, queries the attack fingerprint database, and checks the current duplicate request message. If the request message matches a known attack fingerprint, and if not, the request line, headers, and body are voted on sequentially. If the vote is successful, a random copy of the request message is selected and sent to the second server. The second server's response is received, and a response message is generated, including a response line, headers, and body. Copies of the response message are copied and synchronously distributed to the corresponding executables. Each copy includes a response line, headers, body, request ID, and executable identifier. The client security gateway receives and caches copies of response messages from all online executables, queries the attack fingerprint database, and checks if the current response message copy matches a known attack fingerprint. If it matches, the response is intercepted, and an exception result is returned to the client.

[0082] In the event of an anomaly such as a response attack, the security defense method of the present invention is applied to a client, a first server, and a second server. The first server includes a client security gateway, a server security gateway, several heterogeneous executors, and a scheduler. The method includes the following steps: the client security gateway receives a client request message, which includes a request line, a request header, and a request body; copies of the request message are generated according to the number of executors in the online executor list and synchronously distributed to the corresponding executors one by one; the copy of the request message includes a request line, a request header, a request body, a request ID, and an executor identifier; the executors receive the corresponding copy of the request message, process it, and forward the copy of the request message to the server security gateway. The server-side security gateway receives and caches copies of request messages from all online executors. It queries the attack fingerprint database to check if copies of current request messages with the same request ID match known attack fingerprints. If a match is not found, it votes on the request line, headers, and body sequentially. If the voting is successful, it randomly selects a copy of the request message and sends it to the second server. It receives the response from the second server and generates a response message, including a response line, headers, and body. It copies the response message and synchronously distributes it to the corresponding executors. Each response message copy includes a response line, headers, body, request ID, and executor identifier. The executor receives the corresponding response message copy, processes it, and forwards it to the client. The security gateway on the client side receives and caches copies of response messages from all online executors, queries the attack fingerprint database, and checks whether the current response message copy matches a known attack fingerprint. If they do not match, the response line, response header, and response body are voted on sequentially. If a vote fails, the corresponding abnormal executor identifier is transmitted to the scheduler, and the exception result is returned to the client. Simultaneously, attack features are extracted from the abnormal response message copy, an attack fingerprint is generated, stored in the attack fingerprint database, and synchronized to the attack fingerprint database of the server-side security gateway. The scheduler dynamically manages executors and maintains a list of online executors. Based on the abnormal executor identifier, it performs self-cleaning, removing abnormal executors from the online executor list and reconstructing new ones. The executor is added to the online executor list; the client security gateway receives the client request message again, which includes a request line, request header, and request body; a copy of the request message is generated based on the number of executors in the online executor list and synchronously distributed to the corresponding executor; the copy of the request message includes a request line, request header, request body, request ID, and executor identifier; the executor receives the corresponding copy of the request message, processes it, and forwards it to the server security gateway; the server security gateway receives and caches the copy of the request message from all online executors, queries the attack fingerprint database, checks whether the current copy of the request message matches a known attack fingerprint, if it matches, it intercepts the request and returns an exception result to the client.

[0083] In one embodiment, an electronic device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the security defense method.

[0084] In one embodiment, a computer-readable storage medium stores computer instructions that are used to cause a processor to execute the security defense method.

[0085] In one embodiment, a computer program product is provided, the computer program product including a computer program that implements the security defense method when executed by a processor.

Claims

1. A security defense method, characterized in that, Applied to a first server comprising several heterogeneous executors, the method includes the following steps: the first server receives a request message, and generates multiple copies of the first request message according to the number of executors in the online executor list, each of the first request message copies being processed by the corresponding executor to obtain a corresponding second request message copy; The first server votes on all copies of the second request message from online executors. If the vote is abnormal, the executor that processed the abnormal copy of the second request message is determined to be an abnormal executor and removed from the list of online executors. If the vote is normal, any normal copy of the second request message is selected and sent to the second server. Receive a response message in response to the normal second request message copy, and generate multiple first response message copies according to the number of executors in the online executor list. Each first response message copy is processed by the corresponding executor to obtain the corresponding second response message copy. The first server votes on the second response message copies of all online executors. If the vote is abnormal, the executor that processed the abnormal second response message copy is determined to be an abnormal executor and removed from the list of online executors. If the vote is normal, any normal second response message copy is selected and sent to the client.

2. The security defense method according to claim 1, characterized in that, The first server's voting on the second request message copies of all online executors further includes: the first server querying the attack fingerprint database to check whether the current second request message copy matches a known attack fingerprint; if it matches, the request message is intercepted and an exception result is returned; if it does not match, the second request message copy is voted on, and if the vote is abnormal, attack features are extracted from the abnormal second request message copy, an attack fingerprint is generated, and stored in the attack fingerprint database, wherein the attack fingerprint has a lifespan time. The first server's voting on the second response message copies of all online executors further includes: the first server querying the attack fingerprint database to check whether the current second response message copy matches a known attack fingerprint; if it matches, the response message is intercepted and an exception result is returned; if it does not match, the second response message copy is voted on, and if the vote is abnormal, attack features are extracted from the abnormal second response message copy, an attack fingerprint is generated, and stored in the attack fingerprint database, wherein the attack fingerprint has a lifespan time.

3. The security defense method according to claim 1, characterized in that, The second response message copy includes a response line, a response header, and a response body. The first server uses either consensus voting or majority voting on all second response message copies at three voting levels: response line, response header, and response body. Consistency voting means that if there is inconsistency at any voting level, all second response message copies are considered abnormal and an abnormal result is returned. If all voting levels are consistent, all second response message copies are considered normal. Majority voting means that if a second response message copy corresponding to an execution entity is inconsistent with the majority of other execution entities at any voting level, the second response message copy is considered abnormal, the corresponding execution entity is considered abnormal, and the second response message copies of the remaining majority of execution entities are considered normal. If all copies of the second response message are inconsistent at any voting level, then all copies of the second response message are considered to be voting abnormal, all execution bodies are abnormal execution bodies, and abnormal results are returned; if all copies of the second response message are consistent at all voting levels, then all copies of the second response message are considered to be voting normally.

4. The security defense method according to claim 1, characterized in that, The second request message copy includes a request line and a request header. The first server uses consistent voting or majority voting at two voting levels, the request line and the request header, for all second request message copies. Consistent voting means that if there is inconsistency at any voting level, all second request message copies are judged to be voting abnormally and an abnormal result is returned. If all voting levels are consistent, all second request message copies are judged to be voting normally. Majority voting means that if a copy of the second request message corresponding to an executor is inconsistent with the majority of other executors at any voting level, then the copy of the second request message is determined to be abnormal, the corresponding executor is an abnormal executor, and the copies of the second request messages of the majority of other executors are normal. If all copies of the second request message are inconsistent at any voting level, then all copies of the second request message are considered to be voting abnormal, all execution bodies are abnormal execution bodies, and an abnormal result is returned; if all copies of the second request message are consistent at all voting levels, then all copies of the second request message are considered to be voting normally.

5. The security defense method according to claim 4, characterized in that, The second request message copy also includes a request body. The first server uses consensus voting or majority voting at three voting levels—request line, request header, and request body—for all second request message copies.

6. The security defense method according to claim 1, characterized in that, The first server performs a unique vote on all copies of the second request message belonging to the same request message. After the first response message copy is processed by the corresponding executor to obtain the corresponding second response message copy, all copies of the second request message and all copies of the first response message belonging to the same request message are deleted.

7. The security defense method according to claim 6, characterized in that, The process of the last second request message copy belonging to the same request message in the first server creates a voting lock. The voting lock is used by the process that created the voting lock to read all second request message copies belonging to the same request message and perform a unique vote. When the last first response message copy belonging to the same request message is processed by the corresponding executor to obtain the corresponding second response message copy, the process of the last first response message copy creates a deletion lock. The deletion lock is used by the process that created the deletion lock to read all second request message copies and all first response message copies and delete them.

8. The security defense method according to claim 1, characterized in that, The first server includes a client security gateway, a server security gateway, several heterogeneous executors and a scheduler. The client security gateway receives request messages, generates multiple copies of the first request message according to the number of executors in the online executor list, and synchronously distributes them to the corresponding executors. The executor processes the first request message copy, obtains the second request message copy, and forwards it to the server security gateway; The server-side security gateway votes on the second request message copies of all online executors. If the vote is abnormal, the executor that processed the abnormal second request message copy is determined to be an abnormal executor, and the corresponding abnormal executor identifier is transmitted to the scheduler. If the vote is normal, any normal second request message copy is selected and sent to the second server. Receive a response message in response to the normal second request message copy, generate multiple copies of the first response message according to the number of executors in the online executor list, and synchronously distribute them to the corresponding executors one by one; The executor processes the first response message copy, obtains the second response message copy, and forwards it to the client security gateway; The client security gateway votes on the second response message copies of all online executors. If the vote is abnormal, the executor that processed the abnormal second response message copy is determined to be an abnormal executor, and the corresponding abnormal executor identifier is transmitted to the scheduler. If the vote is normal, any normal second response message copy is selected and sent to the client. The scheduler dynamically manages executors and maintains an online executor list. Based on the abnormal executor identifier, the abnormal executor is removed from the online executor list, and a new executor is reconstructed and added to the online executor list.

9. The security defense method according to claim 8, characterized in that, The client security gateway configures and queries the attack fingerprint database, checks whether the current second response message copy matches a known attack fingerprint. If it matches, it intercepts the response message and returns an abnormal result to the client. If it does not match, it votes on the second response message copy. If the vote is abnormal, it extracts attack features from the abnormal second response message copy, generates an attack fingerprint, stores it in the attack fingerprint database, and synchronizes the attack fingerprint to the attack fingerprint database of the server security gateway. The server-side security gateway configures and queries the attack fingerprint database, checks whether the current second request message copy matches a known attack fingerprint, and if it matches, it intercepts the request message and returns an abnormal result to the client. If there is no match, the second request message copy is voted on. If the vote is abnormal, the attack features are extracted from the abnormal second request message copy, an attack fingerprint is generated, stored in the attack fingerprint database, and the attack fingerprint is synchronized to the attack fingerprint database of the client security gateway.

10. An electronic device, characterized in that, The electronic device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the security defense method according to any one of claims 1-9.

11. A security defense system, characterized in that, It includes a client, a first server, and a second server. The first server includes a client security gateway, a server security gateway, several heterogeneous executors, and a scheduler. The client security gateway is used to receive request messages, generate multiple copies of the first request message according to the number of executors in the online executor list, and synchronously distribute them to the corresponding executors. A vote is taken on the second response message copies of all online executors. If the vote is abnormal, the executor that handled the abnormal second response message copy is determined to be an abnormal executor, and the corresponding abnormal executor identifier is transmitted to the scheduler. If the vote is normal, any normal second response message copy is selected and sent to the client. The executor is used to process the first request message copy, obtain the second request message copy, and forward it to the server security gateway; Process the copy of the first response message to obtain the copy of the second response message and forward it to the client's security gateway; The server-side security gateway is used to vote on the second request message copies of all online executors. If the vote is abnormal, the executor that handles the abnormal second request message copy is determined to be an abnormal executor, and the corresponding abnormal executor identifier is transmitted to the scheduler. If the vote is normal, any normal second request message copy is selected and sent to the second server. The system receives a response message in response to the normal second request message copy, generates multiple first response message copies based on the number of execution entities in the online execution entity list, and synchronously distributes them to the corresponding execution entities. The scheduler dynamically manages the execution entities and maintains the online execution entity list. Based on the abnormal execution entity identifier, it removes abnormal execution entities from the online execution entity list and reconstructs new execution entities to add to the online execution entity list.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that are used to cause a processor to execute the security defense method according to any one of claims 1-9.

13. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the security defense method according to any one of claims 1-9.

Images