WO2022104738A1 - Trojan detection method and apparatus, and device - Google Patents

Abstract

A Trojan detection method and apparatus, and a device. The method comprises: receiving a first query packet from a source end, the first query packet comprising an IP address of the source end (101); if the first query packet conforms to domain name system (DNS) protocol specifications, acquiring a first response packet corresponding to the first query packet, the first response packet being sent by a destination end (102); analyzing the first response packet so as to obtain at least IP address of the destination end (103); and if there is no data packet between the IP address of the source end and the at least one IP address of the destination end, determining that a DNS tunneling Trojan is present between the source end and the destination end (104). The method is used to detect whether a DNS tunneling Trojan is hidden in a data packet conforming to DNS protocol specifications, and solves the problem in which intrusion detection systems based on general rules cannot detect high-concealment DNS tunneling Trojans.

Description

A Trojan detection method, device and equipment technical field

The present application relates to the field of communications, and in particular, to a Trojan horse detection method, device and device.

Background technique

Tunneling technology is an important method to improve the stability and security of network protocol (Internet Protocol, IP) data transmission. Commonly used tunneling transmission protocols in tunneling technology include: Internet Protocol Security (IPsec), general routing encapsulation (Generic Routing Encapsulation, GRE), Point to Point Tunneling Protocol (Point to Point Tunneling Protocol, PPTP), etc. A network Trojan is a piece of malicious code hidden in a network system. It has the functions of destroying and deleting files, sending passwords, keylogging and other functions. It is a backdoor program with special hacking functions. Its English name is Trojan (Troy), which means a success in the battle of Troy in ancient Greece. Tactics, attackers can use network Trojans to lurk in the attacked system for a long time and continuously obtain sensitive information of users. Due to its good invisibility and great harm, network control Trojans have been widely used by hackers since its birth, endangering all walks of life in the network system, and traditional industry security such as network security, industrial production security, and financial security are all under great threat.

In order to reduce the threat of Trojans to normal network connections, security personnel analyzed the characteristics of a large number of Trojan samples collected, and found that common network Trojans often use private and dedicated transmission protocols during transmission. Based on such research results, researchers have proposed a variety of methods to discover private dedicated transmission protocols, so as to find network Trojans and improve the ability of terminal devices to resist network Trojan attacks, which also forces designers to gradually shift the design of network Trojans to conceal themselves. With the development of the transmission protocol characteristics, new types of Trojan horses based on legal communication protocols have gradually emerged.

In recent years, a large number of network Trojan horse technologies disguised as legitimate protocols such as Domain Name System (DNS) and Internet Control Message Protocol (ICMP) have appeared, posing a great threat to governments, companies, and individual users. For example, it is reported that an Advanced Persistant Attack (APT) organization has successively carried out network attacks on well-known car companies such as BMW and Toyota. The organization's attack tools include a Trojan horse disguised as DNS protocol for data transmission. During the attack, the DNS protocol becomes the channel for the Trojan to transmit data. This Trojan that uses the DNS protocol as the transmission channel for data transmission is also called DNS tunneling Trojan. Therefore, how to detect the DNS tunnel Trojan in the network transmission channel is a technical problem to be solved urgently by those skilled in the art.

SUMMARY OF THE INVENTION

The present application provides a Trojan horse detection method, device and equipment for solving the above-mentioned technical problems, specifically, the following technical solutions are disclosed:

In a first aspect, the present application provides a Trojan horse detection method, the method includes: receiving a first query packet from a source end, where the first query packet includes the IP address of the source end, when the first query packet conforms to the DNS protocol specification, obtain the first response packet corresponding to the first query packet; parse the first response packet to obtain at least one destination IP address; if there is no difference between the source IP address and the at least one destination IP address If there is a data packet, it is determined that there is a DNS tunnel Trojan horse between the source end and the destination end. The first response packet is sent by the DNS server, and the at least one destination IP address belongs to the destination terminal.

The method can detect whether there is a DNS tunnel Trojan hidden in the data stream conforming to the DNS protocol specification, and solves the problem that the intrusion detection system based on general rules cannot find the DNS tunnel Trojan with high concealment.

In addition, this method can avoid the detection method based on machine learning, which requires a large number of samples to be learned, and at the same time, there are inevitably the problems of false negatives and false positives, and the function of the DNS protocol itself does not need to be combined in the detection process. It will not affect the detection effect.

Optionally, in combination with the first aspect, in a possible implementation of the first aspect, the above method further includes: if there is a data packet between the source IP address and each of the at least one destination IP address, Then it is determined that there is no DNS tunnel Trojan horse between the source end and the destination end.

With reference to the first aspect, in another possible implementation of the first aspect, before acquiring the first response packet corresponding to the first query packet, the method further includes: acquiring the first data packet collected in the first detection period Set, the first data packet set includes at least the data packets of the DNS protocol type;

The receiving the first inquiry packet from the source includes: filtering out all DNS data packets from the first data packet set through the target port, where the DNS data packets include inquiry packets and response packets; The first query packet is filtered out of the packet. Wherein, the target port is port 53 of UDP.

This implementation can filter out all DNS data packets through the target port, thereby providing a basis for detecting whether there are DNS data packets in the tunnel in the subsequent transmission of DNS data packets.

With reference to the first aspect, in yet another possible implementation of the first aspect, the first query packet conforms to the data packet of the DNS protocol specification, including: a length indication field carried in the first query packet and a data packet located in the The actual data length after the length indication field is consistent.

In addition, the above method further includes: if the length indication field carried in the first query packet is inconsistent with the actual data length after the length indication field, determining that the first query packet does not conform to the DNS protocol specification.

This implementation uses the content of the pcap file in the parsed data packet to obtain the data structure and content, thereby judging whether the parsed data structure and content conform to the DNS protocol specification, and then screen out all the data packets conforming to the DNS protocol specification.

With reference to the first aspect, in yet another possible implementation of the first aspect, when it is determined that the first query packet does not conform to the DNS protocol specification, the method further includes: acquiring the source IP address The requested domain name, the domain name is represented by a preset character string; it is judged whether there are characters other than ASCII codes in the domain name represented by the preset character string; There is a DNS tunneling Trojan.

With reference to the first aspect, in yet another possible implementation of the first aspect, the above method further includes: if there are no characters other than the ASCII code, acquiring a first response packet corresponding to the first query packet Analyzing the first response packet to obtain the first data, comprising data type and length in the first data, and judging whether the data type and length included in the first data all meet the DNS protocol specification; If all meet, then Make sure there is no DNS tunneling Trojan.

