Abnormal traffic alarm method, device, system, electronic equipment and storage medium

Abstract

The application provides an abnormal flow alarm method, device and system, electronic equipment and storage medium, and relates to the technical field of communication. The method comprises the following steps: a management platform sends configuration information to an SRv6 node and a flow screening device, wherein the configuration information comprises an abnormal detection rule, a DNS special TLV configuration, a DNS special SID set and a path forwarding strategy; an edge node identifies DNS flow, extracts DNS flow characteristics and fills them into a DNS special TLV field, encapsulates an SRv6 message and loads an access SID, and sends the message to a target flow screening device; the screening device analyzes the TLV field, and performs abnormal detection based on the DNS flow characteristics and the abnormal detection rule; when the DNS flow is detected as abnormal flow, abnormal alarm information is generated and filled into the TLV field, an alarm message is obtained by re-encapsulation and a reporting SID is loaded, and the alarm message is sent to the management platform. The application improves the efficiency of DNS flow abnormal detection.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and specifically to an abnormal traffic alarm method, device, system, electronic device, and storage medium. Background Technology

[0002] With the increasing demand for network security protection, the Domain Name System (DNS), as the core entry point for network access, has seen its abnormal traffic become a significant carrier of network attacks, posing a serious threat to network security. Traffic filtering devices, as network hardware for detecting abnormal traffic, are deployed at the network egress point to perform protocol parsing, feature extraction, rule matching, anomaly detection, and traffic redirection on DNS traffic, thereby enabling the filtering and alerting of abnormal DNS traffic.

[0003] In related technologies, DNS anomaly traffic filtering and alarm schemes are typically implemented based on traditional IP networks (Internet Protocol Networks, IP Networks). The management platform sends DNS anomaly detection rules to the traffic filtering device. The traditional IP network blindly sends DNS traffic to the traffic filtering device, which performs local resolution on the DNS traffic, performs multi-layer decapsulation on the DNS packets, and matches them with the anomaly detection rules to achieve anomaly detection of DNS traffic. When anomaly traffic is detected, the traffic filtering device generates alarm information and reports it to the management platform through an independent control channel. The alarm information is transmitted separately from the anomaly traffic packets.

[0004] However, the above methods have the following problems in implementation: the traffic filtering device needs to repeatedly resolve DNS traffic and perform multi-layer decapsulation, resulting in high computing power overhead and low detection efficiency; at the same time, alarm information is transmitted separately from business traffic, relying on independent signaling channels, resulting in high reporting latency and bandwidth bottlenecks in cross-node synchronization; in addition, DNS traffic still adopts a blind transmission mode in the network, which has poor compatibility with the new generation SRv6 network and is difficult to meet the requirements of high performance, high real-time performance and high accuracy DNS security protection. Summary of the Invention

[0005] The present invention aims to provide an abnormal traffic alarm method, device, system, electronic device and storage medium to at least solve the problems of high computing power consumption, low detection efficiency, high reporting latency and poor compatibility with the new generation SRv6 network in the existing technology.

[0006] The technical solution of the present invention to solve the above-mentioned technical problems is as follows: This invention provides an abnormal traffic alarm method, comprising: The management platform sends configuration information to SRv6 nodes and traffic filtering devices. The configuration information includes anomaly detection rules, DNS dedicated TLV configuration, DNS dedicated SID set and path forwarding policy. The DNS dedicated SID set includes access SID and reporting SID. The SRv6 edge node identifies DNS traffic, extracts DNS traffic features and fills them into the DNS-specific TLV field, encapsulates them to obtain an SRv6 packet and loads the access SID, and sends the SRv6 packet to the corresponding target traffic filtering device based on the path forwarding policy; The target traffic filtering device receives the SRv6 message and parses the DNS-specific TLV field. Based on the DNS traffic characteristics and the anomaly detection rules, it performs anomaly detection on the DNS traffic. When the DNS traffic is detected as abnormal, it generates an anomaly alarm message and fills it into the DNS-specific TLV field. It then re-encapsulates the alarm message and loads the reporting SID. Based on the path forwarding policy, it sends the alarm message to the management platform.

[0007] The technical solution provided by this invention brings at least the following beneficial effects: In the abnormal traffic alarm method provided by this invention, the SRv6 edge node completes DNS traffic identification and feature extraction, and fills the extracted DNS traffic features into the DNS-dedicated TLV field. Subsequent traffic filtering devices can directly obtain DNS traffic features by parsing the DNS-dedicated TLV field without repeatedly parsing DNS packets, reducing local resolution and decapsulation operations, reducing device computing load, and improving anomaly detection efficiency. At the same time, by accessing the SID and path forwarding strategy, DNS traffic is accurately guided to the target traffic filtering device, replacing the traditional blind transmission mode, and improving traffic scheduling and detection response speed. In addition, by filling the abnormal alarm information into the DNS-dedicated TLV field and reporting it to the management platform along with the alarm message based on the reporting SID and path forwarding strategy, alarms do not need to be transmitted through a separate control channel. This achieves alarms and traffic being transmitted along the same path in an integrated manner, reducing alarm latency and alleviating the bandwidth bottleneck caused by cross-node synchronization.

[0008] Based on the above technical solution, the present invention can be further improved as follows.

[0009] Furthermore, the method also includes: the management platform receiving the alarm message; extracting the SID path list from the alarm message; parsing the DNS-specific TLV field to extract the abnormal alarm information and the DNS traffic characteristics; determining all transmission nodes on the DNS traffic transmission path based on the SID path list and the DNS traffic characteristics; and performing corresponding abnormal handling according to a preset handling strategy based on the abnormal alarm information.

[0010] The beneficial effects of this solution are as follows: By receiving alarm messages and extracting the SID path list, the management platform can accurately locate all nodes on the transmission path of abnormal DNS traffic by combining the abnormal alarm information in the DNS-specific TLV field with DNS traffic characteristics. This enables automated tracing and handling of abnormal traffic along the entire path, eliminating the need for manual path verification and reducing handling time. Furthermore, the management platform can perform abnormal handling on the corresponding transmission nodes according to preset handling strategies, improving the targeting and timeliness of abnormal handling.

[0011] Furthermore, the step of detecting anomalies in the DNS traffic based on the DNS traffic characteristics and the anomaly detection rules includes: comparing the DNS traffic characteristics with the anomaly determination conditions of each of the locally synchronized anomaly detection rules; if at least one of the DNS traffic characteristics satisfies the corresponding anomaly determination condition, then the DNS traffic is determined to be abnormal traffic.

[0012] The beneficial effects of this scheme are as follows: By comparing DNS traffic characteristics with the anomaly judgment conditions of locally synchronized anomaly detection rules, DNS traffic is determined to be abnormal traffic when at least one of the DNS traffic characteristics meets the anomaly judgment conditions, thus providing a basis for the anomaly detection of DNS traffic and improving the accuracy of DNS abnormal traffic identification; at the same time, comparison based on locally synchronized anomaly detection rules reduces the overhead of repeated rule queries and remote interaction, thereby improving the response speed and processing efficiency of anomaly detection.

[0013] Furthermore, the management platform assigns a unique rule identifier to each of the anomaly detection rules; when extracting DNS traffic features and filling them into the DNS-specific TLV field, the method further includes: determining the rule that matches the DNS traffic from the locally synchronized anomaly detection rules, obtaining the corresponding rule identifier, and filling the rule identifier into the DNS-specific TLV field.

[0014] The beneficial effects of this scheme are as follows: By assigning a unique rule identifier to each anomaly detection rule, and having the SRv6 edge node fill the DNS-specific TLV field with the rule identifier that matches the DNS traffic, the traffic filtering device can quickly locate the corresponding anomaly detection rule based on the rule identifier when performing anomaly detection. This eliminates the need to perform a full match between the DNS traffic characteristics and all anomaly detection rules again, further shortening the rule matching time and improving anomaly detection efficiency. At the same time, the uniqueness of the rule identifier can avoid rule confusion, improving the accuracy and reliability of DNS anomaly traffic determination.

