A parallel detection and voting system and method for heterogeneous WAFs

Abstract

The application discloses a parallel detection and voting system and method of heterogeneous WAFs, and relates to the technical field of network security detection. The system comprises a transparent TLS offload engine, which is connected in series on a main link between a network firewall and a switch, and is used for performing TLS offload on encrypted traffic; a centralized scheduling platform, which is used for maintaining effective WAF detection nodes in a heterogeneous WAF detection resource pool and issuing scheduling rules; and a heterogeneous WAF detection resource pool, which is deployed on a bypass and comprises a plurality of heterogeneous WAF detection nodes. The transparent TLS offload engine selects at least two heterogeneous WAF detection nodes according to the scheduling rules, distributes the same plaintext HTTP request to the selected nodes in parallel, performs voting according to a configurable voting logic after collecting all security detection results to obtain a final action, and executes release or blocking on a transmission connection according to the final action. The application realizes decoupling of TLS offload and security detection, supports elastic expansion of the detection layer, and improves detection reliability through parallel voting.

Description

Technical Field

[0001] This invention relates to the field of network security detection technology, and in particular to a parallel detection and voting system and method for heterogeneous WAFs. Background Technology

[0002] In existing network topologies, when transparently accessing a Web Application Firewall (WAF) and inspecting Hypertext Transfer Protocol Secure (HTTPS) traffic, a transparent proxy model is traditionally used. The WAF leverages techniques such as transparent proxy to transparently intercept link traffic to user space, completing Transmission Control Protocol termination, TLS offloading, and HTTP proxying, thereby performing security inspections on the obtained plaintext HTTP traffic. For example... Figure 1 As shown, in this type of solution, the WAF is connected in series between the network firewall and the switch, and performs both TLS offloading and HTTP security detection on the same device.

[0003] The traditional approach described above has the following two main drawbacks.

[0004] First, both TLS offloading and HTTP security detection are resource-intensive operations. When the backbone traffic is high, a single device cannot withstand the dual load. Furthermore, due to the inherent topology constraints of transparent access, the device is difficult to scale horizontally, creating a performance bottleneck.

[0005] Secondly, in scenarios with strict security requirements, multiple vendors' WAFs need to be connected. If multiple WAFs are connected in series in a transparent manner, the complexity of network deployment and the number of failure points will be significantly increased. Furthermore, each device needs to independently perform a complete SSL / TLS offload operation, resulting in redundant waste of computing resources and increased deployment costs.

[0006] Third, existing solutions lack a mechanism for parallel collection and centralized voting of multiple detection results. On the one hand, in existing service chain solutions, each detection device processes requests sequentially, with each node independently deciding whether to allow or block. A blocking decision by any node terminates subsequent detection, making it impossible to obtain a complete set of judgments from multiple heterogeneous nodes. On the other hand, while existing homogeneous load balancing solutions can distribute requests to multiple devices, their purpose is to distribute the processing load rather than to obtain multiple independent detection judgments, lacking the function of comprehensively voting on the judgment results of each node. Furthermore, existing solutions also lack configurable voting logic semantics, making it impossible to flexibly configure judgment strategies according to different security levels and false alarm tolerance requirements.

[0007] Therefore, existing technologies urgently need a network security protection solution that can retain the topological advantages of transparent access in real-time forwarding scenarios that are transparently connected to the main network link, dynamically adjust the number of WAF detection nodes without changing the network topology or interrupting existing connections, be compatible with heterogeneous WAFs, and be able to collect detection results from multiple heterogeneous WAFs in parallel and perform configurable voting. Summary of the Invention

[0008] In view of the above-mentioned defects or deficiencies in the prior art, the present invention provides a parallel detection and voting system and method for heterogeneous WAF, which can solve the above-mentioned technical problems mentioned in the background art.

[0009] One aspect of the present invention provides a parallel detection and voting system for heterogeneous WAFs, comprising: a transparent TLS offloading engine, a centralized scheduling platform, and a heterogeneous WAF detection resource pool; the transparent TLS offloading engine is connected in series on the main link between the network firewall and the switch, and is used to receive encrypted traffic and perform TLS offloading on the encrypted traffic to obtain plaintext HTTP requests; the centralized scheduling platform is communicatively connected to the transparent TLS offloading engine and the heterogeneous WAF detection resource pool, and is used to maintain valid WAF detection nodes in the heterogeneous WAF detection resource pool and issue scheduling rules; the heterogeneous WAF detection resource pool is deployed on a bypass outside the main link and does not receive any encrypted traffic, and is communicatively connected to the transparent TLS offloading engine and the centralized scheduling platform through an internal network, and includes multiple heterogeneous WAF detection nodes registered on the centralized scheduling platform; The heterogeneous WAF detection node is configured to, in response to the selection operation of the transparent TLS offloading engine based on the scheduling rules, perform security detection on the received plaintext HTTP request and return the security detection result to the transparent TLS offloading engine; wherein, the transparent TLS offloading engine is configured to: select at least two heterogeneous WAF detection nodes from the heterogeneous WAF detection resource pool according to the scheduling rules issued by the centralized scheduling platform; distribute the plaintext HTTP request in parallel to the selected at least two heterogeneous WAF detection nodes; receive the security detection results returned by the selected at least two heterogeneous WAF detection nodes respectively; after receiving all security detection results, vote on each security detection result according to the voting logic configured in the scheduling rules to obtain the final action, and perform allow or block the transmission connection to which the encrypted traffic corresponding to the plaintext HTTP request belongs based on the final action.