Optionally, the above method further includes: if at least one of the data type and length contained in the first data does not conform to the DNS protocol specification, determining that there is a DNS tunneling Trojan horse.

The method realizes the detection of the DNS tunnel Trojan horse in the data stream that does not conform to the DNS protocol specification, and can accurately find the hidden tunnel Trojan horse in the case of network abnormality or DNS server error, and there is no false positive or false negative. Under the premise of normal network communication, as long as abnormal data packets or packets that do not meet the DNS requirements are found, it can quickly detect whether there is a DNS tunnel Trojan in the tunnel.

Optionally, in another possible implementation of the first aspect, the data packets are all data packets in the first detection period, or, from the time after the first response packet is detected to the first detection period. All packets collected at the end of a detection period.

Among them, all the data packets in the first detection period are also called the first data packet set, which are all the data packets collected from the first response packet detected to the end of the first detection period, also called the first data packet set. Two-packet set. In this implementation manner, when the second data packet set is acquired and detected, since the second data packet set is a subset of the aforementioned first data packet set, compared with detecting the transmission data packets of the first data packet set, this implementation The method only detects the second data packet set, the number of detection packets is reduced, and the detection efficiency is improved.

In a second aspect, the present application also provides a Trojan horse detection device, the device includes: a collection unit, an analysis unit, a determination unit, and the like,

The collecting unit is configured to receive a first query packet from the source end, where the first query packet includes the IP address of the source end, and the parsing unit is configured to obtain and obtain the corresponding information when the first query packet conforms to the DNS protocol specification of the Domain Name System. The first response packet corresponding to the first query packet, the first response packet is sent by the DNS server; the determining unit is used for there is no data between the source IP address and the at least one destination IP address. In the case of the packet, it is determined that there is a DNS tunnel Trojan horse between the source end and the destination end.

Optionally, in combination with the second aspect, in a possible implementation of the second aspect, the determining unit is further configured to have data between the source IP address and each of the at least one destination IP address. In the case of the packet, it is determined that there is no DNS tunnel Trojan horse between the source end and the destination end.

With reference to the second aspect, in another possible implementation of the second aspect, the collection unit is further configured to acquire a first set of data packets collected in the first detection period, where at least one of the first set of data packets is Including data packets of the DNS protocol type; the parsing unit is further configured to filter out all DNS data packets from the first data packet set through the target port, and select the first query packet from all DNS data packets, The DNS data packets include query packets and response packets.

With reference to the second aspect, in yet another possible implementation of the second aspect, the parsing unit is specifically configured to, when the length indication field carried in the first query packet and the actual data located after the length indication field When the lengths are the same, it is determined that the first query packet conforms to the DNS protocol specification.

With reference to the second aspect, in yet another possible implementation of the second aspect, the parsing unit is further configured to, when the length indication field carried in the first query packet and the length indication field located after the length indication field When the actual data lengths are inconsistent, it is determined that the first query packet does not conform to the DNS protocol specification.

With reference to the second aspect, in yet another possible implementation of the second aspect, the parsing unit is further configured to obtain the source end when it is determined that the first query packet does not conform to the DNS protocol specification The domain name requested by the IP address, the domain name is represented by a preset character string; it is judged whether there are characters other than ASCII codes in the domain name represented by the preset character string, and if so, determine the source end to the destination There is a DNS tunneling Trojan between the endpoints.

With reference to the second aspect, in yet another possible implementation of the second aspect, the parsing unit is further configured to obtain a query packet corresponding to the first query packet in the absence of characters other than the ASCII code. The first response packet, which parses the first response packet to obtain first data, where the first data includes a data type and a length; the determining unit is further configured to determine whether the data type and length in the first data are equal. When the DNS protocol specification is complied with, it is determined that there is no DNS tunneling Trojan.

With reference to the second aspect, in yet another possible implementation of the second aspect, the determining unit is further configured to when at least one of the data type and length in the first data does not conform to the DNS protocol specification , it is determined that there is a DNS tunneling Trojan.

Optionally, in combination with the second aspect, in various possible implementations of the second aspect, the data packets are all data packets in the first detection period, or, after the detection of the first response packet All data packets collected from the beginning to the end of the first detection period.

In a third aspect, the present application provides a detection device, the device includes a processor and a memory, and the processor is coupled to the memory, specifically, the memory is used to store computer program instructions; the processor is used to execute the instructions stored in the memory. , so that the detection device executes the aforementioned first aspect and the methods in various implementations of the first aspect.

Specifically, the functions of each unit module in the second aspect above, such as the collection unit, the analysis unit, and the determination unit, may be implemented by the processor and the memory.

Optionally, the detection device is a processing chip or a chip system.

Optionally, the detection device is a network device, or a functional module deployed in the network device.

In addition, the apparatus may also include at least one communication interface, transceiver, sensor and other components.

In a fourth aspect, the present application also provides a computer-readable storage medium, in which instructions are stored, so that when the instructions are executed on a computer or a processor, the instructions can be used to execute the foregoing first aspect and each of the first aspects. method in an implementation.

In addition, the present application also provides a computer program product, the computer program product includes computer instructions, when the instructions are executed by a computer or a processor, the aforementioned first aspect or the method in various implementation manners of the first aspect can be implemented .

It should be noted that the beneficial effects corresponding to the technical solutions of the various implementation manners of the second aspect to the fourth aspect are the same as the beneficial effects of the foregoing first aspect and various implementation manners of the first aspect. For details, please refer to the foregoing first aspect. Aspects and descriptions of beneficial effects in various implementation manners of the first aspect will not be repeated.

Description of drawings

1 is a schematic diagram of establishing a communication connection between a client and a server according to an embodiment of the present application;

2 is another schematic diagram of establishing a communication connection between a client and a server according to an embodiment of the present application;

3 is a schematic diagram of data content obtained after parsing a pcap file provided by an embodiment of the present application;

4 is a flowchart of a Trojan horse detection method provided by an embodiment of the present application;

5 is a flowchart of another Trojan horse detection method provided by an embodiment of the present application;

6 is a schematic diagram of obtaining data content after parsing a DNS data packet according to an embodiment of the present application;

7 is a schematic diagram of obtaining data content by parsing according to an embodiment of the present application;

8 is a flowchart of another Trojan horse detection method provided by an embodiment of the present application;

9 is another schematic diagram of obtaining data content by parsing provided by an embodiment of the present application;

FIG. 10 is another schematic diagram of obtaining data content by parsing provided by an embodiment of the present application;

11 is a schematic structural diagram of a Trojan horse detection device provided by an embodiment of the application;

FIG. 12 is a schematic structural diagram of a detection device provided by an embodiment of the present application.