[0015] Furthermore, the target traffic filtering device receives the SRv6 message and parses the DNS-specific TLV field, and performs anomaly detection on the DNS traffic based on the DNS traffic characteristics and the anomaly detection rules, including: the target traffic filtering device receives the SRv6 message and parses the DNS-specific TLV field, extracts the DNS traffic characteristics and the rule identifier from the DNS-specific TLV field; determines the matching detection rule corresponding to the rule identifier in the locally synchronized anomaly detection rules; compares the DNS traffic characteristics with the anomaly determination conditions of the matching detection rules; if at least one of the DNS traffic characteristics satisfies the corresponding anomaly determination conditions, then the DNS traffic is determined to be anomaly traffic.

[0016] The beneficial effects of adopting the above scheme are as follows: By extracting rule identifiers and DNS traffic characteristics from the DNS dedicated TLV field, the target traffic filtering device can quickly locate the corresponding matching detection rule based on the rule identifier, shortening the rule matching time; at the same time, by accurately comparing the DNS traffic characteristics with the anomaly judgment conditions of the matching detection rule, if at least one characteristic in the DNS traffic characteristics meets the corresponding anomaly judgment conditions, the DNS traffic is judged as abnormal traffic, which not only improves the anomaly detection efficiency, but also ensures the accuracy and reliability of anomaly judgment.

[0017] Furthermore, the DNS-specific TLV configuration is used to define the field structure of the DNS-specific TLV fields, including TLV type, TLV length, rule identifier subfield, DNS traffic feature subfield, and abnormal alarm information subfield.

[0018] The beneficial effects of adopting the above scheme are as follows: By uniformly configuring and standardizing the field structure of the DNS-specific TLV field, the TLV type, TLV length, rule identifier, DNS traffic characteristics, and abnormal alarm information subfields are clearly defined. This enables SRv6 edge nodes, traffic filtering devices, and management platforms to parse and fill the DNS-specific TLV field according to a unified format, ensuring the compatibility, standardization, and accuracy of information exchange between different devices. At the same time, the standardized field structure facilitates the rapid location of the required information, further improving packet parsing efficiency and collaborative processing capabilities.

[0019] Correspondingly, the present invention also provides an abnormal traffic alarm device, comprising: The information configuration module is used by the management platform to send configuration information to SRv6 nodes and traffic filtering devices. The configuration information includes anomaly detection rules, DNS dedicated TLV configuration, DNS dedicated SID set and path forwarding policy. The DNS dedicated SID set includes access SID and reporting SID. The device determination module is used to identify DNS traffic at the SRv6 edge node, extract DNS traffic features and fill them into the DNS-specific TLV field, encapsulate them into an SRv6 packet and load the access SID, and send the SRv6 packet to the corresponding target traffic filtering device based on the path forwarding policy. The anomaly alarm module is used by the target traffic filtering device to receive the SRv6 message and parse the DNS dedicated TLV field, perform anomaly detection on the DNS traffic based on the DNS traffic characteristics and the anomaly detection rules; when the DNS traffic is detected as abnormal traffic, anomaly alarm information is generated and filled into the DNS dedicated TLV field, the alarm message is re-encapsulated and loaded with the reporting SID, and the alarm message is sent to the management platform based on the path forwarding policy.

[0020] Furthermore, the device also includes an anomaly handling module; the anomaly handling module is used for: the management platform receiving the alarm message; extracting the SID path list of the alarm message; parsing the DNS dedicated TLV field to extract the anomaly alarm information and the DNS traffic characteristics; determining all transmission nodes on the DNS traffic transmission path based on the SID path list and the DNS traffic characteristics; and performing corresponding anomaly handling according to a preset handling strategy based on the anomaly alarm information.

[0021] This invention also provides an abnormal traffic alarm system, the system comprising a platform layer, an SRv6 network layer, and a traffic filtering device layer; wherein: The platform layer is used to send configuration information to SRv6 nodes and traffic filtering devices. This configuration information includes anomaly detection rules, DNS-specific TLV configuration, DNS-specific SID set, and path forwarding policies. The DNS-specific SID set includes access SIDs and reporting SIDs. The platform layer also receives alarm messages uploaded by the traffic filtering device layer; extracts the SID path list from the alarm messages; parses the DNS-specific TLV fields to extract anomaly alarm information and DNS traffic characteristics; determines all transmission nodes on the DNS traffic transmission path based on the SID path list and the DNS traffic characteristics; and performs corresponding anomaly handling according to a preset handling policy based on the anomaly alarm information. The SRv6 network layer is used to identify DNS traffic, extract the DNS traffic features and fill them into the DNS dedicated TLV field, encapsulate them to obtain SRv6 packets and load the access SID, and send the SRv6 packets to the corresponding target traffic filtering device in the traffic filtering device layer based on the path forwarding policy. The traffic filtering device layer is used to receive the SRv6 message and parse the DNS dedicated TLV field, perform anomaly detection on the DNS traffic based on the DNS traffic characteristics and the anomaly detection rules; when the DNS traffic is detected as abnormal traffic, the anomaly alarm information is generated and filled into the DNS dedicated TLV field, the alarm message is re-encapsulated and loaded with the reporting SID, and the alarm message is sent to the platform layer based on the path forwarding policy.

[0022] The present invention also provides an electronic device, comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute the instructions to implement the above-described abnormal traffic alarm method.

[0023] The present invention also provides a computer-readable storage medium having a computer program stored thereon, characterized in that the computer program, when executed by a processor, implements the above-mentioned abnormal traffic alarm method. Attached Figure Description

[0024] Figure 1 A flowchart illustrating an abnormal traffic alarm method provided by the present invention; Figure 2 A schematic block diagram of an abnormal traffic alarm device provided by the present invention; Figure 3 A schematic block diagram of an abnormal traffic alarm system provided by the present invention; Figure 4 This is a schematic diagram of an electronic device provided by the present invention. Detailed Implementation

[0025] The principles and features of the present invention are described below. The examples given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0026] In related technologies, DNS abnormal traffic filtering and alarm schemes are typically implemented based on traditional IP networks. The management platform sends DNS abnormality detection rules to the traffic filtering device. The traditional IP network blindly sends DNS traffic to the traffic filtering device, which performs local resolution on the DNS traffic, performs multi-layer decapsulation on the DNS packets, and matches them with the abnormality detection rules to achieve DNS traffic abnormality detection. When abnormal traffic is detected, the traffic filtering device generates alarm information and reports it to the management platform through an independent control channel. The alarm information is transmitted separately from the abnormal traffic packets.

[0027] However, the above methods have the following problems in implementation: the traffic filtering device needs to repeatedly resolve DNS traffic and perform multi-layer decapsulation, resulting in high computing power overhead and low detection efficiency; at the same time, alarm information is transmitted separately from business traffic, relying on independent signaling channels, resulting in high reporting latency and bandwidth bottlenecks in cross-node synchronization; in addition, DNS traffic still adopts a blind transmission mode in the network, which has poor compatibility with the new generation SRv6 network and is difficult to meet the requirements of high performance, high real-time performance and high accuracy DNS security protection.