[0010] Furthermore, the transparent TLS offloading engine also includes a timeout degradation module: This timeout degradation module is configured to, if it fails to collect all security detection results within a preset timeout period, determine whether a final conclusion can be reached based on the current voting logic and the received security detection results; if a final conclusion can be reached, the final action is directly determined; if a final conclusion cannot be reached, it determines whether the current system mode is availability-first or security-first; in availability-first mode, unreturned security detection results are considered allowed; in security-first mode, unreturned security detection results are considered blocked; and the processed security detection results are voted on according to the voting logic to obtain the final action.

[0011] Furthermore, the voting logic includes: if at least one security detection result is an interception, the final action is interception; otherwise, it is permission; the final action is interception only if all security detection results are interceptions; otherwise, it is permission; the security detection result of a specified WAF detection node is taken as the final action; or, each security detection result carries a confidence score, and the confidence scores are weighted and summed according to the weight of each security detection node. When the weighted sum is less than a preset threshold, it is determined to be permission; otherwise, it is interception.

[0012] Furthermore, the centralized scheduling platform is also used for: receiving registration requests sent by each heterogeneous WAF detection node after startup, wherein the registration request includes detection capabilities, communication protocols, and processing capacity; establishing heartbeat health monitoring for each registered heterogeneous WAF detection node and maintaining the status of each heterogeneous WAF detection node; when a new heterogeneous WAF detection node is detected to have successfully registered, updating the current scheduling rules and sending the updated scheduling rules to the transparent TLS offloading engine; wherein the updated scheduling rules include node selection rules for including the new heterogeneous WAF detection node in the parallel distribution range of subsequent plaintext HTTP requests; when the heartbeat health monitoring of a registered heterogeneous WAF detection node fails continuously or a shutdown instruction for the heterogeneous WAF detection node is received, removing the heterogeneous WAF detection node from the heterogeneous WAF detection resource pool, updating the current scheduling rules, and sending the updated scheduling rules to the transparent TLS offloading engine; wherein the updated scheduling rules include node selection rules for stopping the distribution of new plaintext HTTP requests to the removed heterogeneous WAF detection node.

[0013] Furthermore, the scheduling rules include: node selection rules for determining the heterogeneous WAF detection nodes corresponding to each plaintext HTTP request; voting logic rules for determining the final action determination method; and anomaly determination rules for determining the security detection result determination method when receiving an anomaly.

[0014] Furthermore, the transparent TLS offloading engine is further configured to: generate a unique request identifier for the plaintext HTTP request; distribute the plaintext HTTP request with the unique request identifier in parallel, and receive the security detection results corresponding to the plaintext HTTP request with the unique request identifier returned by the heterogeneous WAF detection node; match each security detection result with the corresponding plaintext HTTP request according to the unique request identifier, and maintain the correspondence between the plaintext HTTP request and the transmission connection to which the corresponding encrypted traffic belongs.

[0015] Furthermore, the transparent TLS offloading engine communicates with each heterogeneous WAF detection node through a unified protocol. The unified protocol defines a standardized judgment semantic format. The heterogeneous WAF detection nodes map their respective security detection results to the judgment semantic format specified by the unified protocol and then return them to the transparent TLS offloading engine.

[0016] Another aspect of the present invention provides a parallel detection and voting method for heterogeneous WAFs for a transparent TLS offloading engine, comprising the following steps: receiving encrypted traffic on the main link between the network firewall and the switch, and performing TLS offloading on the encrypted traffic to obtain a plaintext HTTP request; selecting at least two heterogeneous WAF detection nodes from a heterogeneous WAF detection resource pool registered on the centralized scheduling platform according to scheduling rules issued by the centralized scheduling platform; wherein the heterogeneous WAF detection resource pool is deployed on a bypass outside the main link and does not receive any encrypted traffic; distributing the plaintext HTTP request in parallel to the selected at least two heterogeneous WAF detection nodes, and receiving security detection results of the plaintext HTTP request returned by the selected at least two heterogeneous WAF detection nodes, and voting on each security detection result according to the voting logic configured in the scheduling rules after receiving all security detection results to obtain a final action for the plaintext HTTP request; and, based on the final action, allowing or blocking the transmission connection to which the encrypted traffic corresponding to the plaintext HTTP request belongs.

[0017] Furthermore, it also includes: when all security detection results are not collected within a preset timeout period, determining whether a final conclusion can be reached based on the current voting logic and the received security detection results; if a final conclusion can be reached, directly determining the final action; if a final conclusion cannot be reached, determining whether the current system mode is availability-first mode or security-first mode; in availability-first mode, unreturned security detection results are considered as allowed; in security-first mode, unreturned security detection results are considered as blocked; and voting on all processed security detection results according to the aforementioned voting logic to obtain the final action.

[0018] Furthermore, it also includes: generating a unique request identifier for the plaintext HTTP request; distributing the plaintext HTTP requests with the unique request identifier in parallel, and receiving the security detection results corresponding to the plaintext HTTP requests with the unique request identifier returned by the heterogeneous WAF detection nodes; matching each security detection result with the corresponding plaintext HTTP request according to the unique request identifier, and maintaining the correspondence between the plaintext HTTP request and the transmission connection to which the corresponding encrypted traffic belongs.

[0019] The parallel detection and voting system and method for heterogeneous WAFs provided by this invention have the following beneficial effects: (1) Separate TLS offloading and security detection physically and functionally. The offloading engine focuses on TLS offloading and proxy forwarding, while security detection is handled by an independent detection resource pool, avoiding a single device from undertaking two types of resource-intensive operations at the same time. In high-traffic scenarios, the offloading and detection capabilities can be expanded independently as needed.

[0020] (2) The transparent TLS offloading engine is connected in a Layer 2 transparent manner on the main link between the network firewall and the switch. The detection resource pool is independently deployed on a bypass outside the main link and does not directly carry encrypted service traffic. WAF detection nodes can be added or removed online without changing the main link topology or interrupting existing connections, thus breaking through the inherent limitation of traditional transparent proxy WAF that cannot be horizontally expanded due to the topology constraint of being connected in series with the main link.

