CN103179100B - 一种防止域名系统隧道攻击的方法及设备 - Google Patents

Abstract

一种防止域名系统隧道攻击的方法及设备，主要内容包括：判断数据包是否为网络互联协议(IP)报文以及是否为域名系统(DNS)请求报文，当从终端发出的数据包是IP报文形式的DNS请求报文时，则进一步判断数据包中的DNS服务器IP地址是否是预先设定的多台合法DNS服务器的IP地址，若是，则可认为当前终端是正常发起DNS请求报文，并不是域名系统隧道(DNS Tunnel)攻击；否则，可认为终端本次发起数据包的过程为DNS Tunnel攻击，将该数据包丢弃，以减小DNS Tunnel攻击对网络造成的安全风险。

Description

一种防止域名系统隧道攻击的方法及设备

技术领域

本发明涉及网络安全技术领域，尤其涉及一种防止域名系统隧道(DomainName System Tunnel，DNS Tunnel)攻击的方法及设备。

背景技术

域名系统(Domain Name System，DNS)是一种用于传输控制协议/网络互联协议(Transmission Control Protocol/Internet Protocol，TCP/IP)应用程序的分布式数据库，提供域名与网络互联协议(Internet Protocol，IP)地址之间的转换。通过域名系统，用户可以使用便于记忆的域名，由网络中DNS服务器将域名解析为正确的IP地址。

DNS Tunnel攻击又叫绕过无线局域网中的无线控制器(Access Control，AC)设备的验证技术，是利用DNS查询原理来进行的一项攻击方法。下面结合图1及常规的无线局域网上网验证流程来说明DNS Tunnel的实现过程。

在正常的无线局域网环境中，终端连接上无线接入点(Access Point，AP)后，通过AC向合法的DNS服务器的53端口发送DNS请求报文，合法的DNS服务器接收到请求后，在本地查询该域名对应的IP地址，如果在本地没有查询出对应的IP地址，则从互联网中继续查询，并将查询出的IP地址通过AC反馈给终端。终端接到反馈的IP地址后，向AC发出上网请求，AC推送一个要求用户输入验证信息的门户(Portal)页面给终端，用户输入正确的验证信息后，即可接入互联网进行计费上网。

但是，由于AC不能对终端向DNS服务器发起的域名解析请求中的目的地址进行限制，因此，如果终端在本次存储域名和IP地址的对应关系，发起的域名解析请求中的目的地址不是AC分配的DNS服务器，而是其他非法DNS服务器的用户数据报协议(User Datagram Protocol，UDP)53端口的IP地址，则终端通过AC发起域名解析请求的过程，可实现该终端绕过AC认证的上网过程。由于终端的身份得不到合法认证，增加了终端对网络攻击的安全风险，同时也无法对终端的上网过程进行计费。

发明内容

本发明实施例提供一种防止域名系统隧道攻击的方法及设备，以提高防止DNS Tunnel攻击的能力，减少终端对网络进行DNS Tunnel攻击的安全风险。

一种防止域名系统隧道攻击的方法，所述方法包括：

判断终端发送的数据包中的内层报文是否为网络互联协议IP报文，若是，则进一步判断所述IP报文是否为域名系统DNS请求报文；

若所述IP报文是DNS请求报文，则在所述IP报文中的目的地址不是预先设定的DNS服务器的地址时，确定所述数据包为非法数据包。

一种防止域名系统隧道攻击的设备，所述设备包括：

IP报文判断模块，用于判断终端发送的数据包中的内层报文是否为IP报文；

DNS请求报文判断模块，用于在IP报文判断模块判断出所述数据包中的内层报文为IP报文时，判断所述IP报文是否为DNS请求报文；

地址判断模块，用于在DNS请求报文判断模块判断出所述IP报文为DNS请求报文时，判断所述IP报文中的目的地址是否为预先设定的DNS服务器的地址；

防护模块，用于在地址判断模块确定所述IP报文中的目的地址不是预先设定的DNS服务器的地址时，确定所述数据包为非法数据包，并丢弃所述数据包。

由于发起DNS Tunnel攻击的数据包是根据预先获知的非法DNS服务器的IP地址，伪装成DNS请求报文通过AC发送至相应的非法DNS服务器的，因此，本发明实施例的方案以数据包是否为IP报文以及是否为DNS请求报文为判断条件，当从终端发出的数据包是IP报文形式的DNS请求报文时，则进一步判断数据包中的DNS服务器IP地址是否是预先设定的多台合法DNS服务器的IP地址，若是，则可认为当前终端是正常发起DNS请求报文，并不是DNS Tunnel攻击；否则，可认为终端本次发起数据包的过程为DNS Tunnel攻击，并执行相应的防DNS Tunnel攻击操作，以减小DNS Tunnel攻击对网络造成的安全风险。