[0028] To address the aforementioned problems, this invention proposes an abnormal traffic alarm method, apparatus, system, electronic device, and computer-readable storage medium. The technical solutions of the embodiments of this disclosure are described in detail below: In one embodiment of the present invention, an abnormal traffic alarm method is provided. (See reference...) Figure 1 As shown, this abnormal traffic alarm method specifically includes the following steps: S110: The management platform sends configuration information to SRv6 nodes and traffic filtering devices. The configuration information includes anomaly detection rules, DNS dedicated TLV configuration, DNS dedicated SID set and path forwarding policy. The DNS dedicated SID set includes access SID and reported SID. S120: The SRv6 edge node identifies DNS traffic, extracts DNS traffic features and fills them into the DNS-specific TLV field, encapsulates them to obtain SRv6 packets and loads the access SID, and sends the SRv6 packets to the corresponding target traffic filtering device based on the path forwarding policy; S130: The target traffic filtering device receives SRv6 messages and parses the DNS-specific TLV field. Based on DNS traffic characteristics and anomaly detection rules, it performs anomaly detection on DNS traffic. When DNS traffic is detected as abnormal, anomaly alarm information is generated and filled into the DNS-specific TLV field. The alarm message is re-encapsulated and loaded with the reporting SID. The alarm message is sent to the management platform based on the path forwarding policy.

[0029] In the abnormal traffic alarm method provided in the above embodiments, the SRv6 edge node completes DNS traffic identification and feature extraction, and fills the extracted DNS traffic features into the DNS-dedicated TLV field. Subsequent traffic filtering devices can directly obtain DNS traffic features by parsing the DNS-dedicated TLV field without repeatedly parsing DNS packets, reducing local resolution and decapsulation operations, reducing device computing load, and improving anomaly detection efficiency. At the same time, by accessing the SID and path forwarding policy, DNS traffic is accurately guided to the target traffic filtering device, replacing the traditional blind transmission mode, and improving traffic scheduling and detection response speed. In addition, by filling the abnormal alarm information into the DNS-dedicated TLV field and reporting it to the management platform along with the alarm message based on the reporting SID and path forwarding policy, alarms do not need to be transmitted through an independent control channel. This achieves alarms and traffic being transmitted along the same path in an integrated manner, reducing alarm latency and alleviating the bandwidth bottleneck caused by cross-node synchronization.

[0030] The above steps will now be described in more detail in another embodiment.

[0031] In S110, the management platform sends configuration information to SRv6 nodes and traffic filtering devices. The configuration information includes anomaly detection rules, DNS dedicated TLV configuration, DNS dedicated SID set and path forwarding policy. The DNS dedicated SID set includes access SID and reported SID.

[0032] The aforementioned management platform is the central control device for implementing abnormal traffic alarm methods, used for unified configuration and management of SRv6 nodes and traffic filtering devices.

[0033] The aforementioned SRv6 nodes are network forwarding nodes that support the IPv6 Segment Routing IPv6 (SRv6) protocol. They can encapsulate, parse, and forward SRv6 packets according to the segment identifier (SID) and path forwarding policy.

[0034] Specifically, the aforementioned SRv6 nodes include edge nodes and core nodes. Edge nodes are network nodes located on the network access side, used to receive DNS traffic initiated by terminal devices, perform traffic identification, feature extraction, DNS-specific TLV encapsulation, and redirect traffic to designated target traffic filtering devices based on the access SID. Core nodes are SRv6 nodes located at the network backbone layer, used to perform high-speed forwarding of DNS traffic and alarm messages, cross-regional transmission, and path scheduling based on cross-node forwarding SIDs.

[0035] The aforementioned traffic filtering devices are network security devices capable of SRv6 packet resolution, DNS-specific TLV field processing, DNS traffic anomaly detection, anomaly alarm generation, and SRv6 packet repackaging. They are typically deployed at locations with concentrated traffic forwarding, such as metropolitan area network egress, provincial network egress, campus network boundary, and data center ingress. The aforementioned DNS traffic refers to network traffic that performs domain name resolution based on the DNS protocol, including DNS request packets and DNS response packets.

[0036] The above configuration information is a set of parameters uniformly generated and distributed by the management platform to coordinate SRv6 nodes and traffic filtering devices to complete DNS abnormal traffic redirection, detection, alarming, and handling. Specifically, this configuration information includes anomaly detection rules, DNS-specific TLV configuration, DNS-specific SID set, and path forwarding policy.

[0037] The aforementioned anomaly detection rules are a pre-configured set of anomaly judgment conditions for DNS traffic, used to determine whether DNS traffic is abnormal. For example, the aforementioned anomaly detection rules can be configured from aspects such as malicious domain names, abnormal request frequency, DNS message characteristics, and DNS tunnel characteristics. The corresponding anomaly judgment conditions may include: the requested domain name belongs to the preset malicious domain name database, abnormal domain name database, DNS tunnel domain name, or the domain name format does not conform to the DNS specification; the number of requests per unit time exceeds the preset threshold, or it presents a high-frequency, continuous, periodic, or sudden increase request pattern; the message length is abnormal, the fields are illegal, the query type is unconventional, the flag bit is illegal, or there are hidden data encapsulation characteristics; the traffic is unidirectional, asymmetric, has a fixed source, a fixed destination, and a continuously high proportion, or it meets the typical characteristics of scanning, probing, and attack; the domain name is too long, contains illegal characters, has obvious data encryption characteristics, is transmitted according to a fixed period, or is used for covert communication of non-DNS services.

[0038] The above DNS-specific TLV configuration is the configuration information for defining the DNS-specific TLV field extended in the SRH header of the SRv6 message in this embodiment, and is used to define the field structure of the DNS-specific TLV field.

[0039] The aforementioned DNS-specific TLV field is located in the TLV optional area of ​​the SRv6 segment routing header (SRH). It is a custom field based on the SRv6 protocol extension in this embodiment, adopts the Type-Length-Value (TLV) format, and is dedicated to carrying DNS traffic-related information.

[0040] Furthermore, in one specific implementation of this embodiment, the management platform can also assign a unique rule identifier to each of the above-mentioned anomaly detection rules to facilitate the querying and matching of anomaly detection rules and avoid rule confusion. For example, a rule identifier 0001 can be assigned to the malicious domain name matching rule, a rule identifier 0002 can be assigned to the abnormal query frequency rule, and a rule identifier 0003 can be assigned to the DNS tunnel feature matching rule.

[0041] In this specific implementation, the field structure of the DNS-specific TLV field defined based on the above DNS-specific TLV configuration can be shown in Table 1 below: Table 1: Specifically, the aforementioned Type subfield (TLV type) is used to assign a dedicated type value Type=0x08 to the DNS abnormal traffic detection and alarm service. Subsequently, traffic filtering devices can identify and parse DNS traffic characteristics, rule identifiers, and alarm information based on this type value (0x08).

[0042] The Length subfield (TLV length) mentioned above is used to identify the total length of the DNS-specific TLV field in bytes. Combining the Length subfield with the Type subfield mentioned above, the DNS-specific TLV field can be quickly parsed from the SRv6 message.

[0043] The rule identifier subfield mentioned above is used to record the identifier of the detection rule used for DNS traffic anomaly detection. It can be a single rule identifier or a combination of multiple rule identifiers. If it is a single rule identifier, then only a single identifier will be used for single rule detection. If it is a combination of multiple rule identifiers, then the corresponding multiple anomaly detection rules will be used for joint detection, thereby achieving flexible and accurate determination of DNS anomaly traffic.

[0044] The aforementioned DNS traffic feature subfields are used to store the core features of DNS traffic. For example, they may include the target domain name carried in the DNS request or response, the query type of the DNS request (A (IPv4 address query) / AAAA (IPv6 address query) / CNAME (alias query)), the Time To Live (TTL) value, the source Internet Protocol (IP) address and destination IP address of the DNS traffic, the port number of the DNS traffic, and the message type (request / response).

