CN103327025A - 网络访问控制方法及装置 - Google Patents

Abstract

本发明公开了网络访问控制方法及系统，所述方法包括：通过在内核层接收或发送数据的关键位置处添加钩子函数，建立与内核层之间的接口链表；利用所述钩子函数在所述内核层截获域名系统DNS请求包；解析所述DNS请求包的请求查询名字段，获取请求解析的域名信息；将所述域名信息与预置的过滤规则中的域名名单进行匹配，根据匹配结果确定对所述DNS请求包进行放行或者丢弃。通过本发明，在内核态就能实现DNS过滤。

Description

网络访问控制方法及装置

技术领域

本发明涉及网络安全技术领域，具体涉及网络访问控制方法及装置。 

背景技术

URL（Uniform/Universal Resource Locator，统一资源定位符）过滤是现在防火墙的一个重要的访问控制方法，同时还衍生出一系列技术，如URL重组和URL分类服务器连动等。URL过滤固然可以限制到文件级别的粒度，但在实际应用中进行如此细粒度控制的几乎没有，并不限制访问的目录名和文件名，基本还是限制在域名级别。这样带来的问题就是不用URL访问，而是用IP地址访问，例如，在访问前先使用ping、nslookup等工具先解析出IP地址，之后用IP访问，这样URL域名过滤就会失效；其二，即使域名限制成立，但等URL重组完之后，再识别，再强行断开连接，对系统，包括客户端、服务器和防火墙的资源都是很大浪费。另外，URL过滤还有一个比较大的缺陷，在HTTP/1.1中，域名部分是通过HTTP头的“Host:”字段来获取的，其他字段均不能保证能正确获取域名，而这个字段有的服务器并不检查，可以随便填个别的域名，服务器也可以正确返回；而在HTTP/1.0中，这个字段更加不是必须的，因此根本不能保证获取正确的域名。总之，采用URL过滤的方式进行访问控制的方法在过滤的有效性上还有待提高 

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的网络访问控制方法及装置，在内核态就可以实现DNS过滤。 

依据本发明的一个方面，提供了一种网络访问控制方法，包括： 

通过在内核层接收或发送数据的关键位置处添加钩子函数，建立与内核层之间的接口链表； 

利用所述钩子函数在所述内核层截获域名系统DNS请求包； 

解析所述DNS请求包的请求查询名字段，获取请求解析的域名信息； 

将所述域名信息与预置的过滤规则中的域名名单进行匹配，根据匹配结果确定对所述DNS请求包进行放行或者丢弃。 

可选地，所述利用所述钩子函数在所述内核层截获域名系统DNS请求包，包括： 

利用所述钩子函数对发送到所述内核层的数据包进行截获； 

分析所述截获到的数据包，获取DNS请求包。 

可选地，所述分析所述截获到的数据包，获取DNS请求包，包括： 

如果所述截获到的数据包不存在分片，且为线性，则剥离所述数据包的IP头； 

判断所述数据包对应的传输层协议； 

如果所述传输层协议为UDP，则判断所述数据包的目的端口是否为53端口； 

如果是，则确定当前获取到的数据包为DNS请求包。 

可选地，还包括： 

如果所述截获到的数据包存在分片，或者为非线性，则将所截获到的数据包进行放行。 

可选地，还包括： 

如果所述数据包对应的传输层协议不是UDP协议，则将所截获到的数据包进行放行。 

可选地，所述域名名单包括域名白名单，所述根据匹配结果确定对所述DNS请求包进行放行或者丢弃，包括： 

如果所述域名白名单中存在与所述域名信息相匹配的信息，则将所述DNS请求包放行，否则，将所述DNS请求包丢弃。 

可选地，所述域名名单中保存的域名信息为根据预置的哈希算法计算出的各个域名的哈希值，所述将所述域名信息与预置的过滤规则中的域名名单进行匹配包括： 

根据所述哈希算法计算所述域名信息的哈希值； 

将所述哈希值与所述域名名单中保存的各个域名的哈希值进行匹配。 

可选地，所述方法应用于企业版应用程序中，其中，所述企业版应用程序包括安装在企业用户管理控制中心计算设备上的企业版服务端，以及安装在企业用户终端设备上的企业版客户端，通过企业版服务端实现对各个企业版客户端所在用户终端设备的统一管理； 

所述通过在内核层接收或发送数据的关键位置处添加钩子函数，建立与内核层之间的接口链表包括： 

企业版客户端通过在内核层接收或发送数据的关键位置处添加钩子函数，建立与内核层之间的接口链表； 

所述利用所述钩子函数在所述内核层截获域名系统DNS请求包包括： 

企业版客户端利用所述钩子函数在所述内核层截获域名系统DNS请求包； 