附图说明

图1为背景技术中DNS Tunnel攻击原理示意图；

图2为本发明实施例一中防止DNS Tunnel攻击的方法示意图；

图3为本发明实施例一中DNS报文格式示意图；

图4为本发明实施例一中DNS报文的第16bit～第31bit的标志字段被分割为8个子字段的示意图；

图5为本发明实施例二中防止DNS Tunnel攻击的设备的结构示意图；

图6为本发明实施例三中防止DNS Tunnel攻击的设备应用于无线局域网环境中实现防止DNS Tunnel攻击的原理示意图；

图7为本发明实施例三中防止DNS Tunnel攻击的设备应用在实际应用环境中的无线局域网系统架构中的示意图；

图8为本发明实施例三中防止DNS Tunnel攻击的设备的工作流程示意图。

具体实施方式

下面结合具体实施例详细描述本发明方案。

实施例一：

如图2所示，为本发明实施例一中防止域名系统隧道攻击的方法示意图，所述方法包括以下步骤：

步骤101：接收终端发送的数据包，并判断所述数据包是否为无线接入点控制与配置协议(Control And Provisioning of Wireless Access Points ProtocolSpecification，CAPWAP)报文，若是CAPWAP报文，则执行步骤102；若不是CAPWAP报文，则将数据包正常转发。

由于基于CAPWAP的报文可用于AP和AC之间的通信交互，实现对AC关联的所有AP的控制管理和数据转发，对于终端而言，其通过无线方式发送的报文应当封装在CAPWAP隧道中，因此，通过本步骤101的判定，可首先筛选出基于CAPWAP的数据包，若终端发送的数据包不是CAPWAP报文，则表示当前终端并没有利用非法DNS服务器IP地址来伪装DNS请求报文，因此，可直接转发该数据包；若终端发送的数据包是CAPWAP报文，则终端有可能进行的是DNS Tunnel攻击，但并不一定是DNS Tunnel攻击，因此，需要对数据包做进一步分析。

需要说明的是，本步骤101是实现本发明目的的优选方案，通过本步骤101的方案，可以筛选出不是CAPWAP报文的数据包而直接转发，以减少后续判断操作的数据量，即使不执行本步骤101的方案，假定所有的数据包都是CAPWAP报文，也可以通过后续的判断操作识别出本次终端发送数据包的操作是否是DNS Tunnel攻击。

步骤102：解析所述CAPWAP报文，判断解析后的所述CAPWAP报文是数据报文还是控制报文，若为数据报文，执行步骤103；若为控制报文，则将所述数据包正常转发。

所述CAPWAP报文可以是数据报文，也可以是控制报文，若CAPWAP报文是控制报文，则可用于承载AP与AC的信息交互数据，若CAPWAP报文是数据报文，则可用于承载终端用户的数据。

因此，则本步骤102的方案中，通过对所述CAPWAP报文的类型识别，在判定出在所述CAPWAP报文是控制报文时，表示终端当前并没有利用非法DNS服务器IP地址来伪装DNS请求报文，因此，可直接转发该数据包；在判断出解析后的所述CAPWAP报文是数据报文时，表示终端有可能是发起DNSTunnel攻击，但并不一定是DNS Tunnel攻击，需要进行后续判断操作来确定。

需要说明的是，本步骤102也是实现本发明目的的优选方案，通过本步骤102的方案，可以筛选出控制报文类型的CAPWAP报文而直接转发，以减少后续判断操作的数据量，即使不执行本步骤102的方案，假定所有的CAPWAP报文都是数据报文，也可以通过后续的判断操作识别出本次终端发送数据包的操作是否是DNS Tunnel攻击。

步骤103：判断终端发送的数据包中的内层报文是否为IP报文，若是，则执行步骤104；若否，则将数据包正常转发。

由于终端在进行DNS Tunnel攻击时是利用非法DNS服务器的IP地址来伪装为DNS请求报文，因此，当终端发送的数据包中的内层报文为IP报文时，表示该终端有可能发起了DNS Tunnel攻击，需要对该IP报文做进一步分析；当终端发送的数据包中的内层报文不为IP报文时，表示该终端并没有利用非法DNS服务器的IP地址来伪装，因此，可直接转发数据包。