[0021] (3) The same plaintext HTTP request is sent to multiple heterogeneous WAF detection engines in parallel and then the results of multiple independent security detections are combined. Compared with a single WAF detection engine, the false negative rate can be effectively reduced, and the configurable voting logic can be used to adapt to different security levels and false positive tolerance requirements.

[0022] (4) Only one centralized TLS offload is performed across the entire link to avoid the waste of computing resources and accumulation of fault points caused by repeated SSL offload when multiple heterogeneous WAFs are connected in series.

[0023] (5) By associating a unique request identifier with a plaintext HTTP request, the equalization and timing synchronization of multiple security detection results are achieved; by setting a timeout window and performing degradation processing according to the voting strategy, it is ensured that the link is still available and the final decision can be determined when individual detection nodes are abnormal. Attached Figure Description

[0024] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1This is a schematic diagram of the network structure for deploying a traditional transparent proxy WAF in existing technologies; Figure 2 This is a logical architecture diagram of a parallel detection and voting system for a heterogeneous WAF provided in one embodiment of this application; Figure 3 This is a schematic diagram of the internal structure of a transparent TLS offloading engine provided in one embodiment of this application; Figure 4 This is a flowchart illustrating a parallel detection and voting method for a heterogeneous WAF provided in one embodiment of this application; Figure 5 This is a schematic diagram of a timeout degradation processing flow provided in one embodiment of this application; Figure 6 This is a logical schematic diagram of configurable voting provided in one embodiment of this application; Figure 7 This is a timing diagram of parallel heterogeneous detection and voting provided in one embodiment of this application.

[0025] Explanation of reference numerals in the attached figures: 100 - Network Firewall; 200 - Transparent TLS Offload Engine; 210 - TLS Offload Module; 220 - Scheduling Module; 230 - Voting Module; 240 - Connection State Management Module; 250 - Timeout Degradation Module; 300 - Switch; 400 - Centralized Scheduling Platform; 500 - Heterogeneous WAF Detection Resource Pool; 510 - First Heterogeneous WAF Detection Node; 520 - Second Heterogeneous WAF Detection Node; 530 - Third Heterogeneous WAF Detection Node. Detailed Implementation

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

[0027] I. Definition of Terms To facilitate understanding of the technical solutions of this invention, the following provides a unified definition of important technical terms involved in this invention: Transparent TLS Offload Engine: A network device or functional module connected in a transparent Layer 2 manner on the main link between the network firewall and the switch to perform transport layer security protocol offload operations on the encrypted traffic, that is, to decrypt the encrypted traffic to obtain plaintext HTTP requests.

[0028] Centralized scheduling platform: A control plane functional entity deployed independently of the transparent TLS offload engine. It communicates with the transparent TLS offload engine and the heterogeneous WAF detection resource pool to maintain information on valid WAF detection nodes in the heterogeneous WAF detection resource pool and to generate and distribute scheduling rules.

[0029] Heterogeneous WAF detection resource pool: A collection of detection resources deployed on a sideline outside the main link. It does not receive any encrypted traffic and communicates with the transparent TLS offloading engine and centralized scheduling platform through the internal network. It contains multiple heterogeneous WAF detection nodes that have been registered on the centralized scheduling platform.

[0030] Heterogeneous WAF Detection Nodes: Web application firewall functional entities provided by different vendors. Each detection node differs in its detection engine implementation, detection rule base, and judgment logic. They are configured to respond to the selected operation of the transparent TLS offload engine based on scheduling rules, perform security checks on received plaintext HTTP requests, and return the security check results to the transparent TLS offload engine.

[0031] Scheduling rules: A set of configuration information generated by the centralized scheduling platform and distributed to the transparent TLS offloading engine, including but not limited to: node selection rules, used to determine the heterogeneous WAF detection node corresponding to each plaintext HTTP request; voting logic rules, used to determine the judgment method of the final action; and anomaly judgment rules, used to determine the judgment method of the security detection result when receiving an anomaly.

[0032] Voting logic: The mathematical rules or strategies for determining the final action are based on a comprehensive assessment of the security detection results returned by multiple heterogeneous WAF detection nodes.

[0033] Unified Protocol: The standardized interface protocol followed by the transparent TLS offloading engine for communication between itself and various heterogeneous WAF detection nodes. This protocol defines a standardized judgment semantic format. Each heterogeneous WAF detection node maps its own security detection results to the judgment semantic format specified by the unified protocol and then returns them to the transparent TLS offloading engine.

[0034] Request Identifier: A globally unique identifier generated by the transparent TLS offload engine for each plaintext HTTP request.

[0035] Timeout Degradation Module: A component module within the transparent TLS offloading engine, configured to perform degradation processing based on the current voting logic and the received security test results to obtain the final action if all security test results are not collected within a preset timeout period.

[0036] Availability Priority Mode: A system operation mode in which, when a detection node times out or becomes disconnected, the security detection result that has not been returned is considered as allowed to proceed, with link availability as the priority goal.

[0037] Security Priority Mode: A system operating mode in which, when a detection node times out or becomes disconnected, the unreturned security detection result is considered as an interception, with security as the priority goal.

[0038] Main Link: The main data transmission channel between the network firewall and the switch. All traffic entering and leaving the protected network is transmitted through this link. The transparent TLS offload engine is connected in series on this link.

[0039] Bypass: An auxiliary data transmission channel relative to the main link. The heterogeneous WAF detection resource pool is deployed on the bypass and does not directly carry the encrypted traffic of the main link.

[0040] Example 1 like Figure 2 As shown, this embodiment provides a parallel detection and voting system for heterogeneous web application firewalls, including a transparent TLS offloading engine 200, a centralized scheduling platform 400, and a heterogeneous WAF detection resource pool 500 connected in series between a network firewall 100 and a switch 300.