所述解析所述DNS请求包的请求查询名字段，获取请求解析的域名信息包括： 

企业版客户端解析所述DNS请求包的请求查询名字段，获取请求解析的域名信息，并将所述域名信息上传至企业版服务端； 

所述将所述域名信息与预置的过滤规则中的域名名单进行匹配，根据匹配结果确定对所述DNS请求包进行放行或者丢弃包括： 

企业版服务端将所述域名信息与预置的过滤规则中的域名名单进行匹配，根据匹配结果确定对所述DNS请求包进行放行或者丢弃，并向企业版客户端返回相应的处理指令。 

根据本发明的另一方面，提供了一种网络访问控制系统，包括： 

接口链表建立单元，用于通过在内核层接收或发送数据的关键位置处添 加钩子函数，建立与内核层之间的接口链表； 

请求包截获单元，用于利用所述钩子函数在所述内核层截获域名系统DNS请求包； 

解析单元，用于解析所述DNS请求包的请求查询名字段，获取请求解析的域名信息； 

匹配单元，用于将所述域名信息与预置的过滤规则中的域名名单进行匹配，根据匹配结果确定对所述DNS请求包进行放行或者丢弃。 

可选地，所述请求包截获单元，包括： 

截获子单元，用于利用所述钩子函数对发送到所述内核层的数据包进行截获； 

分析子单元，用于分析所述截获到的数据包，获取DNS请求包。 

可选地，所述分析子单元，包括： 

IP头剥离子单元，用于如果所述截获到的数据包不存在分片，且为线性，则剥离所述数据包的IP头； 

协议判断子单元，用于判断所述数据包对应的传输层协议； 

端口判断子单元，用于如果所述传输层协议为UDP，则判断所述数据包的目的端口是否为53端口； 

确定子单元，用于如果是，则确定当前获取到的数据包为DNS请求包。 

可选地，还包括： 

第一放行单元，用于如果所述截获到的数据包存在分片，或者为非线性，则将所截获到的数据包进行放行。 

可选地，还包括： 

第二放行单元，用于如果所述数据包对应的传输层协议不是UDP协议，则将所截获到的数据包进行放行。 

可选地所述域名名单包括域名白名单，所述匹配单元，包括： 

白名单匹配子单元，用于如果所述域名白名单中存在与所述域名信息相匹配的信息，则将所述DNS请求包放行，否则，将所述DNS请求包丢弃。 

可选地，所述域名名单中保存的域名信息为根据预置的哈希算法计算出的各个域名的哈希值，所述匹配单元，包括： 

哈希值计算子单元，用于根据所述哈希算法计算所述域名信息的哈希值； 

哈希值匹配子单元，用于将所述哈希值与所述域名名单中保存的各个域名的哈希值进行匹配。 

可选地，所述系统应用于企业版应用程序中，其中，所述企业版应用程序包括安装在企业用户管理控制中心计算设备上的企业版服务端，以及安装在企业用户终端设备上的企业版客户端，通过企业版服务端实现对各个企业版客户端所在用户终端设备的统一管理； 

所述接口链表建立单元、请求包截获单元、解析单元位于所述企业版客户端； 

所述企业版客户端还包括： 

上传单元，用于在所述解析单元获取到请求解析的域名信息之后，将所述域名信息上传至企业版服务端； 

所述匹配单元位于企业版服务端； 

所述企业版服务端还包括： 

返回单元，用于所述匹配单元确定出对所述DNS请求包进行放行或者丢弃之后，向企业版客户端返回相应的处理指令。 

根据本发明实施例提供的根据本发明提供的网络访问控制方法及装置，能够实现基于DNS过滤的访问控制，即在域名解析时就进行限制，在DNS请求包中就把域名提取出来进行判断。由于DNS一般是UDP包，一个包中就包含了所有信息，包括请求解析的域名信息，不需要通过重组来分离域名信息；其次，由于UDP包比较简单，UDP包头部包含的信息较少，这样UDP包在发送、接收、分析等环节消耗的各种资源消耗远小于TCP，对于服务器来说基本就没有消耗，防火墙跟踪UDP也比跟踪TCP要容易得多；再次，DNS过滤比URL过滤限制的范围更大，通常URL只能限制HTTP服务，而DNS过滤则把该域名对应的所有服务都可以限制住。另外，DNS过滤没有IP访问的漏洞，因为客户机在未访问DNS服务器前根本得不到IP。再者，由 于在内核态就可以实现过滤，因此，可以避免内核态到用户态的数据的拷贝，资源消耗也大大降低。 

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。 

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中： 

图1示出了根据本发明一个实施例的方法的流程图；以及， 

图2示出了根据本发明一个实施例的系统的示意图。 

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。 