Detailed ways

In order to enable those skilled in the art to better understand the technical solutions in the embodiments of the present application, and to make the above-mentioned purposes, features and advantages of the embodiments of the present application more clearly understood, the following describes the technical solutions in the embodiments of the present application with reference to the accompanying drawings. The program is described in further detail.

Before describing the technical solutions of the embodiments of the present application, the application scenarios and related technical terms of the embodiments of the present application are first introduced with reference to the accompanying drawings.

The technical solution of the present application can be applied to a network system, such as an intelligent networked vehicle system. As shown in FIG. 1 , in the scenario of an intelligent networked vehicle system, it includes at least one client (client) and at least one server (server), In addition, other network devices may also be included, such as a gateway (gateway, GW), and a telematics processor (Telematics BOX, T-box). Among them, the communication transmission between the client, the server, and the GW follows the DNS protocol.

The method provided in this embodiment may be applied to a detection apparatus, and the detection apparatus may be deployed in a network system as an independent network device, or may also be deployed in a vehicle gateway GW, T-box, or DNS server. In addition, the T-box exists in the local area network where DNS data is required, and does not require full traffic analysis.

First, a brief introduction to the DNS protocol and related concepts in the DNS protocol is given.

DNS is literally translated into Domain Name System, which is a network service that maps domain names and IP addresses. In general application scenarios, it is deployed in a client/server network connection. For example, using a network terminal as a client (client), a recognized server (server) with domain name resolution function can be specified. For example, the address of the server mapped by a free DNS domain name of Google is 8.8.8.8.

Domain Name is the name of a computer or computer group on the Internet consisting of a string of names separated by dots, which is used to locate and identify computers (sometimes also refer to geographic locations) during data transmission. Because IP addresses are inconvenient to remember and cannot display the name and nature of the address organization, people have designed domain names and mapped the domain names and IP addresses to each other through DNS, so that users can access the Internet more easily and avoid remembering A string of IP addresses that can be directly read by a machine.

Specifically, the process of establishing a communication connection between the client and the server can be seen in Figure 1. When the client needs to complete a certain network service, it will send a request message to the DNS server (DNS server), and the request message contains the domain name. , such as www.example.com, the request message can be used to ask for the IP address of www.example.com. After receiving it, the DNS server finds out the IP address associated with the domain name www.example.com according to the mapping relationship between the domain name and the IP address stored in its own database, and marks the IP address as IP_DST, indicating the destination IP address. The DNS server feeds back the IP_DST to the client through the response data. After the client receives the response data, it resolves the IP_DST, and then the client's IP address IP_SRC establishes a new network connection with IP_DST to implement specific network services. SRC is the abbreviation of Source, which means "source", and DST is the abbreviation of Destination, which means "destination".

In addition, in a scenario involving a GW, such as in a local area network scenario, a GW can be designated as the server side, and the GW can be used to forward the domain name request messages of each client in the local area network, and then the external DNS server returns according to each domain name request message. The IP_DST address is forwarded to the corresponding client. The principle is shown in FIG. 2 . For the specific implementation process, refer to the interaction process in FIG. 1 , which is not repeated in this embodiment.

When data is transmitted between the above clients and the DNS server, or between the client and the switch, there may be a DNS tunnel Trojan horse in the traffic transmitted through the DNS tunnel. Therefore, the purpose of this application is to detect whether there is a DNS tunnel Trojan horse in the network transmission channel.

The following introduces other terminology concepts involved in the technical solutions of the present application.

(1) HTTP protocol and HTTPs protocol

The HTTP protocol (Hypertext Transfer Protocol, Hypertext Transfer Protocol) is a transmission protocol used to transmit hypertext on the Internet. It is an HTTP application protocol running on top of the TCP/IP protocol suite, which can make browsers more efficient and reduce network transmissions.

HTTPs protocol (Hyper Text Transfer Protocol over SecureSocket Layer) is a network protocol constructed by HTTP plus TLS/SSL protocol that can perform encrypted transmission and identity authentication, mainly through digital certificates, encryption algorithms, asymmetric encryption Encryption of Internet data transmission and security protection of Internet transmission through technologies such as encryption keys.

Secure Sockets Layer (SSL), and its successor, Transport Layer Security (TLS), are a security protocol that provides security and data integrity for network communications. TLS and SSL encrypt network connections between the transport layer and the application layer.

(2) RFC document

An RFC document is also called a Request for Comments document (Requests for Comments, RFC), which is a network document or work report used to publish Internet standards and other official publications on the Internet. The RFC document was created in 1969, and the RFC publication is directly responsible for the RFC Editor (RFC Editor), and accepts the general guidance of the Internet Architecture Board (IAB). There are now more than 3000 RFC series documents, and this number is still increasing, and the content is related to the Internet (originally called ARPANET). The draft discusses all aspects of computer communication, with emphasis on network protocols, processes, procedures, and some notions of conference notes, opinions, and style.

(3) pcap file

pcap is a commonly used data packet storage format, which can be understood as a file format. The data in it is stored in a specific format, so if you want to parse the data in it, you must follow a certain format. Using professional tools, such as opening the pcap file with Notepad++ with the HEX-Editor plugin installed, can display the format of the hexadecimal data, and then use the packet capture tool such as wireshark to open the file normally and view the network datagram inside. , and wireshark can also generate files in this format. Of course, other tools can also be used to view pcap files.

A pcap file includes two parts, the pcap header (Pcap Header) and the data area. The data area is divided into multiple data packets, and each packet includes two parts: the data packet header (Packet Header) and the data (Packet Data). The structure is shown in Table 1 below:

Table 1

Among them, the Pcap header is the file header, and each pcap file has only one file header, occupying a total of 24 (B) bytes. There can be multiple headers, and each header is followed by the actual packet. The following are the meanings of the four fields of the Packet Header;

Timestamp(4B): The high bit of the timestamp, accurate to seconds (seconds), which is the timestamp of the Unix operating system. Can be used to log when packets were captured. Timestamp (4B): low-order timestamp, accurate to milliseconds (microseconds). Caplen(4B): The length of the current data area, that is, the length of the captured data frame, from which the position of the next data frame can be obtained. Len(4B): Offline data length, the length of the actual data frame in the network, generally not greater than Caplen, in most cases the same as the Caplen value.