[0045] This embodiment, based on TLV field extension rules, can also add sub-fields (such as DNS request packet length, resolution result, tunnel feature identifier, IP location information, etc.) according to business needs. The total byte length can be dynamically adjusted in multiples of 8 bytes to maintain compatibility with the SRv6 protocol. At the same time, this embodiment follows TLV encoding rules, adopts hexadecimal byte stream encoding, converts character fields to hexadecimal using UTF-8 encoding, and encodes numeric fields in big-endian mode, thereby ensuring the consistency of resolution between SRv6 network nodes and traffic filtering devices.

[0046] The aforementioned anomaly alarm information subfield is used to generate anomaly alarm information when DNS traffic is detected as abnormal traffic by the traffic filtering device. Preferably, this anomaly alarm information subfield is stored in a standardized format and includes information such as anomaly type, hit rule identifier, occurrence timestamp, unique identifier of the traffic filtering device, and local cache address of the abnormal traffic.

[0047] The aforementioned DNS-dedicated SID set is a set of dedicated SIDs allocated for DNS abnormal traffic detection and alarm services, used to identify DNS traffic and guide forwarding paths. For example, this DNS-dedicated SID set may include access SIDs, reporting SIDs, and cross-node forwarding SIDs.

[0048] The aforementioned access SID is a dedicated segment identifier that precisely directs DNS traffic from the SRv6 edge node to its designated target traffic filtering device.

[0049] The aforementioned SID is a dedicated segment identifier that directs alarm messages carrying abnormal alarm information from the target traffic filtering device back to the management platform.

[0050] The aforementioned cross-node forwarding SID is a dedicated segment identifier for cross-node forwarding in the backbone network (between SRv6 core nodes and between multi-level traffic filtering devices).

[0051] This embodiment introduces the aforementioned DNS-specific SID set, which provides a unique identifier for DNS traffic, effectively distinguishing it from ordinary service traffic. Furthermore, it can precisely direct DNS traffic to designated target traffic filtering devices for anomaly detection based on the access SID. Simultaneously, upon detecting abnormal traffic, it can quickly redirect alarm messages carrying alarm information back to the management platform based on the reported SID, simplifying forwarding logic, reducing device processing overhead, and improving the efficiency and reliability of DNS traffic transmission and anomaly detection. In addition, by forwarding SIDs across nodes between SRv6 core nodes and multi-level traffic filtering devices, it enables cross-regional and cross-level forwarding of DNS traffic, anomaly alarm messages, anomaly detection rules, and traffic characteristic information, providing a standardized forwarding path for data synchronization and collaborative detection among multi-level devices across the entire network.

[0052] The aforementioned path forwarding policy is used to instruct SRv6 nodes or traffic filtering devices to select a forwarding path or next-hop node based on preset rules, packet characteristics, service type, or SID identifier.

[0053] In one specific implementation of this embodiment, the management platform can distribute configuration information to SRv6 nodes and traffic filtering devices as follows: Complete configuration information is uniformly distributed to SRv6 nodes and traffic filtering devices via management protocols such as NETCONF. Specifically, this includes: generating anomaly detection rules and distributing them to SRv6 edge nodes and traffic filtering devices to ensure rule synchronization across the entire network; distributing DNS-specific TLV configurations, uniformly specifying TLV types, lengths, and formats of each subfield to ensure consistent field structure and resolution; planning and distributing a DNS-specific SID set, including access SIDs, reporting SIDs, and cross-node forwarding SIDs; and distributing path forwarding policies, instructing SRv6 nodes or traffic filtering devices to select forwarding paths or next-hop nodes based on preset rules, packet characteristics, service types, or SID identifiers.

[0054] In this specific implementation, after receiving the configuration information, each SRv6 node and traffic filtering device completes local storage and policy loading, and enters a working state that can perform DNS traffic identification, redirection, detection, and alarm.

[0055] In S120, the SRv6 edge node identifies DNS traffic, extracts DNS traffic features and fills them into the DNS-specific TLV field, encapsulates them to obtain SRv6 packets and loads the access SID, and sends the SRv6 packets to the corresponding target traffic filtering device based on the path forwarding policy.

[0056] The aforementioned DNS traffic characteristics are the core information used to identify and distinguish DNS traffic. For example, these DNS traffic characteristics may include information such as domain name, query type, TTL (Time to Live) value, source IP address, destination IP address, port number, and message type.

[0057] The aforementioned target traffic filtering device is a network security device used to detect anomalies in DNS traffic, determined based on path forwarding policies and access SIDs.

[0058] For example, in one specific implementation of this embodiment, the SRv6 edge node can identify DNS traffic as follows: The SRv6 edge node parses the header information of the original outgoing traffic to the provincial / metropolitan area network, obtains the transport layer protocol type, port number, and other characteristic information of the packet, and filters out DNS traffic from various types of service traffic based on preset DNS traffic identification rules. Specifically, using port 53 as a typical identification criterion for DNS traffic, and combining the protocol characteristics of Transmission Control Protocol (TCP) and User Datagram Protocol (UDP), DNS traffic is identified as follows: If the source port or destination port of the packet is port 53, and the packet is transmitted using TCP or UDP, then the packet is identified as DNS traffic.

[0059] Through the above identification methods, SRv6 edge nodes can quickly and accurately identify DNS traffic without decapsulating service data or affecting forwarding performance, providing a foundation for subsequent feature extraction, TLV encapsulation, and path routing.

[0060] The above extraction of DNS traffic features and filling of them into the DNS-specific TLV field can achieve the following: For identified DNS traffic, the SRv6 edge node extracts its DNS traffic features. For tunnel-encapsulated or encrypted DNS traffic, only the outer header information of the packet is parsed to extract directly obtainable surface features, without the need for deep decapsulation of the inner tunnel packet. The extracted DNS traffic features are then filled into the DNS traffic feature subfield of the DNS-specific TLV field. The surface features include information that can be directly obtained from the packet header, such as the source IP address, destination IP address, source port, destination port, transport layer protocol type, packet length, TTL value, and outer packet type. Deep decapsulation refers to the complex processing operations such as unpacking, decryption, reassembly, and deep parsing performed on the inner tunnel packet.

[0061] Preferably, during the TLV encapsulation stage described above, while the SRv6 edge node fills the DNS traffic characteristics into the DNS traffic characteristics subfield, it can also determine the rule matching the current DNS traffic from the locally synchronized anomaly detection rules, obtain the corresponding rule identifier, and fill the rule identifier into the DNS-specific TLV field. Specifically, the rule matching the current DNS traffic is a detection rule that matches the current DNS traffic based on information such as domain name, query type, request frequency, and packet characteristics, and its rule identifier is filled into the rule identifier subfield.

[0062] The above encapsulation of the SRv6 packet and loading of the access SID, and sending the SRv6 packet to the corresponding target traffic filtering device based on the path forwarding policy, can achieve the following: The SRv6 edge node carries the DNS-specific TLV field in the optional TLV area of ​​the SRH, completes the assembly of the SRH header and the outer IPv6 header according to the RFC9800 protocol specification, and uses the original DNS traffic as the payload to encapsulate a complete SRv6 packet; the access SID is loaded into the encapsulated complete SRv6 packet to identify the SRv6 packet as a DNS-specific towing packet, and the SRv6 packet is forwarded hop-by-hop to the target traffic filtering device specified by the access SID according to the path forwarding policy pre-issued by the management platform.

[0063] In S130, the target traffic filtering device receives SRv6 packets and parses the DNS-specific TLV field. Based on DNS traffic characteristics and anomaly detection rules, it performs anomaly detection on DNS traffic. When DNS traffic is detected as abnormal, it generates anomaly alarm information and fills it into the DNS-specific TLV field. It then re-encapsulates the alarm message and loads the reporting SID. Based on the path forwarding policy, it sends the alarm message to the management platform.