步骤104：判断所述IP报文是否为DNS请求报文，若是，则执行步骤105；若否，则将数据包正常转发。

具体的，判断所述IP报文是否为DNS请求报文，包括以下三步：

第一步：根据所述IP报文中的协议号判断所述IP报文是否为UDP报文，若是则执行第二步；若否，则确定所述IP报文不为DNS请求报文，因此，将数据包正常转发。

具体的，可当所述IP报文中的协议字段的编码为0x11(转换为十进制为17)时，表明该IP报文为UDP报文。

第二步：判断所述IP报文中的目的端口是否为53端口，若是，则执行第三步；若否，则确定所述IP报文不为DNS请求报文，因此，将数据包正常转发。

由于DNS协议运行在UDP之上，使用的端口是53端口，该53端口为DNS服务器所开放，用于进行域名解析，故终端进行DNS Tunnel攻击或是发起正常的DNS请求报文时，都是使用此53端口，因此，本步骤中将IP报文中的目的端口是否为53端口作为判断条件，可用于识别终端当前发起的是否是正常的DNS请求报文或是伪装的DNS请求报文。

第三步：解析内层DNS协议报文头，根据DNS协议报文头格式，判断所述DNS协议报文头格式对应的报文类型是否为请求报文，若为请求报文，则确定所述IP报文为DNS请求报文，若否，则确定所述IP报文不为DNS请求报文，因此，将数据包正常转发。

DNS定义了一个用于请求和响应的报文，其报文格式如图3所示，其中，16～31这部分中的16bit的标志字段被分割为如图4所示的8个子字段，在上述第三步中，可通过解析图4中的“QR”子字段，如果该字段的值为“1”，代表为请求报文，则解析该请求报文中的IP报头；若为0，则代表该报文为响应报文，将其进行正常的转发。

本步骤104也不限于其他判断IP报文是否为DNS请求报文的方式。

步骤105：判断所述IP报文中的目的地址是否为预先设定的DNS服务器的地址，若不是，确定所述数据包为非法数据包，并将其丢弃；若是，则将数据包正常转发。

预先设定的DNS服务器的地址可以是运营商全网中可用的合法DNS服务器的地址，或部分区域中可用的合法DNS服务器的地址，若通过之前步骤101至步骤104的判断确定数据包可能为进行DNS Tunnel攻击而伪装的数据包时，则通过本步骤105的判断，在确定终端是针对合法的DNS服务器发起的DNS请求报文时，可认为终端并没有进行DNS Tunnel攻击；在确定终端没有针对指定合法的DNS服务器发起DNS请求报文时，可直接确定终端当前进行的是DNS Tunnel攻击，将其发送的非法数据包进行丢弃或通过记录日志并发送邮件的方式对发送非法数据包的终端进行告警处理。

实施例二

本发明实施例二提出一种防止域名系统隧道攻击的设备，其结构示意图如图5所示，包括：IP报文判断模块11、DNS请求报文判断模块12、地址判断模块13和防护模块14，其中：

IP报文判断模块11，用于判断终端发送的数据包中的内层报文是否为IP报文。

DNS请求报文判断模块12，用于在IP报文判断模块11判断出所述数据包中的内层报文为IP报文时，判断所述IP报文是否为DNS请求报文。

地址判断模块13，用于在DNS请求报文判断模块12判断出所述IP报文为DNS请求报文时，判断所述IP报文中的目的地址是否为预先设定的DNS服务器的地址。

防护模块14，用于在地址判断模块13确定所述IP报文中的目的地址不是预先设定的DNS服务器的地址时，确定所述数据包为非法数据包，并将其丢弃。

较优的，所述设备还包括：

CAPWAP报文判断模块15，用于判断所述数据包是否为CAPWAP报文。

所述IP报文判断模块11，具体用于在CAPWAP报文判断模块15判断出所述数据包为CAPWAP报文时，判断CAPWAP报文中的内层报文是否为IP报文。

较优的，所述设备还包括：

数据报文判断模块16，用于解析CAPWAP报文，并判断解析后的所述CAPWAP报文是否为数据报文。

所述IP报文判断模块11，具体用于在CAPWAP报文判断模块15判断出所述数据包为CAPWAP报文，且数据报文判断模块16判断出所述CAPWAP报文为数据报文时，判断CAPWAP报文中的内层报文是否为IP报文。

