CN112640392B - 一种木马检测方法、装置和设备 - Google Patents

一种木马检测方法、装置和设备 Download PDF

Info

Publication number
CN112640392B
CN112640392B CN202080004649.4A CN202080004649A CN112640392B CN 112640392 B CN112640392 B CN 112640392B CN 202080004649 A CN202080004649 A CN 202080004649A CN 112640392 B CN112640392 B CN 112640392B
Authority
CN
China
Prior art keywords
packet
dns
data
address
destination
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202080004649.4A
Other languages
English (en)
Other versions
CN112640392A (zh
Inventor
那键
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of CN112640392A publication Critical patent/CN112640392A/zh
Application granted granted Critical
Publication of CN112640392B publication Critical patent/CN112640392B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1425—Traffic logging, e.g. anomaly detection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/145—Countermeasures against malicious traffic the attack involving the propagation of malware through the network, e.g. viruses, trojans or worms

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Evolutionary Computation (AREA)
  • Data Mining & Analysis (AREA)
  • Medical Informatics (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Artificial Intelligence (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Virology (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请公开了一种木马检测方法、装置和设备，所述方法包括：接收来自源端的第一询问包，所述第一询问包中包括源端的IP地址，当所述第一询问包符合域名***DNS协议规范，获取与所述第一询问包对应的第一响应包，所述第一响应包为目的端发送，解析第一响应包得到至少一个目的IP地址；如果所述源端IP地址和所述至少一个目的IP地址之间均不存在数据包，则确定源端到目的端之间存在DNS隧道木马。本方法能够检测出符合DNS协议规范的数据包中是否隐藏有DNS隧道木马，解决了基于一般规则的入侵检测***无法发现高隐蔽性DNS隧道木马的问题。

Description

一种木马检测方法、装置和设备
技术领域
本申请涉及通信领域，尤其是涉及一种木马检测方法、装置和设备。
背景技术
隧道技术，是提高网络协议(Internet Protocol，IP)数据传输稳定性、安全性的一个重要方法，在隧道技术中常用的隧道传输协议包括：互联网安全协议(InternetProtocol Security，IPsec)、通用路由封装(Generic Routing Encapsulation，GRE)、点对点隧道协议(Pointto Point Tunneling Protocol，PPTP)等。网络木马，是指隐藏在网络***中的一段恶意代码。它具备破坏和删除文件、发送口令、键盘记录等功能，是具备特殊黑客功能的一种后门程序，其英文名称为Trojan(特洛伊)，含义取自古希腊时期的特洛伊之战中的一种成功战术，攻击者可以利用网络木马在被攻击***长期潜伏，持续获取用户的敏感信息。由于隐蔽性好且危害性大，网络控制类木马自诞生以来被黑客广泛使用，危害遍及网络***的各行各业，网络安全、工业生产安全、金融安全等传统产业安全都受到极大的威胁。
为降低木马对于正常网络连接的威胁，安全人员对搜集到的大量木马样本进行特征分析，发现一般的网络木马在传输时往往采用私有专用传输协议。基于这样的研究结果，研究人员提出多种方法来发现私有专用传输协议，从而可以查找出网络木马，提升终端设备抵抗网络木马攻击的能力，这样也迫使设计者将网络木马设计的逐渐转向隐蔽自身传输协议特征的路线发展，逐渐出现了基于合法通信协议的新型木马。
近年来，伪装成域名***(DomainName System，DNS)、互联网控制消息协议(Internet Control Message Protocol，ICMP)等合法协议的网络木马技术大量出现，对政府、公司、个人用户构成极大威胁。例如据报道，某高级可持续攻击(AdvancedPersistantAttack，APT)组织接连对宝马、丰田等知名车企进行网络攻击，该组织的攻击工具中就包含有伪装成DNS协议进行数据传输的木马。在攻击过程中，DNS协议成为该木马进行数据传输的通道，这种以DNS协议为传输通道进行数据传输的木马又称为DNS隧道木马。因此，如何在网络传输通道中检测出DNS隧道木马是本领域技术人员亟待解决的技术问题。
发明内容
本申请提供一种木马检测方法、装置和设备，用于解决上述技术问题，具体地，公开了以下技术方案：
第一方面，本申请提供了一种木马检测方法，该方法包括：接收来自源端的第一询问包，所述第一询问包中包括源端的IP地址，当所述第一询问包符合DNS协议规范，获取与所述第一询问包对应的第一响应包；解析所述第一响应包得到至少一个目的IP地址；如果所述源端IP地址和所述至少一个目的IP地址之间均不存在数据包，则确定所述源端和目的端之间存在DNS隧道木马。其中，第一响应包为DNS服务器发送，所述至少一个目的IP地址归属于所述目的端。
本方法能够检测出符合DNS协议规范的数据流中是否隐藏有DNS隧道木马，解决了基于一般规则的入侵检测***无法发现高隐蔽性DNS隧道木马的问题。
另外，本方法又可以避免采用基于机器学习的检测方法，需要对大量样本进行学习，同时又不可避免的存在漏报、误报的问题，并且检测过程中也无需结合DNS协议本身的功能，因此不会影响检测的效果。
可选的，结合第一方面，在第一方面的一种可能的实现中，上述方法还包括：如果所述源端IP地址和每个所述至少一个目的IP地址之间均存在数据包，则确定所述源端和所述目的端之间不存在DNS隧道木马。
结合第一方面，在第一方面的另一种可能的实现中，获取与所述第一询问包对应的第一响应包之前，还包括：获取在第一检测周期内采集的第一数据包集合，所述第一数据包集合中至少包括DNS协议类型的数据包；
所述接收来自源端的第一询问包，包括：通过目标端口从所述第一数据包集合中过滤出所有DNS数据包，所述DNS数据包包括询问包和响应包；从所述所有DNS数据包中筛选出所述第一询问包。其中，所述目标端口为UDP的53号端口。
本实现方式通过目标端口可以过滤出所有DNS数据包，从而为后续在传输DNS数据包中检测隧道中是否存在DNS数据包提供依据。
结合第一方面，在第一方面的又一种可能的实现中，所述第一询问包符合所述DNS协议规范的数据包，包括：所述第一询问包中携带的长度指示字段与位于所述长度指示字段之后的实际数据长度一致。
另外，上述方法还包括：如果所述第一询问包中携带的长度指示字段与位于所述长度指示字段之后的实际数据长度不一致，则确定所述第一询问包不符合所述DNS协议规范。
本实现方式利用解析数据包中pcap文件的内容，得到数据结构和内容，从而判断解析的数据结构和内容是否符合DNS协议规范，进而筛选出所有符合DNS协议规范的数据包。
结合第一方面，在第一方面的又一种可能的实现中，在确定所述第一询问包不符合所述DNS协议规范的情况下，所述方法还包括：获取所述源端IP地址请求的域名，所述域名通过预设字符串表示；判断通过所述预设字符串表示的域名中是否存在ASCII码之外的字符；如果存在，则确定所述源端到所述目的端之间存在DNS隧道木马。
结合第一方面，在第一方面的又一种可能的实现中，上述方法还包括：如果不存在所述ASCII码之外的字符，则获取与所述第一询问包对应的第一响应包；解析所述第一响应包得到第一数据，所述第一数据中包含数据类型和长度，判断所述第一数据中包含的数据类型和长度是否均符合DNS协议规范；如果均符合，则确定不存在DNS隧道木马。
可选的，上述方法还包括：如果所述第一数据中包含数据类型和长度的至少一个不符合所述DNS协议规范，则确定存在DNS隧道木马。
本方法实现了对于不符合DNS协议规范的数据流中DNS隧道木马检测，能够在网络异常或者DNS服务器出错的情况下，准确地发现隐藏的隧道木马，并且不存在误报、漏报的情况。在网络通信正常的前提下，只要发现不符DNS合规范要求的异常数据包或报文，就可以迅速地检测出隧道中是否存在DNS隧道木马。
可选的，在第一方面的又一种可能的实现中，所述数据包为第一检测周期内的所有数据包，或者，为从检测到的第一个响应包之后开始到所述第一检测周期结束时采集的所有数据包。
其中，第一检测周期内的所有数据包又称为第一数据包集合，为从检测到的第一个响应包之后开始到所述第一检测周期结束时采集的所有数据包又称为第二数据包集合。本实现方式，当获取并检测第二数据包集合时，由于该第二数据包集合是前述第一数据包集合中的子集，所以相比于检测第一数据包集合的传输数据包，本方法仅检测第二数据包集合，检测包的数量减少，检测效率提高。
第二方面，本申请还提供了一种木马检测装置，所述装置包括：采集单元、解析单元、和确定单元等，
其中，采集单元，用于接收来自源端的第一询问包，所述第一询问包中包括源端的IP地址，解析单元，用于在所述第一询问包符合域名***DNS协议规范，获取与所述第一询问包对应的第一响应包，所述第一响应包为DNS服务器发送；确定单元，用于在所述源端IP地址和所述至少一个目的IP地址之间均不存在数据包的情况下，确定所述源端到目的端之间存在DNS隧道木马。
可选的，结合第二方面，在第二方面的一种可能实现中，所述确定单元，还用于在所述源端IP地址和每个所述至少一个目的IP地址之间均存在数据包的情况下，确定所述源端和所述目的端之间不存在DNS隧道木马。
结合第二方面，在第二方面的另一种可能的实现中，所述采集单元，还用于获取在第一检测周期内采集的第一数据包集合，所述第一数据包集合中至少包括DNS协议类型的数据包；所述解析单元，还用于通过目标端口从所述第一数据包集合中过滤出所有DNS数据包，以及从所有DNS数据包中选择所述第一询问包，所述DNS数据包包括询问包和响应包。
结合第二方面，在第二方面的又一种可能的实现中，所述解析单元，具体用于当所述第一询问包中携带的长度指示字段与位于所述长度指示字段之后的实际数据长度一致时，确定所述第一询问包符合所述DNS协议规范。
结合第二方面，在第二方面的又一种可能的实现中，所述解析单元，还用于当所述第一询问包中携带的所述长度指示字段与位于所述长度指示字段之后的实际数据长度不一致时，确定所述第一询问包不符合所述DNS协议规范。
结合第二方面，在第二方面的又一种可能的实现中，所述解析单元，还用于在确定所述第一询问包不符合所述DNS协议规范的情况下，获取所述源端IP地址请求的域名，所述域名通过预设字符串表示；判断通过所述预设字符串表示的域名中是否存在ASCII码之外的字符，如果存在，则确定所述源端到所述目的端之间存在DNS隧道木马。
结合第二方面，在第二方面的又一种可能的实现中，所述解析单元，还用于不存在所述ASCII码之外的字符的情况下，获取与所述第一询问包对应的第一响应包，解析所述第一响应包得到第一数据，所述第一数据中包含数据类型和长度；所述确定单元，还用于在所述第一数据中的数据类型和长度均符合DNS协议规范时，确定不存在DNS隧道木马。
结合第二方面，在第二方面的又一种可能的实现中，所述确定单元，还用于当所述第一数据中的数据类型和长度的至少之一不符合所述DNS协议规范时，确定存在DNS隧道木马。
可选的，结合第二方面，在第二方面的上述各种可能的实现中，所述数据包为第一检测周期内的所有数据包，或者，为从检测到的第一个响应包之后开始到所述第一检测周期结束时采集的所有数据包。
第三方面，本申请提供了一种检测设备，该设备包括处理器和存储器，且处理器与存储器耦合，具体地，存储器用于存储计算机程序指令；处理器用于执行存储器中存储的所述指令，以使得所述检测设备执行前述第一方面及第一方面各种实现方式中的方法。
具体地，上述第二方面中各个单元模块，比如采集单元、解析单元和确定单元等的功能可通过所述处理器和所述存储器来实现。
可选的，所述检测设备为一种处理芯片，或芯片***。
可选的，所述检测设备为一种网络设备，或部署在网络设备中的功能模块。
此外，所述装置还可以包括至少一个通信接口，收发器、传感器等部件。
第四方面，本申请还提供了一种计算机可读存储介质，该存储介质中存储有指令，使得当指令在计算机或处理器上运行时，可以用于执行前述第一方面以及第一方面各种实现方式中的方法。
另外，本申请还提供了一种计算机程序产品，该计算机程序产品包括计算机指令，当该指令被计算机或处理器执行时，可实现前述第一方面或第一方面的各种实现方式中的方法。
需要说明的是，上述第二方面至第四方面的各种实现方式的技术方案所对应的有益效果与前述第一方面以及第一方面的各种实现方式的有益效果相同，具体参见上述第一方面以及第一方面的各种实现方式中的有益效果描述，不再赘述。
附图说明
图1为本申请实施例提供的一种建立客户端与服务器之间通信连接的示意图；
图2为本申请实施例提供的另一种建立客户端与服务器之间通信连接的示意图；
图3为本申请实施例提供的一种对pcap文件解析后得到的数据内容的示意图；
图4为本申请实施例提供的一种木马检测方法的流程图；
图5为本申请实施例提供的另一种木马检测方法的流程图；
图6为本申请实施例提供的一种解析DNS数据包后得到数据内容的示意图；
图7为本申请实施例提供的一种解析得到数据内容的示意图；
图8为本申请实施例提供的又一种木马检测方法的流程图；
图9为本申请实施例提供的另一种解析得到数据内容的示意图；
图10为本申请实施例提供的又一种解析得到数据内容的示意图；
图11为本申请实施例提供的一种木马检测装置的结构示意图；
图12为本申请实施例提供的一种检测设备的结构示意图。
具体实施方式
为了使本技术领域的人员更好地理解本申请实施例中的技术方案，并使本申请实施例的上述目的、特征和优点能够更加明显易懂，下面结合附图对本申请实施例中的技术方案作进一步详细的说明。
在对本申请实施例的技术方案说明之前，首先结合附图对本申请实施例的应用场景和相关技术术语进行介绍。
本申请的技术方案可应用于一种网络***，比如智能网联汽车***，如图1所示在智能网络汽车***场景下，包含至少一个客户端(client)和至少一个服务端(server)，另外还可以包括其他网络设备，比如网关(gate way，GW)、远程信息处理器(Telematics BOX，T-box)。其中，客户端与服务端，以及GW之间的通信传输遵循DNS协议。
本实施例提供的方法可应用于一种检测装置，该检测装置可作为一个独立的网络设备部署在网络***中，或者还可以被部署在车辆网关GW，T-box、或者DNS服务器中。并且，所述T-box存在DNS数据需求的局域网内，不需要全流量解析。
首先，对DNS协议和DNS协议中的相关概念做简要介绍。
DNS直译为域名***，是将域名和IP地址进行映射的一个网络服务，在一般应用场景下，采用client/server网络连接方式的进行部署。例如将一个网络终端作为client(客户端)，可以指定一个公认的具备域名解析功能的server(服务端)，比如Google公司的一个免费DNS域名所映射的server的地址为8.8.8.8。
域名(Domain Name)是由一串用点分隔的名字组成的Internet上某一台计算机或计算机组的名称，用于在数据传输时对计算机的定位标识(有时也指地理位置)。由于IP地址具有不方便记忆并且不能显示地址组织的名称和性质等缺点，因此人们设计出了域名，并通过DNS来将域名和IP地址相互映射，从而使用户更方便地访问互联网，避免去记住能够被机器直接读取的IP地址数串。
具体地，建立client与server之间通信连接的过程可参见图1所示，当client需要完成某个网络业务时，会向DNS服务器(DNS server)端发送一个请求消息，该请求消息中包含域名，比如www.example.com，该请求消息可用于询问www.example.com的IP地址。DNSserver端接收后根据自身数据库当中存储的域名与IP地址的映射关系，查找出与域名www.example.com关联的IP地址，并将该IP地址标记为IP_DST，表示目的端IP地址。DNSserver端将该IP_DST通过响应数据反馈给client，client收到响应数据后，解析出IP_DST，随后client的IP地址IP_SRC与IP_DST建立新的网络连接，实现特定的网络业务。其中SRC为Source的缩写，表示“源端”，DST为Destination的缩写，表示“目的端”。
另外，在包含GW的场景下，比如在某一局域网场景，可指定一个GW为server端，利用该GW转发局域网内各个client的域名请求消息，然后再将外部DNS server根据各个域名请求消息所返回的IP_DST地址转发给对应的client，其原理如图2所示，具体的实现过程可参考图1的交互过程，本实施例对此不再赘述。
在上述各个client与DNS server，或者client与交换机之间传输数据时，通过DNS隧道传输的流量可能存在DNS隧道木马，因此本申请目的是检测网络传输通道中是否被存在DNS隧道木马。
下面对本申请的技术方案中涉及的其他术语概念进行介绍。
(1)HTTP协议和HTTPs协议
HTTP协议(Hypertext Transfer Protocol，超文本传输协议)是用来在Internet上传送超文本的传送协议。它是运行在TCP/IP协议族之上的HTTP应用协议，它可以使浏览器更加高效，使网络传输减少。
HTTPs协议(Hyper Text Transfer Protocol over SecureSocket Layer，超文本传输安全协议)是由HTTP加上TLS/SSL协议构建的可进行加密传输、身份认证的网络协议，主要通过数字证书、加密算法、非对称密钥等技术完成互联网数据传输加密，实现互联网传输安全保护。
安全套接字协议(Secure Sockets Layer，SSL)，及其继任者传输层安全(Transport Layer Security，TLS)是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层与应用层之间对网络连接进行加密。
(2)RFC文档
RFC文档也称请求注解文档(Requests for Comments，RFC)，这是用于发布Internet标准和Internet其他正式出版物的一种网络文件或工作报告。RFC文档初创于1969年，RFC出版物由RFC编辑(RFC Editor)直接负责，并接受体系结构委员会(InternetArchitecture Board，IAB)的一般性指导。现在已经有3000多个RFC系列文件，并且这个数目还在不断增加,内容和Internet(开始叫做为ARPANET)相关。草案讨论了计算机通讯的方方面面，重点在网络协议，过程，程序，以及一些会议注解，意见，风格方面的概念。
(3)pcap文件
pcap是常用的数据包存储格式，可以理解为就是一种文件格式，里面的数据是按照特定格式存储的，所以如果想要解析里面的数据，就必须按照一定的格式。利用专业工具，比如用安装了HEX-Editor插件的Notepad++打开pcap文件，能够显示16进制数据的格式，再用wireshark这种抓包工具就可以正常打开这种文件，查看里面的网络数据报了，同时wireshark也可以生成这种格式的文件。当然还可以使用其它工具来查看pcap文件。
一个pcap文件包括pcap报头(Pcap Header)和数据区两个部分，其中，数据区又分成多个数据包，每个包中包括数据包头(Packet Header)和数据(Packet Data)两个部分，总体结构如下表1所示：
表1
Figure BDA0002946840810000061
其中，Pcap报头是文件头，每一个pcap文件只有一个文件头，总共占24(B)字节。数据包头可以有多个，每个数据包头后面都跟着真正的数据包。以下是Packet Header的4个字段含义；
Timestamp(4B)：时间戳高位，精确到秒(seconds)，这是Unix操作***时间戳。可用于记录捕获数据包的时间。Timestamp(4B)：时间戳低位，能够精确到毫秒(microseconds)。Caplen(4B)：当前数据区的长度，即抓取到的数据帧长度，由此可以得到下一个数据帧的位置。Len(4B)：离线数据长度，网路中实际数据帧的长度，一般不大于Caplen，多数情况下和Caplen值一样。
Packet Data中，Packet是链路层的数据帧，长度就是Packet Header中定义的Caplen值，所以每个Packet Header后面都跟着Caplen长度的Packet Data。也就是说pcap文件并没有规定捕获的数据帧之间有什么间隔字符串。Packet数据帧部分的格式为标准的网络协议格式。参见图3所示，为对pcap文件解析后得到的数据内容示意图。第一行“0000”中的字符串表示Pcap Header，第二行“0010”和第三行“0020”部分字符串表示的是PacketHeader，本示例中省略Packet Header中的字符串。重点关注第四行“0030”中包含Caplen值和位于每个Caplen值后面的数据(Packet Data)，该数据通过一系列的字符串表示。比如当Caplen值为“02”时，表示后面的字符串1的长度为两个字节；当Caplen值为“04”时，表示后面的字符串2的长度为4个字节；Caplen值为“03”时，表示后面的字符串3的长度为3个字节，以此类推。
下面对本申请的技术方案进行说明。
本申请为了从流量分析中检测出针对智能网联设备的DNS隧道木马，提供的检测装置需要具备从IP流量数据中过滤并解析DNS协议的功能，以及具备从DNS响应报文给出的服务器IP地址与源端之间通信的数据中关联搜索的功能。
参见图4，为本申请提供了一种木马检测方法的流程图，该方法可应用于一种检测装置，该检测装置可以位于GW上，或者还可以作为一个独立的网络设备，位于GW和client(客户端)之间任意位置。或者还可以位于网络中的其他位置，本实施例对此不予限制。该方法包括：
101：接收来自源端的第一询问包，所述第一询问包中包括源端的IP地址。
所述源端为某一客户端，所述目的端为源端请求进行业务传输的网络设备。所述第一询问包是所述源端向DNS服务器发送的DNS数据包。
此外，所述源端所对应的地址为源端IP地址，所述源端的IP地址可通过解析所述第一询问包获得，或者，从DNS服务器中获得，本实施例对获得方式不予限制。
102：当所述第一询问包符合域名***DNS协议规范，获取与所述第一询问包对应的第一响应包，所述第一响应包为DNS服务器发送。
所述第一响应包是所述DNS服务器根据第一询问包查找到的响应数据包，该响应数据包中包括目的IP地址，且所述第一响应包也为DNS数据包。所述第一询问包可以是检测周期内的第一个DNS数据包，或者也可以是中间某一个DNS数据包。
所述符合DNS协议规范是指，对第一询问包解析后得到的数据内容，数据结构符合DNS协议规范，比如DNS协议中包含Caplen值与该Caplen值后指示Packet Data长度等。
103：解析所述第一响应包得到至少一个目的IP地址。
所述至少一个目的IP地址归属于所述目的端，由于一个目的端可能包含多个服务地址，所以解析第一响应包会获得一个或多个目的IP地址。并且，一个源端IP地址与解析的一个目的IP地址之间存在一条通信链路，如果解析有N个目的IP地址，则源端IP地址与N个目的IP地址间存在N条通信链路。然后判断N条通信链路上的数据包传输情况。
判断所述源端IP地址和所述至少一个目的IP地址之间是否均存在数据包。
104：如果所述源端IP地址和所述至少一个目的IP地址之间均不存在数据包，则确定所述源端到所述目的端之间存在DNS隧道木马。
另外，上述方法还包括：如果所述源端IP地址和每个所述至少一个目的IP地址之间均存在数据包，则确定所述源端到所述目的端之间不存在DNS隧道木马。
因为在正常的(或不存在)DNS隧道木马的通信过程当中，当请求域名对应的IP地址被DNS服务器解析出目的IP地址时，DNS数据通信中必然存在源端与目的端之间的通信数据包，产生通信流量。如果检测装置采集的数据过程中，没有采集到源端和目的端之间的数据包传输，则确定存在DNS隧道木马；反之，如果有一条或者一条以上的通信链路检测到数据包传输，则确定源端和目的端之间不存在DNS隧道木马。
本方法能够检测出完全符合DNS协议规范的数据流中，是否隐藏有DNS隧道木马，解决了基于一般规则的入侵检测***无法发现高隐蔽性DNS隧道木马的问题。
下面对上述步骤101至104的检测过程进行详细说明。参见图5，本实施例提供的检测方法包括：
201：启动检测装置，获取在第一检测周期内采集的第一数据包集合。
其中，第一数据包集合为检测装置在第一检测周期内采集的所有数据包，统称为第一数据包集合，简称“Data 1”。其中该第一数据包集合中包括不同类型的数据包，比如包括但不限于DNS数据包、HTTP数据包、TCP数据包、TLS数据包等。
具体地，检测装置周期性地检测各个客户端与目的端之间的数据。比如在第一检测周期对客户端1(client 1)与目的端1(DST 1)之间的数据进行检测，获得第一检测周期内的所有数据包。例如，假设第一检测周期内目标检测数据包的数量为2000个，当检测到第一个DNS数据包时开始计数，到第2000个数据包为止，所包含的所有数据包组成第一数据包集合。如图6所示，如果第1个DNS数据包所对应的编号(No.)是13219，第2000个数据包的编号为15219，则编号从第13219至第15219的数据包集合为所述第一数据包集合。
或者，检测装置获取之前某一时间段内的所有数据包，比如在当前时刻之前的近10min之内，获取源端和目的端之间传输的所有数据包，作为所述第一数据包集合。
此外，编号为13219的DNS数据包为一种询问包，该询问包被client 1发出之后，在编号第13385个包中检测到第一响应包，该第一响应包与第一询问包对应的DNS数据包。本实施例中，将从编号第13385(不含)之后的第一个数据包，即从编号第13386的数据包开始至编号第15219之间的所有数据包，称为第二数据包集合，本实施例将所述第二数据包集合简称为“Data 2”。且所述第二数据包集合中至少包括：DNS、HTTP、TCP、TLS等类型的数据包。
需要说明的是，本实施例对上述Data 1和Data 2进行研究，对在编号第13219个包之前的数据包不予关心。
202：通过目标端口过滤出所述第一检测周期内的所有DNS数据包。
检测装置从所述第一数据包集合中获得筛选出所有DNS数据包。例如采用用户数据报协议(User Datagram Protocol，UDP)协议，目的端口的端口号(Dst Port)为53，在所述第一数据包集合中所有经过53号端口输出的数据包为DNS数据包。这些DNS数据包组成第三数据包集合，本实施例将该第三数据包集合简称为“Data 3”。所述第三数据包集合中仅包括DNS类型的数据包。
如图6所示，本实施例中在第一数据包集合中筛选出的Data 3里包含两个DNS数据包，分别是编号第13219和第13385的DNS数据包，且这两个DNS数据包中一个是询问包，一个是响应包。
203：从所有DNS数据包(Data 3)中选择第一询问包。
检测装置对筛选出的所有DNS数据包做解析，对于每个DNS数据包解析后可得的信息如表2所示，包括：数据包编号(No.)、接收时间(Time)、源端地址(Source)、目的端地址(Destination)、协议类型(Protocol)、长度(Length)和备注(Info)等。
表2
Figure BDA0002946840810000081
其中，在“备注”信息中包含指示该数据包是否为询问包(standard query)，或者是与某一询问包对应的响应包(standard query response)，另外还包括域名，比如cn.xxx.com等信息。“*”表示隐藏字符，可以是0至9中的任意数值。
如果所述DNS数据包中有多个询问包，则可以选择其中的第一个数据包为所述第一询问包，或者选择其中的某一个为所述第一询问包。本实施例对具体的选择过程不做限制。
204：判断第一询问包是否符合DNS协议规范。
具体地，一种实现方式是，按照“RFC文档”中关于DNS的相关规定，对数据按照字段进行逐段解析，判断各个字段的取值是否均在规定的范围内，如果每个字段的取值都在规定的范围之内，则判断该第一询问包为符合DNS协议规范，具体的要求DNS规范当中列举的极为详细，这里不做赘述。
实际操作过程当中可以按照规范编写程序进行判断，或者也可以调用pcap读取解析软件应用程序编程接口(Application Programming Interface，API)进行判断，参见图7为一种结合开源pcap来读取解析软件得到的解析结果，该解析结果是解析软件对DNS询问包解析后输出的。
比如，以解析第一询问包为例，图7中的“0030”行和“0040”行是stander query数据包中较为关键的部分，每个圆圈中的指示字段为Caplen值(或称Caplen长度指示字段)，单位为字节，用于指示位于其后的数据长度。比如“02”指示后面段(位于Caplen值的PacketData)的数据长度为两个字节，“04”指示后面段的数据长度为4个字节，“03”指示后面段的数据长度为3个字节，“00”指示后面段的数据长度为0的字节。在步骤204中判断是否符合DNS协议规范，可具体地理解为：判断长度指示字段与后面段的实际数据长度是否一致。如果存在一个或一个以上长度指示字段与位于该字段后的数据(方框)的实际长度不一致，则判断该第一询问包不符合DNS协议规范。
205：如果是，则从该第一询问包中获得源端SRC的IP地址。
如果是，即判断第一询问包中解析的所有长度指示字段与后面段的实际数据长度都一致，则根据上述表2所示的信息获得源端IP地址，该源端设备的IP地址可表示为IP_SRC。具体地，一种可能的实施方式是，检测装置先根据解析的表2中的信息确定当前被检测的询问包的目的端IP地址，即DST的IP地址，然后根据该目的端IP地址确定所述源端的IP地址，即IP_SRC。
206：接上述步骤205，根据第一询问包的解析内容确定与所述第一询问包对应的第一响应包。与前述实施例的步骤102相同。
具体地，在上述Data 3中查找与第一询问包的源端IP地址和目的端IP地址分别对应的DNS数据包，比如在第一询问包中的源端IP地址“192.168.*.**”是另一个DNS数据包的目的端地址，而第一询问包中的目的端地址“192.168.*.*”是该另一个数据包的源端地址，且该另一个数据包在“备注”信息中是standard query response包，则确定该另一个DNS数据包与第一询问包对应的第一响应包。
本实施例中，每一个询问包对应一个响应包。
207：解析第一响应包，从该第一响应包中得到目的端的IP地址集合，所述目的端的IP地址集合中包括至少一个目的IP地址。与前述实施例的步骤103相同。
一种实现方式是，按照“RFC文档”中DNS协议规范，对第一响应包进行编程解析，或者利用pcap读取解析API解析得到解析结果。例如，该解析结果中包括DNS服务器在第一响应数据包中解析出的两个目的地址IP_DST，并标记这两个目的IP地址分别为：IP_DST1为202.**.**.**0，IP_DST2为202.**.**.**1。进而得到所述目的端IP地址集合中包括IP_DST1和IP_DST2。
208：判断源端IP地址和至少一个目的IP地址之间是否均存在数据包。
即判断源端IP地址与每个目的IP地址之间是否都有传输的数据包存在。所述数据包可以是上述的第一数据包集合，即“Data 1”；或者，也可以是上述的第二数据包集合，即“Data 2”。
本实施例中，以检测上述Data 2的流量传输为例，检测装置按照源端地址IP_SRC过滤Data 2的流量，分别搜索IP_SRC与IP_DST_i，(i≥1且为正整数)的通信数据；这种基于IP_SRC与DNS响应数据包中给出的IP_DST_i，在IP流量中进行成对过滤的技术，又称为关联数据搜索技术，通过该关联数据搜索技术可获知每条通信链路上是否有传输的数据包。
209：如果是，则确定源端到目的端之间不存在DNS隧道木马。
即均存在数据包，则确定从源端client 1到目的端DST 1之间没有DNS隧道木马。比如，IP_SRC与IP_DST1之间为第一通信链路，IP_SRC与IP_DST2之间为第二通信链路，且第一通信链路和第二通信链路中只要有一条传输链路上有数据包，则确定源端到目的端之间不存在DNS隧道木马。
210：如果否，则确定源端到目的端之间存在DNS隧道木马。
即如果所有所述通信链路中都没有检测到Data 2数据包，则确定源端client 1到目的端DST 1之间存在DNS隧道木马。比如，上述第一通信链路和第二通信链路上都没有检测到Data 2数据包，即IP_SRC与IP_DST1和IP_DST2中两条通信链路上都没数据包传输，则确定源端到目的端之间存在DNS隧道木马。
因为从DNS协议的基本功能出发，DNS的本意是客户端向域名服务器，询问提供某种网络业务的服务器IP地址，这个网络业务可以是HTTP、HTTPs、以及即时通信等等。也就是说，在正常的、不存在隧道木马的通信过程当中，如果请求域名对应的IP地址也被DNS服务器解析出来IP_DST，DNS数据通信后面必然存在client端IP地址IP_SRC，与IP_DST之间的传输数据包。
本实施例中，如果检测装置采集IP数据，仅仅解析其中的DNS协议数据，且DNS响应包(或响应报文)当中已经给出IP_DST，在DNS数据后的采集到的其它协议数据中，必然存在IP_SRC与IP_DST之间通信的数据流量；反之，DNS响应包给出IP_DST地址，但没有采集到存在IP_SRC与IP_DST之间通信的数据包，则可以确定源端和目的端之间存在DNS隧道木马。
本实施例提供的方法能够检测出完全符合DNS协议规范的数据流量中，是否隐藏有DNS隧道木马，解决了基于一般规则的入侵检测***无法发现高隐蔽性DNS隧道木马的问题。
另外，本方法又可以避免采用基于机器学习的检测方法，需要对大量样本进行学习，同时又不可避免的存在漏报、误报的问题，并且检测过程中也无需结合DNS协议本身的功能，因此不会影响检测的效果。
此外，在上述步骤204的判断中，还包括：如果否，即当前检测的第一询问包不符合DNS协议规范时，即存在一个或一个以上长度指示字段与位于该字段后的数据的实际长度不一致，比如Caplen长度指示值为“04”，但其后的数据实际长度不是4个字节，则执行以下方法步骤。具体地，如图8所示，方法包括：
211：获取第一询问包对应的源端地址IP_SRC请求的域名。
一种可能的实现方式是，在上述步骤203中，按照DNS协议中stander query的规范解析数据包，所述stander query包是IP_SRC向DNS server发出的，即图6中编号第13219的数据包。该数据包中备注信息中包含所述IP_SRC请求的域名，本实施例中，所述IP_SRC请求的域名为“cn.xxxx.com”。
212：判断所述请求的域名中是否存在不可见字符。
所述IP_SRC请求的域名通过ASCII码表示，所述ASCII码(American StandardCode for Information Interchange，美国信息交换标准代码)是基于拉丁字母的一套电脑编码***，主要用于显示现代英语和其他西欧语言。它是最通用的信息交换标准，并等同于国际标准ISO/IEC 646。ASCII第一次以规范标准的类型发表是在1967年，最后一次更新则是在1986年，到目前为止共定义了128个字符。
所谓不可见字符，即位于ASCII码取值范围(128个字符)之外的字符。
213：如果是，即存在不可见字符，则确定源端到目的端之间存在DNS隧道木马。
214：如果不存在所述不可见字符，即所述IP_SRC请求的域名中的字符全都是ASCII码中的字符，则从第一询问包中确定与其对应的第一响应包。具体过程可参考前述步骤205，此处不再赘述。
215：解析所述第一响应包，判断解析第一响应包后得到的第一数据中“数据类型和长度”是否符合DNS协议规范。
具体地，按照DNS协议中响应数据的规范解析所述第一数据，其中响应数据是DNSserver向源端地址IP_SRC发送的数据，按照DNS协议规范要求，包含如下情形：当目的端IP地址IP_DST为IPv4时，standerd query response数据包中的IP地址长度应为4；当目的端IP地址IP_DST为IPv6时，standerd query response数据包中的IP地址长度应为16。所述“数据类型和长度”检测方法具体包括：
215-1：判断解析的数据类型是IPv4还是IPv6。
一种实现方法是，在第一询问包(standerd query response)中的负载部分，获得IP_DST数据长度指示字段，目前为4或6，该指示字段占1个字节，如果该字节取值为0x04，则IP_DST为IPv4；如果该字节取值为0x06，则IP_DST为IPv6。
215-2：判断IPv4或者IPv6中指示的数据长度(Data length)是否为预设值，对于所述IPv4其对应的IP地址长度为第一预设值，所述第一预设值为4；对于IPv6其对应的IP地址长度为第二预设值，所述第二预设值为16。
216：如果是，即IP_DST长度与结合上一步216-1中解析出的长度一致，则检测不存在DNS隧道木马。
217：如果否，即解析的IP_DST长度与结合上一步216-1的解析出的长度指示不一致，比如IP地址的数据类型为IPv4时，响应数据包中的IP地址长度不是4；或者IP地址的数据类型为IPv6时，响应数据包中的IP地址长度不是16，则判断结果为存在DNS隧道木马。
图9给出图6中编号13385数据包解析的正常DNS协议standard query response解析结果，该解析目的端IP地址IP_DST的数据类型为IPv4，且地址长度满足第一预设值4，则符合DNS协议规范，进而确定不存在DNS隧道木马。
图10给出了图6中编号为13385数据包解析的发生异常的解析结果，该解析目的端IP地址IP_DST的数据类型为IPv4，但是指示字段“04”后面实际地址数据长度为3，而不是第一预设值4，即不符合DNS协议规范，则确定存在DNS隧道木马。
本方法实现了对于不符合DNS协议规范的数据流量中DNS隧道木马检测，能够在网络异常或者DNS服务器出错的情况下，准确地发现隐藏的隧道木马，并且不存在误报、漏报的情况。在网络通信正常的前提下，只要发现不符DNS合规范要求的异常数据包或报文，就可以迅速地检测出DNS隧道中是否存在DNS隧道木马。
下面介绍与上述方法实施例对应的装置实施例。
图11为本申请实施例提供的一种木马检测装置的结构示意图。所述装置可以是一种网络设备，或位于所述网络设备中的一个部件，例如芯片电路。并且该装置可以实现前述实施例中的DNS木马检测方法。
具体地，如图11所示，该装置可以包括：采集单元1101、解析单元1102和确定单元1103。其中，可选的，所述解析单元1102又可称为DNS协议解析单元，所述确定单元1103又可称为木马判别单元。此外，所述装置还可以包括存储单元等其他的单元或模块，本实施例对此不予限制。
其中，采集单元1101用于接收来自源端的第一询问包，所述第一询问包中包括源端的IP地址。解析单元1102用于当所述第一询问包符合DNS协议规范的情况下，获取与所述第一询问包对应的第一响应包，以及解析所述第一响应包得到至少一个目的IP地址。确定单元1103用于在所述源端IP地址和所述至少一个目的IP地址之间均不存在数据包的情况下，确定所述源端到所述目的端之间存在DNS隧道木马。
其中，所述第一响应包为DNS服务器发送，且所述至少一个目的IP地址归属于目的端。
可选的，在一种具体的实施方式中，确定单元1103，还用于所述源端IP地址和每个所述至少一个目的IP地址之间均存在数据包的情况下，确定所述源端到所述目的端之间不存在DNS隧道木马。
其中，所述数据包为第一检测周期内的所有数据包，或者，为从检测到的第一个响应包之后开始到所述第一检测周期结束时采集的所有数据包。所述数据包由采集单元1101采集后获得。
另外，可选的，在另一种具体的实施方式中，采集单元1101还用于在获取与所述第一询问包对应的第一响应包之前，获取在第一检测周期内采集的第一数据包集合，所述第一数据包集合中至少包括DNS协议类型的数据包。解析单元1102还用于通过目标端口从所述第一数据包集合中过滤出所有DNS数据包，以及从所有DNS数据包中选择所述第一询问包，所述DNS数据包包括询问包和响应包。
其中，所述目标端口为UDP的53号端口。
可选的，在又一种具体的实施方式中，解析单元1102具体用于轮询所有DNS数据包中的每个数据包，判断当前检测的数据包中携带的长度指示字段与位于所述长度指示字段之后的实际数据长度是否一致；如果一致，则确定所述当前检测的数据包符合所述DNS协议规范；并统计所有符合所述DNS协议规范的数据包。
在一种具体的实现方式中，解析单元1102具体用于当所述第一询问包中携带的长度指示字段与位于所述长度指示字段之后的实际数据长度不一致，确定所述第一询问包不符合所述DNS协议规范。
另外，解析单元1102还用于检测第一询问包中携带的长度指示字段与位于所述长度指示字段之后的实际数据长度不一致时，确定所述第一询问包不符合所述DNS协议规范。
可选的，在又一种具体的实施方式中，解析单元1102还用于在确定所述第一询问包不符合所述DNS协议规范的情况下，获取所述源端IP地址请求的域名，所述域名通过字符串表示。确定单元1103还用于判断通过所述字符串表示的域名中是否存在ASCII码之外的字符，如果存在，则确定所述源端到所述目的端之间存在DNS隧道木马。
另外，确定单元1103还用于在不存在所述ASCII码之外的字符时，解析单元1102获取所述第一询问包对应的第一响应包；解析所述第一响应包得到第一数据，所述第一数据中包含数据类型和长度，确定单元1103还用于判断解析在所述第一数据中的数据类型和长度是否均符合DNS协议规范，如果均符合，则确定不存在DNS隧道木马。
以及，确定单元1103还用于当所述第一数据中的数据类型和长度至少一个不符合所述DNS协议规范时，确定存在DNS隧道木马。
图12示出了一种检测设备的结构示意图，该检测设备可以是一种网络设备。所述检测设备包括：处理器110、存储器120、和至少一个通信接口130。其中，处理器110、存储器120和至少一个通信接口130可通过通信总线耦合。
其中，处理器110为检测设备的控制中心，可用于设备间的通信，例如包括与至少一个客户端，以及服务器DST等其他设备之间的信息传输。
处理器110可以由集成电路(Integrated Circuit，IC)组成，例如可以由单颗封装的IC所组成，也可以由连接多颗相同功能或不同功能的封装IC而组成。举例来说，处理器110可以包括中央处理器(Central Processing Unit，CPU)或数字信号处理器(DigitalSignal Processor，DSP)等。
此外，处理器110还可以包括硬件芯片，所述该硬件芯片可以是专用集成电路(application specific integrated circuit，ASIC)，可编程逻辑器件(programmablelogic device，PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(complexprogrammable logic device，CPLD)，现场可编程逻辑门阵列(field-programmable gatearray，FPGA)，通用阵列逻辑(generic array logic，GAL)或其任意组合。可选的，所述硬件芯片为一种芯片***或芯片电路。
存储器120用于存储和交换各类数据或软件，包括存储第一数据包集合、第二数据包集合、第三数据包集合、询问包和响应包等。此外存储器120中可以存储有计算机程序和代码。
具体地，存储器120可以包括易失性存储器(volatile memory)，例如随机存取内存(RandomAccess Memory，RAM)；还可以包括非易失性存储器(non-volatile memory)，例如快闪存储器(flash memory)，硬盘(Hard Sisk Drive，HDD)或固态硬盘(Solid-StateDrive，SSD)，存储器120还可以包括上述种类的存储器的组合。
通信接口130，使用任何收发器一类的装置，用于与其它设备或通信网络通信，如以太网，无线接入网(radio access network，RAN)，无线局域网(Wireless Local AreaNetwork，WLAN)、虚拟可扩展局域网(Virtual Extensible LocalAreaNetwork，VXLAN)等。
应理解，上述检测设备中还可以包括其他更多或更少的部件，本申请实施例示意的结构并不构成对检测设备的具体限定。并且图12所示的部件可以以硬件，软件、固件或者其任意组合的方式来实现。
当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。例如，在前述图11所示的检测装置中的采集单元1101可以通过通信接口130来实现，所述解析单元1102和确定单元1103的功能可以由处理器110来实现，所述存储单元的功能可以由存储器120实现。
具体地，所述检测设备利用至少一个通信接口130接收来自源端的第一询问包，所述第一询问包中包括源端的IP地址，处理器110确定该第一询问包符合DNS协议规范时，获得与第一询问包所对应的第一响应包，并解析该第一响应包得到至少一个目的IP地址；以及，检测当所述源端IP地址和所述至少一个目的IP地址之间均不存在数据包时，确定所述源端到目的端之间存在DNS隧道木马。具体地，处理器110通过调用存储器120中的程序代码，执行上述实施例图4、图5或图8所示的方法。
此外，该检测设备中还包括移动通信模块、无线通信模块等。所述移动通信模块包括：2G/3G/4G/5G等无线通信功能的模块。此外，还可以包括滤波器、开关、功率放大器、低噪声放大器(low noise amplifier，LNA)等。所述无线通信模块可以提供应用在检测设备上的包括WLAN、蓝牙(bluetooth)，全球导航卫星***(global navigation satellitesystem，GNSS)，调频(frequency modulation，FM)等无线通信的解决方案。
此外，本申请实施例还提供了一种网络***，该网络***结构可以是如前述图1或图2所示网络架构，包括至少一个客户端、至少一个服务器、DNS服务器，以及网关等通信设备。其中，上述每个设备的结构可以是如图12所示的检测设备，用于实现前述实施例中的检测方法。
本实施例能够检测出完全符合DNS协议规范的数据包中，是否隐藏有DNS隧道木马，解决了基于一般规则的入侵检测***无法发现高隐蔽性DNS隧道木马的问题。另外，对于不符合DNS协议规范的数据包中DNS隧道木马检测，能够在网络异常或者DNS服务器出错的情况下，准确地发现隐藏的隧道木马，并且不存在误报、漏报的情况。在网络通信正常的前提下，只要发现不符DNS合规范要求的异常数据包或报文，就可以迅速地检测出DNS隧道中是否存在DNS隧道木马。
本申请实施例还提供一种计算机程序产品，所述计算机程序产品包括一个或多个计算机程序指令。在计算机加载和执行所述计算机程序指令时，全部或部分地产生按照上述各个实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络或者其他可编程装置。
所述计算机程序指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个通信设备、计算机、服务器或数据中心通过有线或无线方式向另一个通信设备进行传输。
其中，所述计算机程序产品和所述计算机程序指令可以位于前述检测设备的存储器中，从而实现本申请实施例所述的木马检测方法。
此外，在本申请的描述中，除非另有说明，“多个”是指两个或多于两个。另外，为了便于清楚描述本申请实施例的技术方案，在本申请的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。
以上所述的本申请实施方式并不构成对本申请保护范围的限定。

Claims (14)

1.一种木马检测方法，其特征在于，所述方法用于基于域名***DNS协议的隐蔽数据传输，所述方法包括：
获取在第一检测周期内采集的第一数据包集合，所述第一数据包集合中至少包括DNS协议类型的数据包，所述数据包为第一检测周期内的所有数据包，或者，为从检测到的第一个响应包之后开始到所述第一检测周期结束时采集的所有数据包；
通过目标端口从所述第一数据包集合中过滤出所有DNS数据包，所述DNS数据包包括询问包和响应包；
接收来自源端的第一询问包，所述第一询问包从所述DNS数据包中选择，所述第一询问包中包括源端的IP地址；
当所述第一询问包符合DNS协议规范，获取与所述第一询问包对应的第一响应包，所述第一响应包为DNS服务器发送，其中，所述第一询问包符合DNS协议规范是指：所述第一询问包中携带的长度指示字段与位于所述长度指示字段之后的实际数据长度一致；
解析所述第一响应包得到至少一个目的IP地址；
如果所述源端IP地址和所述至少一个目的IP地址之间均不存在数据包，则确定所述源端到所述目的端之间存在DNS隧道木马。
2.根据权利要求1所述的方法，其特征在于，还包括：
如果所述源端IP地址和每个所述至少一个目的IP地址之间均存在数据包，则确定所述源端到所述目的端之间不存在DNS隧道木马。
3.根据权利要求1所述的方法，其特征在于，还包括：
如果所述第一询问包中携带的长度指示字段与位于所述长度指示字段之后的实际数据长度不一致，则所述第一询问包不符合所述DNS协议规范。
4.根据权利要求3所述的方法，其特征在于，当所述第一询问包不符合所述DNS协议规范，还包括：
获取所述源端IP地址请求的域名，所述域名通过预设字符串表示；
判断通过所述预设字符串表示的域名中是否存在ASCII码之外的字符；
如果存在，则确定所述源端到所述目的端之间存在DNS隧道木马。
5.根据权利要求4所述的方法，其特征在于，还包括：
如果不存在所述ASCII码之外的字符，则获取与所述第一询问包对应的第一响应包；
解析所述第一响应包得到第一数据，所述第一数据中包含数据类型和长度；
如果所述第一数据中的数据类型和长度均符合DNS协议规范，则确定不存在DNS隧道木马。
6.根据权利要求5所述的方法，其特征在于，还包括：
如果所述第一数据中的数据类型和长度的至少一个不符合所述DNS协议规范，则确定存在DNS隧道木马。
7.一种木马检测装置，其特征在于，所述装置用于基于域名***DNS协议的隐蔽数据传输，所述装置包括：
采集单元，用于获取在第一检测周期内采集的第一数据包集合，所述第一数据包集合中至少包括DNS协议类型的数据包，所述数据包为第一检测周期内的所有数据包，或者，为从检测到的第一个响应包之后开始到所述第一检测周期结束时采集的所有数据包；
解析单元，用于通过目标端口从所述第一数据包集合中过滤出所有DNS数据包，以及从所述所有DNS数据包中选择所述第一询问包，所述DNS数据包包括询问包和响应包；
所述采集单元，还用于接收来自源端的所述第一询问包，所述第一询问包中包括源端的IP地址；
解析单元，用于当所述第一询问包符合DNS协议规范，获取与所述第一询问包对应的第一响应包，以及解析所述第一响应包得到至少一个目的IP地址，所述第一响应包为DNS服务器发送；
确定单元，用于在所述源端IP地址和所述至少一个目的IP地址之间均不存在数据包的情况下，确定所述源端到目的端之间存在DNS隧道木马；
其中，所述第一询问包符合DNS协议规范是指：所述第一询问包中携带的长度指示字段与位于所述长度指示字段之后的实际数据长度一致。
8.根据权利要求7所述的装置，其特征在于，
所述确定单元，还用于在所述源端IP地址和每个所述至少一个目的IP地址之间均存在数据包的情况下，确定所述源端到所述目的端之间不存在DNS隧道木马。
9.根据权利要求7所述的装置，其特征在于，
所述解析单元，还用于当所述第一询问包中携带的长度指示字段与位于所述长度指示字段之后的实际数据长度不一致时，确定所述第一询问包不符合所述DNS协议规范。
10.根据权利要求9所述的装置，其特征在于，
所述解析单元，还用于获取所述源端IP地址请求的域名，所述域名通过预设字符串表示；
所述确定单元，还用于判断通过所述预设字符串表示的域名中是否存在ASCII码之外的字符，如果存在，则确定所述源端到所述目的端之间存在DNS隧道木马。
11.根据权利要求10所述的装置，其特征在于，
所述解析单元，还用于不存在所述ASCII码之外的字符的情况下，获取与所述第一询问包对应的第一响应包，解析所述第一响应包得到第一数据，所述第一数据中包含数据类型和长度；
所述确定单元，还用于在所述第一数据中的数据类型和长度均符合DNS协议规范时，确定不存在DNS隧道木马。
12.根据权利要求11所述的装置，其特征在于，
所述确定单元，还用于当所述第一数据中的数据类型和长度的至少一个不符合所述DNS协议规范时，确定存在DNS隧道木马。
13.一种检测设备，包括处理器和存储器，处理器与存储器耦合，其特征在于，
所述存储器，用于存储计算机程序指令；
所述处理器，用于执行所述存储器中存储的所述指令，以使得所述检测设备执行如权利要求1至6中任一项所述的方法。
14.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序指令，
当所述计算机程序指令被运行时，实现如权利要求1至6中任一项所述的方法。
CN202080004649.4A 2020-11-20 2020-11-20 一种木马检测方法、装置和设备 Active CN112640392B (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2020/130593 WO2022104738A1 (zh) 2020-11-20 2020-11-20 一种木马检测方法、装置和设备

Publications (2)

Publication Number Publication Date
CN112640392A CN112640392A (zh) 2021-04-09
CN112640392B true CN112640392B (zh) 2022-05-13

Family

ID=75291188

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202080004649.4A Active CN112640392B (zh) 2020-11-20 2020-11-20 一种木马检测方法、装置和设备

Country Status (2)

Country Link
CN (1) CN112640392B (zh)
WO (1) WO2022104738A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113992442B (zh) * 2021-12-28 2022-03-18 北京微步在线科技有限公司 一种木马连通成功检测方法及装置

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8266295B2 (en) * 2005-02-24 2012-09-11 Emc Corporation System and method for detecting and mitigating DNS spoofing trojans
EP2222048A1 (en) * 2009-02-24 2010-08-25 BRITISH TELECOMMUNICATIONS public limited company Detecting malicious behaviour on a computer network
CN101567884B (zh) * 2009-05-26 2011-12-14 西北工业大学 网络窃密木马检测方法
CN102594825B (zh) * 2012-02-22 2016-08-17 北京百度网讯科技有限公司 一种内网木马的检测方法和装置
US9411955B2 (en) * 2012-08-09 2016-08-09 Qualcomm Incorporated Server-side malware detection and classification
US20140157405A1 (en) * 2012-12-04 2014-06-05 Bill Joll Cyber Behavior Analysis and Detection Method, System and Architecture
CN103326894B (zh) * 2013-05-29 2016-12-28 深信服网络科技（深圳）有限公司 Dns隧道检测的方法和装置
US10412107B2 (en) * 2017-03-22 2019-09-10 Microsoft Technology Licensing, Llc Detecting domain name system (DNS) tunneling based on DNS logs and network data
CN107733851B (zh) * 2017-08-23 2020-05-01 刘胜利 基于通信行为分析的dns隧道木马检测方法
CN108390864B (zh) * 2018-02-01 2020-12-11 杭州安恒信息技术股份有限公司 一种基于攻击链行为分析的木马检测方法及***
CN108769034B (zh) * 2018-06-01 2021-02-26 杭州安恒信息技术股份有限公司 一种实时在线监测远控木马控制端ip地址的方法及装置
CN108848201A (zh) * 2018-06-14 2018-11-20 深信服科技股份有限公司 检测利用dns隧道传输隐秘数据的方法、***及装置
CN110071829B (zh) * 2019-04-12 2022-03-04 腾讯科技（深圳）有限公司 Dns隧道检测方法、装置及计算机可读存储介质
CN111865876B (zh) * 2019-04-29 2021-10-15 华为技术有限公司 网络的访问控制方法和设备
CN110505246B (zh) * 2019-09-25 2021-10-08 腾讯科技（深圳）有限公司 客户端网络通讯检测方法、装置及存储介质
CN111277570A (zh) * 2020-01-10 2020-06-12 中电长城网际***应用有限公司 数据的安全监测方法和装置、电子设备、可读介质
CN111600863B (zh) * 2020-05-08 2022-09-13 杭州安恒信息技术股份有限公司 网络入侵检测方法、装置、***和存储介质
CN111600865B (zh) * 2020-05-11 2022-06-07 杭州安恒信息技术股份有限公司 一种异常通信检测方法、装置及电子设备和存储介质
CN111953673B (zh) * 2020-08-10 2022-07-05 深圳市联软科技股份有限公司 一种dns隐蔽隧道检测方法及***

Also Published As

Publication number Publication date
CN112640392A (zh) 2021-04-09
WO2022104738A1 (zh) 2022-05-27

Similar Documents

Publication Publication Date Title
US9049220B2 (en) Systems and methods for detecting and preventing flooding attacks in a network environment
AU2002242043B2 (en) Network port profiling
EP3297248B1 (en) System and method for generating rules for attack detection feedback system
WO2021139643A1 (zh) 加密攻击网络流量检测方法，其装置及电子设备
CN111526121B (zh) 入侵防御方法、装置、电子设备及计算机可读介质
US11777971B2 (en) Bind shell attack detection
JP2009510815A (ja) サーチ前のパケットのリアセンブル方法及びシステム
US7584506B2 (en) Method and apparatus for controlling packet transmission and generating packet billing data on wired and wireless network
US10116538B2 (en) Attributing network address translation device processed traffic to individual hosts
Kaushik et al. Network forensic system for port scanning attack
US20230412591A1 (en) Traffic processing method and protection system
US20120047572A1 (en) Decapsulation of data packet tunnels to process encapsulated ipv4 or ipv6 packets
CN115174676A (zh) 汇聚分流方法及其相关设备
CN112822204A (zh) 一种nat的检测方法、装置、设备及介质
CN112640392B (zh) 一种木马检测方法、装置和设备
CN107864110B (zh) 僵尸网络主控端检测方法和装置
CN113765849B (zh) 一种异常网络流量检测方法和装置
CN113347184A (zh) 网络流量安全检测引擎的测试方法、装置、设备及介质
CN102724068B (zh) 一种在IPv6混合网络中进行审计日志资产识别的方法
US7266088B1 (en) Method of monitoring and formatting computer network data
Haghighat et al. Payload attribution via character dependent multi-bloom filters
CN113904843B (zh) 一种终端异常dns行为的分析方法和装置
Nie et al. Intrusion detection using a graphical fingerprint model
CN114050917A (zh) 音频数据的处理方法、装置、终端、服务器及存储介质
US9049170B2 (en) Building filter through utilization of automated generation of regular expression

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant