Traffic data processing method, processor and electronic device
By intercepting and detecting traffic data from enterprise information systems and blocking packet transmission, the problem of false blocking caused by single-IP blocking policies has been solved, and the accuracy of traffic data processing has been improved.
Patent Information
- Application Number
- CN202610794283.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-06-03
- Publication Date
- 2026-08-25
AI Technical Summary
In existing technologies, due to the large number and variety of users in an enterprise or company's information system, single-IP blocking policies may lead to false blocking, resulting in low accuracy in traffic data processing.
By acquiring traffic data from various access devices through the network port, generating data packets, and intercepting and detecting these data packets, blocking packets are sent based on the detection results to block network access to the access devices.
It improves the processing accuracy of traffic data, ensures the accuracy of traffic data processing for accessing devices, and avoids false blocking.
Smart Images

Figure CN122640197A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of vehicles, and more specifically, to a method for processing traffic data, a processor, and an electronic device. Background Technology
[0002] Currently, most devices and products employ a single Internet Protocol (IP) blocking strategy to combat internet cyberattacks. However, for enterprises or companies, information systems involve numerous business processes and a large number and variety of users. Single-IP blocking may result in false alarms due to security operation policies or other reasons. This can cause falsely blocked IPs to be unable to access normal business using traffic data, leading to technical problems such as low accuracy in traffic data processing.
[0003] There is currently no effective solution to the technical problem of low processing accuracy of the aforementioned traffic data. Summary of the Invention
[0004] This application provides a method, processor, and electronic device for processing traffic data, in order to at least solve the technical problem of low processing accuracy of traffic data.
[0005] According to one aspect of the embodiments of this application, a method for processing traffic data is provided. The method includes: acquiring various traffic data from multiple access devices requesting access to the network from a network interface; generating data packets from the various traffic data; performing interception detection on the data packets to obtain an interception detection result; and, in response to the interception detection result indicating that the data packet is in an intercepted state, sending a blocking packet for the data packet to the network interface, wherein the sent blocking packet is used to block the access devices from accessing the network using the traffic data.
[0006] Optionally, intercepting and detecting data packets to obtain interception and detection results includes: storing data packets in a receive memory queue; in response to an interception and detection instruction for data packets, reading the stored data packets from the receive memory queue, and intercepting and detecting the read data packets to obtain interception and detection results.
[0007] Optionally, the read data packets are intercepted and detected to obtain interception and detection results, including: performing shallow packet parsing on the read data packets to obtain shallow packet parsing results, wherein the shallow packet parsing results are structured data that presents traffic data in tuples; performing flow table matching on the shallow packet parsing results and flow table matching results to obtain flow table matching results; and performing behavior detection on the read data packets based on the flow table matching results to obtain interception and detection results.
[0008] Optionally, based on the flow table matching result, behavior detection is performed on the read data packets to obtain interception detection results, including: in response to the flow table matching result indicating that the structure data corresponding to the shallow packet parsing result matches the state data in the flow table, address matching is performed on the read data packets and candidate addresses to obtain address matching results; in response to the address matching result indicating that the source address of the read data packets fails to match the candidate address, access list matching is performed on the read data packets and access list to obtain access list matching results; based on the access list matching results, behavior detection is performed on the read data packets to obtain interception detection results.
[0009] Optionally, based on the access list matching result, behavior detection is performed on the read data packet to obtain the interception detection result, including: in response to the access list matching result indicating that the read data packet fails to match the access rules in the access list, deep packet parsing is performed on the read data packet to obtain the parsing result; based on the parsing result, behavior detection is performed on the read data packet to obtain the interception detection result.
[0010] Optionally, based on the parsing result, behavior detection is performed on the read data packets to obtain interception detection results, including: in response to the protocol corresponding to the parsing result being different from the blacklist protocol and the whitelist protocol, domain name matching is performed on the parsing result and the candidate domain name to obtain a domain name matching result; in response to the domain name matching result indicating that the domain name in the parsing result fails to match the candidate domain name, behavior detection is performed on the read data packets to obtain interception detection results.
[0011] Optionally, in response to the interception detection result indicating that the data packet is in an intercepted state, a blocking packet for the data packet is sent to the network interface, including: in response to the interception detection result indicating that the data packet is in an intercepted state, creating a blocking packet; and sending the blocking packet to the network interface through a sending memory queue.
[0012] According to another aspect of the embodiments of this application, another method for processing traffic data is provided. The method includes: receiving a blocking packet for a data packet, wherein the data packet is generated from various traffic data of various access devices requesting access to the network, and the blocking packet is sent to the network interface in response to an interception detection result obtained by intercepting the data packet indicating that the data packet is in an intercepted state; and blocking the access devices from accessing the network using the traffic data through the blocking packet.
[0013] According to one aspect of the embodiments of this application, a traffic data processing apparatus is provided. The apparatus may include: an acquisition unit, configured to acquire various traffic data from a network interface from various access devices requesting access to the network; a generation unit, configured to generate data packets from the various traffic data; a detection unit, configured to perform interception detection on the data packets and obtain an interception detection result; and a sending unit, configured to send a blocking packet for the data packets to the network interface in response to the interception detection result indicating that the data packets are in an interception state, wherein the sent blocking packet is used to block the access devices from accessing the network using the traffic data.
[0014] According to another aspect of the embodiments of this application, another traffic data processing apparatus is provided, which may include: a receiving unit, configured to receive a blocking packet for a data packet, wherein the data packet is generated from various traffic data of various access devices requesting access to the network respectively, and the blocking packet is sent to the network port in response to an interception detection result obtained by intercepting the data packet indicating that the data packet is in an intercepted state; and a blocking unit, configured to block the access device from accessing the network using the traffic data through the blocking packet.
[0015] According to another aspect of the embodiments of this application, a processor is also provided. The processor is used to run a program, wherein the program is executed by the processor to perform the methods described in the embodiments of this application.
[0016] According to another aspect of the embodiments of this application, an electronic device is also provided, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods in various embodiments of this application when it runs.
[0017] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided. This computer-readable storage medium includes a stored program, wherein, when the program is executed, it controls the device where the computer-readable storage medium is located to perform the methods of the embodiments of this application.
[0018] According to another aspect of the embodiments of this application, a computer program product is also provided, the computer program product including a computer program, wherein the computer program implements the methods in the embodiments of this application when executed by a processor.
[0019] According to another aspect of the embodiments of this application, a computer program product is also provided, including a non-volatile computer-readable storage medium for storing a computer program, which, when executed by a processor, implements the method in the embodiments of this application.
[0020] According to another aspect of the embodiments of this application, a computer program is also provided, which, when executed by a processor, implements the methods described in the embodiments of this application.
[0021] In this embodiment, various traffic data requests from multiple access devices to access the network are obtained from the network port; these traffic data are then generated into data packets; the data packets are intercepted and detected to obtain an interception detection result; in response to the interception detection result indicating that the data packet is in an intercepted state, a blocking packet for the data packet is sent to the network port. Because this embodiment performs interception detection on the data packets after generating them from the acquired traffic data, it can determine whether the data packet is in an intercepted state. If the interception detection result indicates that the data packet is in an intercepted state, a blocking packet for the data packet is sent to the network port. This achieves the goal of blocking access devices from using traffic data to access the network through blocking packets, thereby solving the technical problem of low processing accuracy of traffic data and thus achieving the technical effect of improving the processing accuracy of traffic data. Attached Figure Description
[0022] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:
[0023] Figure 1 This is a schematic diagram illustrating an application scenario of a traffic data processing method according to an embodiment of this application;
[0024] Figure 2 This is a flowchart of a traffic data processing method according to an embodiment of this application;
[0025] Figure 3 This is a flowchart of another method for processing traffic data according to an embodiment of this application;
[0026] Figure 4 This is a schematic diagram of a system for detecting and blocking network bypass traffic quintuples according to an embodiment of this application;
[0027] Figure 5 This is a schematic diagram of a traffic data processing apparatus according to an embodiment of this application;
[0028] Figure 6 This is a schematic diagram of another traffic data processing apparatus according to an embodiment of this application;
[0029] Figure 7 This is a schematic diagram of an electronic device according to an embodiment of this application. Detailed Implementation
[0030] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present application.
[0031] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0032] According to an embodiment of this application, an embodiment of a method for processing traffic data is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.
[0033] As an optional implementation, the above-described traffic data processing method can be applied, but is not limited to, to applications such as... Figure 1 The application scenarios shown. Figure 1 This is a schematic diagram illustrating an application scenario of a traffic data processing method according to an embodiment of this application, such as... Figure 1 As shown, in the application scenario, terminal device 10 can communicate with server 13 via network 11, but is not limited to this. Server 13 can perform operations on the database, such as write or read data operations. Terminal device 10 may include, but is not limited to, a human-computer interaction screen, a processor, and a memory. The human-computer interaction screen can be used to display virtual machines on mobile terminal 10, but is not limited to this. Vehicle 12 can be used to respond to the aforementioned human-computer interaction operations, execute corresponding operations, or generate corresponding instructions and send the generated instructions to server 13.
[0034] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here. Specifically, the processing of traffic data in this application may include: step S102, obtaining various traffic data from multiple access devices requesting network access from the network port; step S104, generating data packets from the various traffic data; step S106, performing interception detection on the data packets to obtain an interception detection result; and step S108, in response to the interception detection result indicating that the data packet is in an intercepted state, sending a blocking packet for the data packet to the network port.
[0035] It should be noted that all information and data involved in this application (including but not limited to traffic data) are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of such data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.
[0036] According to an embodiment of this application, a method for processing traffic data is provided. It should be noted that the steps shown in the flowcharts of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be performed in a different order than that shown here.
[0037] Figure 2 This is a flowchart of a traffic data processing method according to an embodiment of this application, such as... Figure 2 As shown, the method may include the following steps.
[0038] Step S201: Obtain various traffic data from the network interface, representing requests from multiple access devices to access the network.
[0039] In the technical solution provided in step S201 of this application, the aforementioned network port is a network interface, that is, a physical or virtual network adapter port.
[0040] In this embodiment, the aforementioned multiple access devices can be various terminal devices from the Internet or corporate intranet. For example, the aforementioned multiple access devices may include: personal computers (PCs), mobile terminals, servers, Internet of Things (IoT) devices, scanners, and malware, etc.
[0041] In this embodiment, the aforementioned various traffic data can be used to represent communication data and payload content at the packet level. For example, the aforementioned various traffic data can be network communication data streams with different protocols, different purposes, and different behavior patterns.
[0042] In this embodiment, various traffic data from multiple access devices requesting network access are obtained from the network port. Optionally, in this embodiment, when an access device requests network access, the traffic data of that access device's network access request can be obtained from the network interface. For example, when a scanner requests network access, the traffic data of that scanner's network access request can be obtained from the network interface, thereby achieving the purpose of obtaining traffic data from the network port.
[0043] Step S202: Generate data packets from the various traffic data.
[0044] In the technical solution provided in step S202 of this application, the aforementioned data packet is a network unit obtained by structuring and encapsulating traffic data. The aforementioned data packet needs to be stored in a data receiving queue (rx queue).
[0045] In this embodiment, after obtaining various traffic data from multiple access devices requesting network access from the network port, the various traffic data are generated into data packets.
[0046] Optionally, this embodiment can structure the traffic data based on the acquired traffic data to obtain structured traffic data, and encapsulate the structured traffic data to obtain encapsulated traffic data, that is, a data packet, thereby achieving the purpose of generating data packets from multiple types of traffic data.
[0047] Optionally, by parsing the traffic data according to a data parsing protocol, the traffic data content can be obtained. By structuring the traffic data content, structured traffic data content can be obtained. Finally, by encapsulating the structured traffic data content, encapsulated traffic data content can be obtained as data packets.
[0048] Step S203: Intercept and detect the data packets to obtain the interception and detection results.
[0049] In the technical solution provided by step S203 of this application, the interception detection result can be used to indicate whether the data packet is in an intercepted state. For example, the interception detection result can indicate that the data packet is in an intercepted state, or it can indicate that the data packet is not in an intercepted state.
[0050] In this embodiment, after generating data packets from various traffic data, the data packets are intercepted and detected to obtain the interception and detection results.
[0051] Optionally, this embodiment detects whether a data packet interception detection command exists. If a data packet interception detection command is detected, the data packet is intercepted to obtain an interception detection result, thereby achieving the purpose of determining whether the data packet is in an intercepted state.
[0052] Optionally, if an interception and detection instruction for a data packet is detected, the stored data packet is read from the receive memory queue, and shallow packet parsing, flow table matching, and behavior detection are performed on the read data packet in sequence to obtain the interception and detection result.
[0053] Step S204: In response to the interception detection result indicating that the data packet is in an intercepted state, a blocking packet for the data packet is sent to the network interface.
[0054] In the technical solution provided by step S204 of this application, the transmitted blocking packet can be used to block the access device from accessing the network using traffic data. For example, the blocking packet can be a Transmission Control Protocol (TCP) blocking packet.
[0055] In this embodiment, after intercepting and detecting the data packet and obtaining the interception detection result, in response to the interception detection result indicating that the data packet is in an intercepted state, a blocking packet for the data packet is sent to the network port.
[0056] Optionally, in this embodiment, when the interception detection result indicates that the data packet is in an intercepted state, a blocking packet for the data packet is sent to the network interface through the data transmission queue (tx queue), thereby achieving the purpose of blocking the access device from accessing the network using traffic data through the blocking packet.
[0057] Optionally, in this embodiment, if the interception detection result indicates that the data packet is not in an intercepted state, an access permission instruction is sent to the network interface through the tx queue, thereby achieving the purpose of allowing the access device to access the network using traffic data.
[0058] In steps S201 to S204 of this application, various traffic data requests from multiple access devices to access the network are obtained from the network port; these traffic data are generated into data packets; the data packets are intercepted and detected to obtain an interception detection result; in response to the interception detection result indicating that the data packet is in an intercepted state, a blocking packet for the data packet is sent to the network port. Since this embodiment of the application performs interception detection on the data packets after generating them from the obtained traffic data, it can determine whether the data packet is in an intercepted state. If the interception detection result indicates that the data packet is in an intercepted state, a blocking packet for the data packet is sent to the network port. This achieves the goal of blocking access devices from using traffic data to access the network through blocking packets, thereby solving the technical problem of low processing accuracy of traffic data and achieving the technical effect of improving the processing accuracy of traffic data.
[0059] The method described in this embodiment will be further described below.
[0060] As an optional embodiment, step S203, which involves intercepting and detecting data packets to obtain interception and detection results, includes: storing data packets in a receiving memory queue; reading the stored data packets from the receiving memory queue in response to an interception and detection instruction for the data packets; and performing interception and detection on the read data packets to obtain interception and detection results.
[0061] In this embodiment, the aforementioned receive memory queue is the rx queue to which data packets need to be stored.
[0062] In this embodiment, after generating data packets from various traffic data, the generated data packets are stored in a receiving memory queue. Then, the system checks for the presence of interception detection commands for data packets. If an interception detection command for a data packet is detected, the stored data packet is read from the receiving memory queue, and interception detection is performed on the read data packet to obtain the interception detection result. For example, shallow packet parsing, flow table matching, and behavior detection are performed sequentially on the read data packet to obtain the interception detection result. This achieves the goal of determining whether a data packet is in an intercepted state, thereby improving the accuracy of the interception detection result.
[0063] The following section further describes the steps of intercepting and detecting the read data packets and obtaining the interception and detection results in this embodiment.
[0064] As an optional implementation, behavior detection is performed on the read data packets to obtain interception detection results, including: performing shallow packet parsing on the read data packets to obtain shallow packet parsing results; performing flow table matching on the shallow packet parsing results and flow table matching results to obtain flow table matching results; and performing behavior detection on the read data packets based on the flow table matching results to obtain interception detection results.
[0065] In this embodiment, the shallow packet parsing result can be structured data presenting traffic data as tuples. For example, the tuple is a five-tuple (source IP / port, destination IP / port, protocol).
[0066] In this embodiment, after reading the stored data packets from the receive memory queue in response to the interception and detection command for the data packets, shallow packet parsing is performed on the read data packets to obtain shallow packet parsing results. If the shallow packet parsing results indicate that the read data packets have the potential to support processing network layer protocols and transport layer protocols, then flow table matching is performed on the shallow packet parsing results to obtain flow table matching results. Subsequently, based on the flow table matching results, address matching, access list matching, and behavior detection are performed on the read data packets in sequence to obtain interception and detection results. This achieves the goal of determining whether a data packet is in an interception state, thereby improving the technical effect of improving the accuracy of interception and detection results.
[0067] Optionally, the shallow packet parsing described above can include: link layer parsing, network layer parsing, and transport layer parsing. For example, shallow packet parsing can be performed as follows: extracting the Ethernet header from the packet's memory buffer (mbuf), parsing the Ethernet type and source / destination MAC address, saving this information to the packet's context structure, thereby identifying whether the Ethernet type supports processing, and returning a support status enumeration value. Network layer parsing can be performed as follows: parsing the IPv4 / IPv6 class, source IP, destination IP, and network layer protocol, thereby identifying whether the network layer protocol supports processing, and returning a support status enumeration value. Transport layer parsing can be performed as follows: parsing TCP and User Datagram Protocol (UDP), and obtaining the source port, destination port, acknowledgment number (recv_ack) from the receiving end, and sender sequence number (sent_seq), thereby identifying whether the transport layer protocol supports processing. If an unsupported transport layer protocol is identified, the process proceeds to the packet output step. If a whitelisted protocol is identified, the process proceeds to the packet output step. If a supported transport layer protocol is identified, the process continues and flow table matching begins.
[0068] The following section further describes the steps of performing behavior detection on the read data packets based on the flow table matching results in this embodiment to obtain the interception detection results.
[0069] As an optional implementation, based on the flow table matching result, behavior detection is performed on the read data packets to obtain an interception detection result, including: in response to the flow table matching result indicating that the structure data corresponding to the shallow packet parsing result matches the state data in the flow table, address matching is performed on the read data packets and candidate addresses to obtain an address matching result; in response to the address matching result indicating that the source address of the read data packets fails to match the candidate address, access list matching is performed on the read data packets and access list to obtain an access list matching result; based on the access list matching result, behavior detection is performed on the read data packets to obtain an interception detection result.
[0070] In this embodiment, the candidate addresses may include an IP blacklist and an IP whitelist.
[0071] In this embodiment, the source address can be the source IP address.
[0072] In this embodiment, after performing flow table matching on the shallow packet parsing results and obtaining the flow table matching results, if the flow table matching results indicate that the structure data corresponding to the shallow packet parsing results matches the state data in the flow table, then the read data packets are matched against the IP blacklist and IP whitelist to obtain the address matching results. If the address matching results indicate that the source address of the read data packets fails to match the IP blacklist and IP whitelist, then the read data packets are matched against the access control list (ACL) to obtain the access list matching results. Subsequently, based on the access list matching results, deep packet parsing and behavior detection are sequentially performed on the read data packets to obtain the interception detection results. This achieves the goal of determining whether a data packet is in an intercepted state, thereby improving the accuracy of the interception detection results.
[0073] For example, the IP intelligence matching described above can be performed as follows: When the program starts, it initializes the IP_IOC management context, creates a Bloom filter, a whitelist hash table, and a blacklist hash table. Then, it reads the whitelist hash table and the blacklist hash table from shared memory. The IP_IOC management context can include: the current IP_IOC context structure, the current shared memory handle, the context switching lock, the numa node, and the last synchronization time. The shared memory is designed as a dual data area to eliminate read / write contention and waiting. Different producers and consumers operate on different buffers through the context switching lock, naturally avoiding lock contention. In this scenario, IP_IOC is read-only for detection, while other programs can write to and update the whitelist and blacklist hash tables in another shared memory area. The IP_IOC detection process is as follows: First, the flow key (forward and reverse) is extracted to detect IP pairs, checking the source IP and destination IP respectively. A Bloom filter is used to match whether the IP is in the whitelist or blacklist. If it is in the whitelist, IP intelligence matching is performed; if it is in the blacklist, IP intelligence matching is allowed but rejected. Update the flow table, adding the current flow key (i.e., the 5-tuple, IP protocol port) and the IP_IOC action. If the IP is blacklisted, proceed to the TCP blocking RST packet generation step. If the IP is whitelisted, proceed to the packet output step; if the process continues, perform ACL matching.
[0074] For example, the above ACL matching can be performed as follows: Initialize the ACL management context structure instance, create and link shared memory, and initialize the ACL with the ACL rule data in the shared memory using DPDK functions such as rte_acl_create and rte_acl_build. The ACL actions can be categorized as ignoring the packet, allowing the packet, or denying the packet. ACL rules can include: ACL identification (ID), source IP, destination IP, port, protocol expiration time, ACL action, and priority. The ACL filtering context can include: a DPDK-specific rte_acl_ctx structure, a reference counter, and a context creation timestamp. The ACL management context structure, similar to the IP_IOC structure above, can include: the currently active ACL filtering context, context switching lock, shared memory handle, numa node, and last synchronization time. If the ACL action denies, the process proceeds to the TCP blocking RST packet generation step; if the ACL action ignores, the process proceeds to the packet output step; if the process continues, deep packet parsing is performed.
[0075] The following section further describes the steps of performing behavior detection on the read data packets based on the access list matching results in this embodiment to obtain the interception detection results.
[0076] As an optional implementation, behavior detection is performed on the read data packets based on the access list matching result to obtain an interception detection result, including: in response to the access list matching result indicating that the read data packets fail to match the access rules in the access list, deep packet analysis is performed on the read data packets to obtain a parsing result; based on the parsing result, behavior detection is performed on the read data packets to obtain an interception detection result.
[0077] In this embodiment, the access rules described above can be used to match the relationship between the read data packets and the data packets to be ignored, allowed, and denied.
[0078] In this embodiment, after matching the read data packet with the access list to obtain the access list matching result, if the access list matching result indicates that the read data packet fails to match the access rules in the access list—that is, if the read data packet is not a data packet to be ignored, allowed, or denied—then deep packet inspection is performed on the read data packet to obtain the analysis result. Based on the analysis result, behavior detection is then performed on the read data packet to obtain the interception detection result. This achieves the goal of determining whether a data packet is in an intercepted state, thereby improving the accuracy of the interception detection result.
[0079] The following section further describes the steps of performing behavior detection on the read data packets based on the parsing results to obtain the interception detection results in this embodiment.
[0080] As an optional implementation method, based on the parsing result, behavior detection is performed on the read data packets to obtain the interception detection result, including: in response to the protocol corresponding to the parsing result being different from the blacklist protocol and the whitelist protocol, the parsing result is matched with the candidate domain name to obtain the domain name matching result; in response to the domain name matching result indicating that the domain name in the parsing result fails to match the candidate domain name, behavior detection is performed on the read data packets to obtain the interception detection result.
[0081] In this embodiment, the candidate domain names may include a blacklist of matching domain names and a whitelist of matching domain names.
[0082] In this embodiment, after performing deep packet inspection on the read data packets and obtaining the inspection results, if the protocol corresponding to the inspection results is different from the blacklist and whitelist protocols, then the inspection results are matched with the matching domain blacklist and matching domain whitelist to obtain the domain matching results. If the domain matching results indicate that the domain in the inspection results fails to match the matching domain blacklist and matching domain whitelist, behavior detection is performed on the read data packets to obtain the interception detection results. This achieves the goal of determining whether the data packets are in an interception state, thereby improving the accuracy of the interception detection results.
[0083] Optionally, if the domain name matching result indicates that the domain name in the resolution result matches the blacklist of matching domain names, a blocking packet is created for the data packet. If the domain name matching result indicates that the domain name in the resolution result matches the whitelist of matching domain names, the data packet is output by sending it to a memory queue.
[0084] The following section further describes the steps of responding to the interception detection result in this embodiment, indicating that the data packet is in an intercepted state, and sending a blocking packet for the data packet to the network interface.
[0085] As an optional implementation, in response to the interception detection result indicating that the data packet is in an intercepted state, a blocking packet for the data packet is sent to the network interface, including: in response to the interception detection result indicating that the data packet is in an intercepted state, creating a blocking packet; and sending the blocking packet to the network interface through a sending memory queue.
[0086] In this embodiment, the aforementioned sending memory queue is the data sending queue (tx queue).
[0087] In this embodiment, after obtaining the interception detection result, if the interception detection result indicates that the data packet is in an intercepted state, a blocking packet is created for the data packet. Then, the blocking packet is sent to the network port through the tx queue. This achieves the goal of blocking access devices from using traffic data to access the network through the blocking packet, thereby improving the technical effect of improving the processing accuracy of traffic data.
[0088] In this embodiment, after generating data packets from the various types of traffic data, the data packets are intercepted and detected to determine whether they are in an intercepted state. If the interception detection result indicates that the data packet is in an intercepted state, a blocking packet for the data packet is sent to the network port. This achieves the goal of blocking access devices from using traffic data to access the network through the blocking packet, thereby solving the technical problem of low processing accuracy of traffic data and achieving the technical effect of improving the processing accuracy of traffic data.
[0089] According to an embodiment of this application, a method for processing traffic data is provided. It should be noted that the steps shown in the flowcharts of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be performed in a different order than that shown here.
[0090] Figure 3 This is a flowchart of a traffic data processing method according to an embodiment of this application, such as... Figure 3 As shown, the method may include the following steps.
[0091] Step S301: Receive a blocking packet for the data packet.
[0092] In the technical solution provided by step S301 of this application, the data packet is generated by generating various traffic data of various access devices requesting access to the network.
[0093] In this embodiment, the aforementioned blocking packet is sent to the network interface in response to the interception detection result obtained from the interception detection of the data packet, indicating that the data packet is in an intercepted state.
[0094] In this embodiment, blocking packets targeting data packets are received. Optionally, this embodiment can receive blocking packets from a transmit memory queue via a network interface.
[0095] Step S302: By blocking packets, the access device is prevented from accessing the network using traffic data.
[0096] In the technical solution provided by step S302 of this application, after receiving the blocking packet for the data packet, the access device is blocked from accessing the network using traffic data through the blocking packet.
[0097] Optionally, this embodiment uses TCP blocking packets to block the mobile terminal from accessing the network using its traffic data, thereby achieving the goal of blocking the access device from accessing the network using traffic data through blocking packets.
[0098] In steps S301 to S302 of this application, a blocking packet for the data packet is received. By using the blocking packet, the access device is blocked from accessing the network using traffic data. This achieves the purpose of blocking the access device from accessing the network using traffic data through the blocking packet, thereby solving the technical problem of low processing accuracy of traffic data and thus achieving the technical effect of improving the processing accuracy of traffic data.
[0099] The technical solutions of the embodiments of this application will be illustrated below with reference to preferred embodiments.
[0100] Currently, most devices and products employ a single-IP blocking strategy to counter internet cyberattacks. However, for enterprises or companies, information systems involve numerous business processes and a large number and variety of users. Single-IP blocking may result in false alarms due to security operation policies or other reasons. This can cause falsely blocked IPs to be unable to access normal business using traffic data, leading to technical problems such as low accuracy in traffic data processing.
[0101] To address the aforementioned technical problems, this application proposes a method for processing traffic data. After generating data packets from various acquired traffic data, the method performs interception detection on the data packets to determine whether they are in an interception state. If the interception detection result indicates that the data packet is in an interception state, a blocking packet targeting the data packet is sent to the network port. This achieves the goal of blocking access devices from using traffic data to access the network through the blocking packet, thereby solving the technical problem of low processing accuracy of traffic data and achieving the technical effect of improving the processing accuracy of traffic data.
[0102] In this embodiment, a detection and blocking system for network bypass traffic quintuples can, in response to a detection result indicating that a data packet is in an intercepted state, block access devices from using traffic data to access the network by blocking the data packet. For example, Figure 4 This is a schematic diagram of a network bypass traffic quintuple detection and blocking system according to an embodiment of this application, as shown below. Figure 4 As shown, the system 400 may include: a data receiving queue 401, an interception and detection module 402, and a data sending queue 403.
[0103] In this embodiment, the data receiving queue (rx queue) 401 described above can be used to store data packets generated from traffic data.
[0104] For example, the system obtains network traffic data from the network port, generates data packets from the traffic data, and imports the generated data packets into the data receiving queue 401.
[0105] In this embodiment, the interception and detection module 402 can be used to read data packets from the data receiving queue 401 and perform the following interception and detection operations on the read data packets: shallow packet parsing, flow table matching, IP intelligence matching, access control list (ACL) matching, deep packet parsing, domain name intelligence matching, and traffic behavior feature (flow_ips) detection.
[0106] In this embodiment, the shallow packet parsing described above can include: link layer parsing, network layer parsing, and transport layer parsing. For example, the shallow packet parsing can be performed as follows: extracting the Ethernet header from the mbuf of the data packet, parsing out the Ethernet type and source / destination MAC address, saving them to the packet's context structure, thereby identifying whether the Ethernet type supports processing, and returning a support status enumeration value. The network layer parsing can be performed as follows: parsing the IPv4 / IPv6 class, source IP, destination IP, and network layer protocol, thereby identifying whether the network layer protocol supports processing, and returning a support status enumeration value. The transport layer parsing can be performed as follows: parsing TCP and UDP, and obtaining the source port, destination port, acknowledgment number (recv_ack) from the receiving end, and sender sequence number (sent_seq), thereby identifying whether the transport layer protocol supports processing.
[0107] In this embodiment, if an unsupported transport layer protocol is identified, the process proceeds to the packet output step. If a whitelisted protocol is identified, the process proceeds to the packet output step. If a supported transport layer protocol is identified, the process continues, and flow table matching begins.
[0108] In this embodiment, the flow table matching described above can be performed as follows: A DPDK lock-free hash table is created using the creation key (rte_hash_create) of the Data Plane Development Kit (DPDK). The created DPDK lock-free hash table may include: a name, the maximum number of entries in the flow table, a pointed-to flow key structure (cp_flow_key_t), a hash seed, and a Non-Uniform Memory Access Node (NUMA_Node). The cp_flow_key_t may include: source IP, destination IP, source port, destination port, the IP protocol number for TCP / UDP, and the IPv4 / IPv6 identifier. The flow key (flow_key), i.e., the IP address, port, and protocol in the data packet, is extracted from the packet context. Then, a flow table entry is searched, prioritizing forward flow entries. If the flow key is found, the flow table is matched. A flow entry flow_entry_ is initialized, and the timestamp and whether the flow_entry_t instance is a TCP packet identifier are updated. This flow entry is then returned. If the flow table is not found, an empty branch is returned. If the forward flow does not exist, first use `flow_key_reverse` to reverse the source IP and source port of the current flow key `flow_key` (network traffic packets are divided into inbound and outbound directions) and copy them to the reverse flow key (`reverse_key`). Creating forward and reverse flow table entries can be done as follows: For a forward flow entry, initialize the flow entry's action to the `STAGE_RESULT_SUCCESS` enumeration value (`stage_result_t`), initialize `policy_id` to 0, and perform other initialization actions. Then, use `rte_hash_add_key_data` to add the newly added flow key and flow entry to the flow table. Creating a reverse flow entry is the same as creating a forward flow entry, but uses the reverse flow key `reverse_key`. Add it to the flow table, and then search for the newly created forward flow table entry. Since a forward flow entry was created in the previous step, it will be found. Get the result of the current flow entry action (atomic read), update the flow entry statistics, release the flow entry reference, and use dump_flow_match_result to print some flow entry action information for packet data matching.Finally, based on the action result of the flow table entry, the final result is determined and returned as an enumeration value. The returned enumeration value is then used as the input parameter of the step transition function to perform the following transition steps: Transition 1: If the process continues, start performing IP intelligence matching; Transition 2: If IP_IOC is allowed, ACL is allowed, whitelist protocol, domain name IOC is allowed, etc., then proceed to the packet output step; Transition 3: If IP_IOC is rejected, ACL is rejected, blacklist protocol, domain name IOC is rejected, then proceed to the TCP blocking RST packet generation step.
[0109] In this embodiment, the aforementioned IP intelligence can be executed as follows: Upon program startup, the IP_IOC management context is initialized, a Bloom filter is created, a whitelist hash table is created, and a blacklist hash table is created. Then, the whitelist hash table and blacklist hash table are read from shared memory. The IP_IOC management context may include: the current IP_IOC context structure, the current shared memory handle, a context switching lock, a NUMA node, and the last synchronization time. The shared memory is designed as a dual data area to eliminate read / write contention and waiting. Different producers and consumers operate on different buffers through the context switching lock, naturally avoiding lock contention. The scenario is that IP_IOC is read-only for detection, while other programs can write to and update the whitelist and blacklist hash tables in another shared memory area. The IP_IOC detection process is as follows: First, the flow key (forward and reverse) is extracted to detect IP pairs, checking the source IP and destination IP respectively. A Bloom filter is used to match whether the IP is in the whitelist or blacklist. If it is in the whitelist, the IP intelligence is matched; if it is in the blacklist, the IP intelligence matching is allowed but rejected. Update the flow table, adding the current flow key (i.e., the 5-tuple, IP protocol port) and the IP_IOC action. If the IP is blacklisted, proceed to the TCP blocking RST packet generation step. If the IP is whitelisted, proceed to the packet output step; if the process continues, perform ACL matching.
[0110] In this embodiment, the ACL matching can be performed as follows: Initialize the ACL management context structure instance, create and link shared memory, and initialize the ACL using the ACL rule data in the shared memory through DPDK functions such as rte_acl_create and rte_acl_build. The ACL actions can be categorized as ignoring the packet, allowing the packet, or denying the packet. ACL rules can include: ACL ID, source IP, destination IP, port, protocol expiration time, ACL action, and priority. The ACL filtering context can include: a DPDK-specific rte_acl_ctx structure, a reference counter, and a context creation timestamp. The ACL management context structure, similar to the IP_IOC structure above, can include: the currently active ACL filtering context, context switching lock, shared memory handle, numa node, and last synchronization time. If the ACL action denies, proceed to the TCP blocking RST packet generation step; if the ACL action ignores, proceed to the packet output step; if the process continues, perform deep packet parsing.
[0111] In this embodiment, the deep packet inspection can be performed as follows: if the protocol is resolved to a blacklist, proceed to the TCP blocking RST packet generation step; if the protocol is resolved to a whitelist, proceed to the packet output step; if the process continues, perform domain name information matching.
[0112] In this embodiment, the domain name intelligence matching can be performed as follows: if the domain name matches the blacklist, proceed to the TCP blocking RST packet generation step; if the domain name matches the whitelist, proceed to the packet output step; if the process continues, perform flow_ips detection.
[0113] In this embodiment, the above flow_ips detection can be performed as follows: if the detection fails, proceed to the TCP blocking RST packet generation step; if the process continues, proceed to the packet output step.
[0114] In this embodiment, the aforementioned data sending queue (tx queue) 403 can send constructed TCP blocking packets to the network interface.
[0115] In this embodiment, after generating data packets from the acquired various traffic data, the data packets are intercepted and detected to determine whether the data packets are in an intercepted state. If the interception detection result indicates that the data packets are in an intercepted state, a blocking packet for the data packets is sent to the network port. This achieves the goal of blocking access devices from using traffic data to access the network through blocking packets, thereby solving the technical problem of low processing accuracy of traffic data and thus achieving the technical effect of improving the processing accuracy of traffic data.
[0116] According to an embodiment of this application, a traffic data processing apparatus is also provided. It should be noted that this traffic data processing apparatus can be used to execute one of the traffic data processing methods described in the embodiments.
[0117] Figure 5 This is a schematic diagram of a traffic data processing apparatus according to an embodiment of this application. Figure 5 As shown, the traffic data processing device 500 may include: an acquisition unit 501, a generation unit 502, a detection unit 503, and a transmission unit 504.
[0118] The acquisition unit 501 is used to acquire various traffic data from the network port for various access devices requesting access to the network.
[0119] The generation unit 502 is used to generate data packets from various types of traffic data.
[0120] The detection unit 503 is used to intercept and detect data packets and obtain the interception and detection results.
[0121] The sending unit 504 is used to send a blocking packet for the data packet to the network interface in response to the interception detection result indicating that the data packet is in an interception state. The sent blocking packet is used to block the access device from accessing the network using traffic data.
[0122] Optionally, the detection unit 503 may include: a storage module for storing data packets in a receiving memory queue; and a detection module for reading the stored data packets from the receiving memory queue in response to an interception and detection command for the data packets, and performing interception and detection on the read data packets to obtain an interception and detection result.
[0123] Optionally, the detection module may include: a parsing submodule, used to perform shallow packet parsing on the read data packets to obtain shallow packet parsing results, wherein the shallow packet parsing results are structured data that presents traffic data in tuples; a matching submodule, used to perform flow table matching on the shallow packet parsing results and flow table to obtain flow table matching results; and a detection submodule, used to perform behavior detection on the read data packets based on the flow table matching results to obtain interception detection results.
[0124] Optionally, the detection submodule can perform the following steps to perform behavior detection on the read data packets based on the flow table matching results, and obtain the interception detection results: In response to the flow table matching result indicating that the structure data corresponding to the shallow packet parsing result matches the state data in the flow table, the read data packets are matched with the candidate addresses to obtain the address matching results; In response to the address matching result indicating that the source address of the read data packets fails to match the candidate address, the read data packets are matched with the access list to obtain the access list matching results; Based on the access list matching results, the read data packets are subjected to behavior detection to obtain the interception detection results.
[0125] Optionally, the detection submodule can perform the following steps to perform behavior detection on the read data packets based on the access list matching results, and obtain the interception detection results: in response to the access list matching result indicating that the read data packets fail to match the access rules in the access list, perform deep packet parsing on the read data packets to obtain the parsing results; based on the parsing results, perform behavior detection on the read data packets to obtain the interception detection results.
[0126] Optionally, the detection submodule can perform the following steps to perform behavior detection on the read data packets based on the parsing results and obtain the interception detection results: in response to the protocol corresponding to the parsing result being different from the blacklist protocol and the whitelist protocol, perform domain name matching on the parsing result and the candidate domain name to obtain the domain name matching result; in response to the domain name matching result indicating that the domain name in the parsing result fails to match the candidate domain name, perform behavior detection on the read data packets to obtain the interception detection results.
[0127] Optionally, the sending unit 504 may include: a creation module, used to create a blocking packet in response to an interception detection result indicating that the data packet is in an interception state; and a sending module, used to send the blocking packet to the network interface through a sending memory queue.
[0128] In this embodiment, a traffic data processing apparatus is provided. The apparatus may include an acquisition unit for acquiring various traffic data from multiple access devices requesting network access from a network port; a generation unit for generating data packets from the various traffic data; a detection unit for intercepting and detecting the data packets to obtain interception and detection results; and a sending unit for sending a blocking packet to the network port in response to the interception and detection results indicating that the data packet is in an intercepted state. The sent blocking packet is used to block access devices from using traffic data to access the network, thereby achieving the goal of blocking access devices from using traffic data to access the network through blocking packets, thus solving the technical problem of low processing accuracy of traffic data, and thus achieving the technical effect of improving the processing accuracy of traffic data.
[0129] According to an embodiment of this application, another traffic data processing apparatus is also provided. It should be noted that this traffic data processing apparatus can be used to execute one of the traffic data processing methods described in the embodiments.
[0130] Figure 6 This is a schematic diagram of a traffic data processing apparatus according to an embodiment of this application. Figure 6 As shown, the traffic data processing device 600 may include a receiving unit 601 and a blocking unit 602.
[0131] The receiving unit 601 is used to receive a blocking packet for a data packet, wherein the data packet is generated by various traffic data of various access devices requesting access to the network, and the blocking packet is sent to the network port in response to the interception detection result obtained by intercepting the data packet, indicating that the data packet is in an intercepted state.
[0132] The blocking unit 602 is used to block access devices from accessing the network using traffic data by blocking packets.
[0133] In this embodiment, a traffic data processing apparatus is provided. The apparatus may include: a receiving unit for receiving blocking packets for data packets, wherein the data packets are generated from various traffic data requests from multiple access devices to access the network, and the blocking packets are sent to the network interface in response to an interception detection result indicating that the data packets are in an intercepted state; and a blocking unit for blocking access devices from accessing the network using traffic data through the blocking packets. This achieves the goal of blocking access devices from accessing the network using traffic data through blocking packets, thereby solving the technical problem of low processing accuracy of traffic data and achieving the technical effect of improving the processing accuracy of traffic data.
[0134] According to an embodiment of this application, a processor is also provided for running a program, wherein the program is executed by the processor to perform the methods described in the embodiment.
[0135] According to an embodiment of this application, an electronic device is also provided. Figure 7 This is a schematic diagram of an electronic device according to an embodiment of this application, such as... Figure 7 As shown, the electronic device 700 may include a memory 710 and a processor 720, wherein the memory 710 is used to store an executable program; and the processor 720 is used to run the program stored in the memory 710, wherein the program executes the methods in various embodiments of this application when it runs.
[0136] In this application, "multiple" refers to two or more.
[0137] In this application, unless otherwise expressly defined, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection between two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.
[0138] The terms “first,” “second,” “third,” “fourth,” etc., in this application (if present) are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.
[0139] In this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, in this application, the character " / " generally indicates that the preceding and following related objects have an "or" relationship.
[0140] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided. This computer-readable storage medium includes a stored program, wherein, when the program is executed, it controls the device on which the computer-readable storage medium is located to perform the method described in the embodiments.
[0141] Computer-readable storage media, also known as computer storage media, may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. These propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable storage media can transmit, propagate, or transfer programs for use by or in conjunction with an instruction execution system, apparatus, or device.
[0142] The program code contained in a computer-readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, radio frequency, or any suitable combination thereof.
[0143] According to an embodiment of this application, a computer program product is also provided, which includes a computer program, wherein the computer program, when executed by a processor, implements the method in the embodiment.
[0144] According to an embodiment of this application, a computer program product is also provided, including a non-volatile computer-readable storage medium for storing a computer program, which, when executed by a processor, implements the method described in the embodiment.
[0145] According to an embodiment of this application, a computer program is also provided, which, when executed by a processor, implements the method described in the embodiment.
[0146] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.
[0147] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.
[0148] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between units or modules may be electrical or other forms.
[0149] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0150] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0151] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to related technologies, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.
[0152] The above are merely preferred embodiments of this application. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this application, and these improvements and modifications should also be considered within the scope of protection of this application.
Claims
1. A method for processing traffic data, characterized in that, include: Obtain various traffic data from multiple access devices requesting network access from the network port; Generate data packets from the various types of traffic data respectively; The data packets are intercepted and detected to obtain the interception and detection results; In response to the interception detection result indicating that the data packet is in an intercepted state, a blocking packet for the data packet is sent to the network port, wherein the sent blocking packet is used to prevent the access device from accessing the network using the traffic data.
2. The method according to claim 1, characterized in that, The data packets are intercepted and detected to obtain the interception and detection results, including: Store the data packet in the receive memory queue; In response to an interception and detection instruction for the data packet, the stored data packet is read from the receive memory queue, and the read data packet is intercepted and detected to obtain the interception and detection result.
3. The method according to claim 2, characterized in that, The interception and detection of the read data packets are performed to obtain the interception and detection results, including: The read data packets are subjected to shallow packet parsing to obtain shallow packet parsing results, wherein the shallow packet parsing results are structured data that presents the traffic data in tuples; The shallow packet parsing results are matched with the flow table to obtain the flow table matching results; Based on the flow table matching results, behavior detection is performed on the read data packets to obtain the interception detection results.
4. The method according to claim 3, characterized in that, Based on the flow table matching results, behavior detection is performed on the read data packets to obtain the interception detection results, including: In response to the flow table matching result indicating that the structure data corresponding to the shallow packet parsing result matches the state data in the flow table, the read data packet is matched with the candidate address to obtain the address matching result; In response to the address matching result indicating that the source address of the read data packet fails to match the candidate address, the read data packet is matched with the access list to obtain the access list matching result; Based on the access list matching results, behavior detection is performed on the read data packets to obtain the interception detection results.
5. The method according to claim 4, characterized in that, Based on the access list matching results, behavior detection is performed on the read data packets to obtain the interception detection results, including: In response to the access list matching result indicating that the read data packet fails to match the access rules in the access list, deep packet parsing is performed on the read data packet to obtain the parsing result; Based on the parsing results, behavior detection is performed on the read data packets to obtain the interception detection results.
6. The method according to claim 5, characterized in that, Based on the parsing results, behavior detection is performed on the read data packets to obtain the interception detection results, including: In response to the fact that the protocol corresponding to the parsing result is different from the blacklist protocol and the whitelist protocol, the parsing result is matched with the candidate domain name to obtain the domain name matching result; In response to the domain name matching result indicating that the domain name in the resolution result fails to match the candidate domain name, behavior detection is performed on the read data packet to obtain the interception detection result.
7. The method according to any one of claims 1 to 6, characterized in that, In response to the interception detection result indicating that the data packet is in an intercepted state, a blocking packet for the data packet is sent to the network interface, including: In response to the interception detection result indicating that the data packet is in the interception state, the blocking packet is created; The blocking packet is sent to the network port via a memory queue.
8. A method for processing traffic data, characterized in that, include: Receive a blocking packet for a data packet, wherein the data packet is generated from various traffic data of various access devices requesting access to the network, and the blocking packet is sent to the network interface in response to the interception detection result obtained by intercepting the data packet, indicating that the data packet is in an intercepted state; The blocking packet prevents the accessing device from accessing the network using the traffic data.
9. A processor, characterized in that, The processor is used to run a program, wherein the program is executed by the processor to perform the method according to any one of claims 1 to 8.
10. An electronic device, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, performs the method according to any one of claims 1 to 8.