CN103905581A - 基于行为差异性的dns高速解析方案和配套的抗流量类攻击安全方案 - Google Patents
基于行为差异性的dns高速解析方案和配套的抗流量类攻击安全方案 Download PDFInfo
- Publication number
- CN103905581A CN103905581A CN201410066376.2A CN201410066376A CN103905581A CN 103905581 A CN103905581 A CN 103905581A CN 201410066376 A CN201410066376 A CN 201410066376A CN 103905581 A CN103905581 A CN 103905581A
- Authority
- CN
- China
- Prior art keywords
- dns
- area network
- local area
- lan
- message
- 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.)
- Pending
Links
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本基于行为差异性的DNS高速解析方案和配套的抗流量类攻击安全方案在不对现有DNS体系做较大改变的情况下通过重写DNS客户端和在网关增加专门针对DNS封包的转发协议,使得DNS封包优先在局域网内转发,同时利用微服务端思想,将DNS客户端改造成一个个微型的DNS服务端,利用个体行为的差异性,将部分DNS解析请求在局域网内解决,另外,考虑到解析权威性和安全性,微服务端提供的解析能力将仅限于客户端已经成功解析的目标,而且通过巧妙的利用网络设备极限处理能力有极限的特点和增加DNS报文字段,提高单个DNS封包对资源的消耗和在网关的DNS报文转发协议的安全转发规则的设定,将对广域网的冲击转嫁到局域网中,将大范围网络故障限制在小范围的局域网中,大大提高DNS体系的抗流量类攻击的能力。
Description
技术领域
本发明涉及到互联网中DNS解析体系,能提供比现有体系更加高速、安全、稳定的解析方案,且能解决大部分针对DNS服务器发起的流量类攻击,解决因为DNS服务器被攻击造成大范围解析异常的问题。
背景技术
目前,互联网体系中使用的DNS为树型结构,由DNS解析过程而衍生的流量类攻击基本无法防御,近年来DNS服务器被攻击造成的大范围网络异常现象的次数越来越多,众多的黑客朋友都怀着这样或那样的目的将目光瞄准了DNS体系,而现今DNS体系已经被证实非常脆弱。自从RFC1035文档规范了DNS体系以来DNS系统至今未经过较大的改动,而现今的互联网甚至将来的物联网都迫切需要更加高效、更加稳定、更加安全的DNS体系。为此,本发明提出一种在无需较大改动现有DNS体系的情况下,比现有体系更加高效、更加稳定、更加安全的方案。本方案中利用局域网信息交互速度快的特点,将部分DNS解析请求转嫁到局域网中,利用局域网的闲置资源,节省服务器的资源,达到变相扩大服务器服务能力的目的,同时,由于局域网信息交互的速度非常快,使得能在局域网中被解析的DNS请求解析速度变得非常快,变相提高了DNS解析质量。
为此,在本方案中改造了现有的DNS客户端,成功利用微服务器思想,使得客户端也具有有限的服务能力,为DNS请求在局域网中被解析打好了基础。与此同时,由于该方案的特殊性,使得其虽然能保证服务器的安全,但是却又对局域网造成了威胁,故此,本方案更是专门为其设计了安全方案,确保其造成的威胁降到了最低。而且由于本方案采用了局域网解析的方法,故就算是全球所有的DNS服务器全部拒绝提供服务,仍然可以依靠局域网缓存提供部分服务,以确保不会因为服务端的原因导致DNS体系全面瘫痪。
发明内容
本发明由域名快速解析方案和其配套的安全方案组成,具体如下:
一:域名快速解析方案
关于快速解析方案,其实全称应该是基于局域网快速信息交互的高速域名解析方案,简称快速解析方案,从名字就可以看出,他是基于局域网的,他将利用到局域网的某些优势;经过估算,在局域网内,域名解析速度平均能提高一倍,请注意,是平均,不是所有,对于常用域名而言,最快能在2MS内解析完成,对于用户较少的域名,在某些程度上还没有现有域名解析方案快。
对于现有的正在运行的域名解析方案,我想大家都比较熟悉,所以就不在详细介绍;现有运行的方案是客户端-服务端模式的,这种模式不可否认有诸多优点,但是现在却有点不太适用,当然,并不是说完全不能用,而是说如果服务端一旦无法提供服务,那么,所有域名解析服务将无法运行(尤其是某根服务器莫名其妙的拒绝服务的情况下),因为所有的数据都在服务端,客户端并没有数据,也许有人问,现在的正在运行的解析方案不是有客户端缓存这个东西么,确实,DNS缓存确实存在,也在一定程度上提高了再次访问的解析效率,但是,以来缓存数量有限,二来缓存都是独立的,即A的缓存不能给B用,所以说,能提高再次访问效率,但不能从根本上解决问题。
而且,随着近年来越来越多的DNS服务器受到攻击导致大范围的解析故障来看,这种客户端-服务端的模式确实有改变的必要,要知道,域名解析式互联网的基石之一,一旦域名解析无法正常提供服务,那么整个互联网体系都将面临崩溃!
对此,我提出来基于局域网的高速解析技术,当然,这样说太笼统,下面来一一解释;
首先说的是行为差异性,我们知道,人类是群居动物,是由个体组成的群落,但是,个体之间是彼此独立的,所以,就算是同样的行为,个体之间都有不同的表现方式,如同样是浏览网页,A喜欢通过导航网站hao123寻找今日头条,但B却喜欢直接打开凤凰网看,同样的行为,不同的表现方式,这就是个体间的差异性,同样,这些差异性也是域名高速解析方案的基础之一;其次,域名高速解析方案还涉及到另一个技术:局域网(严格的来讲应该是时域网,为方便区分,以下统称时域网)。时域网的定义如下:在网络中,只要该网络中任意节点的信息交互速度在一定的时间内,则该网络称之为时域网。也就是说,这个时域网其实不再以地域或范围作为划分标准,而是以信息交互的速度来作为划分标准,这样就打破了地域的限制,使得本方案中“相邻”主机的数量更大,使得更多的解析请求消化在时域网中而不是DNS服务器,这样就能节省服务器的资源。在本方案中,时域网定义的时间界限为5MS,即所有信息交互速度在5MS内的主机将被视为在一个时域网内。
在这里需要重新定义缓存的概念,原本的位于客户端的DNS缓存只是作为一个快速查询的产物,但是在本方案中,缓存不再如此简单,他被添加了生命周期,也就是说缓存不再是永久的,他也拥有的实效性,缓存只有在其有效时间内可以提供服务,超过有效期的缓存将被放弃。这样做的原因是因为互联网的信息更新太快了,如果缓存被设计成永久有效,那么会出现某域名更新的其ip地址,但缓存没有,而由于缓存的永久有效性,局域网解析时将会解析错误。
对于高速解析方案而言,在服务端并未有太大的改变,改变的基本上都位于客户端,具体变化为改变的解析优先级,传统解析顺序是先查询缓存,如果没有则向服务器发出查询请求,总共只有两个查询序列,但是在新方案中,第一查询序列仍是查询缓存,第一序列也就是缓存查询没有结果时,第二查询序列不是向服务器发出查询请求,而是向时域网广播自己的查询请求,而时域网在线主机接到查询请求后,会查询自己的缓存中是否能查询到,有则返回查询结果,没有则不理会(即不发回查询失败的结果)。由于本方案中对时域网的定义,我们可以知道,如果时域网中有主机的缓存中有我们需要的结果,那么整个解析过程可在5MS内完成,甚至最快可在1MS内完成,当然,也有时域网中所有在线主机都没有结果的情况,这样也就意味着第二序列查询失败,那么我们就需要转到第三序列,也就是直接向DNS服务器发出查询请求。修改后的方案增加了一个查询序列,如果再第二序列查询失败的情况下,无疑要比原来只有两个序列的方案要慢,但是,如果第二查询序列成功,将要比现有的方案快得多,这样的后果无疑是使用人数多的网站解析速度更快,而使用人数少的网站解析更慢,但这符合资源的最优化分配的原则。
实际上,整个方案是利用了微服务器思想,将以前的客户端添加了服务端功能,也就是客户端即服务端,将客户端变成了一个个微小的服务端,然后再利用时域网信息交互速度快的特点,将时域网用户的解析需求发送到时域网的其他主机上,解决一部分常见的网站的解析请求,减轻DNS服务器的压力。但是这样做的后果却是为局域网攻击提供了一条快速而有效的路径,因为在本方案中,需要将局域网用户的需求转发给所有局域网用户,所以会占用大量局域网资源,一旦有用户在短时间内大量发送请求解析的报文,那么局域网的资源将在很短的时间内被消耗一空,而形成类似断网的结果。所以在使用该方案的同时,必须搭配使用专门为该方案而设计的安全方案,具体请看下文。
二:DNS报文新增内容及抗流量类攻击问题
在前文中我提到了这份安全方案的重要性,但是我想再次解释一下:首先,我们从上文的域名高速解析方案中可以看出,我们将用户的解析需求进行了转嫁,没错,就是转嫁,我们将客户端改造,使其具有服务能力,然后利用这些服务能力来解决同一局域网的用户的解析需求,实际上是将面向DNS服务器的解析请求转嫁到了局域网中的用户,依靠大量的用户基数来消化这些请求,而由于前文中提到的行为差异性,无疑使得这种转嫁具有成功的可能,但是,这种转嫁并不是没有代价的,这种代价就是局域网资源的消耗,虽然这种代价在我们看来是非常的微小,但再微小的代价一旦乘以用户基数将变成非常可怕!要知道,在网络的设计中,任何网络的资源利用率都不是100%的,也就是说有一定的资源闲置,而我们的方案利用的是这一部分闲置资源,这在平时是非常好的方案,但是,一旦有局域网用户大量的发送解析请求的情况发生,那么因为报文优先级的问题(我们不可能将DNS的报文的优先级设为最低,那样的话就达不到高速解析的目的)当闲置资源不够用时,就开始抢占其他的资源,最终的结果就是整个局域网中充斥着大量的DNS的报文,其他的报文寸步难行,造成断网的结果(类似于死ping);至于为什么我仅仅只是解释局域网问题而不解释DNS服务器遭到流量类攻击的问题,那是因为在本方案中哪怕是发起流量类攻击,真正能攻击到的DNS服务器的流量将剩不了多少,基本不会对DNS服务器造成影响,因为局域网设备的性能有限,大量的DNS报文充斥网络时,真正能到达DNS服务器的报文将大大减少。
而对于怎么实现防通过上文提到的方法攻击局域网的问题,经过研究,发现基于现有的DNS报文结构无法解决这个问题,所以对于DNS报文的结构进行了修改,准确的说是增加了DNS报文的大小,在不改变现有DNS的报文结构的基础上,在其末尾增加了一部分内容,具体为:国家或地区代码、地区邮政编码(取4个有效位)、步进次数、使用时间、解析结果标记;其中,考虑到现有互联网体系速率的提高,以及以后的发展,国家或地区编码占用2个字节(共16位)地区邮政编码占用2个字节(16位)(注:取4个有效位是针对10进制而言)步进次数同样占用2个字节(共16位)(注:根据目前互联网情况,约5个节点就达到了本文中的局域网的限制,故在本设计中仅设计步进最大数为5,其余的未使用到的作为保留,一遍以后互联网质量提高后修改)使用时间因为考虑到实际情况,将占用4个字节(具体解释将在下文给出)解析结果标记占用2个字节。具体见下表
国家或地区编码:采用高位计算法,不足部分补零,例如国家或地区编码为01,那么其编码为0000000000000001,用于判断该DNS请求来源国,用于是否屏蔽该国DNS请求,是第一判断条件。
地区邮政编码:取该地区所属国家或地区的邮政编码,如湖南省娄底市娄星区的具体邮政编码为417000,那么取其前4位为4170作为该地区的邮政编码,同样采用高位计算法,不足位补零(我不确定采用4位是否合适,因为采用4为那么地区列表的最大长度将有9999个,我不确定现在的设备运算能力是否能快速的处理这么多数据,也许可以根据实际情况设定为3位,也就是最大长度为999)。
步进次数:记录该DNS报文转发的次数,从第一个节点算起,每经过一个节点就加一,是DNS报文转发协议判断是否终止转发的条件之一;
使用时间:记录该DNS报文从生成到被某节点转发所经过的时间,每经过一个节点,就加上上一节点到该节点所经过的时间,(设置4个字节长度是因为目前计算机最小计时单位是毫秒,但不代表永远都是毫秒,当更加高级的量子计算机常规化时,也许计时单位就变成了微秒、纳秒,到时候4个字节的长度就派上用场了)是DNS报文转发协议判断是否继续转发的条件之一;
解析结果标记:是最终解析结果标记,第一位为1代表局域网解析成功,第二位为1代表局域网解析失败,第三位为1代表DNS服务器解析成功,第四位为1代表DNS服务器解析失败;第五位为1代表无法连接DNS服务器,(注:此处位数为从右至左为第一位,即从右数起的首位为第一位)第十六位到第十三位为报文状态标示位,其中,第十六位为1代表局域网请求报文,第十五位为1代表局域网回传报文,第十四位为1代表服务器请求报文,第十三位为1代表服务器回传报文。在整个标记段中,第十六位到第十三位只允许一位为1,第一位到第5位只允许一位为1且当报文标记为请求报文时第一到第五位全部置零。
现在我们给出了新增的报文内容,这些内容不是乱加的,是有作用的,首先,在网关处会有一个DNS报文转发协议,所有的安全工作和报文转发工作都由这个协议来完成,这个协议就是检测我们新增的这些东西,依据前提条件,决定是否转发该DNS报文,具体过程如下:
对于每一个DNS报文,协议都有检测新增的字段,具体如下:检测地区邮政编码,然后判断是否在阻止列表内,是的话就无视该报文,处理下一个报文,如果不在列表内,检测标记位中的标记,判断是哪种报文,如果局域网请求报文并且符合报文规则,则判断步进数是否达到临界值,是的话无视报文,处理下一个报文,不是的话检测时间是否超时,未超时则转发报文。
从上文我们可以看到,一个报文,我们会经过多次判断,只有这个报文符合规范并且不再阻止列表时这个报文才会被转发,否则这个报文会被丢弃,当然,这里也许还不能看出其为什么能抗流量类攻击,解释一下:一个报文需要经过如此多的判断才会被允许转发,相比较原先的报文而言,其消耗的资源明显变多,但是我们的总资源是有限的,同一时间内原来能转发的报文也许是10,但是新的报文能转发的可能就变成了5,这还是全部转发服务器请求报文,别说还有局域网请求报文,这样,实际上能到达服务器的报文将大大减少,而且在高强度的工作下,局域网设备可能会首先承受不了而崩溃,这样整个局域网都将离开公网,这样的话由局域网中发出的攻击永远别想到达服务器,达到了防范流量类攻击的目的,当然,这样做局域网会崩溃,同样要遭受损失,但是这样的损失总比整个互联网无法解析来的强!而且我们可以通过设定安全规则来减少这样的损失,而如何减小这个损失则交给整个体系的核心:DNS报文转发协议来完成。
三:DNS报文转发协议
作为整个体系的核心,该协议将承担绝大部分的工作,包括报文的转发,安全控制等等,下面就来介绍该协议要完成的工作:
首先呢,最重要的无疑是给整个体系构建一个基础运行环境,该体系要求的环境是高速,那么,就要求协议能够给出高速的路径,所以协议需要对所有能连接的路径做测试,记录测试结果,以便于报文的转发,其条件如下:对每条路径进行测试,并记录信息交互速度,单位是MS,不足一毫秒的记录为0MS,超过5毫秒的不记录,然后将所有的记录建立表,该查询过程60秒进行一次。
接下来是建立禁止通行列表,该表中记录的是被禁止通行的报文中地区邮政编码,作用是阻止来至某一区域的流量攻击,该表60分钟刷新一次。
然后建立局域网解析成功列表,该表仅记录局域网解析成功的域名,10秒钟刷新一次;
完成的基础工作,接下来是对报文进行检测,以保证只通过正常的报文,具体规则如下:第一项检测:检查报文中的地区邮政编码,判断是否在阻止列表,是则丢弃报文,否则进行下一项检测;第二项检测:检查报文是否符合报文规则,是进行下一项检测,否则丢弃;第三项检测:检测报文类别,根据类别处理报文:如果是服务器回传报文,检测标记位中服务器查询结果,如果标记位为服务器解析成功,该报文中对应的地区邮政编码解析成功次数加1,转发报文;如果是局域网回传报文,检测成功记录中是否有该地址的解析成功记录,如果有,则转发,如果没有,记录并转发;如果标记位为请求报文,则转入下一项检测;第四项检测:该报文中地区邮政编码的解析请求次数加1,判断是否为局域网请求报文,是转入第六项检测;否则为服务器请求报文,该报文中地区邮政编码的解析请求次数加1,转发报文并进行第五项检测;第五项检测:检查所有的地区邮政编码的请求总次数与成功次数比,如果超过1/5,将该邮政编码加入阻止列表,并清空该邮政编码的统计数据。第六项检测:检测报文中的步进数是否小于或等于4和时间是否小于等于5,是的话根据时间选择路径转发,具体要求为协议记录的路径的信息交互的时间加上该报文中的时间,如果小于5则转发到该路径,如果大于5则不转发。(注:路径是指网关与网关之间,网关下属的客户端属于必须转发,所以不计算在内)。
四:几条条特殊命令
这是几条条特殊的命令,是为特殊情况设计的,为的是弥补本方案某些情况下的不足之处,一条是在客户端用的,作用是调整客户端对局域网解析错误的容差,具体命令为:DNS mode -参数(s、h)其中参数s代表高可靠模式,为的就是解决局域网用户提供的错误地址但该用户确是响应最快的情况,具体工作原理为:启用高可靠模式后,经局域网解析到的地址不再是接收即用,而是等到局域网解析时间到后统计由局域网用户回传的解析结果,选取被解析次数超过4次并且被解析次数最多的地址作为解析结果,如果不足4个或者超过4个的最高被解析次数不少于2个地址,则向最少5个且个数为单数的DNS服务器发出解析请求,选取由服务器发回的结果中不少于3个的最高次数的地址作为解析结果,如果由服务器发回的结果均少于3个,那么选取发回结果最快的地址作为解析地址。当局域网解析失败时,该模式下同时向3个服务器发出解析请求,选取解析地址次数最高的那个地址作为解析结果,如果3个服务器返回结果不一样,则选取响应速度最快的那个地址作为解析结果。(注:在该模式下,如果连续3次同一域名的解析结果相同,该地址将转向缓存,以后该地址的解析将直接读取缓存的结果,不再向局域网和服务器发出解析请求);参数h代表为高速度模式,在该模式下,无论是局域网解析还是服务器解析,均只选取响应速度最快的那个地址作为解析结果(即有结果就使用,不再判断是否正确,类似于UDP协议的只管发送不管是否接收到一样),同时,只要解析成功,该结果就写入缓存中。
一条命令是在服务端使用的,该命令具体由有关部门决定。该命令的使用环境为:在全部的DNS服务器因为战争、地质灾害、政治问题等因素而无法提供服务的情况下,通过新的服务器发出这条命令,汇总所有的位于客户端的缓存,以重建DNS服务器。
还有一条命令同样是在服务端使用,该命令具体由有关部门决定。该命令具体使用环境为特殊时期,具体使用哪个参数由有关部门决定,其中参数分为紧急信息管制参数和战争信息管制参数;紧急信息管制参数使用后所有能接到该命令的DNS客户端将屏蔽现有DNS服务器设置,关闭局域网解析通道,清空缓存,统一使用由该命令设定的DNS服务器,有效时间为24小时,且一个更新周期内只能使用一次(一个周期一般为7天);战争管制参数使用后所有能接到该命令的DNS客户端强制性设定DNS服务器为命令设定的服务器,关闭局域网解析通道,清空缓存;无有效期限制,直至服务端发出解除战争管制模式命令为止。(注:以上所有由服务端发出的命令均只能由预设的地址发出,且命令发出后需经过客户端128次有效性校验并且128次校验均成功后才能生效)
五:DNS客户端安全协议
作为运行在客户机上的客户端,是阻止流量类攻击的第一道屏障,也是上文几条特殊命令的直接执行者,所以其任务繁重,具体要实现的功能如下:
1. 提供基本的DNS解析服务,该功能与现有的DNS客户端没有较大的差别,只是多了一个接收局域网查询请求并返回查询结果。
2. 按内建模型监控客户机DNS解析请求,一旦短时间内请求次数超过模型计算出的临界次数,将向网关报告,由网关判断是否拉入禁止列表。原始监控模型为3T+1模型,具体为由客户端统计该客户端下的PC每天的请求次数,算出每个统计周期的平均值,然后计算三天来所有周期的平均值,该值就是T,而1则是3天内所有周期中请求次数最高的那个周期的值,所以,3T+1这个临界值就是三天来每个周期的平均值的三倍加上三天来最高请求次数的一个周期的次数。(我不知道这个模型是否合适,但我只能给出这样一个模型,更好的模型可以由厂商开发,在模型方面不做任何限制)
3.统计功能,实际上该功能时为了配合网关而设计的,目的是统计用户的请求次数,为模型分析提供原始数据(这里可玩的花样有很多,仅作提示,具体可由厂商设计)
4.自我完整性检查,可以说设计这个完全是迫不得已,为的就是防止客户端被修改,以便客户端能正常实现设计的功能,因为无论是统计功能也好,还是特殊命令的执行也好,均依赖于客户端,所以必须保证客户端的完整性,而且需要做到自我修复。
六:服务端用报文转换协议
对于这个协议,可以说是为了减轻损失而设计的,毕竟,对客户端进行改造只需要发布一次系统跟新,但是对服务器进行改造却非常麻烦,所以有了这个协议,这个协议运行于网络与服务器之间,类似于防火墙,作用是将新的客户端传来的报文砍掉新增的部分,使得其报文变成原来没有修改时的报文,便于服务器处理,当然,被砍掉的这部分是不会被丢弃的,因为我们需要给出一个结果:当服务器成功解析时,协议就会将被砍部分中的标记位中代表服务器解析成功的位置1,将代表服务器回传的位置1.然后附加在服务器返回的报文上,便于DNS报文转发协议的统计和处理。
七:请求报文与回传报文结构上的区别
精简报文是非常有必要的精简局域网报文能够减少资源的消耗,提高效率,也便于网关的判断,但由于本人学识有限,无法提出最优化的精简方案,故在本方案中默认不精简,具体的优化方案将交由厂商决定。但有一点需要强调的是,本方案中对报文新增的部分不能精简,因为这一部分除了为网关提供判断依据外,还关系到下一阶段对服务端体系的修改,故不能改动本方案中DNS报文新增的部分。
Claims (3)
1.基于行为差异性的DNS高速解析方案和配套的抗流量类攻击安全方案由 基于局域网快速信息交互的高速域名解析方案和配套的抗流量类攻击安全方案组成,其特征为 基于局域网快速信息交互的高速域名解析方案负责包含局域网解析在内的解析工作,配套的抗流量类攻击安全方案负责解决对基于局域网快速信息交互的高速域名解析方案造成的潜在的网络安全问题特别是流量类攻击问题。
2.根据权利要求1所述的基于局域网快速信息交互的高速域名解析方案,其特征是客户端利用了微服务器思想,使得客户端具有了一定的服务能力;DNS解析过程由原来的客户端-服务端模式更改为客户端-局域网-服务端模式;根据信息交互的速度重新定义了局域网并改名为时域网;更改缓存生命周期,缓存也具有时效性;在现有DNS报文的末尾追加国家或地区代码、地区邮政编码(取4个有效位)、步进次数、使用时间、解析结果标记5个字段以及高可靠模式和高速度模式这两种运行模式。
3.根据权利要求1所述的配套的抗流量类攻击安全方案,其特征是运行于网关的DNS报文转发协议,内建的3T+1监控模型。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410066376.2A CN103905581A (zh) | 2014-02-26 | 2014-02-26 | 基于行为差异性的dns高速解析方案和配套的抗流量类攻击安全方案 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410066376.2A CN103905581A (zh) | 2014-02-26 | 2014-02-26 | 基于行为差异性的dns高速解析方案和配套的抗流量类攻击安全方案 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN103905581A true CN103905581A (zh) | 2014-07-02 |
Family
ID=50996735
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201410066376.2A Pending CN103905581A (zh) | 2014-02-26 | 2014-02-26 | 基于行为差异性的dns高速解析方案和配套的抗流量类攻击安全方案 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN103905581A (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116132154A (zh) * | 2023-02-03 | 2023-05-16 | 北京六方云信息技术有限公司 | Dns隧道流量检测系统的验证方法、装置、设备及存储介质 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1207704A2 (en) * | 1996-02-20 | 2002-05-22 | Hewlett-Packard Company | Accessing a telephone number |
CN1564539A (zh) * | 2004-03-31 | 2005-01-12 | 中国科学院计算技术研究所 | 一种移动自组织网络中域名系统的实现方法 |
CN101350814A (zh) * | 2008-08-26 | 2009-01-21 | 成都卫士通信息产业股份有限公司 | 一种安全远程接入技术及其网关 |
CN101483648A (zh) * | 2009-02-20 | 2009-07-15 | 杭州华三通信技术有限公司 | Dns缓存探测的方法、系统、装置和dns服务器 |
CN101674268A (zh) * | 2009-09-25 | 2010-03-17 | 中兴通讯股份有限公司 | 接入因特网控制装置及其方法、网关 |
CN101815105A (zh) * | 2010-03-25 | 2010-08-25 | 上海交通大学 | 带智能缓存的域名解析服务系统及其服务方法 |
-
2014
- 2014-02-26 CN CN201410066376.2A patent/CN103905581A/zh active Pending
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1207704A2 (en) * | 1996-02-20 | 2002-05-22 | Hewlett-Packard Company | Accessing a telephone number |
CN1564539A (zh) * | 2004-03-31 | 2005-01-12 | 中国科学院计算技术研究所 | 一种移动自组织网络中域名系统的实现方法 |
CN101350814A (zh) * | 2008-08-26 | 2009-01-21 | 成都卫士通信息产业股份有限公司 | 一种安全远程接入技术及其网关 |
CN101483648A (zh) * | 2009-02-20 | 2009-07-15 | 杭州华三通信技术有限公司 | Dns缓存探测的方法、系统、装置和dns服务器 |
CN101674268A (zh) * | 2009-09-25 | 2010-03-17 | 中兴通讯股份有限公司 | 接入因特网控制装置及其方法、网关 |
CN101815105A (zh) * | 2010-03-25 | 2010-08-25 | 上海交通大学 | 带智能缓存的域名解析服务系统及其服务方法 |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116132154A (zh) * | 2023-02-03 | 2023-05-16 | 北京六方云信息技术有限公司 | Dns隧道流量检测系统的验证方法、装置、设备及存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10320628B2 (en) | Confidence scoring of device reputation based on characteristic network behavior | |
CN105681133B (zh) | 一种检测dns服务器是否防网络攻击的方法 | |
Xu et al. | DNS for massive-scale command and control | |
US9124621B2 (en) | Security alert prioritization | |
Zhou et al. | Exploiting the Vulnerability of Flow Table Overflow in Software‐Defined Network: Attack Model, Evaluation, and Defense | |
CN105577496B (zh) | 一种家庭网关利用云平台识别接入设备类型的系统 | |
US20130031626A1 (en) | Methods of detecting dns flooding attack according to characteristics of type of attack traffic | |
US20130042319A1 (en) | Method and apparatus for detecting and defending against cc attack | |
CN110324295B (zh) | 一种域名系统泛洪攻击的防御方法和装置 | |
CN103581363A (zh) | 对恶意域名和非法访问的控制方法及装置 | |
CN108259425A (zh) | 攻击请求的确定方法、装置及服务器 | |
CN101789940A (zh) | 一种防范dns请求报文洪泛攻击的方法及装置 | |
CN101478387A (zh) | 超文本传输协议攻击防御方法、装置和系统 | |
CN104468554A (zh) | 基于ip和host的攻击检测方法和装置 | |
CN103139138A (zh) | 一种基于客户端检测的应用层拒绝服务防护方法及系统 | |
US20110173318A1 (en) | Method, Device and Gateway Server for Detecting Proxy at the Gateway | |
CN109561111A (zh) | 一种攻击源的确定方法及装置 | |
CN103995901B (zh) | 一种确定数据节点失效的方法 | |
Novotny et al. | On-demand discovery of software service dependencies in MANETs | |
CN102223422A (zh) | 一种dns报文处理方法及网络安全设备 | |
CN102413197A (zh) | 访问统计处理方法及装置 | |
CN111786990B (zh) | 一种针对web主动推送跳转页面的防御方法和系统 | |
CN103905581A (zh) | 基于行为差异性的dns高速解析方案和配套的抗流量类攻击安全方案 | |
CN109120579A (zh) | 恶意域名的检测方法、装置及计算机可读存储介质 | |
CN115190107B (zh) | 基于泛域名多子系统管理方法、管理终端及可读存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20140702 |
|
WD01 | Invention patent application deemed withdrawn after publication |