Implementation method for high-speed tandem drainage backflow anomaly detection message blocking based on FPGA (Field Programmable Gate Array)

Abstract

The invention discloses an FPGA (Field Programmable Gate Array)-based high-speed tandem drainage backflow anomaly detection message blocking implementation method, which comprises the following steps of: receiving an original message, inputting the received original message into an FPGA, analyzing and extracting a protocol field, and selecting a corresponding drainage strategy according to the field to obtain a drainage message; if a corresponding strategy does not exist, checking a high-speed flow table outside the FPGA and updating data, after mirroring encapsulation is carried out on a message hitting a drainage strategy, inputting a processing strategy to carry out backflow and back-dyeing judgment, after success, de-encapsulating and outputting the backflow message, processing the back-dyeing message through a flow table, and storing the back-dyeing message into high-speed flow table expansion data; according to the scheme, a high-speed, efficient and real-time network security protection system is constructed by adopting a collaborative thought of drainage and backflow as well as mirroring and backdyeing, linear speed processing is accelerated by means of FPGA hardware, high-density integration is realized, the cost is low, network blocking attacks can be accurately detected, the blank is filled, and autonomous controllability of a network security core technology is promoted.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a method for implementing high-speed serial connection backflow anomaly detection message blocking based on FPGA. Background Art

[0002] Amidst the evolution of network technology, the rapid increase in interface speeds has always been a core driver of security system transformation. When interface speeds remained at 1G, 2.5G, 10G, and 40G, software solutions based on the x86 architecture dominated the market with their flexible adaptability. Leveraging the general computing power of the CPU, these solutions could rapidly respond to new attack signatures through code iteration, demonstrating significant portability and upgrade advantages in scenarios with limited traffic. However, inherent stability shortcomings persisted with software systems, with problems such as memory leaks and process crashes being difficult to eradicate. This led to over 90% of deployments in the industry opting for parallel or non-serial models. With the widespread adoption of 100G interfaces in backbone networks and the commercialization of 400G interfaces in supercomputing centers, performance bottlenecks in software architectures have been fully exposed. When traffic on a single interface exceeds 100G, the instruction cycles of x86 processors can no longer keep up with line-speed processing requirements. Even with multi-machine cluster load balancing, the low-latency forwarding characteristics required for serial deployments are impossible to achieve. Parallel deployments now face an even more challenging situation: First, traffic mirroring integrity cannot be guaranteed, as the sampling analysis techniques used by some vendors can miss 10%-15% of attack samples. Second, the transmission delay of blocking instructions is amplified by high-speed traffic. Tests in a laboratory simulating a 400G environment showed that the average time from attack traffic identification to blocking was 2.3 seconds, sufficient to leak terabytes of data. The key to solving this problem lies in building a hybrid architecture combining hardware acceleration and flexible programmability. From a reliability perspective, this requires a carrier-grade hardware platform as the foundation. Key forwarding logic is typically implemented in ASICs or FPGAs, with high-frequency operations like TCP handshake verification and DDoS signature matching pushed down to the hardware layer, achieving 99.999% uptime. Furthermore, the inclusion of FPGAs as a programmable middle layer preserves the wire-speed processing capabilities of hardware acceleration while enabling rapid response to new attack patterns through firmware updates. In terms of deployment model, the implementation of the cascade architecture requires overcoming three technical bottlenecks: first, adopting a dual-active redundant design with master-slave failover time under 50ms to ensure that single points of failure do not affect business continuity; second, developing an intelligent traffic scheduling chip to achieve microsecond-level traffic diversion at 400G line speeds to avoid overloading single computing points; and third, building a separate "hardware forwarding plane + software control plane" architecture to prevent abnormal fluctuations in the control plane from being transmitted to the forwarding plane. Test data from one manufacturer shows that this architecture achieved a forwarding performance degradation rate of less than 0.5% during a 72-hour 400G full-load stress test, far exceeding the 3% degradation threshold of software solutions.

[0003] In terms of cost and integration, this integrated hardware and software architecture, based on FPGA technology and centered around hardware architecture, employs a processing approach combining diversion and reflow, mirroring, and back-infection. This provides a high-speed, efficient, and real-time technical solution for effectively detecting, blocking, and controlling network attack traffic, harmful content, and illegal websites. While meeting design requirements, this solution achieves high-density integration and cost advantages, providing a practical and feasible technical solution for addressing these critical issues and filling a gap in the field. Summary of the Invention

[0004] To achieve the above objectives, the present invention adopts a technical solution: a method for implementing high-speed serial connection backflow anomaly detection and blocking based on FPGA, the method comprising: Receive the original message in the link and input it into the FPGA; Parse the message and extract the protocol field in the original message; Select the corresponding diversion strategy based on the protocol field to obtain the diversion message; if there is no corresponding diversion strategy, query and update the data of the high-speed flow table carried by the FPGA; If the diversion policy is matched, the diversion message is mirrored and encapsulated. The encapsulated diversion message is input into the diversion message processing policy, and the backflow and back-infection are judged. If the backflow and back-dyeing are judged to be successful, a backflow and back-dyeing message is obtained; The return flow and return staining message is distinguished and judged. If it is a return flow message, it is decapsulated to obtain the message and output it. When distinguishing and judging the return flow and return staining message, if it is a return staining message, it is processed in the return staining flow table and stored in the high-speed flow table, and the data of the high-speed flow table is expanded.

[0005] Furthermore, the backflow and back-contamination message is distinguished and judged, and if it is not a backflow message, the process ends.

[0006] Furthermore, if no traffic diversion strategy is matched, a corresponding blocking strategy is selected based on the protocol field; If the corresponding blocking policy is hit, the original message is discarded, and it is determined whether the discarded original message is diverted. If so, the discarded original message is encapsulated and diverted through the diversion message processing policy. The discarded original message carries the policy and information hit by the discarded original message.

[0007] Furthermore, if no blocking policy is matched, the original message is output to the link.

[0008] Furthermore, it is determined whether the discarded original message needs to be diverted. If not, the process ends.

[0009] Furthermore, the diversion strategy is at least one or more of a flow-based global diversion strategy, a feature message-based diversion strategy, a five-tuple mask rule-based diversion strategy, and a flexible five-tuple rule-based diversion strategy.

[0010] Furthermore, the mirroring strategy is at least one or more of a flow-based global mirroring strategy, a feature message-based mirroring strategy, a five-tuple mask rule-based mirroring strategy, and a flexible five-tuple rule-based mirroring strategy.

[0011] Furthermore, the blocking strategy is at least one or more of a blocking strategy based on a characteristic message, a blocking strategy based on a five-tuple mask rule, and a blocking strategy based on a flexible five-tuple rule.

[0012] Furthermore, when both the blocking strategy and the diversion strategy are determined to be valid, after the diversion message executes the blocking strategy, the diversion message carries the flag and strategy information of the hit blocking strategy when being diverted.

[0013] Furthermore, when receiving the diversion message, the diversion message processing strategy determines whether the diversion message is misjudged, and the misjudged message will flow back into the link.

[0014] Compared with existing technologies, this technical solution innovatively adopts the collaborative processing ideas of diversion and backflow, mirroring and back-infection, and builds a high-speed, efficient and real-time network security protection system that can accurately detect and promptly block network attack traffic, bad information and illegal website access. The traffic diversion mechanism uses multi-dimensional strategies to direct suspicious traffic to the backend detection module. The return flow mechanism ensures that normal traffic returns to the original link after processing, ensuring business continuity. Mirroring technology replicates and analyzes critical traffic, and the return flow mechanism dynamically updates the detection results to the flow table, enabling precise control of subsequent similar traffic. This solution leverages FPGA hardware acceleration to achieve line-rate processing speeds, enabling real-time response to millions of frames per second, meeting the demands of high-speed network environments. While maintaining high-density integration, it significantly reduces unit traffic processing costs through optimized hardware architecture and algorithms, offering significant cost advantages. This technology effectively addresses core issues such as real-time interception of cyberattacks and precise filtering of harmful information, providing a practical solution for protecting critical information infrastructure. Its innovative architecture and localized design fill a technological gap in high-speed network security protection and promote the independent and controllable development of core network security technologies. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 The figure is a flow chart of the method for implementing the high-speed serial connection backflow anomaly detection message blocking based on FPGA of the present invention.

[0016] Figure 2 This is a schematic diagram of the encapsulation structure of the diversion message and the return message of the present invention.

[0017] Figure 3 This is a schematic diagram of the mirror image message encapsulation structure of the present invention.

[0018] Figure 4 This is a schematic diagram of the back-dyeing message encapsulation structure of the present invention.

[0019] Figure 5 This is a schematic diagram of the backstaining message format of the present invention. DETAILED DESCRIPTION

[0020] The following, in conjunction with the accompanying drawings of the embodiments of the present invention, provides a clear and complete description of the technical solutions in the embodiments of the FPGA-based high-speed serial backflow anomaly detection and message blocking implementation method and system provided by the present invention. Obviously, the described embodiments are only a portion of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making any creative efforts are within the scope of protection of the present invention.

[0021] like Figure 1 As shown, a method for implementing high-speed serial connection backflow anomaly detection and blocking based on FPGA includes: Receive the original message in the link and input it into the FPGA.

[0022] Specifically, the input of the original message in the receiving link into the FPGA is the starting link of the entire process. The efficient and stable operation of this link directly affects the accuracy and real-time performance of subsequent anomaly detection and message blocking. The receiving link is usually composed of a physical layer interface, a data link layer processing module, and other parts. The original message is transmitted in the link in the form of a high-speed serial data stream, which contains rich network information such as source address, destination address, protocol type, data payload, etc. When the original message enters the receive link, it first undergoes signal conversion and recovery through the physical layer interface. This interface converts the externally transmitted analog electrical or optical signal into a digital signal recognizable by the FPGA. Clock and data recovery techniques are then used to synchronize the data with the clock, ensuring accurate data sampling at high transmission speeds. The synchronized digital signal is then fed into the data link layer processing module, which performs preliminary processing such as frame synchronization and CRC checks on the data, eliminating invalid frames caused by transmission errors and ensuring the integrity of the original message data entering the FPGA. The method comprises: parsing a message and extracting a protocol field in the original message.

[0023] Specifically, after the original message is successfully input into the FPGA, parsing the message and extracting the protocol fields is a key prerequisite for subsequent anomaly detection. This step aims to accurately extract the core information used to determine whether the message is abnormal from the massive amount of raw data, providing reliable data support for subsequent detection algorithms. The FPGA uses a parallel pipeline architecture to parse messages. This architecture fully utilizes the FPGA's hardware resources to achieve real-time parsing of high-speed messages. After the message data is read from the buffer, it first enters the frame header recognition module, which quickly locates the starting position of the frame header based on the characteristics of different network protocols.

[0024] After Ethernet frame parsing is complete, the data enters the network layer protocol parsing module. If the message contains the IP protocol, this module parses the IP header and extracts fields such as the source IP address, destination IP address, IP protocol version, lifetime, and protocol type. The source and destination IP addresses are key information for determining the source and destination of the message, while the protocol type field indicates the transport layer protocol used by the upper layer, providing guidance for the next step of transport layer parsing. Transport layer protocol analysis involves extracting fields such as the source port number, destination port number, sequence number, acknowledgment number, and control bits for TCP. For UDP, the primary focus is on the source and destination port numbers. This port number information can clearly identify the application or service to which the message corresponds, and combined with the IP address, can further determine the specific communication process. TCP's control bits, which reflect the connection's establishment, maintenance, and shutdown status, are crucial for detecting abnormal connections. During the parsing process, the FPGA also verifies fields such as the message length and checksum. If a message with a checksum error or abnormal length is found, it will be marked as invalid and discarded directly, preventing invalid data from occupying subsequent processing resources. At the same time, to cope with protocol nesting and complex message structures, the parsing module adopts configurable parsing rules that can flexibly adapt to the protocol types that may appear in the actual network environment. This ensures that even when encountering unknown or custom protocols, basic common fields such as addresses and ports can be extracted, ensuring the compatibility and scalability of the parsing process. Through the above parsing process, the FPGA can complete the extraction of protocol fields from a single-frame message in nanoseconds, integrating the key information scattered in the message into structured data. This data will be sent to the anomaly detection module for subsequent diversion and reflux status judgment and abnormal behavior analysis.

[0025] The method includes: selecting a corresponding diversion strategy according to a protocol field, and obtaining a diversion message; if there is no corresponding diversion strategy, querying and updating the data of a high-speed flow table carried out outside the FPGA.

[0026] Specifically, the link of selecting the corresponding diversion strategy based on the protocol field is the core of achieving high-speed serial diversion. Its efficiency directly determines the processing capacity of the entire anomaly detection and blocking system. The extracted protocol fields include key information such as the source IP address, destination IP address, source port number, destination port number, and protocol type. This information forms the basis for determining the packet diversion path. The FPGA pre-stores a series of preset diversion strategies based on factors such as network topology, security requirements, and service priorities. When the parsed protocol field fully matches the matching criteria of a preset diversion strategy, the FPGA immediately triggers the execution mechanism corresponding to the strategy, marking the original message as a diversion message and directing it to the preset diversion path through the internal high-speed data channel. During the marking process, specific identification information, such as the diversion channel number and priority tag, is added to the diversion message so that the subsequent backflow processing link can accurately identify it and perform the corresponding operation. At the same time, the FPGA monitors the transmission process of the diversion message in real time to ensure that it is not lost or misordered in the diversion path, thereby ensuring the reliability of the diversion.

[0027] If the parsed protocol field doesn't correspond to a pre-set traffic diversion strategy, the FPGA's high-speed flow table is needed for querying and updating data. The high-speed flow table is a dynamic data structure built on high-speed storage media such as SRAM or DDR4. It stores the mapping between active traffic characteristics and corresponding traffic diversion strategies in the current network, supporting millions of queries per second and perfectly adapting to the needs of high-speed message processing. The FPGA establishes a connection to an external high-speed flow table via a dedicated high-speed interface. When a query is needed, the extracted protocol fields are processed using a specific hash algorithm to generate a corresponding flow table index. Using this index, the FPGA can quickly locate a potentially matching entry in the high-speed flow table. If a matching flow entry is found, indicating a corresponding diversion policy exists, the packet is marked as a diversion message and diversion is performed according to that policy. Simultaneously, the flow entry's relevant data, such as the packet counter and last active time, is updated based on the packet's transmission status to reflect the latest traffic status. If no matching flow table entry is found in the high-speed flow table, it means that the traffic characteristics corresponding to the message appear for the first time or are not covered by the preset policy. At this time, the FPGA will insert the protocol field information of the message as a new flow table entry into the high-speed flow table according to the preset flow table update rules, and assign it a default diversion policy. When inserting new entries, replacement algorithms such as LRU will be used to manage the high-speed flow table. When the flow table storage space is insufficient, entries that have not been accessed for a long time will be automatically eliminated to ensure that the flow table always stores the most active traffic characteristics. At the same time, the newly inserted flow table entry will be marked as pending confirmation. Subsequently, through interaction with the controller, its diversion policy will be adjusted and optimized according to the actual network operation conditions, realizing dynamic update and adaptive management of high-speed flow table data. Through the aforementioned protocol field-based traffic diversion strategy selection and high-speed flow table query and update mechanism, the FPGA can achieve flexible and efficient traffic diversion for various types of messages. This not only ensures rapid processing under preset policies, but also adapts to changes in network traffic through dynamic flow tables, laying a solid foundation for subsequent anomaly detection and backflow processing.

[0028] Furthermore, the diversion strategy is at least one or more of a flow-based global diversion strategy, a feature message-based diversion strategy, a five-tuple mask rule-based diversion strategy, and a flexible five-tuple rule-based diversion strategy.

[0029] Specifically, the flow-based global traffic diversion strategy diverts the first N packets of each flow based on the flow table. This strategy has a separate control enable switch, and the value of N can be set by software. This strategy is used to divert the first N packets of all flows to the backend software for identification and judgment of services, attack detection, and other functions.