[0041] A network firewall 100 is deployed at the network boundary to enforce network and transport layer-based access control policies on traffic entering and leaving the protected network. A switch 300 is deployed inside the protected network to forward traffic to the protected server. A transparent TLS offload engine 200 is connected in a Layer 2 transparent manner on the main link between the network firewall 100 and the switch 300 to offload encrypted HTTPS traffic to obtain plaintext HTTP requests.

[0042] The centralized scheduling platform 400 is a control plane functional entity deployed independently of the transparent TLS offload engine 200, and it communicates with both the transparent TLS offload engine 200 and the heterogeneous WAF detection resource pool 500. The centralized scheduling platform 400 receives registration requests from each heterogeneous WAF detection node, maintains information on valid WAF detection nodes in the heterogeneous WAF detection resource pool 500, generates scheduling rules, and distributes them to the transparent TLS offload engine 200. The scheduling rules include node selection rules, voting logic rules, and anomaly detection rules.

[0043] The heterogeneous WAF detection resource pool 500 is deployed on a bypass outside the main link, does not receive any encrypted traffic, and communicates with the transparent TLS offloading engine 200 and the centralized scheduling platform 400 through the internal network. The heterogeneous WAF detection resource pool 500 contains multiple heterogeneous WAF detection nodes already registered on the centralized scheduling platform 400, including the first heterogeneous WAF detection node 510, the second heterogeneous WAF detection node 520, and the third heterogeneous WAF detection node 530. Each heterogeneous WAF detection node is provided by a different vendor and differs in its detection engine implementation, detection rule base, and judgment logic, thus constituting a heterogeneous node.

[0044] The centralized scheduling platform 400 is also used to maintain the status of each detection node in the heterogeneous WAF detection resource pool 500 and to handle the registration and deactivation of detection nodes. The detailed process is as follows: After a new heterogeneous WAF detection node starts up, it completes its own initialization, including loading the detection rule base and establishing a unified protocol listening service. Once initialization is complete, the heterogeneous WAF detection node sends a registration request to the centralized scheduling platform (400). The registration request uses the registration message format defined by the unified protocol, including the detection node identifier, detection capability information, supported communication protocol types, processing capacity, and the detection node address. The detection node identifier is a globally unique identifier, and the detection capability information includes the detection rule set version, detection engine type, and supported HTTP protocol versions. The processing capacity is measured in the number of HTTP requests that can be processed per second.

[0045] Upon receiving a registration request, the centralized scheduling platform 400 verifies the identity and capabilities of the detection node, confirming that it is an authorized and legitimate WAF device that supports the detection interface and judgment semantic format specified in the unified protocol. If verification is successful, the centralized scheduling platform 400 assigns a node identifier to the detection node, includes it in the heterogeneous WAF detection resource pool 500, and records the relevant information in the node information table of the resource pool view. If verification fails, a registration failure response is returned, carrying a failure reason code.

[0046] The centralized scheduling platform 400 establishes heartbeat health monitoring for each registered detection node, sending heartbeat probe messages to each node at a fixed heartbeat interval H, typically 30 seconds. The heartbeat probe message includes a sending timestamp; upon receiving it, the detection node immediately returns a heartbeat response, including both a receiving and returning timestamp. The centralized scheduling platform 400 calculates the round-trip time based on the receiving and returning timestamps and updates the health status record. If no heartbeat response is received from a detection node in N consecutive heartbeat probes, the node is considered disconnected, where N is a preset threshold for consecutive failures, typically 3. The centralized scheduling platform 400 maintains the status information of each detection node, including registration status, health status, current processing load, most recent heartbeat time, and most recent round-trip time.

[0047] When the centralized scheduling platform 400 detects that a new detection node has successfully registered and completed verification, it triggers the scheduling rule update process. It reads the updated resource pool view, obtains information on all available detection nodes, regenerates the scheduling rules, includes the new node in the parallel distribution scope of subsequent plaintext HTTP requests, and distributes the updated complete scheduling rules to the transparent TLS offloading engine 200 through the configured distribution channel. Upon receiving the updated scheduling rules, the transparent TLS offloading engine 200 performs a rule hot-loading operation, applying the updated scheduling rules only to subsequently received requests. Requests already being processed continue to use the previous scheduling rules to ensure the consistency of detection and connection stability for existing requests.

[0048] When the centralized scheduling platform 400 detects consecutive failures in heartbeat health monitoring of a detection node or receives a shutdown command actively sent by the detection node, it removes the detection node from the resource pool. The shutdown command is actively sent by the detection node before normal shutdown to notify the centralized scheduling platform 400 to update the scheduling rules in advance. The centralized scheduling platform 400 deletes the node from the node information table in the resource pool view, regenerates the scheduling rules, stops distributing new plaintext HTTP requests to the removed node, and sends the updated scheduling rules to the transparent TLS offloading engine 200. The transparent TLS offloading engine 200 will no longer include the removed node in the selection scope for subsequent received requests. For existing requests from removed nodes that have not yet returned results, the timeout degradation module 250 will handle them according to the timeout degradation strategy.

[0049] The aforementioned registration and removal mechanism enables online elastic scaling of the detection resource pool. During expansion, the transparent TLS offload engine 200 maintains its deployment method connected to the main link, requiring no changes to the network topology and ensuring existing connections are not interrupted. During scaling down, faulty nodes or normally offline nodes can be quickly isolated, reducing the risk of fault propagation. The addition and removal of detection nodes are completely transparent to clients and protected servers. Therefore, this invention, while retaining the topological advantages of transparent access, overcomes the inherent limitation of traditional transparent proxy WAFs, which cannot be horizontally scaled due to topological constraints from being connected to the main link.