较优的，所述DNS请求报文判断模块12具体包括：

UDP判断单元21，用于根据所述IP报文中的协议号判断所述IP报文是否为UDP报文；

端口判断单元22，用于在UDP判断单元21判断出所述IP报文为UDP报文时，判断所述IP报文的目的端口是否为53端口。

请求报文判断单元23，用于在端口判断单元22判断出所述IP报文中的目的端口为53端口时，解析内层DNS协议报文头，根据DNS协议报文的头格式，判断所述DNS协议报文头格式对应的报文类型是否为请求报文。

DNS请求报文确定单元24，用于在请求报文判断单元23判断出报文类型为请求报文时，确定所述IP报文为DNS请求报文。

本发明实施例二中防止域名系统隧道攻击的设备可以是独立于AC的设备，该设备可具有一个数据包输入输出接口，一方面用于接收来自终端的数据包，并发送给设备中的其他模块进行DNS Tunnel攻击的防止操作，如丢弃确定的非法数据包；另一方面可将合法数据包发送给AC。所述防止域名系统隧道攻击的设备也可以是AC中的设备。

实施例三

如图6所示，为本发明实施例二中的防止DNS Tunnel攻击的设备应用于无线局域网环境中实现防止DNS Tunnel攻击的原理示意图，其中所述防止DNS Tunnel攻击的设备可以为AC中的设备中，也可以作为一个独立的设备设置于AP和AC之间，用于防止DNS Tunnel攻击，考虑到实际应用环境一方面需要在AP和AC之间需要设置交换机以便于支持Portal服务器向终端推送Portal页面以及远程用户拨号认证系统(Remote Authentication Dial In UserService，Radius)服务器对终端进行认证和计费，另一方面需在AC之后连接动态主机设置协议(Dynamic Host Configuration Protocol，DHCP)服务器，以便于为终端分配IP，本实施例三中以如图7所示的实际应用环境中的无线局域网系统为例，对实施例二中的防止DNS Tunnel攻击的设备的在该系统中的具体应用进行详细说明。

图7中所述的系统包括：终端71、终端所在的AP72、交换机73、portal服务器74、Radius服务器75、防止DNS Tunnel攻击的设备76、AC77和DHCP服务器78。其中：

终端71，用于发送数据包进行上网业务。

AP72，用于作为无线接入设备，将终端连接起来，接收终端发送的数据包，并将包含DNS请求报文的数据包及其他数据包转发给交换机73。

交换机73，用于将从AP接收到的数据包转发给防止DNS Tunnel攻击的设备76。

portal服务器74，用于在接收到AP提交的包含DNS请求报文的数据包后，给终端71反馈Web认证页面。

Radius服务器75，用于在用户提交认证信息后，对Portal服务器提交的认证信息进行认证。

防止DNS Tunnel攻击的设备76，用于在从交换机73接收到来自AP的数据包时，判断终端发送的数据包中的内层报文是否为网络互联协议IP报文，若是，则进一步判断所述IP报文是否为域名系统DNS请求报文，若所述IP报文是DNS请求报文，则在所述IP报文中的目的地址不是预先设定的DNS服务器的地址时，确定所述数据包为非法数据包，并将其进行丢弃处理。

AC77，用于将来自AP的数据包进行汇聚并接入互联网(Internet)，并将配置信息和无线用户认证等信息反馈给AP72。

DHCP服务器78，用于在接收到终端71或AP72发送的包含DNS请求报文的数据包后，将IP地址、AC地址列表等配置信息响应给AP。

下面以终端71向AC77发包含DNS请求报文的数据包进行上网业务为例，结合图7所述的系统，详细说明防止DNS Tunnel攻击的设备76的工作流程。

如图8所示的防止DNS Tunnel攻击的设备的工作流程示意图，包括以下步骤：

步骤201：终端通过DHCP服务器获取到IP地址，并通过无线链路连接到AP。

步骤202：AP通过DHCP服务器获取到AC的IP地址，通过交换机向AC发出访问Internet的请求信息。

步骤203：防止DNS Tunnel攻击的设备判断该承载请求信息的数据包中的内层报文是否为IP报文，若是，则执行步骤204；若否，则判定该数据包为合法数据包，直接转发该数据包至AC。

步骤204：防止DNS Tunnel攻击的设备判断所述IP报文是否为DNS请求报文，若是，则执行步骤205；若否，则判定该数据包为合法数据包。