[0030] The flow-based global traffic diversion strategy uses the flow table as its core basis and focuses on performing traffic diversion processing on the first N packets of each flow in the network. This strategy plays an important role in the entire message processing process, accurately screening key data and providing support for in-depth background analysis. The flow table not only stores basic flow characteristics, such as the source IP address, destination IP address, source port number, destination port number, and protocol type, which uniquely identify each flow, but also records status information such as the number of packets currently processed for each flow. This information provides the data foundation for accurately identifying the "top N packets." After parsing a packet to extract the protocol fields, the FPGA determines the flow to which it belongs based on these fields and quickly queries the flow table for the corresponding processing status. The specific mechanism for diverting the first N packets of each flow is as follows: for a newly emerging flow, after its first packet arrives, the FPGA queries the flow table and finds that there is no processing record for this flow. It then marks it as a diverting message and creates an entry for this flow in the flow table, recording the number of diverted messages as 1. When the second packet of this flow arrives, if the number of diverted messages is less than N, it is marked as a diverting message again and the corresponding count in the flow table is updated. This process continues until the number of diverted messages for this flow reaches N. Subsequent messages will no longer be diverted and will be processed according to the normal forwarding path. This policy is equipped with a separate control enable switch, integrated within the FPGA as a hardware register. This switch can be turned on and off by writing specific instructions to the register via software. When the switch is on, the global traffic diversion policy takes effect, diverting the first N packets of all flows to the backend software. When the switch is off, the policy is suspended, and no additional traffic is diverted, regardless of the number of diverted packets recorded in the flow table. This design allows the policy to be flexibly enabled and disabled based on actual business needs, reducing unnecessary traffic diversion overhead when backend analysis is not required, and improving overall processing efficiency. The value of N can be configured through software. A dedicated configuration register within the FPGA stores the value of N, which can be read and written by software through the bus interface. The value of N typically ranges from 1 to several thousand, and the specific value can be adjusted based on the characteristics of the network traffic and the processing capabilities of the backend software. Furthermore, the setting of N is dynamic. During system operation, the software can modify the value of N in real time based on changes in network traffic and business analysis results, ensuring that the traffic diversion strategy is always optimized. The core function of this strategy is to direct the first N packets of all flows to the backend software, providing a critical data source for the backend software to perform functions such as business identification and attack detection. For business identification, the first few packets of a flow often contain key characteristics such as the service's protocol handshake information and application identification. By parsing these packets, the backend software can quickly determine the service type of the flow, such as video stream, file transfer stream, instant messaging stream, etc., providing a basis for subsequent differentiated processing and bandwidth allocation. In terms of attack detection, many network attack behaviors will exhibit abnormal characteristics in the initial stage of the flow. At the same time, by only directing the first N packets, the large amount of data transmission caused by directing the entire flow is avoided. While ensuring the information required for backend analysis, the use of network bandwidth and backend processing resources is minimized. The traffic diversion strategy based on signature packets uses a table lookup based on the packet's characteristics. For specific characteristics, the software can configure traffic diversion for packets matching these characteristics. Its core logic is to perform a table lookup based on the characteristics carried by the packet itself. For packets matching these characteristics, the software pre-sets rules to include them in the traffic diversion process. This strategy is highly targeted and flexible, accurately capturing packets with specific attributes on the network. The message features mentioned here cover a wide range of content. They can be specific values ​​in protocol fields, such as a source IP address of a specific network segment, a destination port number of a common service port such as 80 or 443, or an ICMP protocol type. They can also be specific character strings or feature codes in the data payload. These features are pre-organized and stored in a dedicated feature table. Similar to a high-speed flow table, the feature table also uses high-speed storage media to support FPGA rapid query of message features. Once the FPGA has parsed the message and extracted the relevant fields and content, it initiates a feature-based table lookup process. First, the FPGA extracts the corresponding signature information from the parsed message according to pre-set feature extraction rules. The FPGA then compares the extracted signature information with the entries in the signature table one by one. This comparison utilizes a parallel search algorithm, enabling a single-frame message to be matched against all entries in the signature table in a very short time. Software plays a key role in rule development and configuration within this strategy. Staff can flexibly configure the signature table through the software interface or programming interface. When traffic diversion is required for packets with a specific signature, the software writes the corresponding information into the signature table, associates a diversion tag with it, and sets the diversion path for packets matching that signature.

[0031] The software's feature table configuration not only includes adding new feature entries but also supports modifying and deleting existing entries. If the network environment changes and certain existing features are no longer needed, the software can quickly delete the corresponding feature table entries. If the traffic diversion strategy for a particular feature packet needs to be adjusted, such as changing the diversion path or canceling diversion, the software can directly modify the configuration information associated with that feature entry. This entire process does not interrupt the normal operation of the FPGA, ensuring real-time and convenient policy adjustments. Furthermore, to cope with complex and ever-changing network scenarios, the software supports feature combination settings, allowing you to logically combine multiple features to form more precise traffic diversion rules. Only when a message meets all the conditions in a combined feature is it considered a hit, triggering traffic diversion. This combination further improves the accuracy of the diversion strategy and effectively avoids misdirection. The advantage of a traffic diversion strategy based on signature packets is its ability to focus on packets of specific significance within the network. Through flexible software configuration, diversion targets can be adjusted at any time based on actual needs. This strategy can be used for both security detection and timely capture of potentially threatening packets, as well as business monitoring, analyzing traffic for specific service types, providing strong support for network management and optimization. Furthermore, by diverting only packets matching specific signatures, the amount of traffic diverted is significantly reduced, reducing the pressure on backend processing resources. This, in conjunction with the global flow-based traffic diversion strategy, creates a multi-layered, comprehensive traffic diversion system. The traffic diversion policy based on quintuple mask rules allows you to configure arbitrary mask rules for 5-tuple information and divert packets matching the mask rules. Focusing on the quintuple information of a packet, it can configure arbitrary mask rules to divert packets matching the rules, meeting diverse and refined traffic diversion needs within the network. The quintuple is the most critical identifying information in a network packet. It includes the source IP address, destination IP address, source port number, destination port number, and transport layer protocol type. These five elements together constitute the fundamental characteristics of a flow, uniquely identifying a specific communication process on the network. Masking rules, based on the quintuple information, determine the fields of interest by setting mask bits. Using masking rules, packets with similar characteristics can be grouped together, enabling batch diversion of packets within a specific range. When configuring a diversion strategy based on a five-tuple mask rule, the software provides an intuitive and flexible configuration interface. Staff can set a mask for each element in the five-tuple according to actual needs. Taking the source IP address as an example, if you need to divert all packets from the 192.168.1.0 / 24 network segment, you can set the source IP address mask to 255.255.255.0. At this time, as long as the first 24 bits of the source IP address of the packet are 192.168.1, regardless of the last 8 bits, it will be judged to have hit the mask rule. For port numbers, if you want to divert packets with source port numbers between 1024-65535, you can set the source port mask to 0xFFFF and use the port range rule to ensure that all port numbers within the range are hit. At the same time, protocol types can also be filtered by masks. In addition to masking individual quintuple elements, this policy also supports masking multiple elements in combination. This combined masking rule can further narrow the diversion scope, improve diversion accuracy, and prevent irrelevant messages from being misdirected. After receiving and parsing a message, the FPGA extracts the five-tuple information from the message and compares it with the preconfigured five-tuple mask rule. During this comparison, the FPGA processes each element of the five-tuple according to the mask rule, comparing only the valid bits specified by the mask. If the processed five-tuple information exactly matches the matching value in the mask rule, the message is considered to have matched the rule, triggering the traffic diversion mechanism and sending the message to the background processing module via the pre-configured diversion path. The advantage of this strategy lies in its strong flexibility and adaptability. By configuring different masking rules, you can achieve both precise diversion of specific individual packets and bulk diversion of packets of a certain type or range. Furthermore, masking rule configuration is dynamic. During system operation, staff can modify masking rules at any time through software based on network traffic changes and business needs without restarting the system, ensuring the real-time and scalability of the diversion strategy. In practice, traffic diversion strategies based on quintuple mask rules can be widely used in various scenarios. For example, in network monitoring, mask rules can be configured to divert all packets accessing a specific server to analyze server access. In security protection, mask rules can be configured for the IP address of a known attack source to divert all packets from that source to the security detection engine for in-depth inspection. In bandwidth management, mask rules can be used to divert high-volume video streams, limiting their bandwidth or optimizing their quality. Compared with the flow-based global diversion strategy and the feature message-based diversion strategy, the diversion strategy based on the five-tuple mask rule focuses more on the precise matching of message communication identifiers. It can achieve all-round diversion control from macro to micro through flexible mask settings. The three complement each other and jointly build an efficient and reliable diversion system, providing strong support for subsequent anomaly detection and message blocking.

[0032] The flexible five-tuple rule diversion strategy can match rules for a single arbitrary five-tuple and divert the flow that hits the strategy.

[0033] Its core lies in the ability to accurately match rules for a single arbitrary five-tuple. When the five-tuple information of a certain flow completely matches the preset rules, the flow will be diverted. This strategy greatly improves the accuracy and targeting of diversion, and can better meet the diversion needs in specific scenarios. The single arbitrary quintuple mentioned here covers various specific combinations that may appear in network communications. It can be a combination of a specific source IP address, a specific destination IP address, a specific source port number, a specific destination port number, and a specific protocol type. It can also be a combination in which some elements are fixed and some elements are flexibly changed. However, when matching rules, the quintuple information of the flow is required to completely correspond to each item in the preset rules. The software provides a detailed and convenient interface for rule configuration. Based on actual business needs, staff can manually enter or select specific quintuple element values ​​to construct a single quintuple rule. Once configured, the rule is stored in a dedicated rule table within the FPGA. The rule table utilizes a high-speed storage structure, ensuring the FPGA can quickly read and compare rules.