[0050] like Figure 3 As shown, the transparent TLS offload engine 200 includes the following internal components: TLS Offload Module 210: Used to perform TLS protocol offload operations on encrypted traffic. TLS Offload Module 210 receives encrypted traffic from network firewall 100, completes a TLS handshake with the client, decrypts the encrypted traffic to obtain a plaintext HTTP request; upon receiving a response from the protected server, it performs TLS re-encryption on the response traffic before sending it to the client. TLS Offload Module 210 itself does not perform any security checks on the plaintext HTTP request. TLS Offload Module 210 holds the private key of the server certificate, completes certificate verification and key negotiation during the TLS handshake with the client, and generates a session key, which is used for symmetric decryption of subsequent encrypted traffic.

[0051] The scheduling module 220 is used to determine the detection subset corresponding to the plaintext HTTP request based on the scheduling rules issued by the centralized scheduling platform 400, and to distribute the same plaintext HTTP request in parallel to the selected heterogeneous WAF detection nodes via a unified protocol. The unified protocol is the application layer communication protocol between the transparent TLS offloading engine 200 and the heterogeneous WAF detection nodes, and can be carried on top of HTTP, TCP, or TLS protocols. The unified protocol message includes a protocol header and a protocol data portion. The protocol header contains fields such as message type and request identifier, and the message type includes at least a detection request and a detection response. The data portion of the detection request message contains the plaintext HTTP request, and the data portion of the detection response message contains an action field and a confidence field. Through the above format constraints, each heterogeneous WAF detection node exposes a consistent detection interface and judgment semantic format, enabling the transparent TLS offloading engine 200 to drive multiple heterogeneous WAFs to perform detection in a unified calling method, without needing to adapt different communication interfaces for different vendors, thus providing a semantically unified input for the voting module 230. The scheduling module 220 is also used to parse the node selection rules in the scheduling rules, and select at least two heterogeneous WAF detection nodes from the heterogeneous WAF detection resource pool 500 according to the classification conditions of the plaintext HTTP request. The classification conditions include, but are not limited to: source Internet Protocol address, destination Internet Protocol address, Uniform Resource Locator (URL) category, host field, destination port number, and Internet Protocol address reputation rating.

[0052] Voting module 230: This module integrates multiple security detection results according to the configurable voting logic configured in the scheduling rules to obtain the final action for the plaintext HTTP request. Voting module 230 takes the entire set of security detection results as input and calculates the final action based on the voting logic rules.

[0053] Connection state management module 240: Maintains the correspondence between plaintext HTTP requests and their respective transport connections, as well as the association between plaintext HTTP requests and the security detection results returned by each heterogeneous WAF detection node. Connection state management module 240 maintains a request context for each plaintext HTTP request, which includes at least: a request identifier, a transport connection identifier, a list of received security detection results, and a reception status flag. Connection state management module 240 uses the request identifier to achieve alignment and timing synchronization between multiple security detection decisions and their respective requests.

[0054] Timeout Degradation Module 250: Used to perform degradation processing according to a voting strategy when individual heterogeneous WAF detection nodes time out or lose connection. The Timeout Degradation Module 250 is set with a preset timeout period T. If all security detection results are not collected within the timeout period T, the Timeout Degradation Module 250 determines whether a final conclusion can be reached based on the current voting logic and the received security detection results. If a final conclusion can be reached, the final action is directly determined; if a final conclusion cannot be reached, degradation processing is performed according to the current system mode.

[0055] The heterogeneous WAF detection nodes 510, 520, and 530 communicate with the transparent TLS offloading engine 200 via a unified protocol. This unified protocol abstracts the detection capabilities of each heterogeneous WAF, exposing a consistent detection interface and judgment semantics, thereby shielding vendor differences and achieving heterogeneous compatibility. The unified protocol supports multiple transport layer bearer methods, including but not limited to Layer 2 or Layer 3 methods, Internet Content Adapter (TCP) methods, and HTTP methods.

[0056] The modules described above in the transparent TLS offloading engine 200 can be implemented in the same physical device or distributed across different physical devices. In this embodiment, the modules are integrated into the same physical device to achieve the lowest possible forwarding latency. The transparent TLS offloading engine 200 is implemented as a dedicated hardware device. The TLS offloading module 210 uses a hardware acceleration card to perform TLS encryption and decryption operations, while the remaining modules are implemented by the central processing unit executing firmware programs.

[0057] This embodiment physically and functionally separates the TLS offloading module 210 from the security detection function, allowing the transparent TLS offloading engine 200 to handle only TLS offloading and traffic forwarding tasks, without simultaneously performing resource-intensive security detection operations on the same device. This eliminates the on-device performance bottleneck of traditional transparent proxy WAFs. Furthermore, since the transparent TLS offloading engine 200 maintains its Layer 2 transparent connection to the main link deployment method, while the detection resource pool 500 is deployed independently in the bypass, the detection layer can achieve elastic scaling without altering the network topology.

[0058] like Figure 4 As shown, this embodiment provides a parallel detection and voting method for a heterogeneous web application firewall applied to a transparent TLS offload engine 200, including the following steps: Step S101: Receive encrypted traffic at the transparent access point of the transparent TLS offloading engine and perform TLS offloading on the encrypted traffic to obtain a plaintext HTTP request.

[0059] The transparent TLS offload engine 200 is connected in series at Layer 2 transparently on the main link between the network firewall 100 and the switch 300, receiving encrypted HTTPS traffic from the network firewall 100. The TLS offload module 210 performs TLS protocol offload operations on the encrypted traffic.