首先需要说明的是，本发明实施例提供的网络访问控制方法的执行主体可以是一种防火墙系统，该防火墙系统一般应用于具有数据转发功能的网络设备中，例如带数据转发功能的路由器，或者大型骨干网的出口等，并且该防火墙系统一般是运行在Linux等开源系统中。为了便于描述，本发明实施例中均以路由器为例进行介绍。需要说明的是，路由器本身可以实现一些简单的包过滤功能，但是在实际应用中仍然需要在路由器上部署防火墙，这是因为：首先，从设备产生的根源来看，路由器的产生是基于对网络数据包路由而产生的。路由器需要完成的是将不同网络的数据包进行有效的路由，至于为什么路由、是否应该路由、路由过后是否有问题等根本不关心，所关心 的是:能否将不同的网段的数据包进行路由从而进行通讯。而防火墙是产生于人们对于安全性的需求。数据包是否可以正确的到达、到达的时间、方向等不是防火墙关心的重点，重点是这个(一系列)数据包是否应该通过、通过后是否会对网络造成危害。从技术实现的角度来看，路由器核心的ACL列表是基于简单的包过滤，而防火墙是基于状态包过滤的应用级信息流过滤。 

例如，一个最为简单的应用：企业内网的一台主机，通过路由器对内网提供服务(假设提供服务的端口为TCP1455)。为了保证安全性，在路由器上需要配置成：从外到内只允许客户端访问服务器的TCP1455端口，其他拒绝。针对现在的配置，存在的安全脆弱性如下: 

（1）IP地址欺骗(使连接非正常复位) 

（2）TCP欺骗(会话重放和劫持) 

存在上述隐患的原因是，路由器不能监测TCP的状态。如果在内网的客户端和路由器之间放上防火墙，由于防火墙能够检测TCP的状态，并且可以重新随机生成TCP的序列号，则可以彻底消除这样的脆弱性。同时，防火墙的一次性口令认证客户端功能，能够实现在对应用完全透明的情况下，实现对用户的访问控制，其认证支持标准的Radius协议和本地认证数据库，可以完全与第三方的认证服务器进行互操作，并能够实现角色的划分。 

总之，在具有数据转发工具的路由器等设备中，需要配置相应的防火墙系统，而防火墙系统在进行网络访问控制时的有效性需要得到保证。为此，本发明实施例中，提供了一种基于DNS（Domain Name System，域名系统）过滤的网络访问控制方法，其中，DNS用以实现主机域名和主机IP地址之间的相互转换，其核心是一个分布式数据库。所谓的DNS过滤，即在域名解析时就进行限制，在DNS请求包中就把域名提取出来进行判断。由于DNS一般是UDP（User Datagram Protocol，用户数据包协议）包，一个包中就包含了所有信息，包括请求解析的域名信息，不需要通过重组来分离域名信息(对于TCP（Transmission Control Protocol，传输控制协议）的DNS协议可以关闭，使用UDP的已经足够了)；其次，由于UDP包比较简单，UDP包头部包含的信息较少，这样UDP包在发送、接收、分析等环节消耗的各种资源消耗远小于TCP，对于服务器来说基本就没有消耗，防火墙跟踪UDP也比跟 踪TCP要容易得多；再次，DNS过滤比URL过滤限制的范围更大，通常URL只能限制HTTP（Hypertext transfer protocol，超文本传输协议）服务，而DNS过滤则把该域名对应的所有服务都可以限制住。另外，DNS过滤没有IP访问的漏洞，因为客户机在未访问DNS服务器前根本得不到IP。 

当然，DNS过滤与URL过滤相比，其缺点主要是无法控制到目录和文件级别的粒度的。但是一般的信息过滤不需要控制到如此细的粒度，所以在进行信息过滤时可以将两者结合起来以DNS过滤为主，URL过滤为辅。总之，使用DNS过滤，能更快更有效的限制对域名的访问，过滤得也更彻底，强于URL过滤。下面对具体的实现方式进行详细地介绍。 

参见图1，本发明实施例提供的网络访问控制方法可以包括以下步骤： 

S101：通过在内核层接收或发送数据的关键位置处添加钩子函数，建立与内核层之间的接口链表； 

NetFilter在2.4.x内核中引入，成为linux平台下进行网络应用的主要扩展，不仅包括防火墙的实现，还包括报文的处理(如报文加密、报文分类统计等)等。list成员用于维护Netfilter hook的列表。hook成员是一个指向nf_hookfn类型的函数的指针，该函数是这个hook被调用时执行的函数。 

其中，成员hook即用户定义的钩子函数；owner表示注册这个钩子函数的模块，因为NetFilter是内核空间的，所以一般以模块的形式来完成钩子函数注册；pf与hooknum一起索引到特定协议特定编号的钩子函数队列，用于索引nf_hooks；priority决定在同一队列（pf与hooknum相同）的顺序，priority越小则排列越靠前。 