[0034] After the FPGA parses the received message and extracts the five-tuple information for the flow, it immediately compares the five-tuple against any single five-tuple rule in the rule table. During this comparison, the FPGA precisely matches each element of the five-tuple. This means that the source IP address must be identical to the source IP address in the rule, and the destination IP address, source port number, destination port number, and protocol type must also correspond exactly. This precise matching mechanism avoids misjudgments caused by fuzzy matching, ensuring that only flows that fully comply with the rule are diverted. Once a flow is determined to match a single, pre-defined five-tuple rule, the FPGA immediately initiates traffic diversion for that flow. Unlike diversion for individual packets, this diversion targets the entire flow. Starting with the first matching packet, all subsequent packets belonging to the flow are continuously diverted to the designated background processing module. During the diversion process, the FPGA marks the flow and, through its internal flow tracking mechanism, identifies subsequent packets belonging to the flow in real time, ensuring the continuity and integrity of the diversion. Flexible five-tuple rule-based traffic diversion strategies offer unique value in practical applications. During network troubleshooting, when a specific communication flow experiences an anomaly, you can configure a five-tuple rule for that flow to divert it to an analysis tool, allowing for detailed analysis of the entire flow's messages and rapid locating the cause of the problem. For specific business assurance, dedicated communication flows for critical services can be configured with rules to divert them to higher-priority processing channels, ensuring stable service delivery. During security audits, traffic diversion allows for full recording and auditing of specific flows involving the transmission of sensitive information, ensuring compliance.

[0035] Compared with the diversion strategy based on the five-tuple mask rule, the diversion strategy based on the flexible five-tuple rule focuses more on "precise matching". It does not use the mask to filter the range of elements, but matches the specific five-tuple combination. Therefore, it has irreplaceable advantages when a specific flow needs to be processed separately. At the same time, the rules of this strategy also support dynamic updates. The staff can add, modify or delete a single five-tuple rule in the rule table at any time as needed, so that the diversion strategy can quickly adapt to changes in the network environment. The method comprises: if the drainage strategy is hit, mirroring the drainage message and encapsulating it; inputting the encapsulated drainage message into the drainage message processing strategy, and performing backflow and back-infection judgment.

[0036] Specifically, the traffic diversion message is encapsulated using VxLAN, and its encapsulation format is as follows: Figure 2 As shown in the figure, the source and destination port numbers in the traffic diversion message are both 4789.

[0037] Specifically, when a message hits the preset diversion strategy, it enters the mirror strategy implementation and encapsulation link of the diversion message. This link is the key link connecting diversion and subsequent processing. Its processing effect directly affects the transmission quality of the diversion message and the accuracy of subsequent judgment. The core of the mirroring strategy is to replicate or divert traffic to meet different business needs. Mirroring strategies can be categorized into various types based on the actual application scenario. A dedicated mirroring processing module within the FPGA replicates or diverts traffic in real time based on pre-set mirroring rules. The replication process utilizes a parallel processing mechanism to ensure that, even in high-speed message transmission scenarios, the mirroring operation does not affect the transmission latency of the original message. After the mirroring process is completed, the drainage message needs to be encapsulated. The purpose of encapsulation is to add specific identification information and control fields to the drainage message so that it can be accurately identified and managed during subsequent transmission and processing. The encapsulated content usually includes the drainage policy identifier, metadata of the original message, check fields, etc. The encapsulation process is completed by the encapsulation engine inside the FPGA. The engine uses an efficient protocol encapsulation algorithm and can complete the encapsulation of a single-frame drainage message within microseconds. The encapsulated drainage message will form a frame structure that conforms to a specific format. This frame structure is compatible with the interface requirements of the back-end processing module and can carry sufficient control information to provide a basis for the subsequent execution of the drainage message processing strategy. After the encapsulated drainage message is input into the drainage message processing strategy, the first task is to perform backflow and backflow judgment. The backflow judgment is mainly to determine whether the drainage message needs to be returned to the original transmission path after background processing. The judgment is usually based on the feedback results of the background processing module. For example, if the background processing determines that the drainage message is normal business traffic and needs to continue to be transmitted to the destination address, the backflow mechanism is triggered; if it is determined to be an abnormal message, there is no need for backflow, and blocking is performed directly. The backflow judgment module inside the FPGA will receive the feedback signal from the background processing module in real time, and combine it with the identification information encapsulated in the drainage message to quickly make a decision on whether to backflow or not. Back-polling checks whether the returned traffic messages need to be marked or modified to reflect the results of background processing. This is also performed by a dedicated module within the FPGA. This module applies necessary markings or field modifications to the returned messages based on background processing instructions and pre-set back-polling rules. This modification process utilizes atomic operations to ensure message consistency and integrity. During the reflow and back-infection judgment process, the FPGA maintains high-speed communication with the background processing module, exchanging processing results and control instructions in real time through a dedicated control channel. To cope with the high concurrency of diversion message processing scenarios, the judgment process adopts a pipeline processing architecture. Multiple diversion messages can be judged in parallel at different processing stages, significantly improving processing efficiency. At the same time, the judgment results are recorded in real time in an internal logging module, which records information such as the diversion message processing time, reflow status, and back-infection flags, providing a basis for subsequent system debugging and performance analysis. Through the above-mentioned mirror encapsulation, backflow and backflow judgment process, the diversion message can complete the whole process management from diversion to processing to possible backflow according to the preset strategy. This not only ensures that the background processing module can obtain sufficient traffic data for analysis, but also ensures the smooth transmission of normal business traffic, realizing the organic combination of anomaly detection and normal network operation. Furthermore, the mirroring policy is at least one or more of a flow-based global mirroring policy, a feature-based mirroring policy, a five-tuple mask rule-based mirroring policy, or a flexible five-tuple rule-based mirroring policy. Mirroring policies are independently managed and configured. Unlike diversion policies, mirroring copies a message from the original message flow, leaving the original message flow forwarding process unchanged. Diversion policies, on the other hand, alter the original message flow forwarding process, requiring message flows targeted by the diversion policy to be diverted. After diversion processing, the message flow is then returned to the original forwarding path.

[0038] The flow-based global mirroring policy mirrors the first N packets of each flow based on the flow table. This policy has a separate control enable switch, and the value N can be set by software. This policy is used to mirror the first N packets of all flows to the backend software for identification and assessment of services, attack detection, and other functions. Its core logic is to mirror the first N packets of each flow based on the flow table. This policy precisely filters the initial packets of a flow, providing an efficient and targeted data source for backend software functions such as service identification and attack detection. The flow table plays a key role here, storing basic information about each flow in the network, including its unique identifier, flow status, and processed packet count. When a message enters the processing flow, the FPGA determines the flow it belongs to based on the information contained in the message and searches the flow table for the relevant record of that flow to determine whether the current message needs to be mirrored. The mirroring process for the first N messages in each flow is clearly targeted. For a newly emerging flow, after its first message arrives, the FPGA queries the flow table and finds that the message count for the flow is 0, which triggers the mirroring mechanism and mirrors the message. At the same time, the message count for the flow in the flow table is increased by 1. When the second message of the flow arrives, if the count is still less than N, the mirroring process continues and the count is updated until the count reaches N. At this time, subsequent messages of the flow are no longer mirrored and are only transmitted along the normal path. This processing method ensures that the background software can obtain key information in the initial stage of each flow, while avoiding the large amount of data transmission pressure brought by mirroring the entire flow, achieving a good balance between efficiency and information integrity. This policy is equipped with a separate control enable switch, which provides a convenient way to flexibly enable and disable the policy. The control enable switch is typically integrated into the FPGA as a hardware register. Software can be used to control the switch state by writing specific instructions to the register. When the switch is on, the global mirroring policy takes effect, and the first N packets of all flows are mirrored according to the rules. When the switch is off, the policy is suspended and no further mirroring is performed. This design allows the policy to be quickly disabled to save system resources when background analysis is not required, or quickly enabled when needed to adapt to different network operation scenarios.