[0064] For example, the above-mentioned anomaly detection of DNS traffic based on DNS traffic characteristics and anomaly detection rules includes: comparing the DNS traffic characteristics with the anomaly judgment conditions of each anomaly detection rule that has been synchronized locally; if at least one of the DNS traffic characteristics meets the corresponding anomaly judgment condition, then the DNS traffic is determined to be abnormal traffic.

[0065] Preferably, corresponding to the process in step S120 of simultaneously filling the rule identifier of the anomaly detection rule matching the DNS traffic into the rule identifier subfield, the above anomaly detection process can also be implemented as follows: the target traffic filtering device receives the SRv6 message and parses the DNS dedicated TLV field, extracts the DNS traffic features and rule identifier from the DNS dedicated TLV field; determines the matching detection rule corresponding to the rule identifier in the locally synchronized anomaly detection rules; compares the DNS traffic features with the anomaly judgment conditions of the matching detection rules; if at least one feature in the DNS traffic features meets the corresponding anomaly judgment conditions, then the DNS traffic is determined to be anomaly traffic.

[0066] In one specific implementation of this embodiment, the target traffic filtering device receives SRv6 packets and parses the DNS-specific TLV field. Anomaly detection of DNS traffic based on DNS traffic characteristics and anomaly detection rules can be achieved as follows: The target traffic filtering device receives SRv6 packets sent by the SRv6 edge node and parses the packets, locates the optional TLV area in the SRv6 segment routing packet header, and quickly identifies, locates, and extracts the complete DNS-specific TLV field using the exclusive type value Type=0x08 of the DNS-specific TLV field. It then parses the DNS traffic characteristics and rule identifiers to obtain them. Based on the parsed rule identifiers, it directly matches the corresponding anomaly detection rules and analyzes whether each DNS traffic characteristic meets the corresponding anomaly judgment condition based on the matched anomaly detection rules. If at least one characteristic meets its corresponding anomaly judgment condition, the DNS traffic is determined to be anomaly traffic.

[0067] Specifically, assuming the matched anomaly detection rules include the malicious domain rule corresponding to rule identifier 0001 and the DNS tunnel feature rule corresponding to rule identifier 0003, the above-mentioned target traffic filtering device can complete the anomaly determination based on DNS traffic features and rule identifiers according to the following example: Malicious Domain Name Rule Judgment: Extract the requested domain name from the DNS traffic feature subfield of the DNS dedicated TLV field, compare the requested domain name with the locally pre-configured malicious domain name database, and if a domain name in the malicious domain name database is matched, the DNS traffic is determined to be abnormal traffic; DNS tunnel feature rules: Extract the requested domain name and message length from the DNS traffic feature subfield of the DNS dedicated TLV field. If the character length of the requested domain name exceeds the first preset threshold, contains a large number of random characters, illegal characters or encoding features, or the message length exceeds the second preset threshold, the DNS traffic is determined to be abnormal traffic. The first and second preset thresholds can be flexibly set according to the actual scenario.

[0068] It should be noted that if either of the above two anomaly detection rules results in abnormal traffic, then the DNS traffic is determined to be abnormal traffic.

[0069] In this embodiment, when none of the features in the DNS traffic characteristics meet the anomaly judgment conditions corresponding to the anomaly detection rules, the DNS traffic is determined to be normal traffic. For the DNS traffic determined to be normal traffic, the target traffic filtering device strips the SRv6 header, restores the original DNS traffic, and forwards the original DNS traffic normally according to the original transmission path of the service, thus ending the current abnormal traffic identification and alarm process.

[0070] If the DNS traffic is determined to be abnormal traffic through the above anomaly detection process, the target traffic filtering device will continue to execute the following abnormal alarm information encapsulation and reporting process: generate abnormal alarm information and fill it into the DNS dedicated TLV field, re-encapsulate to obtain alarm message and load the reporting SID, and send the alarm message to the management platform based on the path forwarding policy.

[0071] The above-mentioned abnormal alarm information is standardized alarm information generated by the target traffic filtering device based on the abnormal detection results; for example, the abnormal alarm information includes information such as abnormality type, hit rule, detection timestamp, target traffic filtering device identifier, and traffic cache address.

[0072] The aforementioned alarm message is an SRv6 message carrying abnormal alarm information, DNS traffic characteristics, and rule identifiers. It is used to upload abnormal information to the management platform so that the management platform can complete source tracing, analysis, and subsequent handling.

[0073] For example, in one specific implementation of this embodiment, the abnormal alarm information encapsulation and reporting process of the above-mentioned target traffic filtering device can be implemented as follows: Abnormal alarm information is generated according to a standardized format based on the abnormal detection results; the generated abnormal alarm information is written into the abnormal alarm information subfield of the DNS dedicated TLV, while retaining the original DNS traffic feature subfield and rule identifier subfield; the outer IPv6 header and SRv6 segment routing packet header are reassembled, the DNS dedicated TLV is carried in the optional TLV area of ​​the SRH, and the original DNS traffic is used as the payload to complete the SRv6 packet recapsulation; a reporting SID is loaded onto the recapsulated alarm message to identify it as a DNS abnormal alarm message that needs to be forwarded to the management platform; the alarm message is transmitted back to the SRv6 network, and each network node prioritizes and forwards the alarm message based on the reporting SID and the path forwarding policy pre-issued by the management platform, and then forwards the alarm message to the management platform.

[0074] Preferably, in another embodiment of the present invention, after step S130, the management platform can further perform source tracing, analysis, and subsequent handling of abnormal traffic based on the following step S140, as follows: In S140, the management platform receives alarm messages; extracts the SID path list from the alarm messages; parses the DNS-specific TLV field to extract abnormal alarm information and DNS traffic characteristics; determines all transmission nodes on the DNS traffic transmission path based on the SID path list and DNS traffic characteristics; and executes corresponding abnormal handling according to the preset handling strategy based on the abnormal alarm information.

[0075] The above SID path list is a segment list located in the SRH header of the alarm message. It is used to identify the transmission path of DNS traffic and records the node information of all SID nodes that the DNS traffic passes through from the SRv6 edge node to the traffic filtering device and then to the management platform.

[0076] The aforementioned preset handling strategies are anomaly handling rules pre-configured by the management platform, used to perform corresponding anomaly handling based on anomaly type, risk level, and transmission node information; the aforementioned anomaly handling includes actions such as targeted blocking based on source IP, rate limiting, and adding to the blacklist based on domain name.

[0077] In one specific implementation of this embodiment, the process by which the management platform determines all transmission nodes on the DNS traffic transmission path and performs anomaly handling can be implemented as follows: Receiving an alarm message carrying the reported SID; parsing the alarm message according to the SRv6 protocol specification to obtain the SID path list in the SRH; identifying and extracting the DNS-specific TLV field from the optional TLV area of ​​the SRH based on the exclusive type value Type=0x08 of the DNS-specific TLV field; parsing to obtain the anomaly alarm information and DNS traffic characteristics; and performing standardized format parsing to convert it into visual data that can be displayed on the management platform interface for path tracing and statistical analysis; based on the SID path list... The system traces the access nodes, transmission paths, and network devices through which abnormal traffic passes. By combining the source IP address and requested domain name information extracted from the DNS dedicated TLV field, it identifies the initiating device or user of the abnormal traffic, clarifies the source entity of the abnormal behavior, and thus reconstructs all transmission nodes on the traffic transmission path. Based on the anomaly type, risk level, and source tracing results obtained from the resolution, the system automatically triggers corresponding handling actions according to the preset handling strategy. It controls the issuance of management and control instructions to SRv6 network nodes. These management and control instructions include, but are not limited to: targeted blocking and rate limiting based on source IP address, adding malicious domain names to the blacklist, adjusting abnormal traffic paths, and updating detection strategies, thereby achieving coordinated handling of abnormal traffic.