[0060] The TLS protocol includes a handshake phase and a record phase. During the handshake phase, the TLS offload module 210 holds the digital certificate of the protected server and its corresponding private key. When the client initiates a TLS handshake request, the TLS offload module sends the server certificate to the client, completing certificate verification, key exchange, and handshake completion. During the handshake process, the TLS offload module 210 negotiates and generates a pre-master key with the client, and derives a session key based on the pre-master key. This session key is then used to symmetrically decrypt encrypted traffic to obtain a plaintext HTTP request. The TLS offload module (210) does not perform any security checks on this plaintext HTTP request.

[0061] Step S102: Determine the detection subset corresponding to the plaintext HTTP request based on the scheduling rules issued by the centralized scheduling platform.

[0062] The scheduling module 220 parses the node selection rules in the scheduling rules issued by the centralized scheduling platform 400. The scheduling module 220 extracts the classification features of the plaintext HTTP request, including but not limited to: source Internet Protocol address, destination Internet Protocol address, Uniform Resource Locator (URL) category, host field, destination port number, and Internet Protocol address reputation. The scheduling module 220 matches the classification features with the classification conditions in the node selection rules to determine the detection subset corresponding to the plaintext HTTP request. The detection subset includes at least two detection nodes registered on the centralized scheduling platform 400 and originating from a heterogeneous WAF. The selected detection nodes are in a parallel rather than serial relationship; that is, the same plaintext HTTP request is simultaneously distributed to all selected detection nodes.

[0063] Step S103: Send the same plaintext HTTP request in parallel to each detection node in the detection subset via a unified protocol.

[0064] The scheduling module 220 simultaneously and in parallel distributes the same plaintext HTTP request to each heterogeneous WAF detection node in the detection subset via a unified protocol. Let the number of heterogeneous WAF detection nodes in the detection subset be m (m≥2). The scheduling module 220 generates a unique request identifier for the current plaintext HTTP request and constructs m detection request messages. Each detection request message contains a unified protocol header and a message body. The unified protocol header contains fields such as request identifier, message type, and request length; the message body contains complete plaintext HTTP request data. The scheduling module 220 simultaneously sends the m detection request messages to the m heterogeneous WAF detection nodes through the internal network. Since there is no dependency between the heterogeneous WAF detection nodes, the processing delay of any heterogeneous WAF detection node does not affect the parallel processing of other detection nodes.

[0065] Step S104: Receive the security detection results returned by each detection node through the unified protocol, and perform equalization and timing synchronization of each security detection result based on the request identifier.

[0066] The scheduling module 220 receives security detection results returned by each heterogeneous WAF detection node in the detection subset via a unified protocol through the internal network. Each security detection result message contains a request identifier. The connection state management module 240 aggregates the asynchronously returned security detection results into the same request context based on the request identifier. The connection state management module 240 maintains a request context data structure for each plaintext HTTP request, including: request identifier, transmission connection identifier, expected total number of received results m, list of received results, reception status flag, and request distribution timestamp.

[0067] When the scheduling module 220 receives a security detection result, the connection state management module 240 extracts the request identifier, looks up the corresponding request context, adds the security detection result to the received list, and sets the received status flag of the corresponding detection node to "received". The connection state management module 240 also maintains the correspondence between plaintext HTTP requests and their respective transport connections, and establishes and maintains a mapping table between request identifiers and transport connection identifiers.

[0068] The connection status management module 240 continuously monitors whether all security detection results have been collected. If all results have been collected, the voting operation in step S105 is triggered; if not, it continues to wait. It then determines whether all security detection results have been collected within a preset timeout period T. If all results are collected within timeout period T, it proceeds to step S105; if timeout period T expires before all results are collected, it enters timeout degradation processing. The value of the preset timeout period T can be determined comprehensively based on the historical processing latency of the detection node, network latency, and the service's tolerance for latency.

[0069] See Figure 5When the preset timeout period T expires and there are detection nodes that have not returned security detection results, the timeout degradation module 250 executes the following timeout degradation process: First, determine whether a conclusion can be reached based on the current voting logic and the received security detection results. Specifically, if the voting logic is "interception occurs if any interception result exists" and at least one of the received security detection results has been determined to be an interception, then the final action is directly determined to be interception. If the voting logic is "interception only occurs if all interceptions are made" and at least one of the received results has been determined to be a release, then the final action is directly determined to be release.

[0070] Then, if the received security detection results are inconclusive and there are indeed missing results, the current system mode is read. The current system modes include availability-first mode and security-first mode. In availability-first mode, the system treats unreturned security detection results as allowed by default, ensuring that business traffic remains connected even when the main link detection node is abnormal, avoiding link congestion due to individual node failures. This mode is suitable for scenarios where business continuity requirements are higher than security detection completeness. In security-first mode, the system treats unreturned security detection results as blocked by default, preventing attack traffic from being mistakenly allowed due to missing detections. This mode is suitable for scenarios where security detection completeness requirements are higher than business continuity requirements. Through these two degradation modes, the system can determine the final action based on preset policies when a detection node times out or becomes unreachable, balancing the differentiated needs of link availability and security.

[0071] The processed security test results are substituted into the voting logic to obtain the final action and execute it, while recording the degradation event. The degradation event record includes: the identifier of the detection node that timed out or lost contact, the number of missing security test results, the degradation mode used, and the final voting result, and is sent to the centralized scheduling platform 400 for audit analysis and capacity expansion decisions.

[0072] Step S105: Combine the results of each security test according to the voting logic configured in the scheduling rules to obtain the final action.

[0073] Voting module 230 takes the complete set of security detection results as input and the voting logic configured in the scheduling rules as the calculation rules to calculate the final action. See also Figure 6 The configurable voting logic of this invention includes, but is not limited to, the following four strategies: (1) Any interception constitutes an interception policy. If there is at least one security detection result that is determined to be an interception, the final action is to intercept; otherwise, the final action is to allow passage. This policy is suitable for high-security scenarios with zero tolerance for false negatives.

[0074] (2) Block only if all security checks result in a block; otherwise, allow. This strategy is suitable for scenarios where reducing false alarms is the primary objective.