[0039] The size of N can be flexibly configured through software, allowing the strategy to be dynamically adjusted based on actual needs. Software can modify the value of N by accessing the FPGA's internal configuration registers, typically ranging from 1 to hundreds or even thousands. The core function of this strategy is to mirror the first N packets of all flows to the backend software, providing support for the implementation of various functions. Regarding service identification, the first N packets of a flow often contain key information such as the service's protocol characteristics and handshake information. By parsing these packets, the backend software can quickly determine the service type of the flow, such as video streaming or file transfer, providing a basis for subsequent differentiated services and resource allocation. Regarding attack detection, many attack behaviors exhibit abnormal characteristics in the initial stages of a flow, such as the probe packets of a port scan attack or the initial connection packets of malware. By analyzing these mirrored first N packets, the backend software can promptly identify potential attack signs and generate corresponding detection results, providing decision support for subsequent protective measures. In addition, since only the first N packets of each flow are mirrored, this strategy greatly reduces the use of network bandwidth and background storage and processing resources. Compared with mirroring the entire flow, the data volume is greatly reduced, but the key information of the initial stage of the flow is retained, while ensuring the effective operation of background functions, it improves the overall performance and resource utilization of the system. Signature-based mirroring strategies use a table lookup based on the packet's signature. For specific signatures, the software can configure mirroring for packets matching these signatures. The core mechanism is to perform a table lookup based on the signatures carried by the packet itself. For packets matching these signatures, the software pre-configures rules to include them in the mirroring process, providing accurate analysis data for the backend software. The message features here cover a wide range of dimensions, including fixed identifiers in protocol fields, specific source IP address segments, destination port numbers, and protocol types; signature codes in the data payload, such as virus signature strings and application-specific identification fields; and behavioral attributes of the message, such as abnormal message lengths and TTL value transitions. These features are systematically stored in a feature table external to the FPGA. Constructed using high-speed storage media, the feature table supports nanosecond-level table lookup responses to meet the real-time processing requirements of high-speed network environments. When a message enters the FPGA processing flow, it first passes through the parsing module to extract key information and then enters the feature matching engine. This engine extracts the corresponding feature fields from the message according to pre-set feature extraction rules and compares them in parallel with the entries in the feature table. This comparison process uses a hardware-accelerated hashing algorithm or an exact matching algorithm to simultaneously verify multiple features within a single clock cycle, ensuring non-blocking feature matching even at message traffic rates of millions of frames per second. The software plays a core role in feature configuration and rule management within this strategy. Staff can add, modify, or delete feature entries in the feature table through a graphical interface or command-line tools. The software configuration process also supports hierarchical and combined feature configuration. This combined feature mechanism significantly improves image accuracy and prevents irrelevant messages from occupying image bandwidth. Furthermore, the software regularly maintains the feature table, automatically clearing invalid features that have been unused for a long time through an aging mechanism to ensure efficient use of feature table storage resources. When the FPGA's signature matching engine determines that a message matches a signature in the signature table, the mirroring process is immediately triggered. The mirroring module replicates the message in real time, generating a mirror copy that is identical to the original. One copy continues to travel along the original path, ensuring unimpeded network communication. The other copy is encapsulated with a mirror identifier and sent to backend analysis equipment via a dedicated mirroring channel. This encapsulation process utilizes a lightweight protocol, adding only necessary metadata to minimize overhead on the mirrored traffic. The advantage of this policy lies in its high flexibility and precision. By focusing on packets with specific characteristics, it not only provides targeted analysis samples for backend software, but also avoids bandwidth waste caused by global mirroring. In practice, this policy can be widely used in scenarios such as security monitoring, business analysis, and troubleshooting. For example, when an unknown attack occurs on the network, administrators can quickly add attack signatures through the software, mirror relevant packets in real time for reverse analysis, and quickly generate defense rules. This demonstrates the closed-loop processing capability of "from precise mirroring to in-depth analysis to rapid response." A mirroring policy based on a quintuple mask rule can be configured with any mask rule for the 5-tuple information, mirroring the packets that match the mask rule. The core of this policy is to implement targeted mirroring of packets that match the rule by configuring any mask rule for the quintuple information, providing targeted traffic data for background software analysis and monitoring. The quintuple contains the source IP address, destination IP address, source port number, destination port number, and protocol type, which together form the core identifier of a network packet. Mask rules, on the other hand, filter each field in the quintuple by setting a specific mask value to determine the range of packets to be mirrored.

[0040] During the configuration process, the software provides an intuitive and flexible operation interface, allowing staff to set mask rules for each field of the quintuple according to actual needs. For the source IP address and destination IP address, the mask is represented by a 32-bit binary number. The value of each bit determines whether the corresponding IP address bit is included in the match. 1 indicates that the bit needs to be matched exactly, and 0 indicates that the bit is ignored. For the source port number and destination port number, the mask is a 16-bit binary number. By setting different mask values, matching of specific ports or port ranges can be achieved. The mask of the protocol type field is an 8-bit binary number. By setting the mask, packets of a specific protocol type can be filtered out, such as mirroring only packets of the TCP or UDP protocol. In addition to setting mask rules for a single field, this policy also supports configuring combined mask rules for multiple fields. For example, you can configure a combined rule with a source IP address of 10.0.0.0 / 8, a destination port number of 80, and a protocol type of TCP. Only packets that meet all three conditions will be considered a match and mirrored. This combined configuration significantly improves mirroring accuracy, accurately capturing traffic with specific combined characteristics and preventing irrelevant packets from occupying mirroring resources. When the FPGA receives a message, it first parses it, extracting the quintuple information and then comparing it against the preconfigured quintuple mask rule. During the comparison, the FPGA processes each field of the quintuple according to the mask rule, comparing only the valid bits specified by the mask. If the processed quintuple information exactly matches the matching value in the rule, the message is considered to have matched the rule, and the mirroring mechanism is triggered.

[0041] During the mirroring process, the mirroring module within the FPGA replicates the messages that match the rules in real time, generating mirror copies that are identical to the original messages. The original messages continue to travel along their normal paths, ensuring unimpeded network communications. Mirror identification information, such as the rule number and hit timestamp, is added to the mirror copies. This information helps backend software distinguish between mirrored messages matching different rules. The mirror copies are then sent via a dedicated high-speed mirroring channel to backend analysis equipment, such as traffic monitoring systems and intrusion detection systems. To ensure efficient transmission along the mirroring channel, the mirror identification information is lightweight, occupying minimal additional bandwidth to minimize impact on overall network performance. The advantage of this strategy lies in its flexibility and adaptability. By configuring different masking rules, you can achieve both precise mirroring of specific individual packets and batch mirroring of packets of a certain type or range. Furthermore, masking rule configuration supports dynamic updates. Staff can modify rules at any time through software based on network traffic changes and business needs without restarting the system, ensuring that the mirroring strategy can quickly respond to changes in the network environment. In practice, mirroring strategies based on quintuple mask rules can be widely used in various scenarios. In network security protection, mask rules can be configured to mirror packets originating from specific suspicious network segments and accessing specific ports, facilitating backend system detection of potential attacks. In business analysis, mask rules can be configured for the IP addresses and ports of critical business servers to mirror all packets accessing the servers, allowing analysis of business traffic characteristics and operational status. In bandwidth management, mask rules can be used to mirror packets from high-traffic applications, providing data support for bandwidth allocation and optimization. Compared with other mirroring strategies, the mirroring strategy based on the five-tuple mask rule can accurately locate the traffic that needs attention in a complex network environment due to its flexible matching ability of the network core identifier, providing efficient and valuable mirroring data for the background software. It is an important part of the network monitoring and analysis system. The flexible five-tuple mirroring strategy matches a single, arbitrary five-tuple rule and mirrors the flows that match the rule. Its core is to match a single, arbitrary five-tuple rule. When the five-tuple information of a flow exactly matches the preset rule, the flow is mirrored. This allows for precise targeting of specific traffic, providing highly focused data support for background analysis. The single arbitrary quintuple here refers to a specific and unique combination of source IP address, destination IP address, source port number, destination port number, and protocol type. This can be any possible quintuple combination found on the network, including the specific protocol and source port combination used by a specific user accessing a specific server, or any other clearly identified quintuple. This focus on a single quintuple enables the mirroring policy to accurately capture specific flows. The software provides a meticulous approach to rule configuration. Through a dedicated configuration interface, personnel can manually enter or select specific quintuple element values ​​to construct a mirroring rule for a single quintuple. Once configured, the rule is stored in a dedicated rule table within the FPGA. The rule table utilizes a high-speed storage structure, ensuring rapid access and matching by the FPGA. After receiving and parsing a message, the FPGA extracts the five-tuple information for the flow to which the message belongs and then precisely compares it against a single arbitrary five-tuple rule stored in the rule table. During this comparison, the FPGA rigorously matches each element of the five-tuple. The source IP address must be identical to the source IP address in the rule, and the destination IP address, source port number, destination port number, and protocol type must also correspond exactly. No deviation is allowed. This precise matching mechanism ensures that only flows that fully comply with the preset rules are targeted, preventing irrelevant traffic from being mirrored due to fuzzy matching and significantly improving mirroring accuracy. Once a flow matches a flexible five-tuple rule, the FPGA immediately initiates mirroring of that flow. Unlike mirroring a single message, this mirroring targets the entire flow. Starting with the first matching message in the flow, all subsequent messages belonging to the flow are mirrored continuously. The FPGA's internal flow tracking module monitors subsequent messages in real time, accurately identifying the messages belonging to the flow based on the five-tuple information, ensuring the continuity and integrity of the mirroring. During the mirroring process, the FPGA's mirroring module replicates each packet in the matching flow in real time, generating a mirror copy that is identical to the original. The original packet continues to travel along its normal path, ensuring smooth network communication. The mirror copy is then assigned specific mirror identifiers, such as the unique flow identifier and the matching rule number. These identifiers help backend software identify the flow and corresponding rule to which the mirrored packet belongs. The mirror copy is then sent via a dedicated high-speed mirroring channel to backend analysis equipment, such as deep packet inspection systems and service analysis platforms. The significant advantage of this strategy lies in its unparalleled precision. By matching a single, arbitrary five-tuple rule, it can precisely target a specific flow for mirroring without interfering with other unrelated flows. This effectively reduces the amount of mirrored data and reduces the use of backend processing resources and network bandwidth. Furthermore, rule configuration is highly flexible. Staff can add, modify, or delete five-tuple rules in the rule table at any time based on actual needs, enabling dynamic adjustments during system operation to adapt to changes in specific flows within the network. Specifically, the mirror message encapsulation adopts VxLAN format, and its encapsulation structure is as follows Figure 3 As shown in the figure, to distinguish diverted and mirrored packets, the UDP source port number is 6188.