In Packet Data, Packet is the data frame of the link layer, and the length is the Caplen value defined in the Packet Header, so each Packet Header is followed by Packet Data of Caplen length. That is to say, the pcap file does not specify any interval strings between captured data frames. The format of the packet data frame part is the standard network protocol format. Referring to Figure 3, it is a schematic diagram of the data content obtained after parsing the pcap file. The string in the first line "0000" represents the Pcap Header, and the strings in the second line "0010" and the third line "0020" represent the Packet Header. In this example, the string in the Packet Header is omitted. Focus on the fourth line "0030" that contains Caplen values and the data (Packet Data) behind each Caplen value, which is represented by a series of strings. For example, when the Caplen value is "02", it means that the length of the following string 1 is two bytes; when the Caplen value is "04", it means that the length of the following string 2 is 4 bytes; the Caplen value is When "03", it means that the length of the following string 3 is 3 bytes, and so on.

The technical solution of the present application will be described below.

In order to detect DNS tunnel Trojans targeting intelligent network-connected devices from traffic analysis, the detection device provided in this application needs to have the function of filtering and parsing DNS protocol from IP traffic data, and the server IP address given from the DNS response message. The function of correlation search in the data communicated between the address and the source.

Referring to FIG. 4, the present application provides a flow chart of a Trojan horse detection method. The method can be applied to a detection device, and the detection device can be located on the GW, or can also be used as an independent network device, located in the GW and the client. (clients) anywhere between. Alternatively, it may also be located at another location in the network, which is not limited in this embodiment. The method includes:

101: Receive a first query packet from the source end, where the first query packet includes the IP address of the source end.

The source is a client, and the destination is a network device that the source requests to perform service transmission. The first query packet is a DNS data packet sent by the source end to the DNS server.

In addition, the address corresponding to the source end is the IP address of the source end, and the IP address of the source end can be obtained by parsing the first query packet, or obtained from a DNS server, and the obtaining method is not limited in this embodiment .

102: When the first query packet conforms to the DNS protocol specification of the domain name system, obtain a first response packet corresponding to the first query packet, where the first response packet is sent by the DNS server.

The first response packet is a response packet found by the DNS server according to the first query packet, the response packet includes a destination IP address, and the first response packet is also a DNS packet. The first query packet may be the first DNS data packet in the detection period, or may also be a certain DNS data packet in the middle.

Complying with the DNS protocol specification means that the data content obtained after parsing the first query packet, the data structure conforms to the DNS protocol specification, for example, the DNS protocol contains the Caplen value and the Caplen value and indicates the length of the Packet Data, etc.

103: Parse the first response packet to obtain at least one destination IP address.

The at least one destination IP address belongs to the destination end. Since one destination end may include multiple service addresses, one or more destination IP addresses will be obtained by parsing the first response packet. In addition, there is a communication link between one source IP address and one resolved destination IP address. If N destination IP addresses are resolved, there are N communication links between the source IP address and the N destination IP addresses. Then, the data packet transmission situation on the N communication links is judged.

It is judged whether there is a data packet between the source IP address and the at least one destination IP address.

104: If there is no data packet between the source IP address and the at least one destination IP address, determine that a DNS tunnel Trojan exists between the source and the destination.

In addition, the above method further includes: if there is a data packet between the source IP address and each of the at least one destination IP address, determining that there is no DNS tunnel Trojan horse between the source and the destination.

Because in the normal (or non-existent) communication process of the DNS tunnel Trojan, when the IP address corresponding to the requested domain name is resolved by the DNS server to the destination IP address, there must be communication data between the source and the destination in the DNS data communication. packets, which generate communication traffic. If the data packet transmission between the source end and the destination end is not collected during the data collection by the detection device, it is determined that there is a DNS tunnel Trojan; on the contrary, if one or more than one communication link detects data packet transmission, then Make sure that there is no DNS tunneling Trojan between the source and destination.

The method can detect whether there is a DNS tunnel Trojan hidden in a data stream that fully complies with the DNS protocol specification, and solves the problem that the intrusion detection system based on general rules cannot find the DNS tunnel Trojan with high concealment.

The detection process of the above steps 101 to 104 will be described in detail below. Referring to Figure 5, the detection method provided by this embodiment includes:

201 : Start the detection apparatus to acquire a first data packet set collected in a first detection period.

Wherein, the first data packet set is all the data packets collected by the detection device in the first detection period, which are collectively referred to as the first data packet set, referred to as "Data 1". The first data packet set includes different types of data packets, for example, including but not limited to DNS data packets, HTTP data packets, TCP data packets, TLS data packets, and the like.

Specifically, the detection device periodically detects data between each client and the destination. For example, in the first detection cycle, the data between the client 1 (client 1) and the destination end 1 (DST 1) is detected, and all data packets in the first detection cycle are obtained. For example, assuming that the number of target detection data packets in the first detection period is 2000, the count starts when the first DNS data packet is detected, and until the 2000th data packet, all the contained data packets constitute the first data packet gather. As shown in Figure 6, if the number (No.) corresponding to the first DNS packet is 13219 and the number of the 2000th packet is 15219, then the set of packets numbered from the 13219th to the 15219th is the A collection of packets.

Alternatively, the detection device acquires all the data packets in a certain period of time before, for example, within nearly 10 minutes before the current moment, and acquires all the data packets transmitted between the source end and the destination end as the first data packet set.

In addition, the DNS data packet numbered 13219 is a kind of query packet. After the query packet is sent by client 1, a first response packet is detected in the number 13385 packet, and the first response packet corresponds to the first query packet. DNS packets. In this embodiment, the first data packet after the No. 13385 (excluding), that is, all the data packets from the No. 13386 data packet to the No. 15219, is called the second data packet set, In this embodiment, the second data packet set is referred to as "Data 2" for short. And the second data packet set at least includes: DNS, HTTP, TCP, TLS and other types of data packets.

It should be noted that, in this embodiment, the above-mentioned Data 1 and Data 2 are studied, and the data packets before the numbered 13219th packet are not concerned.

202: Filter out all DNS data packets in the first detection period through the target port.

The detection device obtains and filters out all DNS data packets from the first data packet set. For example, adopting the User Datagram Protocol (User Datagram Protocol, UDP) protocol, the port number (Dst Port) of the destination port is 53, and in the first data packet set, all the data packets output through port 53 are DNS data packets. These DNS data packets form a third data packet set, which is abbreviated as "Data 3" in this embodiment. The third data packet set includes only DNS type data packets.

As shown in FIG. 6 , in this embodiment, Data 3 screened out in the first data packet set includes two DNS data packets, which are the DNS data packets numbered 13219 and 13385 respectively, and these two DNS data packets are One of them is an inquiry packet and the other is a response packet.

203: Select the first query packet from all DNS data packets (Data 3).

The detection device parses all the filtered DNS packets, and the information available after parsing each DNS packet is shown in Table 2, including: packet number (No.), reception time (Time), source address (Source), destination address (Destination), protocol type (Protocol), length (Length) and remarks (Info), etc.