[0078] In another embodiment of the present invention, information synchronization and sharing among multi-level filtering devices can also be achieved based on the aforementioned cross-node forwarding SID, as follows: After completing DNS traffic anomaly detection, each level of traffic filtering device encapsulates the local anomaly detection rules, extracted DNS traffic features, and generated anomaly alarm information into a synchronization message and loads the corresponding cross-node forwarding SID; based on a preset path forwarding strategy, the synchronization message is quickly forwarded to other levels of traffic filtering devices indicated by the cross-node forwarding SID, for example, metropolitan area network filtering device → provincial network filtering device, park filtering device → metropolitan area network filtering device; after receiving the synchronization message, each level of traffic filtering device parses the anomaly detection rules, DNS traffic features, and anomaly alarm information therein, and automatically updates the locally stored configuration (such as synchronously adding malicious domain name rules and supplementing the tunnel traffic surface feature library), ensuring that the detection rules and feature libraries of all traffic filtering devices in the entire network are consistent, and avoiding anomaly omissions due to rule asynchrony.

[0079] Preferably, while synchronizing information, traffic filtering devices at all levels can also forward their own anomaly detection data to the management platform by combining cross-node forwarding of SID and reporting of SID, so that the management platform can summarize and analyze the data of the entire network and form a global view of DNS anomaly traffic detection across the entire network.

[0080] Furthermore, the management platform can also perform unified control over traffic filtering devices across the entire network based on aggregated data, specifically as follows: When a filtering device at a certain level detects new DNS abnormal traffic characteristics (such as new tunnel domain name surface characteristics), it can synchronize these characteristics to all traffic filtering devices through cross-node forwarding SID; when it is necessary to update the anomaly detection rules, it can also quickly synchronize the updated anomaly detection rules to traffic filtering devices at all levels through cross-node forwarding SID, ensuring the consistency of anomaly detection rules across the entire network; in addition, the management platform can also synchronize the anomaly alarm information of a certain level filtering device to other related filtering devices through cross-node forwarding SID. For example, when a filtering device in a certain park detects an anomaly, the anomaly alarm information is synchronized to the provincial network filtering device for tracing, so as to realize multi-level filtering device collaborative detection and collaborative handling, and improve the comprehensiveness of anomaly traffic identification.

[0081] This embodiment, through the aforementioned cross-node forwarding of SIDs, can quickly synchronize the anomaly detection rules of the management platform to all traffic filtering devices across the network, avoiding missed detections caused by lagging or missing rules in some traffic filtering devices, and ensuring consistent detection standards across the network. Simultaneously, by forwarding SIDs across nodes, new anomaly characteristics discovered by a traffic filtering device at one level can be quickly synchronized to other nodes, enabling all traffic filtering devices across the network to identify such anomalies, thus compensating for the detection blind spots of a single node. Furthermore, multi-level filtering devices can achieve information sharing and collaborative processing through cross-node forwarding of SIDs. Combined with the traffic-driving function of access SIDs, all DNS traffic across the network can be included in the detection scope, avoiding missed detections of cross-regional and cross-level traffic. In addition, the management platform can monitor the detection status of the entire network in real time through global control, promptly patching detection vulnerabilities and significantly improving the coverage of anomaly detection across the entire network.

[0082] Correspondingly, the present invention also provides an abnormal traffic alarm device, referencing Figure 2 As shown, the abnormal traffic alarm device 200 may include an information configuration module 210, a device determination module 220, and an abnormal alarm module 230. Wherein: Information configuration module 210 can be used by the management platform to send configuration information to SRv6 nodes and traffic filtering devices. The configuration information includes anomaly detection rules, DNS dedicated TLV configuration, DNS dedicated SID set and path forwarding policy. The DNS dedicated SID set includes access SID and reporting SID. The device determination module 220 can be used to identify DNS traffic at SRv6 edge nodes, extract DNS traffic features and fill them into the DNS-specific TLV field, encapsulate them to obtain SRv6 packets and load the access SID, and send the SRv6 packets to the corresponding target traffic filtering device based on the path forwarding policy. The anomaly alarm module 230 can be used by the target traffic filtering device to receive SRv6 packets and parse the DNS dedicated TLV field, perform anomaly detection on DNS traffic based on DNS traffic characteristics and anomaly detection rules; when DNS traffic is detected as abnormal traffic, anomaly alarm information is generated and filled into the DNS dedicated TLV field, the alarm message is re-encapsulated and loaded with the reporting SID, and the alarm message is sent to the management platform based on the path forwarding policy.

[0083] In one implementation of this embodiment, the above-mentioned device further includes an anomaly handling module; the anomaly handling module is used for: the management platform receiving alarm messages; extracting the SID path list of the alarm messages; parsing the DNS-specific TLV field to extract abnormal alarm information and DNS traffic characteristics; determining all transmission nodes on the DNS traffic transmission path based on the SID path list and DNS traffic characteristics; and performing corresponding anomaly handling according to a preset handling strategy based on the abnormal alarm information.

[0084] In one implementation of this embodiment, the above-mentioned anomaly alarm module performs the above-mentioned anomaly detection of DNS traffic based on DNS traffic characteristics and anomaly detection rules by executing the following method: comparing the DNS traffic characteristics with the anomaly judgment conditions of each anomaly detection rule that has been synchronized locally; if at least one of the DNS traffic characteristics meets the corresponding anomaly judgment condition, then the DNS traffic is determined to be abnormal traffic.

[0085] In one implementation of this embodiment, the management platform is further configured to assign a unique rule identifier to each anomaly detection rule; when extracting DNS traffic features and filling them into the DNS-specific TLV field, the anomaly alarm module is further configured to: determine the rule that matches the DNS traffic in the locally synchronized anomaly detection rules, obtain the corresponding rule identifier, and fill the rule identifier into the DNS-specific TLV field.

[0086] In one implementation of this embodiment, the above-mentioned anomaly alarm module performs the following method to enable the target traffic filtering device to receive SRv6 packets and parse DNS dedicated TLV fields, and to perform anomaly detection on DNS traffic based on DNS traffic characteristics and anomaly detection rules: The target traffic filtering device receives SRv6 packets and parses DNS dedicated TLV fields, extracts DNS traffic characteristics and rule identifiers from the DNS dedicated TLV fields; determines the matching detection rule corresponding to the rule identifier in the locally synchronized anomaly detection rules; compares the DNS traffic characteristics with the anomaly judgment conditions of the matching detection rules; if at least one of the DNS traffic characteristics satisfies the corresponding anomaly judgment condition, the DNS traffic is determined to be abnormal traffic.

[0087] In one implementation of this embodiment, the DNS-specific TLV configuration is used to define the field structure of the DNS-specific TLV field, including TLV type, TLV length, rule identifier subfield, DNS traffic feature subfield, and abnormal alarm information subfield.

[0088] It should be noted that the specific implementation details of the above-mentioned abnormal traffic alarm device have been explained in detail in the corresponding section of the above-mentioned abnormal traffic alarm method, so they will not be repeated here.

[0089] In addition, this embodiment also provides an abnormal traffic alarm system, referencing Figure 3 As shown, the abnormal traffic alarm system includes a platform layer, an SRv6 network layer, and a traffic filtering device layer; among which: The platform layer is used to distribute configuration information to SRv6 nodes and traffic filtering devices. This configuration information includes anomaly detection rules, DNS-specific TLV configuration, DNS-specific SID set, and path forwarding policies. The DNS-specific SID set includes access SIDs and reported SIDs. It also receives alarm messages uploaded by the traffic filtering device layer; extracts the SID path list from the alarm messages; parses the DNS-specific TLV fields to extract anomaly alarm information and DNS traffic characteristics; determines all transmission nodes on the DNS traffic transmission path based on the SID path list and DNS traffic characteristics; and executes corresponding anomaly handling according to preset handling policies based on the anomaly alarm information. The SRv6 network layer is used to identify DNS traffic, extract DNS traffic features and fill them into the DNS-specific TLV field, encapsulate them to obtain SRv6 packets and load the access SID, and send the SRv6 packets to the corresponding target traffic filtering device in the traffic filtering device layer based on the path forwarding policy. The traffic filtering device layer is used to receive SRv6 packets and parse the DNS-specific TLV field. It performs anomaly detection on DNS traffic based on DNS traffic characteristics and anomaly detection rules. When DNS traffic is detected as abnormal, anomaly alarm information is generated and filled into the DNS-specific TLV field. The alarm message is re-encapsulated and loaded with the reporting SID. The alarm message is sent to the platform layer based on the path forwarding policy.