[0042] The method comprises: if the backflow and backdye are judged to be successful, obtaining a backflow and backdye message.

[0043] Specifically, the return flow and return staining message is distinguished and judged. If it is a return flow message, it is decapsulated to obtain the message and output it. In the process of distinguishing and judging the return flow and return staining message, if it is a return staining message, it is processed in the return staining flow table and stored in the high-speed flow table, and the data of the high-speed flow table is expanded.

[0044] Specifically, when the reflow and re-infection are judged as successful, it means that the diverted message meets the reflow or re-infection conditions after background processing, and a reflow and re-infection message is obtained. This result effectively connects the previous diversion, processing, and judgment steps, laying the foundation for subsequent message processing or flow table updates. Next, the reflow and return contamination messages need to be distinguished and judged. This process is completed by a dedicated identification module inside the FPGA. The module will distinguish the message type based on the specific identifier in the reflow and return contamination message encapsulation information. If the judgment result is a return message, it means that the message does not need additional marking or modification after background processing, and only needs to return to the original transmission path to continue transmission. At this time, the FPGA will start the decapsulation process. The decapsulation process corresponds to the previous encapsulation process. The decapsulation engine will strip off the drainage policy identifier, metadata, check field and other information added during the encapsulation to restore the complete structure of the original message. During the decapsulation process, the check field will be verified to ensure that the message is not damaged during transmission and processing. If the verification fails, the message will be marked as invalid and discarded to prevent the erroneous message from entering the original transmission path. The original message obtained after the decapsulation is completed will be output by the FPGA through the corresponding output port according to its original destination address and transmission path. At this point, the entire processing flow of the message is completed, and it returns to the normal network transmission track smoothly.

[0045] If the identification result indicates a back-polluted message, this indicates that after background processing, the message needs to be updated in the flow table to ensure accurate handling of similar traffic in the future. At this point, the FPGA performs back-polluted flow table processing. Back-polluted flow table processing first extracts key information from the back-polluted message, including the original message's five-tuple information and the policy adjustment instructions generated by background processing. The FPGA then generates a new flow table entry or updates an existing one based on this information.

[0046] After generating or updating a flow table entry, the FPGA stores the processed flow table entry in the high-speed flow table, thereby expanding the high-speed flow table data. During this storage process, the high-speed flow table uses an efficient storage management mechanism to ensure that new flow table entries can be written quickly without affecting the query and read access of other flow table entries. Newly added flow table entries are managed according to the aforementioned LRU and other replacement algorithms to ensure that the high-speed flow table always stores the most valuable flow information. In addition, flow table entries stored in the high-speed flow table are marked as valid, allowing them to immediately participate in subsequent message processing. When similar messages enter, the FPGA can directly query the high-speed flow table to obtain the corresponding processing strategy, improving processing efficiency. By differentially processing return flow and return infection messages, the smooth transmission of normal return flow messages is guaranteed, and the dynamic update of the flow table for return infection messages is realized, so that the high-speed flow table can reflect the latest business needs and security status in the network in real time, further improving the adaptability and accuracy of the entire anomaly detection and message blocking system. The return message is encapsulated in VxLAN, and its encapsulation format is as follows: Figure 2 As shown in the figure, the source and destination port numbers in the return packet are both 4789.

[0047] The return message is encapsulated using ordinary UDP messages. The source and destination port numbers in the return message are 6188, and the encapsulation format is as follows: Figure 4 As shown, the internal format is a customized back-infection message information frame format, including the back-infection message frame header format and the back-infection information frame format, such as Figure 5 shown.

[0048] Furthermore, the backflow and back-contamination message is distinguished and judged, and if it is not a backflow message, the process ends.

[0049] Specifically, in the process of distinguishing and judging the return flow and back-contamination message, in addition to determining it as a return flow message or a back-contamination message, there may also be a situation where it is neither a return flow message nor a back-contamination message. In this case, according to the processing logic, the process will end directly. This "not a return message" situation is usually because the message is determined to require no subsequent operations during background processing. It does not need to return to the original transmission path, and no relevant information needs to be updated in the high-speed flow table.

[0050] When the FPGA's dedicated identification module identifies such a message, it immediately terminates subsequent processing. Specifically, the FPGA does not decapsulate the message or perform backflow table processing. Instead, it directly places the message into its internal discarded message queue. This discarded message queue regularly deletes messages according to a pre-set cleanup mechanism to free up FPGA storage and processing resources, preventing invalid data from occupying system resources and impacting overall processing efficiency. The FPGA also logs the handling of these non-return packets, including the packet's identification information, the time it was determined to be a non-return packet, and the reason code. This log information is stored in an internal log buffer, allowing management personnel to query and analyze it through software to understand the system's handling of various types of packets, providing a reference for optimizing traffic diversion strategies and back-end processing logic. The significance of this processing approach lies in its ability to ensure efficient utilization of system resources, focusing limited computing and storage resources on processing valuable return and return-infection messages, while avoiding wasting resources on invalid messages. Furthermore, a clear termination mechanism ensures the simplicity and determinism of the processing flow, making the entire system's operational logic clearer and reducing errors or redundant operations caused by ambiguous processing. This further enhances the stability and reliability of the FPGA-based high-speed serial backflow anomaly detection and message blocking system.

[0051] Furthermore, the method also includes: if there is no matching diversion strategy, selecting a corresponding blocking strategy based on the protocol field.

[0052] If the corresponding blocking policy is hit, the original message is discarded, and it is determined whether the discarded original message is diverted. If so, the discarded original message is encapsulated and diverted through the diversion message processing policy. The discarded original message carries the policy and information hit by the discarded original message.

[0053] Specifically, when a message does not hit any diversion strategy, the system will enter the blocking strategy processing process based on the protocol field. This link is an important barrier to ensure network security and can intercept messages with potential risks in a timely manner. If it determines that no traffic diversion strategy has been matched, the FPGA invokes its internal blocking strategy matching module. This module compares the protocol field extracted from the packet with a pre-configured blocking strategy library. The protocol field includes key information such as the source IP address, destination IP address, protocol type, and port number. This information is the core basis for determining whether the packet should be blocked.

[0054] If a message matches a blocking policy, the FPGA immediately discards the original message. Before being discarded, the original message undergoes an integrity check to ensure it is indeed an invalid message that matches the blocking policy, preventing legitimate messages from being accidentally deleted. This discard operation removes the original message from the data transmission link and releases the buffer resources it occupied. This prevents the blocked message from entering subsequent network transmission paths, blocking potential threats at the source. After discarding the original message, the system will further determine whether the discarded original message needs to be diverted. If not, the process ends.

[0055] If a discarded original message is determined to require diversion, the FPGA encapsulates it. This encapsulation includes information such as the blocking policy identifier, a summary of the original message's protocol fields, and a discard timestamp. This information not only provides a basis for backend audits but also helps administrators trace the details of blocking events. The encapsulation process utilizes the same efficient algorithm used for diversion message encapsulation, ensuring fast completion and that the encapsulated message format complies with the interface specifications of the backend processing module.

[0056] The encapsulated diversion message is input into the diversion message processing policy and enters the return flow and return detection stages. The return flow determination is used to determine whether the encapsulated diversion message needs to be returned to a specific logging path rather than the original transmission path; the return detection determines whether to update the blocking event information to the high-speed flow table. The entire process forms a comprehensive security protection mechanism through precise blocking and subsequent processing of packets that miss the diversion policy. It not only promptly intercepts threatening packets but also dynamically responds to network threats through information encapsulation and flow table updates, enhancing the system's proactive defense capabilities. Furthermore, the FPGA executes all judgments and operations at hardware-level speeds, ensuring millisecond-level processing latency even in high-speed network environments, meeting real-time protection requirements.

[0057] Furthermore, if no blocking policy is matched, the original message is output to the link.