Table 2

Among them, the "remarks" information includes indicating whether the data packet is a query packet (standard query), or a response packet (standard query response) corresponding to a query packet, and also includes a domain name, such as cn.xxx.com and other information. "*" represents a hidden character, which can be any value from 0 to 9.

If there are multiple query packets in the DNS data packet, the first data packet among them may be selected as the first query packet, or a certain one of them may be selected as the first query packet. This embodiment does not limit the specific selection process.

204: Determine whether the first query packet conforms to the DNS protocol specification.

Specifically, an implementation method is to parse the data segment by segment according to the relevant provisions on DNS in the "RFC document", and determine whether the values of each field are within the specified range. If the value of each field is within the specified range If the values are all within the specified range, it is judged that the first query packet conforms to the DNS protocol specification. The specific requirements are listed in the DNS specification in great detail, and will not be repeated here.

In the actual operation process, the program can be judged according to the specification, or the application programming interface (Application Programming Interface, API) of the pcap reading and parsing software can be called to make judgment. See Figure 7 for a combination of open source pcap to read and analyze the software to obtain The parsing result is output after parsing the DNS query packet by the parsing software.

For example, taking the parsing of the first query packet as an example, the lines "0030" and "0040" in Figure 7 are the key parts of the stander query data packet, and the indication field in each circle is the Caplen value (or the Caplen length). Indication field), in bytes, to indicate the length of the data that follows it. For example, "02" indicates that the data length of the following segment (Packet Data in the Caplen value) is two bytes, "04" indicates that the data length of the following segment is 4 bytes, and "03" indicates that the data length of the following segment is 3 Bytes, "00" indicates that the data length of the following segment is 0 bytes. In step 204, judging whether the DNS protocol specification is complied with can be specifically understood as: judging whether the length indication field is consistent with the actual data length of the following segment. If there is one or more length indication fields that are inconsistent with the actual length of the data (box) located behind the fields, it is determined that the first query packet does not conform to the DNS protocol specification.

205: If yes, obtain the IP address of the source SRC from the first query packet.

If yes, that is, it is judged that all length indication fields parsed in the first query packet are consistent with the actual data lengths of the following segments, then the source IP address is obtained according to the information shown in Table 2 above, and the IP address of the source device can represent is IP_SRC. Specifically, a possible implementation is that the detection device first determines the destination IP address of the currently detected query packet, that is, the IP address of the DST, according to the parsed information in Table 2, and then determines the destination IP address according to the destination IP address. The IP address of the source end, i.e. IP_SRC.

206: Continue to step 205, and determine a first response packet corresponding to the first query packet according to the parsed content of the first query packet. It is the same as step 102 in the previous embodiment.

Specifically, look up the DNS data packets corresponding to the source IP address and destination IP address of the first query packet in the above-mentioned Data 3, such as the source IP address "192.168.*.** in the first query packet. ” is the destination address of another DNS packet, and the destination address “192.168.*.*” in the first query packet is the source address of the other packet, and the other packet is in “Remarks” If the information is a standard query response packet, then determine the first response packet corresponding to the other DNS data packet and the first query packet.

In this embodiment, each inquiry packet corresponds to a response packet.

207: Parse the first response packet, and obtain an IP address set of the destination terminal from the first response packet, where the IP address set of the destination terminal includes at least one destination IP address. It is the same as step 103 in the previous embodiment.

An implementation manner is to programmatically parse the first response packet according to the DNS protocol specification in the "RFC document", or to use pcap to read and parse the parsing API to obtain the parsing result. For example, the parsing result includes two destination addresses IP_DST parsed by the DNS server in the first response data packet, and marks the two destination IP addresses as: IP_DST1 is 202.**.**.**0, IP_DST2 is 202.**.**.**1. It is further obtained that the destination IP address set includes IP_DST1 and IP_DST2.

208: Determine whether there is a data packet between the source IP address and at least one destination IP address.

That is, it is determined whether there are data packets transmitted between the source IP address and each destination IP address. The data packet can be the above-mentioned first data packet set, namely "Data 1"; or, it can also be the above-mentioned second data packet set, namely "Data 2".

In this embodiment, taking the detection of the traffic transmission of the above-mentioned Data 2 as an example, the detection device filters the traffic of Data 2 according to the source address IP_SRC, and searches for the communication data of IP_SRC and IP_DST_i, (i≥1 and is a positive integer); Based on the IP_DST_i given in the IP_SRC and DNS response data packets, the technology of pairwise filtering in IP traffic is also known as the associated data search technology. Through the associated data search technology, it is possible to know whether there is any transmission on each communication link. data pack.

209: If yes, it is determined that there is no DNS tunnel Trojan horse between the source end and the destination end.

That is, if there are data packets, it is determined that there is no DNS tunnel Trojan from the source client 1 to the destination DST 1. For example, the first communication link is between IP_SRC and IP_DST1, the second communication link is between IP_SRC and IP_DST2, and only one transmission link between the first communication link and the second communication link has data packets on it, Then it is determined that there is no DNS tunnel Trojan horse between the source end and the destination end.

210: If not, it is determined that there is a DNS tunnel Trojan horse between the source end and the destination end.

That is, if the Data 2 packets are not detected in all the communication links, it is determined that there is a DNS tunnel Trojan horse between the source client 1 and the destination DST 1. For example, if no Data 2 data packets are detected on the above-mentioned first communication link and the second communication link, that is, no data packets are transmitted on the two communication links of IP_SRC, IP_DST1 and IP_DST2, it is determined that the source end to the destination end There is a DNS tunneling Trojan in between.

Because starting from the basic functions of the DNS protocol, the original intention of DNS is that the client asks the domain name server for the IP address of the server that provides a certain network service. This network service can be HTTP, HTTPs, and instant messaging. That is to say, in the normal communication process without the existence of tunnel Trojans, if the IP address corresponding to the requested domain name is also resolved by the DNS server to IP_DST, the client IP address IP_SRC must exist behind the DNS data communication, and the transmission between IP_DST and IP_SRC must exist. data pack.

In this embodiment, if the detection device collects IP data and only parses the DNS protocol data, and the DNS response packet (or response message) has given IP_DST, in the other protocol data collected after the DNS data, it must be There is data traffic communicating between IP_SRC and IP_DST; on the contrary, if the DNS response packet gives the IP_DST address, but no data packets exist for communication between IP_SRC and IP_DST, it can be determined that there is a DNS tunnel Trojan between the source and destination. .