具体实现时，可以通过内核提供的struct nf_hook_ops成员hook注册注册钩子函数，例如fun_dnsfilter。其中，struct nf_hook_ops只是存储钩子的数据结构，而真正存储这些钩子供协议栈调用的是nf_hooks，从定义可以看出，它其实就是二维数组的链表，例如： 

struct list_head nf_hooks[NFPROTO_NUMPROTO][NF_MAX_HOOKS];[net\filter\core.c] 

其中NFPROTO_NUMPROTO表示钩子关联的协议，NF_MAX_HOOKS 表示钩子应用的位置，可选值在每个协议模块内部定义，这些值代表了钩子函数在协议流程中应用的位置。 

注册钩子函数实际上就是在一个nf_hook_ops链表中再插入一个nf_hook_ops结构。具体进行注册时，list_for_each函数遍历当前待注册的钩子的协议pf及Hook类型所对应的链表，其首地址是&nf_hooks[reg->pf][reg->hooknum]，如果当前待注册钩子的优先级小于匹配的的节点的优先级，则找到了待插入的位置，也就是说，按优先级的升序排列。list_add_rcu把当前节点插入到查到找的适合的位置，这样，完成后，所有pf协议下的hooknum类型的钩子，都被注册到&nf_hooks[reg->pf][reg->hooknum]为首的链表当中了。 

换言之，注册nf_hook_ops，也就向内核注册了一个钩子函数，这些函数有ipt_hook，ipt_local_hook，ipt_route_hook，ipt_local_out_hook等。实际上是直接调用ipt_do_table(ip_tables.c)函数，接下来就是根据table里面的entry来处理数据包了。一个table就是一组防火墙规则的集合，而一个entry就是一条规则，每个entry由一系列的matches和一个target组成，一旦数据包匹配了该某个entry的所有matches，就用target来处理它。 

根据nf_iterate()返回，会有以下情况： 

1、如果结果为NF_ACCEPT，表示钩子函数允许报文继续向下处理，此时应该继续执行队列上的下一个钩子函数，因为这些钩子函数都是对同一类报文在相同位置的过滤，前一个通后，并不能返回，而要所有函数都执行完，结果仍为NF_ACCEPT时，则可返回它； 

2、如果结果为NF_REPEAT，表示要重复执行钩子函数一次；所以钩子函数要编写得当，否则报文会一直执行一个返回NF_REPEAET的钩子函数，当返回值为NF_REPEAT时，不会返回； 

3、如果为其它结果，则不必再执行队列上的其它函数，直接返回它；如NF_STOP表示停止执行队列上的钩子函数，直接返回；NF_DROP表示丢弃掉报文；NF_STOLEN表示报文不再往上传递，与NF_DROP不同的是，它没有调用kfree_skb()释放掉skb；NF_QUEUE检查给定协议(pf)是否有队列处理函数，有则进行处理，否则丢掉。 

由于使用NetFilter的目的是在内核态处理报文，而哪些地方可以处理报文只能是内核已经定义好的。一般来说，内核会允许在报文发送或接收的关键位置添加钩子函数处理，查找代码中NF_HOOK即可知。总之，NetFilter的存在使得在内核空间对报文进行用户定义的要求处理变得可能、简单。一般来说，编写好struct nf_hook_ops，其中hook/pf/hook是必给的参数，然后使用nf_register_hook进行注册就可以了。整个过滤文件可以写了一个内核模块，用insmod进行动态加载。在本发明实施例中，该模块可以位于网络层，在TCP/IP协议栈的位置如图2所示。 

S102：利用所述钩子函数在所述内核层截获域名系统DNS请求包； 

在注册了钩子函数之后，相当于是建立了内核与防火墙的接口链表，这样，当用有数据报文到达时就可以沿着链表一一处理。而本发明实施例中注册的钩子函数可以挂在链表的首位，使得可以最先截获到数据报文，以便对数据报文进行分析，判断是否可以放行。 

其中，在截获到一个数据包时，该数据包可能已经进行了分片处理，由于分片的数据需要重组才能还原，可以直接放过（NF_ACCEPT）。因此，在截获到一个数据包之后，可以首先判断其是否含有分片，如果含有，则直接放过，否则，继续进行判断。在继续进行判断时，还可以判断数据包是否为线性的，也即，是否为顺序到达的，如果到达的顺序出现了错乱，也即数据包非线性，则也可以直接放过（NF_ACCEPT）。在发现一个数据包不含有分片，并且是线性的情况下，就可以将数据包的IP头剥离，然后判断其使用的传输层协议是否为UDP协议，由于DNS请求包都是UDP包，因此，如果发现不是UDP协议，例如TCP或者其他协议等，则可以直接放过。如果发现是UDP包，则还可以继续判断其目的端口是否为53端口，如果是，则可以确定其为一个DNS请求包。其中，53端口是DNS服务器所开放，主要用于域名解析的端口。也就是说，如果需要对某域名进行解析，则需要将数据包发送到53端口，才能到达DNS服务器，相应的，该数据包中就会存在待解析的域名等信息。 