步骤205：防止DNS Tunnel攻击的设备判断所述IP报文中的目的地址是否为预先设定的DNS服务器的地址，若为否，则判定所述数据包为非法数据包，丢弃所述非法数据包或通过记录日志并发送邮件的方式对发送非法数据包的终端进行告警处理。若为是，则判定该数据包为合法数据包，直接转发该数据包至AC。

在本步骤203、步骤204和步骤205中，也可按照实施例一的具体方案防止数据包是否为非法数据包。

步骤206：AC接收来自防止DNS Tunnel攻击的设备的合法数据包，并通过Portal服务器给合法数据包的发送终端反馈Web认证页面。

步骤207：用户输入认证信息，Portal服务器将认证信息提交给Radius服务器进行认证。

步骤208：Radius服务器对用户输入信息进行认证，若认证失败，则返回无线用户认证失败信息；若认证成功，无线用户即可接入Internet进行计费上网。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (5)

1.一种防止域名系统隧道攻击的方法，其特征在于，所述方法包括：

判断数据包是否为无线接入点控制与配置协议CAPWAP报文；

若是CAPWAP报文，则判断终端发送的数据包中的内层报文是否为网络互联协议IP报文，若是，则进一步判断所述IP报文是否为域名系统DNS请求报文；

若所述IP报文是DNS请求报文，则在所述IP报文中的目的地址不是预先设定的DNS服务器的地址时，确定所述数据包为非法数据包，并将其丢弃；

判断所述IP报文是否为DNS请求报文，具体包括：

根据所述IP报文中的协议号判断所述IP报文是否为用户数据报协议UDP报文；

在确定所述IP报文为UDP报文时，进一步判断所述IP报文中的目的端口是否为53端口；

在确定所述IP报文中的目的端口为53端口时，解析内层DNS协议报文头，根据DNS协议报文头格式，判断所述DNS协议报文头格式对应的报文类型是否为请求报文，若是，确定所述IP报文为DNS请求报文。

2.如权利要求1所述的方法，其特征在于，在确定所述数据包为CAPWAP报文之后，且判断终端发送的数据包中的内层报文是否为IP报文之前，所述方法还包括：

解析所述CAPWAP报文，判断解析后的所述CAPWAP报文是否为数据报文，若为数据报文，则执行判断终端发送的数据包中的内层报文是否为IP报文的操作。

3.一种防止域名系统隧道攻击的设备，其特征在于，所述设备包括：

无线接入点控制与配置协议CAPWAP报文判断模块，用于判断数据包是否为CAPWAP报文；

网络互联协议IP报文判断模块，用于在CAPWAP报文判断模块判断出所述数据包为CAPWAP报文时，判断终端发送的数据包中的内层报文是否为IP报文；

域名系统DNS请求报文判断模块，用于在IP报文判断模块判断出所述数据包中的内层报文为IP报文时，判断所述IP报文是否为DNS请求报文；

地址判断模块，用于在DNS请求报文判断模块判断出所述IP报文为DNS请求报文时，判断所述IP报文中的目的地址是否为预先设定的DNS服务器的地址；

防护模块，用于在地址判断模块确定所述IP报文中的目的地址不是预先设定的DNS服务器的地址时，确定所述数据包为非法数据包，并将其丢弃；

所述DNS请求报文判断模块包括：

用户数据报协议UDP判断单元，用于根据所述IP报文中的协议号判断所述IP报文是否为UDP报文；

端口判断单元，用于在UDP判断单元判断出所述IP报文为UDP报文时，判断所述IP报文的目的端口是否为53端口；

请求报文判断单元，用于在端口判断单元判断出所述IP报文中的目的端口为53端口时，解析内层DNS协议报文头，根据DNS协议报文的头格式，判断所述DNS协议报文头格式对应的报文类型是否为请求报文；

DNS请求报文确定单元，用于在请求报文判断单元判断出报文类型为请求报文时，确定所述IP报文为DNS请求报文。

4.如权利要求3所述的设备，其特征在于，所述设备还包括：

数据报文判断模块，用于解析CAPWAP报文，并判断解析后的所述CAPWAP报文是否为数据报文；

所述IP报文判断模块，具体用于在CAPWAP报文判断模块判断出所述数据包为CAPWAP报文，且数据报文判断模块判断出所述CAPWAP报文为数据报文时，判断CAPWAP报文中的内层报文是否为IP报文。

5.如权利要求3所述的设备，其特征在于，所述防止域名系统隧道攻击的设备是无线控制器AC中的设备。