The method provided by this embodiment can detect whether there is a DNS tunnel Trojan hidden in the data traffic that fully complies with the DNS protocol specification, which solves the problem that the intrusion detection system based on general rules cannot find the DNS tunnel Trojan with high concealment.

In addition, this method can avoid the detection method based on machine learning, which requires learning a large number of samples, and at the same time, there are inevitably the problems of false negatives and false positives, and the detection process does not need to combine the functions of the DNS protocol itself, so It will not affect the detection effect.

In addition, in the judgment of the above step 204, it also includes: if no, that is, when the currently detected first query packet does not conform to the DNS protocol specification, that is, there are one or more length indication fields and the actual length of the data behind the field Inconsistent, for example, the Caplen length indication value is "04", but the actual length of the subsequent data is not 4 bytes, then execute the following method steps. Specifically, as shown in Figure 8, the method includes:

211: Obtain the domain name requested by the source end address IP_SRC corresponding to the first query packet.

A possible implementation is that, in the above-mentioned step 203, the data packet is parsed according to the specification of the stander query in the DNS protocol, and the stander query packet is sent by the IP_SRC to the DNS server, that is, the data packet numbered 13219 in Figure 6. The remark information in the data packet includes the domain name requested by the IP_SRC. In this embodiment, the domain name requested by the IP_SRC is "cn.xxxx.com".

212: Determine whether there are invisible characters in the requested domain name.

The domain name requested by the IP_SRC is represented by ASCII code, and the ASCII code (American Standard Code for Information Interchange, American Standard Code for Information Interchange) is a set of computer coding systems based on Latin letters, mainly used to display modern English and other Western European languages . It is the most common information exchange standard and is equivalent to the international standard ISO/IEC 646. ASCII was first published as a canonical standard type in 1967, last updated in 1986, and has so far defined a total of 128 characters.

The so-called invisible characters are characters outside the range of ASCII codes (128 characters).

213: If yes, that is, there are invisible characters, it is determined that there is a DNS tunnel Trojan horse between the source end and the destination end.

214: If the invisible character does not exist, that is, the characters in the domain name requested by the IP_SRC are all characters in ASCII code, determine the first response packet corresponding to the first query packet. For the specific process, reference may be made to the foregoing step 205, which will not be repeated here.

215: Parse the first response packet, and determine whether the "data type and length" in the first data obtained after parsing the first response packet conforms to the DNS protocol specification.

Specifically, the first data is parsed according to the specification of the response data in the DNS protocol, wherein the response data is the data sent by the DNS server to the source address IP_SRC, according to the requirements of the DNS protocol specification, including the following situation: when the destination IP address IP_DST is For IPv4, the length of the IP address in the standerd query response packet should be 4; when the destination IP address IP_DST is IPv6, the length of the IP address in the standerd query response packet should be 16. The "data type and length" detection method specifically includes:

215-1: Determine whether the parsed data type is IPv4 or IPv6.

One implementation method is to obtain the IP_DST data length indication field in the load part of the first query packet (standerd query response), which is currently 4 or 6, and the indication field occupies 1 byte, if the value of the byte is 0x04, IP_DST is IPv4; if the value of this byte is 0x06, IP_DST is IPv6.

215-2: determine whether the data length (Data length) indicated in IPv4 or IPv6 is a preset value, and for the IPv4, its corresponding IP address length is a first preset value, and the first preset value is 4; For IPv6, the corresponding IP address length is a second preset value, and the second preset value is 16.

216: If yes, that is, the IP_DST length is consistent with the length parsed in the previous step 216-1, it is detected that there is no DNS tunnel Trojan.

217: If no, the parsed IP_DST length is inconsistent with the parsed length indication in combination with the previous step 216-1. For example, when the data type of the IP address is IPv4, the length of the IP address in the response packet is not 4; When the data type is IPv6, and the length of the IP address in the response packet is not 16, the judgment result is that there is a DNS tunnel Trojan.

Fig. 9 shows the normal DNS protocol standard query response parsing result of the number 13385 data packet parsing in Fig. 6, the data type of the parsing destination IP address IP_DST is IPv4, and the address length satisfies the first preset value 4, then conforms to the DNS protocol specification, which in turn determines that there is no DNS tunneling Trojan.

Figure 10 shows the abnormal parsing result of the parsing of the data packet numbered 13385 in Figure 6. The data type of the IP address IP_DST of the parsing destination is IPv4, but the actual address data length after the indication field "04" is 3, instead of The first preset value of 4, that is, does not conform to the DNS protocol specification, it is determined that there is a DNS tunnel Trojan.

The method realizes the detection of the DNS tunnel Trojan horse in the data traffic that does not conform to the DNS protocol specification, and can accurately find the hidden tunnel Trojan horse in the case of network abnormality or DNS server error, and there are no false positives or false negatives. Under the premise of normal network communication, as long as abnormal data packets or packets that do not meet the DNS requirements are found, it can quickly detect whether there is a DNS tunnel Trojan in the DNS tunnel.

Apparatus embodiments corresponding to the foregoing method embodiments are introduced below.

FIG. 11 is a schematic structural diagram of a Trojan horse detection device provided by an embodiment of the present application. The apparatus may be a network device, or a component located in the network device, such as a chip circuit. And the device can implement the DNS Trojan detection method in the foregoing embodiment.

Specifically, as shown in FIG. 11 , the apparatus may include: a collection unit 1101 , an analysis unit 1102 and a determination unit 1103 . Wherein, optionally, the parsing unit 1102 may also be referred to as a DNS protocol parsing unit, and the determining unit 1103 may also be referred to as a Trojan horse identification unit. In addition, the apparatus may further include other units or modules such as a storage unit, which are not limited in this embodiment.

The collection unit 1101 is configured to receive a first query packet from the source end, where the first query packet includes the IP address of the source end. The parsing unit 1102 is configured to obtain a first response packet corresponding to the first query packet when the first query packet conforms to the DNS protocol specification, and parse the first response packet to obtain at least one destination IP address. The determining unit 1103 is configured to determine that a DNS tunnel Trojan exists between the source end and the destination end when there is no data packet between the source end IP address and the at least one destination IP address.

Wherein, the first response packet is sent by the DNS server, and the at least one destination IP address belongs to the destination end.

Optionally, in a specific implementation manner, the determining unit 1103 is further configured to determine the source IP address in the case that there is a data packet between the source IP address and each of the at least one destination IP address. There is no DNS tunneling Trojan horse between the endpoint and the destination endpoint.

Wherein, the data packets are all the data packets in the first detection period, or are all the data packets collected from after the detection of the first response packet to the end of the first detection period. The data packet is obtained after being collected by the collection unit 1101 .