[0075] (3) Targeted Node Strategy. The security detection results of the specified heterogeneous WAF detection nodes are taken as the final action. This strategy is suitable for scenarios where a certain authoritative detection engine is the main one and the other engines are only used for side-by-side observation.

[0076] (4) Weighted confidence threshold strategy. Each security detection result carries a confidence score, and each detection node is configured with a weight. The confidence scores are weighted and summed according to the weight of each detection node to obtain a comprehensive confidence score. The comprehensive confidence score is compared with a preset threshold to determine the final action. If the comprehensive confidence score is greater than or equal to the preset threshold, the final action is to block; otherwise, it is to allow passage.

[0077] Because different vendors use different methods to express their internal detection results in heterogeneous WAFs—for example, some vendors use "pass" and "block," some use "allow" and "deny," and some use "normal" and "attack"—and because the confidence levels they use are inconsistent (e.g., some use a percentage system, and some use a graded system), these differences make it impossible to directly compare and synthesize the security detection results from different vendors' WAFs semantically, rendering the determination of the voting logic meaningless.

[0078] To address this issue, the unified protocol of this invention defines a standardized semantic format for decision-making in the protocol data section, namely, a normalized action field and a normalized confidence field. This requires all connected heterogeneous WAF detection nodes to map their internal detection conclusions and confidence metrics to this unified format when returning detection responses. Through the aforementioned format constraints at the protocol level, the security detection results returned by each heterogeneous WAF detection node have a unified semantic format, enabling the voting module 230 to perform comparable and comprehensive processing on the security detection results from heterogeneous nodes.

[0079] Step S106: Based on the final action, allow or block the transmission connection to which the encrypted traffic corresponding to the plaintext HTTP request belongs.

[0080] The transparent TLS offloading engine 200 performs operations based on the final action. If the final action is to allow, the plaintext HTTP request is forwarded to the switch 300 after being re-encrypted by the TLS offloading module 210 using TLS. If the final action is to block, the transmission connection of the encrypted traffic corresponding to the plaintext HTTP request is blocked, including sending TCP reset messages to both the client and server, discarding relevant data packets, or returning an HTTP error response.

[0081] In summary, unlike the existing serial service chain scheme in which each detection device is connected in series and makes independent decisions, in this invention, multiple heterogeneous WAF detection nodes receive the same request in parallel, and the voting module 230 of the transparent TLS offloading engine 200 makes a unified decision. The final action is determined by configurable voting logic, which significantly improves the accuracy and flexibility of voting.

[0082] Figure 7 The interaction sequence between the transparent TLS offloading engine 200 and three heterogeneous WAF detection nodes 510, 520, and 530 is shown. It fully demonstrates the complete data flow and decision-making process from the client initiating an HTTPS request, which is distributed in parallel to multiple heterogeneous detection nodes by the transparent TLS offloading engine, with each node independently returning security detection results, to the voting and comprehensive module summarizing and making a final decision and executing the final action.

[0083] like Figure 7 As shown, the client initiates an HTTPS request, which passes through the network firewall 100 to the transparent TLS offloading engine 200. The TLS offloading module 210 performs TLS offloading to obtain a plaintext HTTP request (sequence step ①). The scheduling module 220 determines the detection subset, including detection nodes 510, 520, and 530, according to the scheduling rules, generates a unique request identifier R_ID, and simultaneously distributes the same plaintext HTTP request to the three detection nodes in parallel (sequence step ②). The three detection nodes independently perform security checks: node A returns permission, node B returns interception, and node C returns permission (sequence step ③). Each detection result carries a unique request identifier, and the connection state management module 240 aggregates each result into the request context based on the unique request identifier. The connection state management module 240 detects that all three detection results have been collected and triggers the voting module 230. The voting logic is "any interception equals interception," and the overall result is interception (sequence step ④). The transparent TLS offloading engine 200 performs a blocking operation.

[0084] The above description is merely a preferred embodiment of the present invention. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to the specific combination of the above-described technical features, but should also cover other technical solutions formed by any combination of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

Claims

1. A parallel detection and voting system for a heterogeneous WAF, characterized in that, include: Transparent TLS offloading engine, centralized scheduling platform, and heterogeneous WAF detection resource pool; The transparent TLS offloading engine is connected in series on the main link between the network firewall and the switch, and is used to receive encrypted traffic and perform TLS offloading on the encrypted traffic to obtain plaintext HTTP requests. The centralized scheduling platform is communicatively connected to the transparent TLS offloading engine and the heterogeneous WAF detection resource pool, and is used to maintain the valid WAF detection nodes and issue scheduling rules in the heterogeneous WAF detection resource pool. The heterogeneous WAF detection resource pool is deployed on a bypass outside the main link and does not receive any encrypted traffic. It communicates with the transparent TLS offloading engine and the centralized scheduling platform through an internal network and contains multiple heterogeneous WAF detection nodes that have been registered on the centralized scheduling platform. The heterogeneous WAF detection node is configured to perform security checks on received plaintext HTTP requests in response to the selected operation of the transparent TLS offloading engine based on the scheduling rules, and return the security check results to the transparent TLS offloading engine. The transparent TLS offloading engine is configured to: select at least two heterogeneous WAF detection nodes from the heterogeneous WAF detection resource pool according to the scheduling rules issued by the centralized scheduling platform; distribute the plaintext HTTP request in parallel to the selected at least two heterogeneous WAF detection nodes; receive the security detection results returned by the selected at least two heterogeneous WAF detection nodes respectively; after receiving all the security detection results, vote on each security detection result according to the voting logic configured in the scheduling rules to obtain the final action; and, based on the final action, allow or block the transmission connection to which the encrypted traffic corresponding to the plaintext HTTP request belongs.