[0058] Specifically, when a message neither hits any diversion strategy nor any blocking strategy, it means that the system has initially judged the message to be normal and legal network traffic. At this time, according to the processing logic, the system will output the original message to the link to ensure that it can continue to complete its normal network transmission mission. This approach is based on the "presumption of innocence" principle of network communications. This means that if there's no evidence of anomalies or threats in a message, it's considered normal traffic, ensuring the continuity and integrity of network communications. This default-to-pass mechanism is crucial in high-speed networks, preventing network delays or service interruptions caused by excessive inspections and ensuring the smooth operation of legitimate applications.

[0059] Before outputting the original message to the link, the FPGA will perform a series of final verification and processing operations to ensure that the output message is in good condition. First, the integrity of the original message will be reconfirmed to check whether the message frame structure, CRC check value, etc. have been damaged due to misoperation in the previous processing link. If a message integrity problem is found, even if it does not hit the blocking strategy, it will be marked as an invalid message and discarded to prevent the damaged message from entering the link and affecting other devices. Secondly, the identification information of the original message that was temporarily modified or added during the parsing and judgment process will be restored, such as the temporary check mark added during parsing, to ensure that the message output to the link is consistent with the original message structure when it was received and complies with the network protocol specifications.

[0060] After verification and processing, the FPGA dispatches the original message to the corresponding physical output port through its internal output port scheduling module. This module selects the optimal output path based on the original message's destination address and link load to avoid port congestion.

[0061] During message output, the FPGA monitors output behavior in real time, recording information such as the message output time, output port, and message length. This information is stored in the system log for subsequent traffic statistics, troubleshooting, and performance analysis. Simultaneously, the monitoring module monitors the status of the output port in real time. If a port failure or link interruption is detected, the port switching mechanism is immediately activated, switching the message to a backup port for output, ensuring that the message successfully enters the link. Outputting original packets that miss blocking policies to the link not only ensures normal network communication but also demonstrates the rigor of the system's processing logic. This complements the diversion and blocking policies, forming a complete "screening-detection-release / interception" processing system: diversion policies target traffic requiring in-depth analysis, blocking policies target traffic identified as threatening, and default output ensures the passage of all other normal traffic. Working together, these three strategies meet network security requirements while balancing the efficiency and availability of network communications. Furthermore, the blocking strategy is at least one or more of a blocking strategy based on a characteristic message, a blocking strategy based on a quintuple mask rule, or a blocking strategy based on a flexible quintuple rule.

[0062] Signature-based blocking strategies are implemented by lookup tables based on the packet's signature. For specific signatures, the software can be configured to discard packets matching these signatures. The core logic is to perform a table lookup and match against packet signatures. For packets matching these signatures, the software discards them according to pre-set rules, effectively blocking potentially threatening traffic. The message characteristics here cover a wide range, including fixed fields in the protocol header, specific source MAC addresses, destination MAC addresses, abnormal TTL values, and non-compliant protocol version numbers; characteristic patterns in the data payload, such as virus signatures, malware instruction sequences, characteristic strings of sensitive information, and abnormal packet lengths; and behavioral characteristics of messages, such as the frequent occurrence of the same source and destination address combinations within a short period of time, and the frequency of message exchanges that do not conform to normal communication patterns. These characteristics are organized by the system and stored in a dedicated feature blocking table. This table uses high-speed storage media to support rapid parallel search operations to meet the real-time message processing requirements in high-speed network environments. After the FPGA receives and parses a message, it enters the feature matching phase. First, the feature extraction module extracts various signature information from the message according to pre-set extraction rules. For example, for protocol header features, it extracts the source MAC address and TTL value. For data payload features, it scans for patterns matching the signature blocking table using methods such as a sliding window. The extracted signature information is then fed into the signature matching engine, which compares it one by one with the entries in the signature blocking table.

[0063] The software plays a key role in configuring signatures and setting rules within this strategy. Staff can flexibly manage the signature blocking table through the software interface or programming interface. When a packet with a specific signature needs to be blocked, the software enters the specific signature into the signature blocking table and associates a "discard" action with it. The software's signature blocking table configuration supports not only adding individual signatures but also combining multiple signatures. For example, a packet can be configured with a combination of "the source IP address is from a suspicious network segment, and the data payload contains specific attack instructions." Only when both conditions are met will the packet be considered a match and discarded. This combination significantly improves the accuracy of blocking policies, effectively reducing false positives and missed detections, and avoiding unnecessary interception of legitimate packets. When the signature matching engine determines that a message matches a feature in the signature blocking table, the FPGA immediately triggers the discard mechanism. First, the message is marked, and information such as the signature entry number, the message's arrival time, and the source and destination addresses are recorded. This information is stored in the log system for subsequent security audits and policy optimization analysis. The FPGA then removes the message from the data transmission link, freeing up the buffer resources it occupied and ensuring that the discarded message cannot continue to be transmitted on the network. Furthermore, to prevent fragments or residual information related to the discarded message from affecting system operation, the FPGA also cleans up the processing path that the message passed through to ensure system stability. The advantages of this strategy lie in its highly targeted and flexible nature. By precisely matching message signatures, it can directly locate and intercept threat messages, avoiding indiscriminate processing of all traffic. This effectively ensures network security while minimizing the impact on normal network communications. Furthermore, the signature blocking table can be updated in real time via software, allowing staff to quickly add signature entries based on emerging network threats. This allows the system to promptly respond to various new attacks and enhance the network's dynamic defense capabilities. In practice, signature-based blocking strategies can be widely applied in various scenarios. For virus and malware protection, they block packets carrying virus signatures to prevent their spread within the network; for intrusion detection, they intercept packets containing attack command sequences to defend against network attacks; and for sensitive information protection, they discard packets containing sensitive signature strings to prevent information leakage. This strategy, in conjunction with other blocking strategies, forms a multi-layered network security protection system, providing a solid foundation for stable network operation. Five-tuple mask rule-based blocking policies can be configured with arbitrary mask rules for the five-tuple information, discarding packets that match the mask rules. The core of this strategy is to configure arbitrary mask rules for the five-tuple information and discard packets that match these rules, effectively blocking potential threat traffic within a specific range or type. The five-tuple information includes the source IP address, destination IP address, source port number, destination port number, and protocol type, which together constitute the core identifier for identifying network traffic. The mask rule, on the other hand, filters each field in the five-tuple by setting a specific mask value to determine the range of messages that need to be blocked. The mask acts like a "filter." A bit with a "1" in the mask indicates that an exact match is required, while a bit with a "0" indicates that it can be ignored and does not participate in the match. This flexible mask setting allows the policy to cover a wide range from a single specific message to a certain category of messages. Configuring multi-field combination mask rules can further enhance the policy's precision. For example, you can configure a combination rule with "source IP address 10.0.0.0 / 8, destination port 21, and protocol type TCP." A packet meeting all three conditions is considered a match and will be dropped. This combination of rules can precisely target traffic with specific communication characteristics, such as packets originating from a specific network segment and attempting to connect via the FTP protocol, effectively preventing the inadvertent blocking of irrelevant traffic. When the FPGA receives a message, it first parses it, extracting the quintuple information and then comparing it with the preconfigured quintuple mask rules. During the comparison process, the FPGA processes each field of the quintuple according to the mask rules, focusing only on the valid bits specified by the mask. If the processed quintuple information exactly matches the matching value in the rule, the message is considered to have matched the rule, and the discard mechanism is triggered. During the discard process, the FPGA first marks packets that match a rule, recording key information such as the rule number, the packet's five-tuple information, and the discard timestamp. This information is stored in the system log for subsequent security audits, threat analysis, and policy optimization. The FPGA then removes the packet from the data transmission link and releases the buffer resources it occupied, ensuring that the blocked packet cannot enter subsequent network transmission paths, completely blocking any potential threats it may pose. Furthermore, to prevent fragments or residual information from discarded packets from affecting system operation, the FPGA also cleans up the internal processing paths that the packet has passed through, ensuring system stability. In practice, blocking strategies based on quintuple mask rules can be widely used in various network security scenarios. In enterprise networks, they can be used to restrict internal hosts from accessing specific external IP addresses or ports, preventing information leakage. In data centers, they can be used to intercept malicious access to specific server ports, ensuring stable server operation. On campus networks, they can be used to block P2P download traffic using specific protocols, effectively allocating network bandwidth. This strategy, in conjunction with other blocking strategies, builds a multi-layered, comprehensive network security protection system, providing strong guarantees for the secure and stable operation of the network.