[0090] The hierarchical structure of the above-mentioned abnormal traffic alarm system will be described in detail below in a specific embodiment: The abnormal traffic alarm system provided in this specific embodiment is applicable to scenarios of DNS abnormal traffic detection, alarm, source tracing and linkage handling based on SRv6. It does not require modification of existing SRv6 network equipment and traffic filtering equipment hardware. It only achieves TLV resolution and encapsulation and SID path configuration through software upgrade. It is compatible with mainstream manufacturers' equipment and tunnels, and DNS traffic abnormal detection with encryption and multi-layer labels. It is suitable for DNS security protection needs in multiple scenarios such as provincial network / metropolitan area network exit, industrial internet park network, and government cloud boundary.

[0091] Specifically, the above-mentioned abnormal traffic alarm system has a three-tiered architecture, including a platform layer, an SRv6 network layer, and a traffic filtering device layer. The details of each layer are as follows: The aforementioned platform layer serves as the decision-making and control hub for the abnormal traffic alarm system. It integrates four core modules: DNS rule management, SRv6SID planning, alarm resolution and display, and source tracing and linkage handling. The specific functions of each module are as follows: The DNS rule management module is used to: uniformly generate, maintain, and distribute DNS anomaly detection rules, which include malicious domain name databases, DNS tunnel detection rules, length thresholds, character feature rules, etc.; and ensure consistent detection standards across the entire network by controlling the synchronization of rules for SRv6 network nodes and traffic filtering devices.

[0092] The SRv6 SID planning module is used to: plan, allocate, and manage a set of dedicated DNS SIDs, which includes access SIDs, reporting SIDs, and cross-node forwarding SIDs; formulate and issue SID path forwarding policies to achieve precise DNS traffic redirection and priority forwarding of alarm messages.

[0093] The alarm parsing and display module is used to: receive SRv6 alarm messages reported by traffic filtering devices, parse the DNS-specific TLV field in the SRH header, extract abnormal alarm information and DNS traffic characteristics, and convert them into displayable, searchable, and statistically quantifiable visual data through standardized parsing and formatting, so as to realize the presentation and recording of abnormal alarm information.

[0094] The source tracing and linkage handling module is used to: reconstruct the complete transmission path of abnormal DNS traffic based on the SID path list and DNS traffic characteristics in the alarm message; automatically trigger linkage handling according to the anomaly type and risk level and according to the preset handling strategy; and achieve end-to-end collaborative handling by controlling the issuance of control commands such as interception, rate limiting, domain name blacklisting, and path adjustment to SRv6 network nodes.

[0095] The aforementioned SRv6 network layer is the core of the abnormal traffic alarm system for traffic redirection and feature delivery. It integrates three core modules: a DNS traffic identification module, an SRv6 TLV encapsulation module, and a SID path forwarding module. The specific functions of each module are as follows: The DNS traffic identification module is used to extract DNS traffic from the raw network traffic based on port 53 and TCP / UDP protocol characteristics. It supports the identification of ordinary DNS traffic, tunnel / encrypted DNS traffic, and DNS traffic encapsulated by multi-layer Virtual Local Area Network (VLAN) / Multiprotocol Label Switching (MPLS). It only extracts the surface-level identifiable core features without deep decapsulation, thus reducing node computing power overhead.

[0096] The SRv6 TLV encapsulation module is used to: fill the DNS traffic features extracted by the DNS traffic identification module and the matching rule identifiers into the DNS-specific TLV field; complete the packet encapsulation according to the SRv6 protocol specification, and carry DNS-related information in the SRv6 SRH header; and load and maintain access SID, reported SID and cross-node forwarding SID related field information for the packet according to path planning requirements, so as to realize the integrated carrying of DNS traffic features, anomaly detection rule information and multi-level SID path information, and support cross-regional and cross-level traffic forwarding and collaborative detection.

[0097] The SID path forwarding module is used to: load access SIDs and accurately guide DNS traffic to the target traffic filtering device based on path forwarding policies; identify the reported SIDs in alarm messages and perform high-priority forwarding of abnormal alarm messages; and complete traffic and information forwarding between multiple levels of devices based on cross-node forwarding SIDs to ensure network-wide collaborative detection and information synchronization.

[0098] The traffic filtering device layer serves as the DNS anomaly detection and alarm encapsulation end of the anomaly alarm system. It integrates four core modules: an SRv6 TLV resolution module, a DNS deep detection module, an anomaly alarm generation module, and an SRv6 packet re-encapsulation module. The specific functions of each module are as follows: The SRv6 TLV resolution module is used to: receive and parse SRv6 packets, identify the DNS-specific TLV field with Type=0x08 from the SRH header, and extract DNS traffic characteristics and rule identifiers; it supports resolving access SID, reported SID, and cross-node forwarding SID information carried in the packets, providing data support for subsequent detection, synchronization, and forwarding.

[0099] The DNS deep detection module is used to perform anomaly detection based on traffic characteristics obtained from TLV resolution and locally synchronized anomaly detection rules. This eliminates the need to repeatedly resolve DNS packets, reducing computational overhead and improving detection efficiency.

[0100] The anomaly alarm generation module is used to generate standardized anomaly alarm information when DNS traffic is detected as abnormal. This information includes anomaly type, hit rule, domain name, source IP, destination IP, packet length, timestamp, device number, etc., providing a basis for subsequent tracing, display, and handling.

[0101] The SRv6 packet re-encapsulation module is used to: fill abnormal alarm information into the DNS-specific TLV field while keeping the original feature and rule identifier unchanged; re-encapsulate the packet with SRv6, load the reporting SID, and report alarms to the management platform based on the path forwarding policy; and load cross-node forwarding SIDs according to collaborative requirements to realize the synchronization of rules, features, and alarm information among multi-level devices and support network-wide collaborative protection.

[0102] It should be noted that the specific implementation details of the above-mentioned abnormal traffic alarm system have been explained in detail in the corresponding section of the above-mentioned abnormal traffic alarm method, so they will not be repeated here.

[0103] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0104] An electronic device according to the present invention includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any of the above-mentioned abnormal traffic alarm methods. That is, an electronic device according to the present invention may include, but is not limited to: a processor and a memory; the memory is used to store the computer program; the processor is used to execute the abnormal traffic alarm method shown in any embodiment of the present invention by calling the computer program.

[0105] In one alternative embodiment, an electronic device is provided, such as Figure 4 As shown, Figure 4 The illustrated electronic device 4000 includes a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, for example, via a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the present invention.

[0106] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this invention. Processor 4001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0107] Bus 4002 may include a path for transmitting information between the aforementioned components. Bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 4002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4 The bus 4002 is represented by only one thick line, but this does not mean that there is only one bus or one type of bus.

[0108] The memory 4003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto.

[0109] The memory 4003 stores application code (computer program) for executing the present invention, and its execution is controlled by the processor 4001. The processor 4001 executes the application code stored in the memory 4003 to implement the content shown in the foregoing method embodiments.

[0110] Among them, electronic devices can also be terminal devices, which can be any device that can install applications, including at least one of smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, smart TVs, and smart in-vehicle devices.