S103：解析所述DNS请求包的请求查询名字段，获取请求解析的域名信息； 

在获取到一个DNS请求包之后，就可以从其中的请求查询名字段中，获取到待解析的域名信息。 

其中，在DNS协议中所有的通信都是通过一种简短格式的报文传递的。该报文由12Byte长的首部(header)和4个长度可变的字段(question、answer、authority和additional)组成。其中,首部指明了接下来报文中将包含哪些段以及此报文是请求还是响应、是标准请求还是其他的类型。Question(问题)段包含向域名服务器提出请求的信息，answer(答案)段、authority(权威)段、additional(附加)段均采用一种称为资源记录RR(resource record)的相同格式。答案段中包含直接回答问题段的资源记录，权威段包含可以指向权威服务器的RRs(基本上是NS记录)，附加段包含和请求相关的信息，但不是直接回答的问题(如NS，MX记录对应的A记录)。 

其中，构造DNS请求包时,应将待请求的域名和请求的类别按照DNS数据包的格式要求加入到Question段，而后再加上首部，封装成DNS报文。Question段主要由以下三个字段组成： 

a)QNAME。待请求的域名，要按照规定将点分制的域名转换成多个标志符的队列。每个标志符=一个字节的字符数+标志符。整个域名以0结尾。规定字符数的最高位为0（表示非压缩域名），所以每个标志符的最大字符数为63。 

b)QTYPE。16位，表示DNS协议所支持的查询类型。 

c)QCLASS。16位，IN(1)表示面向Internet。 

因此，通过解析DNS请求报文的QNAME字段，就可以获取到待解析的域名信息。 

S104：将所述域名信息与预置的过滤规则中的域名名单进行匹配，根据匹配结果确定对所述DNS请求包进行放行或者丢弃。 

为了判断当前获取到的DNS请求包中包含的域名信息是否可以放行，可以预先设置一域名名单，该域名名单可以是白名单也可以是黑名单等等。例如，如果是白名单，则判断当前获取到的域名信息是否位于域名名单中，也即，如果域名白名单中存在与域名信息相匹配的信息，则将该DNS请求包放 行，否则，将该DNS请求包丢弃。其中，域名名单中保存的域名信息可以是域名字符串本身，但是由于域名字符串一般都比较长，因此进行域名信息的比对时，就会耗费比较多的时间。因此，为了便于比对，域名名单中保存的各个域名的域名信息可以是根据预置的哈希算法计算出的各个域名的哈希值。这样，在获取到当前的域名信息之后，也可以首先利用相同的哈希算法计算得到哈希值，然后用哈希值进行比对，从而提高比对的实现效率。 

总之，在本发明实施例中，可以实现基于DNS过滤的网络访问控制，在获得前述DNS过滤本身带来的有益效果的同时，由于在内核态就可以实现过滤，因此，可以避免内核态到用户态的数据的拷贝，资源消耗也大大降低。下面对此进行介绍。如前文所述，本发明实施例提供的网络访问控制方法一般应用于具有数据转发功能的网络设备中，例如路由器等，也即，处理数据的过程一般是，接收到上一网络设备发送的数据包，然后再向下一网络设备转发。对于接收上一网络设备发送的数据包的过程而言，其数据流的过程是：首先到达当前设备的网卡，然后从网卡将数据拷贝到内核，之后需要将数据从内核层再拷贝到用户层，然后在用户层对数据包进行分析，如果可以放行，则再将数据包从用户层拷贝到内核层，然后再由内核层拷贝到网卡，由网卡将数据发送给下一网络设备。而在本发明实施例中，由于在内核层就能实现对数据的DNS过滤，因此，如果发现数据包可以放行，则直接从内核态拷贝到网卡进行发送即可，可见，与一般的网络访问控制过程相比，本发明实施例可以避免从内核层到用户层的数据拷贝过程，从而大大降低了资源消耗。 

需要说明的是，在实际应用中，本发明实施例的方法可以应用于企业版应用程序中，其中，所谓的企业版应用程序包括安装在企业用户管理控制中心计算设备上的企业版服务端，以及安装在企业用户终端设备上的企业版客户端，通过企业版服务端实现对各个企业版客户端所在用户终端设备的统一管理。在这种情况下，步骤S101到S103可以由企业版客户端来完成，并且，企业版客户端在获取到请求解析的域名信息之后，可以将域名信息上传至企业版服务端；而步骤S104就可以在企业版服务端进行，在确定出是否需要对DNS请求包进行放行或者丢弃之后，可以向企业版客户端返回相应的处理指令。 