[0064] Flexible five-tuple rule blocking strategies can match rules against a single, arbitrary five-tuple and discard flows that match the rule. The core of this strategy is the ability to accurately match rules against a single, arbitrary five-tuple. When a flow's five-tuple information completely matches the preset rule, the flow is discarded, achieving precise interception of specific threat flows. The single arbitrary five-tuple mentioned here refers to a specific and unique combination of source IP address, destination IP address, source port number, destination port number and protocol type. This focus on a single five-tuple allows the blocking strategy to accurately target the target flow and avoid interference with other normal flows. The software provides a detailed and flexible approach to rule configuration. Through a dedicated configuration interface, staff can manually enter or select specific quintuple element values ​​to construct blocking rules for a single quintuple. When the FPGA receives a message, it first parses it, extracting the five-tuple information within it. Based on this information, it then determines the flow to which it belongs and searches the rule table for the corresponding blocking rule. During the matching process, the FPGA rigorously and precisely compares each element of the five-tuple. The source IP address must be identical to the source IP address in the rule, and the destination IP address, source port number, destination port number, and protocol type must also correspond exactly, with no deviation allowed. This precise matching mechanism ensures that only flows that fully comply with the preset rules are matched, effectively preventing the accidental blocking of legitimate flows. Once a flow is determined to match a flexible five-tuple rule, the FPGA immediately discards the flow. First, the current packet is marked, recording key information such as the rule number it matched, the flow's five-tuple information, and the discard timestamp. This information is stored in the system log, providing a basis for subsequent security audits, threat tracing, and policy optimization. The FPGA then removes the current packet from the data transmission link, freeing up the buffer resources it occupied. Because the FPGA processes flows, it continuously monitors subsequent packets within that flow through its internal flow tracking mechanism. As long as the five-tuple information of the subsequent packets matches the preset blocking rules, they will be continuously discarded, ensuring that all packets of that flow cannot enter subsequent network transmission paths, completely blocking any threats posed by the flow. The significant advantages of this strategy lie in its extreme precision and flexibility. By matching rules against a single arbitrary quintuple, it can precisely target and block specific threat flows without impacting the transmission of other normal flows, significantly improving the efficiency of network security. Furthermore, rule configuration is dynamic. Staff can add, modify, or delete quintuple rules from the rule table at any time through software based on evolving network threats, enabling real-time adjustments during system operation to rapidly respond to emerging security threats.

[0065] Furthermore, it is determined whether the discarded original message needs to be diverted. If not, the process ends.

[0066] When the discarded original message is determined to need to be diverted, the discarded original message is encapsulated and diverted through the diversion message processing strategy. The discarded original message carries the strategy and information hit by the discarded original message, which is used by the software system to check whether the discard is misjudged.

[0067] In addition, after the process is completed, the system will automatically record the processing results, including the judgment basis for whether the drainage message was not discarded, timestamp and other information, to ensure that the entire processing process is traceable, further ensuring the standardization and reliability of the system operation.

[0068] Furthermore, the method also includes: when the blocking strategy and the diversion strategy are both judged to be valid, after the diversion message executes the blocking strategy, the diversion message carries the flag and strategy information of the hit blocking strategy when being diverted.

[0069] Furthermore, when receiving the diversion message, the diversion message processing strategy determines whether the diversion message is misjudged, and the misjudged message will flow back into the link.

[0070] Specifically, during network traffic processing, a special situation may arise where both a blocking strategy and a diversion strategy are determined to be valid. In this case, the system will process the traffic according to the preset priority mechanism. Generally, the blocking strategy will have a higher priority, and the diversion message will be processed by the blocking strategy first. Subsequently, when the diversion process is completed, the message will carry the flag of the blocking strategy that was hit and the policy information, providing a basis for subsequent misjudgment troubleshooting. When the blocking strategy and the diversion strategy are in effect at the same time, the policy arbitration module inside the FPGA will determine that the blocking strategy should be executed first. This is because the blocking strategy is mainly aimed at traffic that has been clearly threatened, and priority execution can minimize security risks. After the blocking strategy is executed to discard the original message, the FPGA will specially encapsulate the diversion message that needs to enter the diversion path. In addition to the conventional diversion identifier, the encapsulated content will also add a blocking strategy hit flag and detailed policy information, including the blocking strategy number, the five-tuple feature that triggers the blocking, the specific content of the blocking rule, etc. This information is like an "identity tag", which clearly records the reason why the diversion message was hit by the blocking strategy, so that the subsequent processing module can quickly understand its background.

[0071] Upon receiving a diversion message carrying a blocking policy flag, the traffic handling strategy initiates a dedicated false positive detection process. This process uses a backend intelligent analysis engine to determine the rationality of blocking the diversion message, combining network topology information, historical traffic signature databases, service whitelists, and other multi-dimensional data.

[0072] If the diversion message is determined to be a misjudgment, the system will immediately trigger the backflow mechanism. The backflow path of the misjudgment message is the same as the normal backflow message, but a "misjudgment correction" mark will be added to distinguish it from the regular backflow message. During the backflow process, the FPGA will decapsulate the misjudgment message, restore its original data structure, and send it to the original link through a dedicated priority channel to ensure that the misjudgment message can reach the destination address in time and reduce the impact on normal business. At the same time, the system will record detailed information on the misjudgment event, including the misjudgment blocking policy number, message characteristics, correction time, etc., and feed this information back to the policy optimization module to automatically adjust the rule parameters of the relevant blocking policy to avoid the same type of misjudgment from happening again. Furthermore, the above detailed description of one embodiment of the present invention is merely a preferred embodiment of the present invention and should not be considered as limiting the scope of the present invention. Any equivalent changes and improvements made within the scope of the present invention should still fall within the scope of the present invention.

Claims

1. A high-speed serial connection backflow anomaly detection and blocking method based on FPGA, characterized in that: The method includes: Receive the original message in the link and input it into the FPGA; Parse the message and extract the protocol field in the original message; Select the corresponding diversion strategy based on the protocol field to obtain the diversion message; if there is no corresponding diversion strategy, query and update the data of the high-speed flow table carried by the FPGA; If the diversion policy is matched, the diversion message is mirrored and encapsulated. The encapsulated diversion message is input into the diversion message processing policy, and the backflow and back-infection are judged. If the backflow and back-dyeing are judged to be successful, a backflow and back-dyeing message is obtained; The return flow and return staining message is distinguished and judged. If it is a return flow message, it is decapsulated to obtain the message and output it. When distinguishing and judging the return flow and return staining message, if it is a return staining message, it is processed in the return staining flow table and stored in the high-speed flow table, and the data of the high-speed flow table is expanded.

2. The method for implementing high-speed serial connection backflow anomaly detection and blocking based on FPGA according to claim 1 is characterized in that: Distinguish and judge the backflow and backcontamination message. If it is not a backflow message, end.

3. The method for implementing high-speed serial connection backflow anomaly detection and blocking based on FPGA according to claim 2, characterized in that: If no matching diversion strategy is found, the corresponding blocking strategy is selected based on the protocol field. If the corresponding blocking policy is hit, the original message is discarded, and it is determined whether the discarded original message is diverted. If so, the discarded original message is encapsulated and diverted through the diversion message processing policy. The discarded original message carries the policy and information hit by the discarded original message.

4. The method for implementing high-speed serial connection backflow anomaly detection and blocking based on FPGA according to claim 3 is characterized in that: If no blocking policy is matched, the original message is output to the link.

5. The method for implementing high-speed serial connection backflow anomaly detection and blocking based on FPGA according to claim 4 is characterized in that: Determine whether the discarded original message needs to be diverted. If not, end the process.

6. The method for implementing high-speed serial connection backflow anomaly detection and blocking based on FPGA according to claim 1, characterized in that: The diversion strategy is at least one or more of a flow-based global diversion strategy, a feature message-based diversion strategy, a five-tuple mask rule-based diversion strategy, and a flexible five-tuple rule-based diversion strategy.

7. The method for implementing high-speed serial connection backflow anomaly detection and blocking based on FPGA according to claim 1, characterized in that: The mirroring policy is at least one or more of a flow-based global mirroring policy, a feature message-based mirroring policy, a five-tuple mask rule-based mirroring policy, and a flexible five-tuple rule-based mirroring policy.

8. The method for implementing high-speed serial connection backflow anomaly detection and blocking message based on FPGA according to claim 1, characterized in that: The blocking strategy is at least one or more of a blocking strategy based on a characteristic message, a blocking strategy based on a five-tuple mask rule, and a blocking strategy based on a flexible five-tuple rule.

9. The method for implementing high-speed serial connection backflow anomaly detection and blocking message based on FPGA according to claim 1, characterized in that: When both the blocking strategy and the diversion strategy are determined to be valid, after the diversion message executes the blocking strategy, the diversion message carries the flag and strategy information of the matching blocking strategy when it is diverted.

10. The FPGA-based high-speed serial connection backflow anomaly detection message blocking implementation method according to claim 9, characterized in that: When receiving the diversion message, the diversion message processing strategy determines whether the diversion message is a false positive. If it is a false positive, the message will flow back to the link.

Images