In addition, optionally, in another specific implementation manner, the acquisition unit 1101 is further configured to acquire the first response packet collected in the first detection period before acquiring the first response packet corresponding to the first query packet A data packet set, where the first data packet set at least includes data packets of the DNS protocol type. The parsing unit 1102 is further configured to filter out all DNS data packets from the first data packet set through the target port, and select the first query packet from all DNS data packets, where the DNS data packet includes a query packet and a response Bag.

Wherein, the target port is port 53 of UDP.

Optionally, in another specific embodiment, the parsing unit 1102 is specifically configured to poll each data packet in all the DNS data packets, and determine whether the length indication field carried in the currently detected data packet is the same as the length in the data packet. Indicates whether the actual data lengths after the indication field are consistent; if they are consistent, it is determined that the currently detected data packet conforms to the DNS protocol specification; and all data packets conforming to the DNS protocol specification are counted.

In a specific implementation manner, the parsing unit 1102 is specifically configured to determine that the first query packet does not contain a length indication field carried in the first query packet and the actual data length after the length indication field is inconsistent. Complies with the DNS protocol specification.

In addition, the parsing unit 1102 is further configured to detect that the length indication field carried in the first query packet is inconsistent with the actual data length after the length indication field, and determine that the first query packet does not conform to the DNS protocol specification.

Optionally, in another specific implementation manner, the parsing unit 1102 is further configured to obtain the domain name requested by the source IP address when it is determined that the first query packet does not conform to the DNS protocol specification, The domain name is represented by a string. The determining unit 1103 is further configured to determine whether there are characters other than ASCII codes in the domain name represented by the character string, and if so, determine that there is a DNS tunnel Trojan horse between the source end and the destination end.

In addition, the determining unit 1103 is further configured to, when there are no characters other than the ASCII code, the parsing unit 1102 to obtain the first response packet corresponding to the first query packet; and to parse the first response packet to obtain the first data, Described first data includes data type and length, and determining unit 1103 is also used to judge whether the data type and length parsed in the first data all meet the DNS protocol specification, if all meet, then determine that there is no DNS tunnel Trojan horse .

And, the determining unit 1103 is further configured to determine that there is a DNS tunnel Trojan horse when at least one of the data type and length in the first data does not conform to the DNS protocol specification.

FIG. 12 shows a schematic structural diagram of a detection device, and the detection device may be a network device. The detection device includes: a processor 110 , a memory 120 , and at least one communication interface 130 . Wherein, the processor 110, the memory 120 and the at least one communication interface 130 may be coupled through a communication bus.

The processor 110 is the control center of the detection device, and can be used for communication between devices, for example, including information transmission with at least one client and other devices such as the server DST.

The processor 110 may be composed of an integrated circuit (Integrated Circuit, IC), for example, may be composed of a single packaged IC, or may be composed of a plurality of packaged ICs connected with the same function or different functions. For example, the processor 110 may include a central processing unit (Central Processing Unit, CPU) or a digital signal processor (Digital Signal Processor, DSP) or the like.

In addition, the processor 110 may further include a hardware chip, and the hardware chip may be an application specific integrated circuit (ASIC), a programmable logic device (PLD) or a combination thereof. The above-mentioned PLD can be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a general-purpose array logic (generic array logic, GAL) or any combination thereof. Optionally, the hardware chip is a chip system or a chip circuit.

The memory 120 is used for storing and exchanging various types of data or software, including storing the first data packet set, the second data packet set, the third data packet set, the query packet and the response packet, and the like. In addition, computer programs and codes may be stored in the memory 120 .

Specifically, the memory 120 may include volatile memory (volatile memory), such as random access memory (Random Access Memory, RAM); may also include non-volatile memory (non-volatile memory), such as flash memory (flash memory) memory), a hard disk (Hard Sisk Drive, HDD) or a solid-state drive (Solid-State Drive, SSD), the memory 120 may also include a combination of the above-mentioned types of memory.

Communication interface 130, using any transceiver-like device, for communicating with other devices or communication networks, such as Ethernet, Radio Access Network (RAN), Wireless Local Area Network (WLAN), Virtual Extensible Local Area Network (VXLAN), etc.

It should be understood that the above detection device may also include other more or less components, and the structures illustrated in the embodiments of the present application do not constitute a specific limitation on the detection device. And the components shown in FIG. 12 can be implemented in hardware, software, firmware or any combination thereof.

When implemented in software, it can be implemented in whole or in part in the form of a computer program product. For example, the acquisition unit 1101 in the detection device shown in FIG. 11 can be implemented through the communication interface 130, the functions of the analysis unit 1102 and the determination unit 1103 can be implemented by the processor 110, and the function of the storage unit can be implemented by the processor 110. Implemented by memory 120 .

Specifically, the detection device uses at least one communication interface 130 to receive a first query packet from the source end, where the first query packet includes the IP address of the source end, and when the processor 110 determines that the first query packet conforms to the DNS protocol specification, Obtain a first response packet corresponding to the first query packet, and parse the first response packet to obtain at least one destination IP address; and, detect when there is no difference between the source IP address and the at least one destination IP address When there is a data packet, it is determined that there is a DNS tunnel Trojan horse between the source end and the destination end. Specifically, the processor 110 executes the method shown in FIG. 4 , FIG. 5 or FIG. 8 in the foregoing embodiment by calling the program code in the memory 120 .

In addition, the detection device also includes a mobile communication module, a wireless communication module, and the like. The mobile communication module includes modules with wireless communication functions such as 2G/3G/4G/5G. In addition, filters, switches, power amplifiers, low noise amplifiers (LNAs), etc. may also be included. The wireless communication module can provide wireless communication solutions including WLAN, bluetooth (bluetooth), global navigation satellite system (GNSS), frequency modulation (frequency modulation, FM), etc. applied to the detection equipment.

In addition, an embodiment of the present application also provides a network system, and the network system structure may be the network architecture shown in the aforementioned FIG. 1 or FIG. 2 , including at least one client, at least one server, a DNS server, and a communication device such as a gateway. . The structure of each of the above devices may be the detection device shown in FIG. 12 , which is used to implement the detection method in the foregoing embodiment.

This embodiment can detect whether there is a DNS tunnel Trojan hidden in a data packet that fully complies with the DNS protocol specification, and solves the problem that a general rule-based intrusion detection system cannot find a DNS tunnel Trojan with high concealment. In addition, for the detection of DNS tunnel Trojan horses in data packets that do not conform to the DNS protocol specification, the hidden tunnel Trojan horses can be accurately discovered in the case of network abnormalities or DNS server errors, and there are no false positives or false negatives. Under the premise of normal network communication, as long as abnormal data packets or packets that do not meet the DNS requirements are found, it can quickly detect whether there is a DNS tunnel Trojan in the DNS tunnel.