与本发明实施例提供的网络访问控制方法相对应，本发明实施例还提供了一种网络访问控制系统，参见图2，该系统可以包括： 

接口链表建立单元201，用于通过在内核层接收或发送数据的关键位置处添加钩子函数，建立与内核层之间的接口链表； 

请求包截获单元202，用于利用所述钩子函数在所述内核层截获域名系统DNS请求包； 

解析单元203，用于解析所述DNS请求包的请求查询名字段，获取请求解析的域名信息； 

匹配单元204，用于将所述域名信息与预置的过滤规则中的域名名单进行匹配，根据匹配结果确定对所述DNS请求包进行放行或者丢弃。 

具体实现时，所述请求包截获单元202具体可以包括： 

截获子单元，用于利用所述钩子函数对发送到所述内核层的数据包进行截获； 

分析子单元，用于分析所述截获到的数据包，获取DNS请求包。 

其中，所述分析子单元，包括： 

IP头剥离子单元，用于如果所述截获到的数据包不存在分片，且为线性，则剥离所述数据包的IP头； 

协议判断子单元，用于判断所述数据包对应的传输层协议； 

端口判断子单元，用于如果所述传输层协议为UDP，则判断所述数据包的目的端口是否为53端口； 

确定子单元，用于如果是，则确定当前获取到的数据包为DNS请求包。 

另外，该系统还可以包括： 

第一放行单元，用于如果所述截获到的数据包存在分片，或者为非线性，则将所截获到的数据包进行放行。 

第二放行单元，用于如果所述数据包对应的传输层协议不是UDP协议，则将所截获到的数据包进行放行。 

在实际应用中，所述域名名单包括域名白名单，所述匹配单元204具体 可以包括： 

白名单匹配子单元，用于如果所述域名白名单中存在与所述域名信息相匹配的信息，则将所述DNS请求包放行，否则，将所述DNS请求包丢弃。 

或者，所述域名名单中保存的域名信息为根据预置的哈希算法计算出的各个域名的哈希值，所述匹配单元204具体可以包括： 

哈希值计算子单元，用于根据所述哈希算法计算所述域名信息的哈希值； 

哈希值匹配子单元，用于将所述哈希值与所述域名名单中保存的各个域名的哈希值进行匹配。 

其中，所述系统可以应用于企业版应用程序中，其中，所述企业版应用程序包括安装在企业用户管理控制中心计算设备上的企业版服务端，以及安装在企业用户终端设备上的企业版客户端，通过企业版服务端实现对各个企业版客户端所在用户终端设备的统一管理； 

所述接口链表建立单元201、请求包截获单元202、解析单元203位于所述企业版客户端； 

所述企业版客户端还包括： 

上传单元，用于在所述解析单元203获取到请求解析的域名信息之后，将所述域名信息上传至企业版服务端； 

所述匹配单元204位于企业版服务端； 

所述企业版服务端还包括： 

返回单元，用于所述匹配单元204确定出对所述DNS请求包进行放行或者丢弃之后，向企业版客户端返回相应的处理指令。总之，通过本发明实施例提供的上述系统，能够实现基于DNS过滤的访问控制，即在域名解析时就进行限制，在DNS请求包中就把域名提取出来进行判断。由于DNS一般是UDP包，一个包中就包含了所有信息，包括请求解析的域名信息，不需要通过重组来分离域名信息；其次，由于UDP包比较简单，UDP包头部包含的信息较少，这样UDP包在发送、接收、分析等环节消耗的各种资源消耗远小于TCP，对于服务器来说基本就没有消耗，防火墙跟踪UDP也比跟踪TCP要容易得多；再次，DNS过滤比URL过滤限制的范围更大，通常URL只能 限制HTTP服务，而DNS过滤则把该域名对应的所有服务都可以限制住。另外，DNS过滤没有IP访问的漏洞，因为客户机在未访问DNS服务器前根本得不到IP。再者，由于在内核态就可以实现过滤，因此，可以避免内核态到用户态的数据的拷贝，资源消耗也大大降低。 

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。 

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。 

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。 

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书（包括伴随的权利要求、摘要和附图）中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书（包括伴随的权利要求、摘要和附图）中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。 

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。 

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器（DSP）来实现根据本发明实施例的网络访问控制设备中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序（例如，计算机程序和计算机程序产品）。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。 

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。 

本发明还公开了A1、一种网络访问控制方法，包括： 