2. The parallel detection and voting system for a heterogeneous WAF according to claim 1, characterized in that, The transparent TLS offload engine also includes a timeout degradation module: The timeout degradation module is configured to determine whether a final conclusion can be reached based on the current voting logic and the received security detection results if all security detection results are not collected within a preset timeout period. If a final conclusion can be reached, then the final action can be determined directly. If a final conclusion cannot be reached, determine whether the current system mode is availability-first or security-first. In availability-first mode, security check results that are not returned are considered as allowed. In security-first mode, any security detection results that are not returned are considered as blocked. The final action is determined by voting on all processed security test results according to the voting logic described above.

3. The parallel detection and voting system for a heterogeneous WAF according to claim 1, characterized in that, The voting logic includes: if at least one security detection result is an interception, the final action is interception; otherwise, it is permission. The final action is interception only if all security detection results are interceptions; otherwise, it is permission. The security detection result of a specified WAF detection node is taken as the final action. Alternatively, each security detection result carries a confidence score, and the confidence scores are weighted and summed according to the weight of each security detection node. When the weighted sum is less than a preset threshold, it is determined to be permission; otherwise, it is interception.

4. The parallel detection and voting system for a heterogeneous WAF according to claim 1, characterized in that, The centralized scheduling platform is also used for: Receive registration requests sent by each heterogeneous WAF detection node after startup, the registration requests containing detection capabilities, communication protocols and processing capacity; Establish heartbeat health monitoring for each registered heterogeneous WAF detection node and maintain the status of each heterogeneous WAF detection node; When a new heterogeneous WAF detection node is successfully registered, the current scheduling rules are updated, and the updated scheduling rules are sent to the transparent TLS offloading engine. The updated scheduling rules include node selection rules that include the new heterogeneous WAF detection node in the parallel distribution range of subsequent plaintext HTTP requests. When a registered heterogeneous WAF detection node is detected to have failed heartbeat health monitoring consecutively or when a shutdown instruction is received for the heterogeneous WAF detection node, the heterogeneous WAF detection node is removed from the heterogeneous WAF detection resource pool, the current scheduling rules are updated, and the updated scheduling rules are sent to the transparent TLS offloading engine; wherein, the updated scheduling rules include node selection rules that stop distributing new plaintext HTTP requests to the removed heterogeneous WAF detection nodes.

5. The parallel detection and voting system for a heterogeneous WAF according to claim 1, characterized in that, The scheduling rules include: node selection rules, used to determine the heterogeneous WAF detection node corresponding to each plaintext HTTP request; voting logic rules, used to determine the judgment method of the final action; and anomaly judgment rules, used to determine the judgment method of the security detection result when receiving an anomaly.

6. The parallel detection and voting system for a heterogeneous WAF according to claim 1, characterized in that, The transparent TLS offload engine is further configured as follows: Generate a unique request identifier for the plaintext HTTP request; The plaintext HTTP request with the unique request identifier is distributed in parallel, and the security detection result corresponding to the plaintext HTTP request with the unique request identifier is returned by the heterogeneous WAF detection node. Based on the unique request identifier, each security detection result is matched with the corresponding plaintext HTTP request, and the correspondence between the plaintext HTTP request and the transmission connection to which the corresponding encrypted traffic belongs is maintained.

7. The parallel detection and voting system for a heterogeneous WAF according to claim 1, characterized in that: The transparent TLS offloading engine communicates with each heterogeneous WAF detection node through a unified protocol. The unified protocol defines a standardized judgment semantic format. The heterogeneous WAF detection nodes map their respective security detection results to the judgment semantic format specified by the unified protocol and then return them to the transparent TLS offloading engine.

8. A parallel detection and voting method for heterogeneous WAFs, used in a transparent TLS offloading engine, characterized in that, Includes the following steps: Encrypted traffic is received on the main link between the network firewall and the switch, and the encrypted traffic is TLS offloaded to obtain a plaintext HTTP request. According to the scheduling rules issued by the centralized scheduling platform, at least two heterogeneous WAF detection nodes are selected from the heterogeneous WAF detection resource pool that has been registered on the centralized scheduling platform; wherein, the heterogeneous WAF detection resource pool is deployed on a bypass outside the main link and does not receive any encrypted traffic; The plaintext HTTP request is distributed in parallel to at least two selected heterogeneous WAF detection nodes, and the security detection results of the plaintext HTTP request returned by the at least two selected heterogeneous WAF detection nodes are received. After all the security detection results are collected, each security detection result is voted on according to the voting logic configured in the scheduling rules to obtain the final action for the plaintext HTTP request. Based on the final action, the transmission connection to which the encrypted traffic corresponding to the plaintext HTTP request belongs is either allowed or blocked.

9. The parallel detection and voting method for a heterogeneous WAF according to claim 8, characterized in that, Also includes: If all security test results are not collected within the preset timeout period, a final conclusion will be determined based on the current voting logic and the security test results already received. If a final conclusion can be reached, then the final action can be determined directly. If a final conclusion cannot be reached, determine whether the current system mode is availability-first or security-first. In availability-first mode, security check results that are not returned are considered as allowed. In security-first mode, any security detection results that are not returned are considered as blocked. The final action is determined by voting on all processed security test results according to the voting logic described above.

10. The parallel detection and voting method for a heterogeneous WAF according to claim 8, characterized in that, Also includes: Generate a unique request identifier for the plaintext HTTP request; The plaintext HTTP request with the unique request identifier is distributed in parallel, and the security detection result corresponding to the plaintext HTTP request with the unique request identifier is returned by the heterogeneous WAF detection node. Based on the unique request identifier, each security detection result is matched with the corresponding plaintext HTTP request, and the correspondence between the plaintext HTTP request and the transmission connection to which the corresponding encrypted traffic belongs is maintained.

Images