Embodiments of the present application also provide a computer program product, where the computer program product includes one or more computer program instructions. When a computer loads and executes the computer program instructions, all or part of the processes or functions described in the various embodiments described above occur. The computer may be a general purpose computer, special purpose computer, computer network, or other programmable device.

The computer program instructions may be stored in or transmitted from one computer readable storage medium to another computer readable storage medium, for example, the computer instructions may be transmitted from a communication device, computer, server or data The center transmits to another communication device by wire or wireless.

Wherein, the computer program product and the computer program instructions may be located in the memory of the aforementioned detection device, so as to implement the Trojan horse detection method described in the embodiments of the present application.

Also, in the description of this application, unless stated otherwise, "plurality" means two or more than two. In addition, in order to clearly describe the technical solutions of the embodiments of the present application, in the embodiments of the present application, words such as "first" and "second" are used to distinguish the same or similar items with basically the same function and effect. Those skilled in the art can understand that the words "first", "second" and the like do not limit the quantity and execution order, and the words "first", "second" and the like are not necessarily different.

The above-described embodiments of the present application do not limit the protection scope of the present application.

Claims (20)

A Trojan horse detection method, characterized in that the method comprises: receiving a first query packet from the source, where the first query packet includes the IP address of the source; When the first query packet conforms to the domain name system DNS protocol specification, obtain a first response packet corresponding to the first query packet, and the first response packet is sent by the DNS server; Parsing the first response packet to obtain at least one destination IP address; If there is no data packet between the source IP address and the at least one destination IP address, it is determined that there is a DNS tunnel Trojan horse between the source and the destination. The method of claim 1, further comprising: If there is a data packet between the source end IP address and each of the at least one destination IP address, it is determined that there is no DNS tunnel Trojan horse between the source end and the destination end. The method according to claim 1 or 2, wherein before acquiring the first response packet corresponding to the first query packet, the method further comprises: Obtain the first data packet set collected in the first detection period, and the first data packet set at least includes the data packets of the DNS protocol type; The receiving the first query packet from the source includes: Filter out all DNS data packets from the first data packet set through the target port, and the DNS data packets include query packets and response packets; The first challenge packet is selected from all the DNS data packets. The method according to any one of claims 1-3, wherein the first query packet conforms to the DNS protocol specification, comprising: The length indication field carried in the first query packet is consistent with the actual data length located after the length indication field. The method of claim 4, further comprising: If the length indication field carried in the first inquiry packet is inconsistent with the actual data length located after the length indication field, the first inquiry packet does not conform to the DNS protocol specification. The method according to claim 5, wherein when the first query packet does not conform to the DNS protocol specification, the method further comprises: Obtain the domain name requested by the source IP address, where the domain name is represented by a preset character string; Judging whether there are characters other than ASCII codes in the domain name represented by the preset character string; If there is, it is determined that there is a DNS tunnel Trojan horse between the source end and the destination end. The method of claim 6, further comprising: If there is no character other than the ASCII code, obtain the first response packet corresponding to the first query packet; Parsing the first response packet to obtain first data, where the first data includes a data type and a length; If both the data type and length in the first data conform to the DNS protocol specification, it is determined that there is no DNS tunneling Trojan. The method of claim 7, further comprising: If at least one of the data type and length in the first data does not conform to the DNS protocol specification, it is determined that there is a DNS tunneling Trojan horse. The method according to any one of claims 1-8, wherein the data packets are all data packets in the first detection period, or, from the time after the first response packet is detected to the time of the first detection period. All packets collected at the end of the first detection period. A Trojan horse detection device, characterized in that the device comprises: a collection unit, configured to receive a first query packet from the source, where the first query packet includes the IP address of the source; a parsing unit, configured to obtain a first response packet corresponding to the first query packet when the first query packet conforms to the DNS protocol specification of the Domain Name System, and parse the first response packet to obtain at least one destination IP address, where The first response packet is sent by the DNS server; A determining unit, configured to determine that a DNS tunnel Trojan exists between the source end and the destination end when there is no data packet between the source end IP address and the at least one destination IP address. The device of claim 10, wherein: The determining unit is further configured to determine that there is no DNS between the source end and the destination end when there is a data packet between the source end IP address and each of the at least one destination IP address Tunnel Trojan. The device according to claim 10 or 11, characterized in that: The collection unit is further configured to obtain the first data packet set collected in the first detection period, and the first data packet set at least includes the data packets of the DNS protocol type; The parsing unit is further configured to filter out all DNS data packets from the first data packet set through a target port, and select the first query packet from the all DNS data packets, where the DNS data packets include query and response packets. The device according to any one of claims 10-12, characterized in that, The parsing unit is specifically configured to determine that the first query packet complies with the DNS protocol specification when the length indication field carried in the first query packet is consistent with the actual data length after the length indication field. The device of claim 13, wherein: The parsing unit is further configured to determine that the first query packet does not conform to the DNS protocol specification when the length indication field carried in the first query packet is inconsistent with the actual data length after the length indication field . The apparatus of claim 14, wherein: The parsing unit is further configured to obtain the domain name requested by the source IP address, where the domain name is represented by a preset character string; The determining unit is further configured to determine whether there are characters other than ASCII codes in the domain name represented by the preset character string, and if so, determine that there is a DNS tunnel Trojan horse between the source end and the destination end. The apparatus of claim 15, wherein: The parsing unit is further configured to obtain a first response packet corresponding to the first query packet in the absence of characters other than the ASCII code, and parse the first response packet to obtain first data, so The first data includes the data type and length; The determining unit is further configured to determine that there is no DNS tunnel Trojan horse when both the data type and length in the first data conform to the DNS protocol specification. The apparatus of claim 16, wherein: The determining unit is further configured to determine that there is a DNS tunnel Trojan horse when at least one of the data type and length in the first data does not conform to the DNS protocol specification. The device according to any one of claims 10-17, wherein the data packets are all data packets in the first detection period, or, from the time after the detection of the first response packet to the time of the All packets collected at the end of the first detection period. A detection device, comprising a processor and a memory, the processor and the memory are coupled, characterized in that: the memory for storing computer program instructions; The processor is configured to execute the instructions stored in the memory, so that the detection device performs the method according to any one of claims 1 to 9. A computer-readable storage medium, wherein computer program instructions are stored in the computer-readable storage medium, The computer program instructions, when executed, implement a method as claimed in any one of claims 1 to 9.

Images