通过在内核层接收或发送数据的关键位置处添加钩子函数，建立与内核层之间的接口链表； 

利用所述钩子函数在所述内核层截获域名系统DNS请求包； 

解析所述DNS请求包的请求查询名字段，获取请求解析的域名信息； 

将所述域名信息与预置的过滤规则中的域名名单进行匹配，根据匹配结果确定对所述DNS请求包进行放行或者丢弃。 

A2、如A1所述的方法，所述利用所述钩子函数在所述内核层截获域名系统DNS请求包，包括： 

利用所述钩子函数对发送到所述内核层的数据包进行截获； 

分析所述截获到的数据包，获取DNS请求包。 

A3、如A2所述的方法，所述分析所述截获到的数据包，获取DNS请求包，包括： 

如果所述截获到的数据包不存在分片，且为线性，则剥离所述数据包的IP头； 

判断所述数据包对应的传输层协议； 

如果所述传输层协议为UDP，则判断所述数据包的目的端口是否为53端口； 

如果是，则确定当前获取到的数据包为DNS请求包。 

A4、如A3所述的方法，还包括： 

如果所述截获到的数据包存在分片，或者为非线性，则将所截获到的数据包进行放行。 

A5、如A3所述的方法，还包括： 

如果所述数据包对应的传输层协议不是UDP协议，则将所截获到的数据包进行放行。 

A6、如A1至A5任一项所述的方法，所述域名名单包括域名白名单，所述根据匹配结果确定对所述DNS请求包进行放行或者丢弃，包括： 

如果所述域名白名单中存在与所述域名信息相匹配的信息，则将所述DNS请求包放行，否则，将所述DNS请求包丢弃。 

A7、如A1至A5任一项所述的方法，所述域名名单中保存的域名信息为根据预置的哈希算法计算出的各个域名的哈希值，所述将所述域名信息与预置的过滤规则中的域名名单进行匹配包括： 

根据所述哈希算法计算所述域名信息的哈希值； 

将所述哈希值与所述域名名单中保存的各个域名的哈希值进行匹配。 

A8、如A1至A5任一项所述的方法，所述方法应用于企业版应用程序中，其中，所述企业版应用程序包括安装在企业用户管理控制中心计算设备上的企业版服务端，以及安装在企业用户终端设备上的企业版客户端，通过企业版服务端实现对各个企业版客户端所在用户终端设备的统一管理； 

所述通过在内核层接收或发送数据的关键位置处添加钩子函数，建立与内核层之间的接口链表包括： 

企业版客户端通过在内核层接收或发送数据的关键位置处添加钩子函数，建立与内核层之间的接口链表； 

所述利用所述钩子函数在所述内核层截获域名系统DNS请求包包括： 

企业版客户端利用所述钩子函数在所述内核层截获域名系统DNS请求包； 

所述解析所述DNS请求包的请求查询名字段，获取请求解析的域名信息包括： 

企业版客户端解析所述DNS请求包的请求查询名字段，获取请求解析的域名信息，并将所述域名信息上传至企业版服务端； 

所述将所述域名信息与预置的过滤规则中的域名名单进行匹配，根据匹配结果确定对所述DNS请求包进行放行或者丢弃包括： 

企业版服务端将所述域名信息与预置的过滤规则中的域名名单进行匹配，根据匹配结果确定对所述DNS请求包进行放行或者丢弃，并向企业版客户端返回相应的处理指令。 

本发明还公开了B9、一种网络访问控制系统，包括： 

接口链表建立单元，用于通过在内核层接收或发送数据的关键位置处添加钩子函数，建立与内核层之间的接口链表； 

请求包截获单元，用于利用所述钩子函数在所述内核层截获域名系统DNS请求包； 

解析单元，用于解析所述DNS请求包的请求查询名字段，获取请求解析的域名信息； 

匹配单元，用于将所述域名信息与预置的过滤规则中的域名名单进行匹配，根据匹配结果确定对所述DNS请求包进行放行或者丢弃。 

B10、如B9所述的系统，所述请求包截获单元，包括： 

截获子单元，用于利用所述钩子函数对发送到所述内核层的数据包进行截获； 

分析子单元，用于分析所述截获到的数据包，获取DNS请求包。 

B11、如B10所述的系统，所述分析子单元，包括： 

IP头剥离子单元，用于如果所述截获到的数据包不存在分片，且为线性，则剥离所述数据包的IP头； 

协议判断子单元，用于判断所述数据包对应的传输层协议； 

端口判断子单元，用于如果所述传输层协议为UDP，则判断所述数据包的目的端口是否为53端口； 

确定子单元，用于如果是，则确定当前获取到的数据包为DNS请求包。 

B12、如B11所述的系统，还包括： 

