CN103327025B - 网络访问控制方法及装置 - Google Patents
网络访问控制方法及装置 Download PDFInfo
- Publication number
- CN103327025B CN103327025B CN201310268313.0A CN201310268313A CN103327025B CN 103327025 B CN103327025 B CN 103327025B CN 201310268313 A CN201310268313 A CN 201310268313A CN 103327025 B CN103327025 B CN 103327025B
- Authority
- CN
- China
- Prior art keywords
- domain name
- packet
- dns request
- request bag
- enterprise version
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 68
- 238000001914 filtration Methods 0.000 claims abstract description 40
- 238000004458 analytical method Methods 0.000 claims abstract description 36
- 230000008569 process Effects 0.000 claims description 28
- 238000004422 calculation algorithm Methods 0.000 claims description 17
- 230000008878 coupling Effects 0.000 claims description 14
- 238000010168 coupling process Methods 0.000 claims description 14
- 238000005859 coupling reaction Methods 0.000 claims description 14
- 230000005540 biological transmission Effects 0.000 claims description 9
- 108010001267 Protein Subunits Proteins 0.000 claims description 8
- 238000004321 preservation Methods 0.000 claims description 4
- 230000013011 mating Effects 0.000 claims 1
- 230000006870 function Effects 0.000 description 52
- 238000005516 engineering process Methods 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 235000013399 edible fruits Nutrition 0.000 description 3
- 238000013507 mapping Methods 0.000 description 3
- 239000000203 mixture Substances 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 101000911390 Homo sapiens Coagulation factor VIII Proteins 0.000 description 1
- 230000001174 ascending effect Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000001035 drying Methods 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 102000057593 human F8 Human genes 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 229940047431 recombinate Drugs 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
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进行动态加载。在本发明实施例中，该模块可以位于网络层。
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 (16)
1.一种网络访问控制方法，包括：
通过在内核层接收或发送数据的关键位置处添加钩子函数，建立防火墙与内核层之间的接口链表；
所述防火墙利用所述钩子函数在所述内核层截获域名系统DNS请求包；
所述防火墙解析所述DNS请求包的请求查询名字段，获取请求解析的域名信息；
所述防火墙将所述域名信息与预置的过滤规则中的域名名单进行匹配，根据匹配结果确定对所述DNS请求包进行放行或者丢弃。
2.如权利要求1所述的方法，所述利用所述钩子函数在所述内核层截获域名系统DNS请求包，包括：
利用所述钩子函数对发送到所述内核层的数据包进行截获；
分析所述截获到的数据包，获取DNS请求包。
3.如权利要求2所述的方法，所述分析所述截获到的数据包，获取DNS请求包，包括：
如果所述截获到的数据包不存在分片，且为线性，则剥离所述数据包的IP头；
判断所述数据包对应的传输层协议；
如果所述传输层协议为UDP，则判断所述数据包的目的端口是否为53端口；
如果是，则确定当前获取到的数据包为DNS请求包。
4.如权利要求3所述的方法，还包括：
如果所述截获到的数据包存在分片，或者为非线性，则将所截获到的数据包进行放行。
5.如权利要求3所述的方法，还包括：
如果所述数据包对应的传输层协议不是UDP协议，则将所截获到的数据包进行放行。
6.如权利要求1至5任一项所述的方法，所述域名名单包括域名白名单，所述根据匹配结果确定对所述DNS请求包进行放行或者丢弃，包括：
如果所述域名白名单中存在与所述域名信息相匹配的信息，则将所述DNS请求包放行，否则，将所述DNS请求包丢弃。
7.如权利要求1至5任一项所述的方法，所述域名名单中保存的域名信息为根据预置的哈希算法计算出的各个域名的哈希值，所述将所述域名信息与预置的过滤规则中的域名名单进行匹配包括：
根据所述哈希算法计算所述域名信息的哈希值；
将所述哈希值与所述域名名单中保存的各个域名的哈希值进行匹配。
8.如权利要求1至5任一项所述的方法，所述方法应用于企业版应用程序中，其中，所述企业版应用程序包括安装在企业用户管理控制中心计算设备上的企业版服务端，以及安装在企业用户终端设备上的企业版客户端，通过企业版服务端实现对各个企业版客户端所在用户终端设备的统一管理；
所述通过在内核层接收或发送数据的关键位置处添加钩子函数，建立与内核层之间的接口链表包括：
企业版客户端通过在内核层接收或发送数据的关键位置处添加钩子函数，建立与内核层之间的接口链表；
所述利用所述钩子函数在所述内核层截获域名系统DNS请求包包括：
企业版客户端利用所述钩子函数在所述内核层截获域名系统DNS请求包；
所述解析所述DNS请求包的请求查询名字段，获取请求解析的域名信息包括：
企业版客户端解析所述DNS请求包的请求查询名字段，获取请求解析的域名信息，并将所述域名信息上传至企业版服务端；
所述将所述域名信息与预置的过滤规则中的域名名单进行匹配，根据匹配结果确定对所述DNS请求包进行放行或者丢弃包括：
企业版服务端将所述域名信息与预置的过滤规则中的域名名单进行匹配，根据匹配结果确定对所述DNS请求包进行放行或者丢弃，并向企业版客户端返回相应的处理指令。
9.一种网络访问控制系统，包括：
接口链表建立单元，用于通过在内核层接收或发送数据的关键位置处添加钩子函数，建立防火墙与内核层之间的接口链表；
请求包截获单元，用于通过所述防火墙利用所述钩子函数在所述内核层截获域名系统DNS请求包；
解析单元，用于通过所述防火墙解析所述DNS请求包的请求查询名字段，获取请求解析的域名信息；
匹配单元，用于通过所述防火墙将所述域名信息与预置的过滤规则中的域名名单进行匹配，根据匹配结果确定对所述DNS请求包进行放行或者丢弃。
10.如权利要求9所述的系统，所述请求包截获单元，包括：
截获子单元，用于利用所述钩子函数对发送到所述内核层的数据包进行截获；
分析子单元，用于分析所述截获到的数据包，获取DNS请求包。
11.如权利要求10所述的系统，所述分析子单元，包括：
IP头剥离子单元，用于如果所述截获到的数据包不存在分片，且为线性，则剥离所述数据包的IP头；
协议判断子单元，用于判断所述数据包对应的传输层协议；
端口判断子单元，用于如果所述传输层协议为UDP，则判断所述数据包的目的端口是否为53端口；
确定子单元，用于如果是，则确定当前获取到的数据包为DNS请求包。
12.如权利要求11所述的系统，还包括：
第一放行单元，用于如果所述截获到的数据包存在分片，或者为非线性，则将所截获到的数据包进行放行。
13.如权利要求11所述的系统，还包括：
第二放行单元，用于如果所述数据包对应的传输层协议不是UDP协议，则将所截获到的数据包进行放行。
14.如权利要求9至13任一项所述的系统，所述域名名单包括域名白名单，所述匹配单元，包括：
白名单匹配子单元，用于如果所述域名白名单中存在与所述域名信息相匹配的信息，则将所述DNS请求包放行，否则，将所述DNS请求包丢弃。
15.如权利要求9至13任一项所述的系统，所述域名名单中保存的域名信息为根据预置的哈希算法计算出的各个域名的哈希值，所述匹配单元，包括：
哈希值计算子单元，用于根据所述哈希算法计算所述域名信息的哈希值；
哈希值匹配子单元，用于将所述哈希值与所述域名名单中保存的各个域名的哈希值进行匹配。
16.如权利要求9至13任一项所述的系统，所述系统应用于企业版应用程序中，其中，所述企业版应用程序包括安装在企业用户管理控制中心计算设备上的企业版服务端，以及安装在企业用户终端设备上的企业版客户端，通过企业版服务端实现对各个企业版客户端所在用户终端设备的统一管理；
所述接口链表建立单元、请求包截获单元、解析单元位于所述企业版客户端；
所述企业版客户端还包括：
上传单元，用于在所述解析单元获取到请求解析的域名信息之后，将所述域名信息上传至企业版服务端；
所述匹配单元位于企业版服务端；
所述企业版服务端还包括：
返回单元，用于所述匹配单元确定出对所述DNS请求包进行放行或者丢弃之后，向企业版客户端返回相应的处理指令。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201310268313.0A CN103327025B (zh) | 2013-06-28 | 2013-06-28 | 网络访问控制方法及装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201310268313.0A CN103327025B (zh) | 2013-06-28 | 2013-06-28 | 网络访问控制方法及装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN103327025A CN103327025A (zh) | 2013-09-25 |
| CN103327025B true CN103327025B (zh) | 2016-08-24 |
Family
ID=49195555
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201310268313.0A Active CN103327025B (zh) | 2013-06-28 | 2013-06-28 | 网络访问控制方法及装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN103327025B (zh) |
Families Citing this family (33)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103581363B (zh) * | 2013-11-29 | 2017-12-12 | 哈尔滨工业大学（威海） | 对恶意域名和非法访问的控制方法及装置 |
| CN103647774A (zh) * | 2013-12-13 | 2014-03-19 | 扬州永信计算机有限公司 | 基于云计算的web内容信息过滤方法 |
| CN103905434A (zh) * | 2014-03-13 | 2014-07-02 | 亿赞普(北京)科技有限公司 | 一种网络数据处理方法和装置 |
| CN103929418A (zh) * | 2014-03-28 | 2014-07-16 | 汉柏科技有限公司 | 基于网络安全设备的无线上网方法及系统 |
| CN103957284B (zh) * | 2014-04-04 | 2015-09-09 | 北京奇虎科技有限公司 | Dns行为的处理方法、装置及系统 |
| CN105100178B (zh) * | 2014-05-23 | 2019-12-20 | 中兴通讯股份有限公司 | 一种自适应重定向加速处理方法及装置 |
| CN104010000B (zh) * | 2014-06-13 | 2017-12-29 | 北京联宇益通科技发展有限公司 | 安卓系统非超级用户权限下数据包过滤方法、装置和系统 |
| CN104202307B (zh) * | 2014-08-15 | 2018-06-08 | 小米科技有限责任公司 | 数据转发方法及装置 |
| CN105721387A (zh) * | 2014-12-01 | 2016-06-29 | 北京蓝光引力网络股份有限公司 | 防止网络劫持的方法 |
| CN104753928B (zh) * | 2015-03-16 | 2018-08-17 | 苏州科达科技股份有限公司 | 一种码流转发方法及系统 |
| CN106528396B (zh) * | 2015-09-09 | 2019-06-11 | 阿里巴巴集团控股有限公司 | 用于处理应用请求的方法与设备 |
| CN105306616A (zh) * | 2015-09-22 | 2016-02-03 | 深圳前海华视移动互联有限公司 | 一种多媒体终端及基于内核实现的dns拦截方法 |
| CN105245347B (zh) * | 2015-10-22 | 2019-02-26 | 成都卫士通信息产业股份有限公司 | 一种适配多种存储产品的加密系统实现方法 |
| CN105827588B (zh) * | 2015-12-23 | 2019-03-15 | 广东亿迅科技有限公司 | 一种基于网络驱动层的流媒体数据分发系统 |
| CN105959284A (zh) * | 2016-04-29 | 2016-09-21 | 上海斐讯数据通信技术有限公司 | 一种报文过滤系统及方法 |
| CN105915548A (zh) * | 2016-06-20 | 2016-08-31 | 浪潮电子信息产业股份有限公司 | 一种基于netfilter实现DNS过滤的设计方法 |
| CN106375318A (zh) * | 2016-09-01 | 2017-02-01 | 北京神州绿盟信息安全科技股份有限公司 | 一种网络访问控制系统和方法 |
| CN106549944A (zh) * | 2016-10-17 | 2017-03-29 | 上海斐讯数据通信技术有限公司 | 一种基于Linux内核哈希表的域名过滤方法 |
| CN109218454A (zh) * | 2017-04-13 | 2019-01-15 | 阿里巴巴集团控股有限公司 | Dns请求的响应方法及dns服务器 |
| CN107222507A (zh) * | 2017-07-13 | 2017-09-29 | 广州西麦科技股份有限公司 | 一种家庭网络内容访问控制方法及装置 |
| CN109756454B (zh) * | 2017-11-03 | 2022-01-11 | 阿里巴巴集团控股有限公司 | 数据交互的方法、装置和系统 |
| CN108391307B (zh) * | 2018-02-09 | 2021-11-23 | 北京小米移动软件有限公司 | 基于安卓系统的功耗管控方法、装置及存储介质 |
| CN109547580B (zh) * | 2019-01-22 | 2021-05-25 | 网宿科技股份有限公司 | 一种处理数据报文的方法和装置 |
| CN110572377B (zh) * | 2019-08-22 | 2022-02-22 | 网宿科技股份有限公司 | 一种数据转发方法、插件和域名服务器 |
| CN111371920A (zh) * | 2020-03-16 | 2020-07-03 | 广州根链国际网络研究院有限公司 | Dns前端解析方法及系统 |
| CN113726917B (zh) * | 2020-05-26 | 2024-04-12 | 奇安信网神信息技术(北京)股份有限公司 | 域名确定方法、装置和电子设备 |
| CN113872918A (zh) * | 2020-06-30 | 2021-12-31 | 苏州三六零智能安全科技有限公司 | 网络流量分类方法、设备、存储介质及装置 |
| CN113923032B (zh) * | 2021-10-12 | 2024-04-09 | 成都安恒信息技术有限公司 | 一种应用访问控制的接入方法 |
| CN113660292B (zh) * | 2021-10-19 | 2022-01-11 | 北京安华金和科技有限公司 | 一种获取调用客户端的主体的信息方法和装置 |
| CN114339756B (zh) * | 2021-12-17 | 2024-04-26 | 北京北信源软件股份有限公司 | 无线设备的准入和访问策略控制方法、装置及系统 |
| CN114465798B (zh) * | 2022-02-10 | 2024-03-19 | 深圳市共进电子股份有限公司 | 一种报文过滤方法、网关设备及存储介质 |
| CN116566682B (zh) * | 2023-05-16 | 2023-12-08 | 赛姆科技(广东)有限公司 | 一种分布式信息网络安全防护方法、系统及其可读存储介质 |
| CN117278327B (zh) * | 2023-11-21 | 2024-01-26 | 北京熠智科技有限公司 | 一种针对网络请求的访问控制方法及系统 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102025713A (zh) * | 2010-02-09 | 2011-04-20 | 中国移动通信集团北京有限公司 | 一种访问控制方法、系统及dns服务器 |
| CN102185936A (zh) * | 2011-06-23 | 2011-09-14 | 上海牙木通讯技术有限公司 | 一种基于linux操作系统的DNS服务系统和方法 |
| CN102291268A (zh) * | 2011-09-23 | 2011-12-21 | 杜跃进 | 一种安全域名服务器及基于此的恶意域名监控系统和方法 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9172713B2 (en) * | 2008-09-24 | 2015-10-27 | Neustar, Inc. | Secure domain name system |
-
2013
- 2013-06-28 CN CN201310268313.0A patent/CN103327025B/zh active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102025713A (zh) * | 2010-02-09 | 2011-04-20 | 中国移动通信集团北京有限公司 | 一种访问控制方法、系统及dns服务器 |
| CN102185936A (zh) * | 2011-06-23 | 2011-09-14 | 上海牙木通讯技术有限公司 | 一种基于linux操作系统的DNS服务系统和方法 |
| CN102291268A (zh) * | 2011-09-23 | 2011-12-21 | 杜跃进 | 一种安全域名服务器及基于此的恶意域名监控系统和方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN103327025A (zh) | 2013-09-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN103327025B (zh) | 网络访问控制方法及装置 | |
| US11824879B2 (en) | Rule-based network-threat detection for encrypted communications | |
| JP7050937B2 (ja) | コアネットワークドメイン間で伝送されるメッセージの保護 | |
| US8738700B2 (en) | Method and system for providing network services | |
| CN112714194B (zh) | 一种外网主机访问内网设备的方法和网络拓扑结构 | |
| EP2036306B1 (en) | Secure domain information protection apparatus and methods | |
| US20050063377A1 (en) | System and method for monitoring network traffic | |
| US20130191890A1 (en) | Method and system for user identity recognition based on specific information | |
| CN106161335A (zh) | 一种网络数据包的处理方法和装置 | |
| CN104394122A (zh) | 一种基于自适应代理机制的http业务防火墙 | |
| CN108243143A (zh) | 一种基于web代理的网闸穿透方法及系统 | |
| US20170026481A1 (en) | Technique for controlling the service request routing | |
| KR20060028390A (ko) | 다수의 네트워크가 인증되어 서로 통신하고 있는지와 이들 네트워크들 중 두 개로 이루어진 각 조합 간의 통신을 위해 어떤 ｉｐ 프로토콜이 사용되는지를 결정하는 방법 및 시스템, 컴퓨터 판독가능 저장 매체 | |
| Yan et al. | The road to DNS privacy | |
| CN104756462B (zh) | 用于在限制性防火墙后进行tcp turn操作的方法和系统 | |
| Stoecklin et al. | Passive security intelligence to analyze the security risks of mobile/BYOD activities | |
| US11522832B2 (en) | Secure internet gateway | |
| CN110995763A (zh) | 一种数据处理方法、装置、电子设备和计算机存储介质 | |
| Nappa et al. | RevProbe: detecting silent reverse proxies in malicious server infrastructures | |
| US7715326B2 (en) | Webserver alternative for increased security | |
| Nosyk et al. | Intercept and Inject: DNS Response Manipulation in the Wild | |
| CN102932487B (zh) | 数据处理方法及系统 | |
| KR20110070161A (ko) | 봇넷 탐지를 위한 네트워크 트래픽의 행위 패턴 모델링 시스템과 봇넷 탐지를 위한 네트워크 트래픽의 행위 패턴 모델링 방법 | |
| Wachs | A secure and resilient communication infrastructure for decentralized networking applications | |
| Chung et al. | Comcast's web notification system design |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| C41 | Transfer of patent application or patent right or utility model | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20170113 Address after: 100016 Jiuxianqiao Chaoyang District Beijing Road No. 10, building 15, floor 17, layer 1701-26, 3 Patentee after: BEIJING QIANXIN TECHNOLOGY Co.,Ltd. Address before: 100088 Beijing city Xicheng District xinjiekouwai Street 28, block D room 112 (Desheng Park) Patentee before: BEIJING QIHOO TECHNOLOGY Co.,Ltd. Patentee before: Qizhi software (Beijing) Co.,Ltd. |
|
| CP03 | Change of name, title or address | ||
| CP03 | Change of name, title or address |
Address after: 100032 Building 3 332, 102, 28 Xinjiekouwai Street, Xicheng District, Beijing Patentee after: QAX Technology Group Inc. Address before: 100016 15, 17 floor 1701-26, 3 building, 10 Jiuxianqiao Road, Chaoyang District, Beijing. Patentee before: BEIJING QIANXIN TECHNOLOGY Co.,Ltd. |