[0111] It should be noted that, Figure 4 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the invention.

[0112] The present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-mentioned abnormal traffic alarm methods.

[0113] Alternatively, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, a floppy disk, and an optical data storage device, etc.

[0114] In an exemplary embodiment, a computer program product or computer program is also provided, which includes computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the aforementioned abnormal traffic alarm method.

[0115] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0116] It should be understood that the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0117] The computer-readable storage medium provided by this invention can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EEPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0118] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the method shown in the above embodiments.

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

[0120] It should be noted that the terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and represent a limitation on a specific order or sequence. Where appropriate, the order of use for similar objects can be interchanged so that the embodiments of this application described herein can be implemented in an order other than that shown or described.

[0121] Those skilled in the art will recognize that this invention can be implemented as a system, method, or computer program product. Therefore, this invention can be specifically implemented in the following forms: it can be entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software, generally referred to herein as a "circuit," "module," or "system." Furthermore, in some embodiments, this invention can also be implemented as a computer program product contained in one or more computer-readable media, which includes computer-readable program code.

[0122] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. An abnormal traffic alarm method, characterized in that, The method includes: The management platform sends configuration information to SRv6 nodes and traffic filtering devices. The configuration information includes anomaly detection rules, DNS dedicated TLV configuration, DNS dedicated SID set and path forwarding policy. The DNS dedicated SID set includes access SID and reporting SID. The SRv6 edge node identifies DNS traffic, extracts DNS traffic features and fills them into the DNS-specific TLV field, encapsulates them to obtain an SRv6 packet and loads the access SID, and sends the SRv6 packet to the corresponding target traffic filtering device based on the path forwarding policy; The target traffic filtering device receives the SRv6 message and parses the DNS-specific TLV field. Based on the DNS traffic characteristics and the anomaly detection rules, it performs anomaly detection on the DNS traffic. When the DNS traffic is detected as abnormal, it generates an anomaly alarm message and fills it into the DNS-specific TLV field. It then re-encapsulates the alarm message and loads the reporting SID. Based on the path forwarding policy, it sends the alarm message to the management platform.

2. The abnormal traffic alarm method according to claim 1, characterized in that, The method further includes: The management platform receives the alarm message; Extract the SID path list of the alarm message; Parse the DNS-specific TLV field to extract the abnormal alarm information and the DNS traffic characteristics; Based on the SID path list and the DNS traffic characteristics, determine all transmission nodes on the DNS traffic transmission path; Based on the abnormal alarm information, the corresponding abnormal handling is performed according to the preset handling strategy.

3. The abnormal traffic alarm method according to claim 1, characterized in that, The process of detecting anomalies in DNS traffic based on the DNS traffic characteristics and the anomaly detection rules includes: The DNS traffic characteristics are compared with the anomaly judgment conditions of each of the anomaly detection rules that have been synchronized locally. If at least one of the DNS traffic characteristics satisfies the corresponding anomaly determination condition, then the DNS traffic is determined to be abnormal traffic.

4. The abnormal traffic alarm method according to claim 1, characterized in that, The management platform assigns a unique rule identifier to each of the anomaly detection rules. The method further includes, during the extraction of DNS traffic features and their filling into DNS-specific TLV fields: Identify the rule that matches the DNS traffic from the locally synchronized anomaly detection rules, obtain the corresponding rule identifier, and fill the rule identifier into the DNS-specific TLV field.

5. The abnormal traffic alarm method according to claim 4, characterized in that, The target traffic filtering device receives the SRv6 message and parses the DNS-specific TLV field, and performs anomaly detection on the DNS traffic based on the DNS traffic characteristics and the anomaly detection rules, including: The target traffic filtering device receives the SRv6 message and parses the DNS dedicated TLV field, extracting the DNS traffic characteristics and the rule identifier from the DNS dedicated TLV field; Determine the matching detection rule corresponding to the rule identifier from the locally synchronized anomaly detection rules; The DNS traffic characteristics are compared with the anomaly determination conditions of the matching detection rules; If at least one of the DNS traffic characteristics satisfies the corresponding anomaly determination condition, then the DNS traffic is determined to be abnormal traffic.

6. The abnormal traffic alarm method according to claim 5, characterized in that, The DNS-specific TLV configuration is used to define the field structure of the DNS-specific TLV fields, including TLV type, TLV length, rule identifier subfield, DNS traffic feature subfield, and abnormal alarm information subfield.

7. An abnormal flow alarm device, characterized in that, The device includes: The information configuration module is used by the management platform to send configuration information to SRv6 nodes and traffic filtering devices. The configuration information includes anomaly detection rules, DNS dedicated TLV configuration, DNS dedicated SID set and path forwarding policy. The DNS dedicated SID set includes access SID and reporting SID. The device determination module is used to identify DNS traffic at the SRv6 edge node, extract DNS traffic features and fill them into the DNS-specific TLV field, encapsulate them into an SRv6 packet and load the access SID, and send the SRv6 packet to the corresponding target traffic filtering device based on the path forwarding policy. The anomaly alarm module is used by the target traffic filtering device to receive the SRv6 message and parse the DNS dedicated TLV field, perform anomaly detection on the DNS traffic based on the DNS traffic characteristics and the anomaly detection rules; when the DNS traffic is detected as abnormal traffic, anomaly alarm information is generated and filled into the DNS dedicated TLV field, the alarm message is re-encapsulated and loaded with the reporting SID, and the alarm message is sent to the management platform based on the path forwarding policy.

8. The abnormal flow alarm device according to claim 7, characterized in that, The device further includes an anomaly handling module; the anomaly handling module is used for: The management platform receives the alarm message; Extract the SID path list of the alarm message; Parse the DNS-specific TLV field to extract the abnormal alarm information and the DNS traffic characteristics; Based on the SID path list and the DNS traffic characteristics, determine all transmission nodes on the DNS traffic transmission path; Based on the abnormal alarm information, the corresponding abnormal handling is performed according to the preset handling strategy.

9. An abnormal traffic alarm system, characterized in that, The system comprises a platform layer, an SRv6 network layer, and a traffic filtering device layer; wherein: The platform layer is used to send configuration information to SRv6 nodes and traffic filtering devices. This configuration information includes anomaly detection rules, DNS-specific TLV configuration, DNS-specific SID set, and path forwarding policies. The DNS-specific SID set includes access SIDs and reporting SIDs. The platform layer also receives alarm messages uploaded by the traffic filtering device layer; extracts the SID path list from the alarm messages; parses the DNS-specific TLV fields to extract anomaly alarm information and DNS traffic characteristics; determines all transmission nodes on the DNS traffic transmission path based on the SID path list and the DNS traffic characteristics; and performs corresponding anomaly handling according to a preset handling policy based on the anomaly alarm information. The SRv6 network layer is used to identify DNS traffic, extract the DNS traffic features and fill them into the DNS dedicated TLV field, encapsulate them to obtain SRv6 packets and load the access SID, and send the SRv6 packets to the corresponding target traffic filtering device in the traffic filtering device layer based on the path forwarding policy. The traffic filtering device layer is used to receive the SRv6 message and parse the DNS dedicated TLV field, perform anomaly detection on the DNS traffic based on the DNS traffic characteristics and the anomaly detection rules; when the DNS traffic is detected as abnormal traffic, the anomaly alarm information is generated and filled into the DNS dedicated TLV field, the alarm message is re-encapsulated and loaded with the reporting SID, and the alarm message is sent to the platform layer based on the path forwarding policy.

10. An electronic device, characterized in that, include: processor; Memory for storing the executable instructions of the processor; The processor is configured to execute the instructions to implement the abnormal traffic alarm method as described in any one of claims 1 to 6.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the abnormal traffic alarm method according to any one of claims 1 to 6.

Images