第一放行单元，用于如果所述截获到的数据包存在分片，或者为非线性，则将所截获到的数据包进行放行。 

B13、如B11所述的系统，还包括： 

第二放行单元，用于如果所述数据包对应的传输层协议不是UDP协议，则将所截获到的数据包进行放行。 

B14、如B9至B13任一项所述的系统，所述域名名单包括域名白名单，所述匹配单元，包括： 

白名单匹配子单元，用于如果所述域名白名单中存在与所述域名信息相匹配的信息，则将所述DNS请求包放行，否则，将所述DNS请求包丢弃。 

B15、如B9至B13任一项所述的系统，所述域名名单中保存的域名信息为根据预置的哈希算法计算出的各个域名的哈希值，所述匹配单元，包括： 

哈希值计算子单元，用于根据所述哈希算法计算所述域名信息的哈希值； 

哈希值匹配子单元，用于将所述哈希值与所述域名名单中保存的各个域名的哈希值进行匹配。 

B16、如B9至B13任一项所述的系统，所述系统应用于企业版应用程序中，其中，所述企业版应用程序包括安装在企业用户管理控制中心计算设备上的企业版服务端，以及安装在企业用户终端设备上的企业版客户端，通过企业版服务端实现对各个企业版客户端所在用户终端设备的统一管理； 

所述接口链表建立单元、请求包截获单元、解析单元位于所述企业版客户端； 

所述企业版客户端还包括： 

上传单元，用于在所述解析单元获取到请求解析的域名信息之后，将所述域名信息上传至企业版服务端； 

所述匹配单元位于企业版服务端； 

所述企业版服务端还包括： 

返回单元，用于所述匹配单元确定出对所述DNS请求包进行放行或者丢弃之后，向企业版客户端返回相应的处理指令。 

Claims (10)

1.一种网络访问控制方法，包括：

通过在内核层接收或发送数据的关键位置处添加钩子函数，建立与内核层之间的接口链表；

利用所述钩子函数在所述内核层截获域名系统DNS请求包；

解析所述DNS请求包的请求查询名字段，获取请求解析的域名信息；

将所述域名信息与预置的过滤规则中的域名名单进行匹配，根据匹配结果确定对所述DNS请求包进行放行或者丢弃。

2.如权利要求1所述的方法，所述利用所述钩子函数在所述内核层截获域名系统DNS请求包，包括：

利用所述钩子函数对发送到所述内核层的数据包进行截获；

分析所述截获到的数据包，获取DNS请求包。

3.如权利要求2所述的方法，所述分析所述截获到的数据包，获取DNS请求包，包括：

如果所述截获到的数据包不存在分片，且为线性，则剥离所述数据包的IP头；

判断所述数据包对应的传输层协议；

如果所述传输层协议为UDP，则判断所述数据包的目的端口是否为53端口；

如果是，则确定当前获取到的数据包为DNS请求包。

4.如权利要求3所述的方法，还包括：

如果所述截获到的数据包存在分片，或者为非线性，则将所截获到的数据包进行放行。

5.如权利要求3所述的方法，还包括：

如果所述数据包对应的传输层协议不是UDP协议，则将所截获到的数据包进行放行。

6.一种网络访问控制系统，包括：

接口链表建立单元，用于通过在内核层接收或发送数据的关键位置处添加钩子函数，建立与内核层之间的接口链表；

请求包截获单元，用于利用所述钩子函数在所述内核层截获域名系统DNS请求包；

解析单元，用于解析所述DNS请求包的请求查询名字段，获取请求解析的域名信息；

匹配单元，用于将所述域名信息与预置的过滤规则中的域名名单进行匹配，根据匹配结果确定对所述DNS请求包进行放行或者丢弃。

7.如权利要求6所述的系统，所述请求包截获单元，包括：

截获子单元，用于利用所述钩子函数对发送到所述内核层的数据包进行截获；

分析子单元，用于分析所述截获到的数据包，获取DNS请求包。

8.如权利要求7所述的系统，所述分析子单元，包括：

IP头剥离子单元，用于如果所述截获到的数据包不存在分片，且为线性，则剥离所述数据包的IP头；

协议判断子单元，用于判断所述数据包对应的传输层协议；

端口判断子单元，用于如果所述传输层协议为UDP，则判断所述数据包的目的端口是否为53端口；

确定子单元，用于如果是，则确定当前获取到的数据包为DNS请求包。

9.如权利要求8所述的系统，还包括：

第一放行单元，用于如果所述截获到的数据包存在分片，或者为非线性，则将所截获到的数据包进行放行。

10.如权利要求8所述的系统，还包括：

第二放行单元，用于如果所述数据包对应的传输层协议不是UDP协议，则将所截获到的数据包进行放行。

Images