CN103747005B - Dns缓存投毒的防护方法和设备 - Google Patents
Dns缓存投毒的防护方法和设备 Download PDFInfo
- Publication number
- CN103747005B CN103747005B CN201410022832.3A CN201410022832A CN103747005B CN 103747005 B CN103747005 B CN 103747005B CN 201410022832 A CN201410022832 A CN 201410022832A CN 103747005 B CN103747005 B CN 103747005B
- Authority
- CN
- China
- Prior art keywords
- dns
- response message
- fire walls
- domain name
- server
- 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
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种DNS缓存投毒的防护方法和设备。该DNS缓存投毒的防护方法包括:域名服务DNS防火墙接收客户端发送的域名查询请求;DNS防火墙检测DNS防火墙中与域名查询请求相对应的缓存记录是否被标记过,其中,DNS防火墙设置在DNS缓存服务器和DNS服务器之间;以及如果DNS防火墙检测出DNS防火墙中与域名查询请求相对应的缓存记录被标记过,则DNS防火墙控制DNS缓存服务器与DNS服务器采用TCP连接方式进行交互。通过本发明,解决了相关技术中难以基于现有的通信协议及DNS协议,保证DNS缓存不被投毒的问题。
Description
技术领域
本发明涉及通信领域,具体而言,涉及一种DNS缓存投毒的防护方法和设备。
背景技术
域名系统(Domain Name System,简称DNS)缓存投毒是利用DNS协议对源的不可验证的特点,由攻击者伪装成某台DNS权威服务器,采用欺骗的手段,诱骗DNS Cache服务器或DNS转发器接收攻击者提供的恶意内容,并把恶意内容更新入DNS Cache服务器或DNS转发器的本地Cache,其本质是利用了通信的不可靠性进行的欺骗。这里有网络层、传输层协议的问题,也有DNS应用协议的问题。
典型的DNS缓存投毒攻击的基本过程如下:
1,假设攻击者的攻击目标是yyyyy.com这个域,且负责yyyyy.com的真正的权威服务器是A,攻击者期望在DNS Cache服务器B上进行缓存投毒。
2,攻击者会发送一个随机的、不存在的yyyyy.com下的域名(如xyz.yyyyy.com)到服务器B。
3,由于xyz.yyyyy.com并不存在,所以B不可能有其缓存记录。正常情况下,B会经过一系列迭代查询,最终会向A查询xyz.yyyyy.com的权威记录。在这里,由于xyz.yyyyy.com并不真实存在,所以A会向B发送一个NXDOMAIN的错误,并且A会把yyyyy.com的ns记录发送给B——这个过程通常是使用用户数据包协议(User Datagram Protocol,简称UDP)完成的。
4,利用UDP对源的不可验证的特性,攻击者通过源IP的伪造,把自己伪装成A,同时向B发送一个DNS应答报文,恶意应答报文把yyyyy.com的权威NS记录对应的IP地址篡改为攻击者自己的恶意IP地址C(通常,缓存投毒会使用一个超长的DNS生存时间(Time ToLive,简称TTL),以防止B上的DNS缓存会很快失效)。攻击者在恶意IP地址上会开启一个DNS服务,用来代替A对yyyyy.com域名下主机名的解析。
5,如果攻击者的恶意报文先于A的应答到达B(攻击者甚至有可能通过DDoS的手段,瘫痪A,使得A不能进行正常应答),那么B就有可能使用错误的NS记录更新自己的Cache。
6,后续用户通过B进行yyyyy.com的主机名解析时,B就不会使用A而是使用攻击者搭建的C服务器进行解析,得到的所有的yyyyy.com下的主机名对应的IP地址,就都是受攻击者操控的恶意IP地址。
攻击者进而可以达到种植木马、窃取口令、钓鱼或其他政治目的。
目前,在相关技术中,一般采用以下方案来防止DNS缓存投毒:
方案一,在A和B之间采用IPSec隧道进行加密传输。这种方案虽然可以解决源地址欺骗的问题,但是这种方案需要B与所有的权威服务器都建立IPSec隧道(实际上权威服务器两两之间也要建立隧道)。这样,整个DNS系统会构成一个IPSec的完全图,即两两之间都需要IPSec的隧道进行通讯。抛开成本高不说,每新加一台DNS服务器,就需要进行全网的修改,这与DNS协议的设计初衷是根本违背的。因此这种方案虽然具有很高的安全性,但是是高成本且不可维护。
方案二,采用在IPv6中内置IPSec的机制。这种方案虽然可以让所有的DNS服务器之间的通信都是用IPv6协议(客户端和服务器之间的通讯可以仍然采用IPv4),以保证通讯的可靠性,但是其需要IPv6网络。而IPv6网络需要长期建设,当下并不现实。
方案三,采用DNS Tsig和TKey扩展的方案。Tsig和TKey是DNS基础协议的两个标准扩展,它们通过DNS服务器两两之间共享秘密,借助数字签名、验签的机制,保证两两之间的通讯的完整性。攻击者由于不能了解共享的秘密,故而无法伪造权威服务器A发出的正确的应答报文,所以可以避免缓存投毒。但是这种方案与IPSec方案一样,会导致任意一台DNS服务器都需要维护所有其他DNS服务器的Key,因此也是高成本和不可维护的。
方案四,采用DNSSec扩展的方案。DNSSec扩展与Tsig、TKey扩展类似,都是通过数字签名的方式,保证应答报文的完整性。但是DNSSec不使用共享密钥,而是采用公开密钥算法进行加密传输。但是该方案对签名的验证,没有采用统一的、集中的验证基础设施,而是利用DNS协议本身的特点,向自己的直接上级进行验证。而上级也是无法验证的,只能再向上级的上级验证。这样,最终的过程实际是由顶级域服务器层层向下进行验证,如果DNS层次链条中任何一个环节没有部署DNSSec,都会使得验证中断,从而导致通信的不可靠。这种方案需要将所有的DNS服务器同时升级到DNSSec,工作量巨大。
针对相关技术中难以基于现有的通信协议及DNS协议,保证DNS缓存不被投毒的问题,目前尚未提出有效的解决方案。
发明内容
本发明的主要目的在于提供一种DNS缓存投毒的防护方法和设备,以解决相关技术中难以基于现有的通信协议及DNS协议,保证DNS缓存不被投毒的问题。
为了实现上述目的,根据本发明的一个方面,提供了一种DNS缓存投毒的防护方法。该方法包括:域名服务DNS防火墙接收客户端发送的域名查询请求;DNS防火墙检测DNS防火墙中与域名查询请求相对应的缓存记录是否被标记过,其中,DNS防火墙设置在DNS缓存服务器和DNS服务器之间;以及如果DNS防火墙检测出DNS防火墙中与域名查询请求相对应的缓存记录被标记过,则DNS防火墙控制DNS缓存服务器与DNS服务器采用TCP连接方式进行交互。
进一步地,DNS防火墙控制DNS缓存服务器与DNS服务器采用TCP连接方式进行交互之后,防护方法还包括:DNS防火墙接收DNS服务器发送的应答报文;DNS防火墙用接收到的DNS服务器发送的应答报文替换被标记过的缓存记录,将接收到的DNS服务器发送的应答报文作为更新后的缓存记录,其中,在将接收到的DNS服务器发送的应答报文作为更新后的缓存记录之后,防护方法还包括:当DNS防火墙再次接收到客户端发送的域名查询请求时,DNS防火墙发送应答报文至客户端;和/或DNS防火墙将应答报文转发给DNS缓存服务器,并且DNS缓存服务器在DNS缓存服务器中存储接收到的DNS服务器转发的应答报文。
进一步地,DNS防火墙控制DNS缓存服务器与DNS服务器采用TCP连接方式进行交互之后,防护方法还包括:DNS防火墙检测应答报文是否是通过TCP连接方式发送的应答报文;以及如果DNS防火墙检测出应答报文不是通过TCP连接方式发送的应答报文,则DNS防火墙拒绝接收应答报文。
进一步地,在DNS防火墙检测应答报文是否是通过TCP连接方式发送的应答报文之后,防护方法还包括:如果DNS防火墙检测出应答报文是通过TCP连接方式发送的应答报文,则DNS防火墙接收应答报文;DNS防火墙判断应答报文的序列号是否是签名验签序列号;以及如果DNS防火墙判断出应答报文的序列号不是签名验签序列号,则DNS防火墙丢弃接收到的应答报文。
进一步地,在DNS防火墙检测DNS防火墙中与域名查询请求相对应的缓存记录是否被标记过之前,防护方法还包括:DNS防火墙检测DNS防火墙中是否有与域名查询请求相对应的缓存记录;如果DNS防火墙检测出DNS防火墙中没有与域名查询请求相对应的缓存记录,则DNS防火墙检测接收到的与域名查询请求相对应的应答报文的个数是否大于1;如果DNS防火墙检测出接收到的与域名查询请求相对应的应答报文的个数大于1,则DNS防火墙存储接收到的与域名查询请求相对应的应答报文所提供的DNS资源记录;以及DNS防火墙对DNS资源记录进行标记。
进一步地,在DNS防火墙对DNS资源记录进行标记之后,防护方法还包括:DNS防火墙将接收到的与域名查询请求相对应的应答报文所提供的DNS资源记录的生存时间TTL修改为0,得到修改后的应答报文;以及将修改后的应答报文转发给DNS缓存服务器。
为了实现上述目的,根据本发明的另一方面,提供了一种DNS缓存投毒的防护设备。该设备包括:第一接收单元,用于使得域名服务DNS防火墙接收客户端发送的域名查询请求;第一检测单元,用于使得DNS防火墙检测DNS防火墙中与域名查询请求相对应的缓存记录是否被标记过,其中,DNS防火墙设置在DNS缓存服务器和DNS服务器之间;以及控制单元,用于使得如果DNS防火墙检测出DNS防火墙中与域名查询请求相对应的缓存记录被标记过,则DNS防火墙控制DNS缓存服务器与DNS服务器采用TCP连接方式进行交互。
进一步地,该防护设备还包括:第二接收单元,用于使得在DNS防火墙控制DNS缓存服务器与DNS服务器采用TCP连接方式进行交互之后,DNS防火墙接收DNS服务器发送的应答报文;替换单元,用于使得DNS防火墙用接收到的DNS服务器发送的应答报文替换被标记过的缓存记录,将接收到的DNS服务器发送的应答报文作为更新后的缓存记录,其中,在将接收到的DNS服务器发送的应答报文作为更新后的缓存记录之后,防护设备还包括:发送单元,用于使得当DNS防火墙再次接收到客户端发送的域名查询请求时,DNS防火墙发送应答报文至客户端;和/或第一转发单元,用于使得DNS防火墙将应答报文转发给DNS缓存服务器,并且DNS缓存服务器在DNS缓存服务器中存储接收到的DNS服务器转发的应答报文。
进一步地,该防护设备还包括:第二检测单元,用于使得在DNS防火墙控制DNS缓存服务器与DNS服务器采用TCP连接方式进行交互之后,DNS防火墙检测应答报文是否是通过TCP连接方式发送的应答报文;以及拒绝单元,用于使得如果DNS防火墙检测出应答报文不是通过TCP连接方式发送的应答报文,则DNS防火墙拒绝接收应答报文。
进一步地,该防护设备还包括:第三接收单元,用于使得在DNS防火墙检测应答报文是否是通过TCP连接方式发送的应答报文之后,如果DNS防火墙检测出应答报文是通过TCP连接方式发送的应答报文,则DNS防火墙接收应答报文;判断单元,用于使得DNS防火墙判断应答报文的序列号是否是签名验签序列号;以及丢弃单元,用于使得如果DNS防火墙判断出应答报文的序列号不是签名验签序列号,则DNS防火墙丢弃接收到的应答报文。
进一步地,该防护设备还包括:第三检测单元,用于使得在DNS防火墙检测DNS防火墙中与域名查询请求相对应的缓存记录是否被标记过之前,DNS防火墙检测DNS防火墙中是否有与域名查询请求相对应的缓存记录;第四检测单元,用于使得如果DNS防火墙检测出DNS防火墙中没有与域名查询请求相对应的缓存记录,则DNS防火墙检测接收到的与域名查询请求相对应的应答报文的个数是否大于1;存储单元,用于使得如果DNS防火墙检测出接收到的与域名查询请求相对应的应答报文的个数大于1,则DNS防火墙存储接收到的与域名查询请求相对应的应答报文所提供的DNS资源记录;以及标记单元,用于使得DNS防火墙对DNS资源记录进行标记。
进一步地,该防护设备还包括:修改单元,用于使得在DNS防火墙对DNS资源记录进行标记之后,DNS防火墙将接收到的与域名查询请求相对应的应答报文所提供的DNS资源记录的生存时间TTL修改为0,得到修改后的应答报文;以及第二转发单元,用于使得将修改后的应答报文转发给DNS缓存服务器。
通过本发明,采用域名服务DNS防火墙接收客户端发送的域名查询请求;DNS防火墙检测DNS防火墙中与域名查询请求相对应的缓存记录是否被标记过,其中,DNS防火墙设置在DNS缓存服务器和DNS服务器之间;以及如果DNS防火墙检测出DNS防火墙中与域名查询请求相对应的缓存记录被标记过,则DNS防火墙控制DNS缓存服务器与DNS服务器采用TCP连接方式进行交互,解决了相关技术中难以基于现有的通信协议及DNS协议,保证DNS缓存不被投毒的问题,进而达到了防止攻击者缓存投毒的效果。
附图说明
构成本申请的一部分的附图用来提供对本发明的进一步理解,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:
图1是根据相关技术的客户端查询域名请求的过程的示意图;
图2是根据本发明第一实施例的DNS缓存投毒的防护设备的示意图;
图3是根据本发明实施例的客户端、DNS防火墙和DNS缓存服务器交互的示意图;
图4是根据本发明实施例的DNS缓存服务器、DNS防火墙和DNS服务器交互的示意图;
图5是根据本发明第二实施例的DNS缓存投毒的防护设备的示意图;
图6是根据本发明第三实施例的DNS缓存投毒的防护设备的示意图;
图7是根据本发明第一实施例的DNS缓存投毒的防护方法的流程图;
图8是根据本发明第二实施例的DNS缓存投毒的防护方法的流程图;以及
图9是根据本发明第三实施例的DNS缓存投毒的防护方法的流程图。
具体实施方式
需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本发明。
为了使本领域的技术人员更好的理解本发明方案,下面将结合本发明实施例中的附图,对本发明实施例中的进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分的实施例,而不是全部的实施例。基于本发明中的实施例,在本领域普通技术人员没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本发明的保护范围。
需要说明的是,本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含。
根据本发明的实施例,提供了一种方法的流程图设备,该方法的流程图设备用于防止攻击者对DNS缓存服务器进行缓存投毒。
图2是根据本发明第一实施例的DNS缓存投毒的防护设备的示意图。
如图2所示,该设备包括:第一接收单元10、第一检测单元20和控制单元30。
第一接收单元10用于使得域名服务DNS防火墙接收客户端发送的域名查询请求。
域名服务DNS防火墙设置有存储单元,该存储单元用于存储域名查询请求对应的缓存记录。正常情况下,在域名服务DNS防火墙接收客户端发送的域名查询请求之后,DNS防火墙可以通过以下方式向客户端发送与域名查询请求相对应的应答报文:
方式一,DNS防火墙可以根据客户端发送的域名查询请求,查询DNS防火墙中的存储单元以确定是否有与该域名对应的缓存记录。如果存储单元中确定有与该域名对应的缓存记录,则DNS防火墙可以根据该缓存记录向客户端发送应答报文。这样,可以使得客户端就近查询域名对应的相关信息,提高查询效率,并且可以减轻DNS缓存服务器和DNS服务器的负担。
方式二,在方式一的基础上,如果存储单元中确定没有与该域名对应的缓存记录,则DNS防火墙可以将客户端发送的域名查询请求转发给DNS缓存服务器。DNS缓存服务器在接收到DNS防火墙转发的域名查询请求之后,可以根据该域名查询请求查询DNS缓存服务器中的存储单元以确定是否有与该域名对应的缓存记录。如果DNS缓存服务器的存储单元中确定有与该域名对应的缓存记录,则DNS缓存服务器可以根据该缓存记录向DNS防火墙发送应答报文,DNS防火墙在接收到DNS缓存服务器发送的应答报文之后,可以将该应答报文原封不动地转发给客户端。如图3所示。这样,可以使得客户端就近查询域名对应的相关信息,提高查询效率,并且可以减轻DNS服务器的负担。
方式三,在方式二的基础上,如果DNS缓存服务器的存储单元中确定没有与该域名对应的缓存记录,则DNS缓存服务器可以基于该域名查询请求向其他各级服务器发起查询请求。为了方便起见,本发明以向DNS服务器发起域名查询请求为例进行阐述,需要说明的是,这并不给本发明造成不当限定。在DNS缓存服务器基于该域名查询请求向DNS服务器发起查询请求之后,DNS防火墙首先接收该域名查询请求,并根据域名查询请求查询自身的存储单元以确定存储单元中是否有与域名查询请求相对应的缓存记录。如果DNS防火墙的存储单元中没有与域名查询请求相对应的缓存记录,则DNS防火墙将该域名查询请求转发给DNS服务器。DNS服务器在接收到该域名查询请求之后,可以根据该域名查询请求向DNS缓存服务器发送应答报文,此时,DNS防火墙在DNS缓存服务器接收应答报文之前,可以首先拦截该应答报文,并将该应答报文提供的DNS资源记录及其与域名的对应关系学习(存储)到自身的存储单元中。然后,DNS防火墙将拦截到的该应答报文原封不动的转发给DNS缓存服务器,此时,DNS缓存服务器可以将该应答报文提供的DNS资源记录及其与域名的对应关系学习(存储)到自身的存储单元中,并将该应答报文发送给客户端。其中,DNS防火墙、DNS缓存服务器和DNS服务器的交互方式。如图4所示。这样,应答报文可以在DNS缓存服务器和DNS防火墙中进行双重备份,当同一域名查询请求再次被发起时,可以对其进行就近报文应答,提高查询效率,并且可以减轻DNS服务器的负担。
需要说明的是,客户端可以包括一个或者多个,DNS缓存服务器也可以包括一个或者多个。同一域名查询请求可以是同一客户端在不同的时间发起的,也可以是不同的客户端在不同的时间发起的。针对同一域名查询请求,可以有一个或多个应答方给出应答报文。另外,DNS服务器(权威服务器),是指运营商提供的域名的真正被托管的服务器。上述的客户端与DNS防火墙、DNS缓存服务器、DNS服务器之间的交互方式均为用户数据包协议(UserDatagram Protocol,简称UDP)交互方式。UDP交互方式为非连接的交互方式,其向对方发送应答报文时,不需要经过对方的同意,即不需要与对方“握手”,并且该UDP交互方式不需要签名验签。另外,UDP交互方式不能验证应答报文的来源。这样,通过UDP交互方式可以对域名请求进行快速应答,进而可以提高DNS防火墙或者DNS缓存服务器或者DNS服务器对客户端的域名查询请求的应答效率。
第一检测单元20用于使得DNS防火墙检测DNS防火墙中与域名查询请求相对应的缓存记录是否被标记过。
DNS防火墙设置在DNS缓存服务器和DNS服务器之间,在DNS缓存服务器和DNS服务器进行交互时,DNS防火墙作为桥梁,起到“安检”、“监督”和“控制”的作用。
需要说明的是,被标记的缓存记录安全指数较低,并且其来源不明,即被标记的缓存记录为“可疑记录”。这是由于客户端发送了一个域名查询请求,但是DNS防火墙拦截到了多个针对该域名查询请求的应答报文,又由于该应答报文为通过UDP交互方式发送的,其来源具有不可验证性,因此,DNS防火墙在拦截到了多个针对该域名查询请求的应答报文时,其可以对该应答报文提供的DNS资源记录进行标记(如对可疑的应答报文进行着色),以将其与正常的应答报文进行区别。这样,如果基于客户端的域名查询请求,并且DNS防火墙查询到该被标记的缓存记录时,DNS防火墙可以控制DNS缓存服务器与DNS服务器的交互方式以防止攻击者对DNS缓存服务器进行投毒(如种植木马、窃取口令、钓鱼或其他政治目的等)。
控制单元30用于使得DNS防火墙控制DNS缓存服务器与DNS服务器采用TCP连接方式进行交互。
如果DNS防火墙检测出DNS防火墙中与域名查询请求相对应的缓存记录被标记过,则DNS防火墙控制DNS缓存服务器与DNS服务器采用TCP连接方式进行交互。
具体地,如果DNS防火墙检测出DNS防火墙中与域名查询请求相对应的缓存记录被标记过,DNS防火墙不对客户端的域名查询请求进行报文应答,而是将域名查询请求转发给DNS缓存服务器。DNS缓存服务器在接收到该域名查询请求之后,向DNS服务器发起查询请求时。DNS防火墙在DNS服务器接收域名查询请求之前可以首先拦截该域名查询请求,并再次查询自身的缓存记录,如果再次确定与该域名查询请求相对应的缓存记录已经被标记过,则DNS防火墙可以不将该域名查询请求转发给DNS服务器,而是将代替DNS服务器向DNS缓存服务器发送一个带传输控制(Transmisson Control,简称TC)置位的应答报文。该带TC置位的应答报文用于强制DNS缓存服务器采用TCP连接方式进行域名查询请求。
通过本发明实施例,DNS防火墙可以检测其与域名查询请求相对应的缓存记录是否被标记,并且在检测到其与域名查询请求相对应的缓存记录被标记时,控制DNS缓存服务器与DNS服务器采用TCP连接方式进行交互。由于TCP连接方式具有“握手”机制,并且可以通过生成的随机序列号进行签名验签,因此,当攻击者针对客户端发送的域名查询请求向DNS缓存服务器投毒,即当攻击者针对客户端发送的域名查询请求向DNS缓存服务器发送非法的应答报文时,DNS防火墙可以根据攻击者使用的通讯交互方式执行相应的防护命令。例如,当应答报文为通过UDP交互方式发送的应答时,DNS防火墙可以拒绝接收;当应答报文为通过TCP交互方式发送的应答报文,但是经过签名验签发现其序列号为非法序列号(即签名验签不通过),这时,DNS防火墙可以在接收到应答报文之后将其丢弃。
图5是根据本发明第二实施例的DNS缓存投毒的防护设备的示意图。
如图5所示,该实施例可以作为图2所示实施例的优选实施方式,该实施例的DNS缓存投毒的防护设备除了包括第一实施例的第一接收单元10、第一检测单元20和控制单元30之外,还包括第二接收单元40、替换单元50、发送单元60和第一转发单元70。
第一接收单元10、第一检测单元20和控制单元30的作用与第一实施例中的相同,在此不再赘述。
第二接收单元40用于使得在DNS防火墙控制DNS缓存服务器与DNS服务器采用TCP连接方式进行交互之后,DNS防火墙接收DNS服务器发送的应答报文。
此时,DNS防火墙接收到的DNS服务器发送的应答报文为DNS服务器通过TCP交互方式发送的,因此,该次通讯交互经过了“握手”,并且DNS服务器在发送应答报文的同时还发送了签名验签密码,该签名验签密码为DNS服务器和DNS缓存服务器之间约定的随机序列号。通过该约定的随机序列号,DNS缓存服务器可以认证应答报文的来源。
具体地,当DNS缓存服务器接收应答报文的同时,可以验证序列号是否为上述约定的随机序列号。如果验证序列号为上述约定的随机序列号,则认为应答报文来自DNS服务器;如果验证序列号不为上述约定的随机序列号,则认为应答报文为非法的应答报文。其中,DNS防火墙对来自DNS服务器的应答报文可以缓存,而对非法的应答报文可以丢弃。
替换单元50用于使得DNS防火墙用接收到的DNS服务器发送的应答报文替换被标记过的缓存记录,将接收到的DNS服务器发送的应答报文作为更新后的缓存记录。
具体地,DNS防火墙可以先将被标记过的缓存记录删除,再将接收到的DNS服务器发送的应答报文对应于查询的域名请求进行缓存。具体地,这里可以对应于查询的域名请求缓存DNS服务器发送的应答报文中的DNS资源记录。
这样,在客户端再次发送该域名查询请求时,DNS防火墙可以基于该更新后的缓存记录进行报文应答,实现了消除安全隐患的目的,达到了防止非法报文对DNS缓存服务器进行投毒的效果。
发送单元60用于使得当DNS防火墙再次接收到客户端发送的域名查询请求时,DNS防火墙发送应答报文至客户端。
需要说明的是,DNS防火墙再次接收到的域名查询请求可以是为一个或者多个客户端发送的同一域名查询请求,并且该域名查询请求与应答报文相对应。
第一转发单元70用于使得DNS防火墙将应答报文转发给DNS缓存服务器,并且DNS缓存服务器在DNS缓存服务器中存储接收到的DNS服务器转发的应答报文。
DNS防火墙将应答报文转发给DNS缓存服务器时不对应答报文进行任何修改,尤其不对应答报文的生存时间(time to live,简称TTL)进行任何修改,即DNS防火墙原封不动地转发DNS服务器发送的应答报文给DNS缓存服务器。
这样,DNS防火墙将应答报文转发给DNS缓存服务器,可以实现对应答报文双重备份的目的。
需要说明的是,在DNS防火墙用接收到的DNS服务器发送的应答报文替换被标记过的缓存记录,将接收到的DNS服务器发送的应答报文作为更新后的缓存记录之后,本发明实施例也可以仅仅包括发送单元60或者第一转发单元70。
图6是根据本发明第三实施例的DNS缓存投毒的防护设备的示意图。
如图6所示,该实施例可以作为图2所示实施例的优选实施方式,该实施例的DNS缓存投毒的防护设备除了包括第一实施例的第一接收单元10、第一检测单元20和控制单元30之外,还包括第二检测单元80和拒绝单元90。
第一接收单元10、第一检测单元20和控制单元30的作用与第一实施例中的相同,在此不再赘述。
第二检测单元80用于使得在DNS防火墙控制DNS缓存服务器与DNS服务器采用TCP连接方式进行交互之后,DNS防火墙检测应答报文是否是通过TCP连接方式发送的应答报文。
DNS防火墙检测应答报文是否是通过TCP连接方式发送的应答报文可以检测否是通过“握手”机制发送的应答报文。
具体地,DNS防火墙在发送域名查询请求之后,可以检测应答方(如DNS服务器、攻击者)是否发送应答报文的请求。如果检测应答方发送应答报文的请求(即“握手”),则DNS防火墙检测出应答报文是通过TCP连接方式发送的应答报文,并且DNS防火墙接收应答方发送的应答报文;如果检测应答方没有发送应答报文的请求,则DNS防火墙检测出应答报文不是通过TCP连接方式发送的应答报文,并且DNS防火墙拒绝应答方发送的应答报文。
拒绝单元90用于使得如果DNS防火墙检测出应答报文不是通过TCP连接方式发送的应答报文,则DNS防火墙拒绝接收应答报文。
这样,通过将可疑的应答报文,可以达到防止攻击者对缓存服务器投毒的效果。
进一步地,在本发明实施例中,在DNS防火墙检测应答报文是否是通过TCP连接方式发送的应答报文之后,该防护设备还可以包括:第三接收单元、判断单元和丢弃单元。
第三接收单元用于使得如果DNS防火墙检测出应答报文是通过TCP连接方式发送的应答报文,则DNS防火墙接收应答报文。
具体地,DNS防火墙在发送域名查询请求之后,可以检测应答方(如DNS服务器、攻击者)是否发送应答报文的请求。如果检测应答方发送应答报文的请求(即“握手”),则DNS防火墙检测出应答报文是通过TCP连接方式发送的应答报文,并且DNS防火墙接收应答方发送的应答报文。
判断单元用于使得DNS防火墙判断应答报文的序列号是否是签名验签序列号。
此时,DNS防火墙接收到的DNS服务器发送的应答报文为DNS服务器通过TCP交互方式发送的,因此,该次通讯交互经过了“握手”,并且DNS服务器在发送应答报文的同时还发送了签名验签密码(即签名验签序列号),该签名验签密码(即签名验签序列号)为DNS服务器和DNS缓存服务器之间约定的随机序列号。通过该约定的随机序列号,DNS缓存服务器可以认证应答报文的来源。
具体地,当DNS缓存服务器接收应答报文的同时,可以验证序列号是否为上述约定的随机序列号。如果验证序列号为上述约定的随机序列号,则认为应答报文来自DNS服务器。
丢弃单元用于使得如果DNS防火墙判断出应答报文的序列号不是签名验签序列号,则DNS防火墙丢弃接收到的应答报文。
如果验证序列号不为上述约定的随机序列号,则认为应答报文为非法的应答报文。其中,DNS防火墙对来自DNS服务器的应答报文可以缓存,而对非法的应答报文可以丢弃。
进一步地,在本发明实施例中,在DNS防火墙检测DNS防火墙中与域名查询请求相对应的缓存记录是否被标记过之前,该防护设备还可以包括:第三检测单元、第四检测单元、存储单元和标记单元。
第三检测单元用于使得DNS防火墙检测DNS防火墙中是否有与域名查询请求相对应的缓存记录。
第四检测单元用于使得如果DNS防火墙检测出DNS防火墙中没有与域名查询请求相对应的缓存记录,则DNS防火墙检测接收到的与域名查询请求相对应的应答报文的个数是否大于1。
存储单元用于使得如果DNS防火墙检测出接收到的与域名查询请求相对应的应答报文的个数大于1,则DNS防火墙存储接收到的与域名查询请求相对应的应答报文所提供的DNS资源记录。
优选地,如果DNS防火墙检测出接收到的与域名查询请求相对应的应答报文的个数大于1,DNS防火墙可以仅仅存储接收到的与域名查询请求相对应的一个应答报文所提供的DNS资源记录。这样,可以节约DNS防火墙的存储单元的存储空间,减轻DNS防火墙的负担。
进一步优选地,DNS防火墙可以仅仅存储最早接收到的与域名查询请求相对应的一个应答报文所提供的DNS资源记录。
标记单元用于使得DNS防火墙对DNS资源记录进行标记。
正常情况下,一个域名查询请求对应一个应答报文。一旦DNS防火墙接收到多个与同一域名查询请求相对应的应答报文,并且该应答报文均为基于UDP交互方式作出的,因此DNS防火墙将其列为可疑应答报文,并进行标记,如对应答报文提供的DNS资源记录进行着色等。
更进一步地,在本发明实施例中,在DNS防火墙对DNS资源记录进行标记之后,该防护设备还可以包括:修改单元和第二转发单元。
修改单元用于使得DNS防火墙将接收到的与域名查询请求相对应的应答报文所提供的DNS资源记录的生存时间TTL修改为0,得到修改后的应答报文。
第二转发单元用于使得将修改后的应答报文转发给DNS缓存服务器。
需要说明的是,在TTL等于0时,该TTL对应的DNS资源记录不能生存,即不能进行存储。这样,修改后的应答报文由于其TTL等于0,因此修改后的应答报文转发到DNS缓存服务器之后,DNS缓存服务器不对其进行存储。这样,由于可以的应答报文不能存储在DNS缓存服务器,因此实现了防止攻击者对DNS缓存服务器进行投毒的目的。
根据本发明的实施例,提供了一种DNS缓存投毒的防护方法,该DNS缓存投毒的防护方法用于防止攻击者对DNS缓存服务器进行缓存投毒。该DNS缓存投毒的防护方法可以运行在计算机处理设备上。需要说明的是,本发明实施例所提供的DNS缓存投毒的防护方法可以通过本发明实施例的DNS缓存投毒的防护设备来执行,本发明实施例的DNS缓存投毒的防护设备也可以用于执行本发明实施例的DNS缓存投毒的防护方法。
图7是根据本发明第一实施例的DNS缓存投毒的防护方法的流程图。
如图7所示,该方法包括如下的步骤S702至步骤S706:
步骤S702,域名服务DNS防火墙接收客户端发送的域名查询请求。
域名服务DNS防火墙设置有存储单元,该存储单元用于存储域名查询请求对应的缓存记录。正常情况下,在域名服务DNS防火墙接收客户端发送的域名查询请求之后,DNS防火墙可以通过以下方式向客户端发送与域名查询请求相对应的应答报文:
方式一,DNS防火墙可以根据客户端发送的域名查询请求,查询DNS防火墙中的存储单元以确定是否有与该域名对应的缓存记录。如果存储单元中确定有与该域名对应的缓存记录,则DNS防火墙可以根据该缓存记录向客户端发送应答报文。这样,可以使得客户端就近查询域名对应的相关信息,提高查询效率,并且可以减轻DNS缓存服务器和DNS服务器的负担。
方式二,在方式一的基础上,如果存储单元中确定没有与该域名对应的缓存记录,则DNS防火墙可以将客户端发送的域名查询请求转发给DNS缓存服务器。DNS缓存服务器在接收到DNS防火墙转发的域名查询请求之后,可以根据该域名查询请求查询DNS缓存服务器中的存储单元以确定是否有与该域名对应的缓存记录。如果DNS缓存服务器的存储单元中确定有与该域名对应的缓存记录,则DNS缓存服务器可以根据该缓存记录向DNS防火墙发送应答报文,DNS防火墙在接收到DNS缓存服务器发送的应答报文之后,可以将该应答报文原封不动地转发给客户端。如图3所示。这样,可以使得客户端就近查询域名对应的相关信息,提高查询效率,并且可以减轻DNS服务器的负担。
方式三,在方式二的基础上,如果DNS缓存服务器的存储单元中确定没有与该域名对应的缓存记录,则DNS缓存服务器可以基于该域名查询请求向其他各级服务器发起查询请求。为了方便起见,本发明以向DNS服务器发起域名查询请求为例进行阐述,需要说明的是,这并不给本发明造成不当限定。在DNS缓存服务器基于该域名查询请求向DNS服务器发起查询请求之后,DNS防火墙首先接收该域名查询请求,并根据域名查询请求查询自身的存储单元以确定存储单元中是否有与域名查询请求相对应的缓存记录。如果DNS防火墙的存储单元中没有与域名查询请求相对应的缓存记录,则DNS防火墙将该域名查询请求转发给DNS服务器。DNS服务器在接收到该域名查询请求之后,可以根据该域名查询请求向DNS缓存服务器发送应答报文,此时,DNS防火墙在DNS缓存服务器接收应答报文之前,可以首先拦截该应答报文,并将该应答报文提供的DNS资源记录及其与域名的对应关系学习(存储)到自身的存储单元中。然后,DNS防火墙将拦截到的该应答报文原封不动的转发给DNS缓存服务器,此时,DNS缓存服务器可以将该应答报文提供的DNS资源记录及其与域名的对应关系学习(存储)到自身的存储单元中,并将该应答报文发送给客户端。其中,DNS防火墙、DNS缓存服务器和DNS服务器的交互方式如图4所示。这样,应答报文可以在DNS缓存服务器和DNS防火墙中进行双重备份,当同一域名查询请求再次被发起时,可以对其进行就近报文应答,提高查询效率,并且可以减轻DNS服务器的负担。
需要说明的是,客户端可以包括一个或者多个,DNS缓存服务器也可以包括一个或者多个。同一域名查询请求可以是同一客户端在不同的时间发起的,也可以是不同的客户端在不同的时间发起的。针对同一域名查询请求,可以有一个或多个应答方给出应答报文。另外,DNS服务器(权威服务器),是指运营商提供的域名的真正被托管的服务器。上述的客户端与DNS防火墙、DNS缓存服务器、DNS服务器之间的交互方式均为UDP交互方式。UDP交互方式为非连接的交互方式,其向对方发送应答报文时,不需要经过对方的同意,即不需要与对方“握手”,并且该UDP交互方式不需要签名验签。另外,UDP交互方式不能验证应答报文的来源。这样,通过UDP交互方式可以对域名请求进行快速应答,进而可以提高DNS防火墙或者DNS缓存服务器或者DNS服务器对客户端的域名查询请求的应答效率。
步骤S704,DNS防火墙检测DNS防火墙中与域名查询请求相对应的缓存记录是否被标记过。
DNS防火墙设置在DNS缓存服务器和DNS服务器之间,在DNS缓存服务器和DNS服务器进行交互时,DNS防火墙作为桥梁,起到“安检”、“监督”和“控制”的作用。
需要说明的是,被标记的缓存记录安全指数较低,并且其来源不明,即被标记的缓存记录为“可疑记录”。这是由于客户端发送了一个域名查询请求,但是DNS防火墙拦截到了多个针对该域名查询请求的应答报文,又由于该应答报文为通过UDP交互方式发送的,其来源具有不可验证性,因此,DNS防火墙在拦截到了多个针对该域名查询请求的应答报文时,其可以对该应答报文提供的DNS资源记录进行标记(如对可疑的应答报文进行着色),以将其与正常的应答报文进行区别。这样,如果基于客户端的域名查询请求,并且DNS防火墙查询到该被标记的缓存记录时,DNS防火墙可以控制DNS缓存服务器与DNS服务器的交互方式以防止攻击者对DNS缓存服务器进行投毒(如种植木马、窃取口令、钓鱼或其他政治目的等)。
步骤S706,DNS防火墙控制DNS缓存服务器与DNS服务器采用TCP连接方式进行交互。
如果DNS防火墙检测出DNS防火墙中与域名查询请求相对应的缓存记录被标记过,则DNS防火墙控制DNS缓存服务器与DNS服务器采用TCP连接方式进行交互。
具体地,如果DNS防火墙检测出DNS防火墙中与域名查询请求相对应的缓存记录被标记过,DNS防火墙不对客户端的域名查询请求进行报文应答,而是将域名查询请求转发给DNS缓存服务器。DNS缓存服务器在接收到该域名查询请求之后,向DNS服务器发起查询请求时。DNS防火墙在DNS服务器接收域名查询请求之前可以首先拦截该域名查询请求,并再次查询自身的缓存记录,如果再次确定与该域名查询请求相对应的缓存记录已经被标记过,则DNS防火墙可以不将该域名查询请求转发给DNS服务器,而是将代替DNS服务器向DNS缓存服务器发送一个带TC置位的应答报文。该带TC置位的应答报文用于强制DNS缓存服务器采用TCP连接方式进行域名查询请求。
通过本发明实施例,DNS防火墙可以检测其与域名查询请求相对应的缓存记录是否被标记,并且在检测到其与域名查询请求相对应的缓存记录被标记时,控制DNS缓存服务器与DNS服务器采用TCP连接方式进行交互。由于TCP连接方式具有“握手”机制,并且可以通过生成的随机序列号进行签名验签,因此,当攻击者针对客户端发送的域名查询请求向DNS缓存服务器投毒,即当攻击者针对客户端发送的域名查询请求向DNS缓存服务器发送非法的应答报文时,DNS防火墙可以根据攻击者使用的通讯交互方式执行相应的防护命令。例如,当应答报文为通过UDP交互方式发送的应答时,DNS防火墙可以拒绝接收;当应答报文为通过TCP交互方式发送的应答报文,但是经过签名验签发现其序列号为非法序列号(即签名验签不通过),这时,DNS防火墙可以在接收到应答报文之后将其丢弃。
图8是根据本发明第二实施例的DNS缓存投毒的防护方法的流程图。
如图8所示,该DNS缓存投毒的防护方法包括如下的步骤S802至步骤S812B,该实施例可以作为图7所示实施例的优选实施方式。
步骤S802至步骤S806,分别同图7所示实施例的步骤S702至步骤S706,在此不再赘述。
步骤S808,DNS防火墙接收DNS服务器发送的应答报文。
此时,DNS防火墙接收到的DNS服务器发送的应答报文为DNS服务器通过TCP交互方式发送的,因此,该次通讯交互经过了“握手”,并且DNS服务器在发送应答报文的同时还发送了签名验签密码,该签名验签密码为DNS服务器和DNS缓存服务器之间约定的随机序列号。通过该约定的随机序列号,DNS缓存服务器可以认证应答报文的来源。
具体地,当DNS缓存服务器接收应答报文的同时,可以验证序列号是否为上述约定的随机序列号。如果验证序列号为上述约定的随机序列号,则认为应答报文来自DNS服务器;如果验证序列号不为上述约定的随机序列号,则认为应答报文为非法的应答报文。其中,DNS防火墙对来自DNS服务器的应答报文可以缓存,而对非法的应答报文可以丢弃。
步骤S810,DNS防火墙用接收到的DNS服务器发送的应答报文替换被标记过的缓存记录,将接收到的DNS服务器发送的应答报文作为更新后的缓存记录。
具体地,DNS防火墙可以先将被标记过的缓存记录删除,再将接收到的DNS服务器发送的应答报文对应于查询的域名请求进行缓存。具体地,这里可以对应于查询的域名请求缓存DNS服务器发送的应答报文中的DNS资源记录。
这样,在客户端再次发送该域名查询请求时,DNS防火墙可以基于该更新后的缓存记录进行报文应答,实现了消除安全隐患的目的,达到了防止非法报文对DNS缓存服务器进行投毒的效果。
步骤S812A,当DNS防火墙再次接收到客户端发送的域名查询请求时,DNS防火墙发送应答报文至客户端。
需要说明的是,DNS防火墙再次接收到的域名查询请求可以是为一个或者多个客户端发送的同一域名查询请求,并且该域名查询请求与应答报文相对应。
步骤S812B,DNS防火墙将应答报文转发给DNS缓存服务器,并且DNS缓存服务器在DNS缓存服务器中存储接收到的DNS服务器转发的应答报文。
DNS防火墙将应答报文转发给DNS缓存服务器时不对应答报文进行任何修改,尤其不对应答报文的生存时间(time to live,简称TTL)进行任何修改,即DNS防火墙原封不动地转发DNS服务器发送的应答报文给DNS缓存服务器。
这样,DNS防火墙将应答报文转发给DNS缓存服务器,可以实现对应答报文双重备份的目的。
需要说明的是,在DNS防火墙用接收到的DNS服务器发送的应答报文替换被标记过的缓存记录,将接收到的DNS服务器发送的应答报文作为更新后的缓存记录之后,本发明实施例也可以仅仅执行步骤S812A或者步骤S812B。
图9是根据本发明第三实施例的DNS缓存投毒的防护方法的流程图。
如图9所示,该DNS缓存投毒的防护方法包括如下的步骤S902至步骤S910该实施例可以作为图7所示实施例的优选实施方式。
步骤S902至步骤S906,分别同图7所示实施例的步骤S702至步骤S706,在此不再赘述。
步骤S908,DNS防火墙检测应答报文是否是通过TCP连接方式发送的应答报文。
DNS防火墙检测应答报文是否是通过TCP连接方式发送的应答报文可以检测否是通过“握手”机制发送的应答报文。
具体地,DNS防火墙在发送域名查询请求之后,可以检测应答方(如DNS服务器、攻击者)是否发送应答报文的请求。如果检测应答方发送应答报文的请求(即“握手”),则DNS防火墙检测出应答报文是通过TCP连接方式发送的应答报文,并且DNS防火墙接收应答方发送的应答报文;如果检测应答方没有发送应答报文的请求,则DNS防火墙检测出应答报文不是通过TCP连接方式发送的应答报文,并且DNS防火墙拒绝应答方发送的应答报文。
步骤S910,如果DNS防火墙检测出应答报文不是通过TCP连接方式发送的应答报文,则DNS防火墙拒绝接收应答报文。
这样,通过将可疑的应答报文,可以达到防止攻击者对缓存服务器投毒的效果。
进一步地,在本发明实施例中,在DNS防火墙检测应答报文是否是通过TCP连接方式发送的应答报文之后,该防护方法还可以包括:
步骤12,如果DNS防火墙检测出应答报文是通过TCP连接方式发送的应答报文,则DNS防火墙接收应答报文。
具体地,DNS防火墙在发送域名查询请求之后,可以检测应答方(如DNS服务器、攻击者)是否发送应答报文的请求。如果检测应答方发送应答报文的请求(即“握手”),则DNS防火墙检测出应答报文是通过TCP连接方式发送的应答报文,并且DNS防火墙接收应答方发送的应答报文。
步骤14,DNS防火墙判断应答报文的序列号是否是签名验签序列号。
此时,DNS防火墙接收到的DNS服务器发送的应答报文为DNS服务器通过TCP交互方式发送的,因此,该次通讯交互经过了“握手”,并且DNS服务器在发送应答报文的同时还发送了签名验签密码(即签名验签序列号),该签名验签密码(即签名验签序列号)为DNS服务器和DNS缓存服务器之间约定的随机序列号。通过该约定的随机序列号,DNS缓存服务器可以认证应答报文的来源。
具体地,当DNS缓存服务器接收应答报文的同时,可以验证序列号是否为上述约定的随机序列号。如果验证序列号为上述约定的随机序列号,则认为应答报文来自DNS服务器。
步骤16,如果DNS防火墙判断出应答报文的序列号不是签名验签序列号,则DNS防火墙丢弃接收到的应答报文。
如果验证序列号不为上述约定的随机序列号,则认为应答报文为非法的应答报文。其中,DNS防火墙对来自DNS服务器的应答报文可以缓存,而对非法的应答报文可以丢弃。
进一步地,在本发明实施例中,在DNS防火墙检测DNS防火墙中与域名查询请求相对应的缓存记录是否被标记过之前,该防护方法还可以包括:
步骤22,DNS防火墙检测DNS防火墙中是否有与域名查询请求相对应的缓存记录。
步骤24,如果DNS防火墙检测出DNS防火墙中没有与域名查询请求相对应的缓存记录,则DNS防火墙检测接收到的与域名查询请求相对应的应答报文的个数是否大于1。
步骤26,如果DNS防火墙检测出接收到的与域名查询请求相对应的应答报文的个数大于1,则DNS防火墙存储接收到的与域名查询请求相对应的应答报文所提供的DNS资源记录。
优选地,如果DNS防火墙检测出接收到的与域名查询请求相对应的应答报文的个数大于1,DNS防火墙可以仅仅存储接收到的与域名查询请求相对应的一个应答报文所提供的DNS资源记录。这样,可以节约DNS防火墙的存储单元的存储空间,减轻DNS防火墙的负担。
进一步优选地,DNS防火墙可以仅仅存储最早接收到的与域名查询请求相对应的一个应答报文所提供的DNS资源记录。
步骤28,DNS防火墙对DNS资源记录进行标记。
正常情况下,一个域名查询请求对应一个应答报文。一旦DNS防火墙接收到多个与同一域名查询请求相对应的应答报文,并且该应答报文均为基于UDP交互方式作出的,因此DNS防火墙将其列为可疑应答报文,并进行标记,如对应答报文提供的DNS资源记录进行着色等。
更进一步地,在本发明实施例中,在DNS防火墙对DNS资源记录进行标记之后,该防护方法还可以包括:
步骤32,DNS防火墙将接收到的与域名查询请求相对应的应答报文所提供的DNS资源记录的生存时间TTL修改为0,得到修改后的应答报文。
步骤34,将修改后的应答报文转发给DNS缓存服务器。
需要说明的是,在TTL等于0时,该TTL对应的DNS资源记录不能生存,即不能进行存储。这样,修改后的应答报文由于其TTL等于0,因此修改后的应答报文转发到DNS缓存服务器之后,DNS缓存服务器不对其进行存储。这样,由于可以的应答报文不能存储在DNS缓存服务器,因此实现了防止攻击者对DNS缓存服务器进行投毒的目的。
从以上的描述中,可以看出,本发明实现了如下技术效果:DNS防火墙可以检测其与域名查询请求相对应的缓存记录是否被标记,并且在检测到其与域名查询请求相对应的缓存记录被标记时,控制DNS缓存服务器与DNS服务器采用TCP连接方式进行交互。由于TCP连接方式具有“握手”机制,并且可以通过生成的随机序列号进行签名验签,因此,当攻击者针对客户端发送的域名查询请求向DNS缓存服务器投毒,即当攻击者针对客户端发送的域名查询请求向DNS缓存服务器发送非法的应答报文时,DNS防火墙可以根据攻击者使用的通讯交互方式执行相应的防护命令。例如,当应答报文为通过UDP交互方式发送的应答时,DNS防火墙可以拒绝接收;当应答报文为通过TCP交互方式发送的应答报文,但是经过签名验签发现其序列号为非法序列号(即签名验签不通过),这时,DNS防火墙可以在接收到应答报文之后将其丢弃。
需要说明的是,在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行,并且,虽然在流程图中示出了逻辑顺序,但是在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤。
显然,本领域的技术人员应该明白,上述的本发明的各模块或各步骤可以用通用的计算设备来实现,它们可以集中在单个的计算设备上,或者分布在多个计算设备所组成的网络上,可选地,它们可以用计算设备可执行的程序代码来实现,从而,可以将它们存储在存储设备中由计算设备来执行,或者将它们分别制作成各个集成电路模块,或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样,本发明不限制于任何特定的硬件和软件结合。
以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (12)
1.一种DNS缓存投毒的防护方法,其特征在于,包括:
域名服务DNS防火墙接收客户端发送的域名查询请求;
所述DNS防火墙检测所述DNS防火墙中与所述域名查询请求相对应的缓存记录是否被标记过,其中,所述DNS防火墙设置在DNS缓存服务器和DNS服务器之间,其中,所述DNS防火墙用于如果在接收到所述域名查询请求之后拦截到多个针对所述域名查询请求的应答报文,则对所述应答报文提供的DNS资源记录进行标记;以及
如果所述DNS防火墙检测出所述DNS防火墙中与所述域名查询请求相对应的缓存记录被标记过,则所述DNS防火墙控制所述DNS缓存服务器与所述DNS服务器采用TCP连接方式进行交互。
2.根据权利要求1所述的防护方法,其特征在于,所述DNS防火墙控制所述DNS缓存服务器与所述DNS服务器采用TCP连接方式进行交互之后,所述防护方法还包括:
所述DNS防火墙接收所述DNS服务器发送的应答报文;
所述DNS防火墙用接收到的所述DNS服务器发送的应答报文替换被标记过的缓存记录,将接收到的所述DNS服务器发送的应答报文作为更新后的缓存记录,
其中,在将接收到的所述DNS服务器发送的应答报文作为更新后的缓存记录之后,所述防护方法还包括:
当所述DNS防火墙再次接收到所述客户端发送的所述域名查询请求时,所述DNS防火墙发送所述应答报文至所述客户端;和/或
所述DNS防火墙将所述应答报文转发给所述DNS缓存服务器,并且所述DNS缓存服务器在所述DNS缓存服务器中存储接收到的所述DNS服务器转发的应答报文。
3.根据权利要求1所述的防护方法,其特征在于,所述DNS防火墙控制所述DNS缓存服务器与所述DNS服务器采用TCP连接方式进行交互之后,所述防护方法还包括:
所述DNS防火墙检测应答报文是否是通过所述TCP连接方式发送的所述应答报文;以及
如果所述DNS防火墙检测出所述应答报文不是通过所述TCP连接方式发送的所述应答报文,则所述DNS防火墙拒绝接收所述应答报文。
4.根据权利要求3所述的防护方法,其特征在于,在所述DNS防火墙检测应答报文是否是通过所述TCP连接方式发送的所述应答报文之后,所述防护方法还包括:
如果所述DNS防火墙检测出应答报文是通过所述TCP连接方式发送的所述应答报文,则所述DNS防火墙接收所述应答报文;
所述DNS防火墙判断所述应答报文的序列号是否是签名验签序列号;以及
如果所述DNS防火墙判断出所述应答报文的序列号不是签名验签序列号,则所述DNS防火墙丢弃接收到的所述应答报文。
5.根据权利要求1所述的防护方法,其特征在于,在所述DNS防火墙检测所述DNS防火墙中与所述域名查询请求相对应的缓存记录是否被标记过之前,所述防护方法还包括:
所述DNS防火墙检测所述DNS防火墙中是否有与所述域名查询请求相对应的缓存记录;
如果所述DNS防火墙检测出所述DNS防火墙中没有与所述域名查询请求相对应的缓存记录,则所述DNS防火墙检测接收到的与所述域名查询请求相对应的应答报文的个数是否大于1;
如果所述DNS防火墙检测出接收到的与所述域名查询请求相对应的应答报文的个数大于1,则所述DNS防火墙存储接收到的与所述域名查询请求相对应的应答报文所提供的DNS资源记录;以及
所述DNS防火墙对所述DNS资源记录进行标记。
6.根据权利要求5所述的防护方法,其特征在于,在所述DNS防火墙对所述DNS资源记录进行标记之后,所述防护方法还包括:
所述DNS防火墙将接收到的与所述域名查询请求相对应的应答报文所提供的所述DNS资源记录的生存时间TTL修改为0,得到修改后的应答报文;以及
将所述修改后的应答报文转发给所述DNS缓存服务器。
7.一种DNS缓存投毒的防护设备,其特征在于,包括:
第一接收单元,用于使得域名服务DNS防火墙接收客户端发送的域名查询请求;
第一检测单元,用于使得所述DNS防火墙检测所述DNS防火墙中与所述域名查询请求相对应的缓存记录是否被标记过,其中,所述DNS防火墙设置在DNS缓存服务器和DNS服务器之间,其中,所述DNS防火墙用于如果在接收到所述域名查询请求之后拦截到多个针对所述域名查询请求的应答报文,则对所述应答报文提供的DNS资源记录进行标记;以及
控制单元,用于使得如果所述DNS防火墙检测出所述DNS防火墙中与所述域名查询请求相对应的缓存记录被标记过,则所述DNS防火墙控制所述DNS缓存服务器与所述DNS服务器采用TCP连接方式进行交互。
8.根据权利要求7所述的防护设备,其特征在于,所述防护设备还包括:
第二接收单元,用于使得在所述DNS防火墙控制所述DNS缓存服务器与所述DNS服务器采用TCP连接方式进行交互之后,所述DNS防火墙接收所述DNS服务器发送的应答报文;
替换单元,用于使得所述DNS防火墙用接收到的所述DNS服务器发送的应答报文替换被标记过的缓存记录,将接收到的所述DNS服务器发送的应答报文作为更新后的缓存记录,
其中,在将接收到的所述DNS服务器发送的应答报文作为更新后的缓存记录之后,所述防护设备还包括:
发送单元,用于使得当所述DNS防火墙再次接收到所述客户端发送的所述域名查询请求时,所述DNS防火墙发送所述应答报文至所述客户端;和/或
第一转发单元,用于使得所述DNS防火墙将所述应答报文转发给所述DNS缓存服务器,并且所述DNS缓存服务器在所述DNS缓存服务器中存储接收到的所述DNS服务器转发的应答报文。
9.根据权利要求7所述的防护设备,其特征在于,所述防护设备还包括:
第二检测单元,用于使得在所述DNS防火墙控制所述DNS缓存服务器与所述DNS服务器采用TCP连接方式进行交互之后,所述DNS防火墙检测应答报文是否是通过所述TCP连接方式发送的所述应答报文;以及
拒绝单元,用于使得如果所述DNS防火墙检测出所述应答报文不是通过所述TCP连接方式发送的所述应答报文,则所述DNS防火墙拒绝接收所述应答报文。
10.根据权利要求9所述的防护设备,其特征在于,所述防护设备还包括:
第三接收单元,用于使得在所述DNS防火墙检测应答报文是否是通过所述TCP连接方式发送的所述应答报文之后,如果所述DNS防火墙检测出应答报文是通过所述TCP连接方式发送的所述应答报文,则所述DNS防火墙接收所述应答报文;
判断单元,用于使得所述DNS防火墙判断所述应答报文的序列号是否是签名验签序列号;以及
丢弃单元,用于使得如果所述DNS防火墙判断出所述应答报文的序列号不是签名验签序列号,则所述DNS防火墙丢弃接收到的所述应答报文。
11.根据权利要求7所述的防护设备,其特征在于,所述防护设备还包括:
第三检测单元,用于使得在所述DNS防火墙检测所述DNS防火墙中与所述域名查询请求相对应的缓存记录是否被标记过之前,所述DNS防火墙检测所述DNS防火墙中是否有与所述域名查询请求相对应的缓存记录;
第四检测单元,用于使得如果所述DNS防火墙检测出所述DNS防火墙中没有与所述域名查询请求相对应的缓存记录,则所述DNS防火墙检测接收到的与所述域名查询请求相对应的应答报文的个数是否大于1;
存储单元,用于使得如果所述DNS防火墙检测出接收到的与所述域名查询请求相对应的应答报文的个数大于1,则所述DNS防火墙存储接收到的与所述域名查询请求相对应的应答报文所提供的DNS资源记录;以及
标记单元,用于使得所述DNS防火墙对所述DNS资源记录进行标记。
12.根据权利要求11所述的防护设备,其特征在于,所述防护设备还包括:
修改单元,用于使得在所述DNS防火墙对所述DNS资源记录进行标记之后,所述DNS防火墙将接收到的与所述域名查询请求相对应的应答报文所提供的所述DNS资源记录的生存时间TTL修改为0,得到修改后的应答报文;以及
第二转发单元,用于使得将所述修改后的应答报文转发给所述DNS缓存服务器。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410022832.3A CN103747005B (zh) | 2014-01-17 | 2014-01-17 | Dns缓存投毒的防护方法和设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410022832.3A CN103747005B (zh) | 2014-01-17 | 2014-01-17 | Dns缓存投毒的防护方法和设备 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN103747005A CN103747005A (zh) | 2014-04-23 |
CN103747005B true CN103747005B (zh) | 2018-01-05 |
Family
ID=50503992
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201410022832.3A Active CN103747005B (zh) | 2014-01-17 | 2014-01-17 | Dns缓存投毒的防护方法和设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN103747005B (zh) |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106953830B (zh) * | 2016-01-06 | 2020-02-18 | 中国移动通信集团福建有限公司 | Dns安全防护方法、装置及dns |
CN105939337B (zh) | 2016-03-09 | 2019-08-06 | 杭州迪普科技股份有限公司 | Dns缓存投毒的防护方法及装置 |
CN106210165B (zh) * | 2016-07-08 | 2020-01-21 | 中国互联网络信息中心 | 基于ns记录分层授权缓解域名权威记录劫持影响的方法 |
CN106572199B (zh) * | 2016-10-11 | 2019-11-29 | 上海北信源信息技术有限公司 | 一种避免dns污染的方法 |
CN108667799B (zh) * | 2018-03-28 | 2021-01-15 | 中国科学院信息工程研究所 | 一种针对浏览器缓存投毒的防御方法及系统 |
CN112434292B (zh) * | 2020-10-18 | 2023-01-06 | 苏州浪潮智能科技有限公司 | 一种Web缓存投毒防护的方法和设备 |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101257450A (zh) * | 2008-03-28 | 2008-09-03 | 华为技术有限公司 | 网络安全防护方法、网关设备、客户端及网络系统 |
CN101282209A (zh) * | 2008-05-13 | 2008-10-08 | 杭州华三通信技术有限公司 | 防范dns请求报文泛洪攻击的方法及设备 |
CN101321055A (zh) * | 2008-06-28 | 2008-12-10 | 华为技术有限公司 | 一种攻击防范方法和装置 |
US7930428B2 (en) * | 2008-11-11 | 2011-04-19 | Barracuda Networks Inc | Verification of DNS accuracy in cache poisoning |
CN102035809A (zh) * | 2009-09-29 | 2011-04-27 | 成都市华为赛门铁克科技有限公司 | 缓存中毒的防护方法和防护设备及防护系统 |
CN102404334A (zh) * | 2011-12-07 | 2012-04-04 | 山石网科通信技术(北京)有限公司 | 拒绝服务攻击防护方法及装置 |
CN102714663A (zh) * | 2010-01-19 | 2012-10-03 | 阿尔卡特朗讯公司 | 用于预防dns缓存投毒的方法和系统 |
CN103281409A (zh) * | 2013-06-24 | 2013-09-04 | 广州菁英信息技术有限公司 | 基于tcp协议的移动互联网域名解析方法及dns服务器 |
-
2014
- 2014-01-17 CN CN201410022832.3A patent/CN103747005B/zh active Active
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101257450A (zh) * | 2008-03-28 | 2008-09-03 | 华为技术有限公司 | 网络安全防护方法、网关设备、客户端及网络系统 |
CN101282209A (zh) * | 2008-05-13 | 2008-10-08 | 杭州华三通信技术有限公司 | 防范dns请求报文泛洪攻击的方法及设备 |
CN101321055A (zh) * | 2008-06-28 | 2008-12-10 | 华为技术有限公司 | 一种攻击防范方法和装置 |
US7930428B2 (en) * | 2008-11-11 | 2011-04-19 | Barracuda Networks Inc | Verification of DNS accuracy in cache poisoning |
CN102035809A (zh) * | 2009-09-29 | 2011-04-27 | 成都市华为赛门铁克科技有限公司 | 缓存中毒的防护方法和防护设备及防护系统 |
CN102714663A (zh) * | 2010-01-19 | 2012-10-03 | 阿尔卡特朗讯公司 | 用于预防dns缓存投毒的方法和系统 |
CN102404334A (zh) * | 2011-12-07 | 2012-04-04 | 山石网科通信技术(北京)有限公司 | 拒绝服务攻击防护方法及装置 |
CN103281409A (zh) * | 2013-06-24 | 2013-09-04 | 广州菁英信息技术有限公司 | 基于tcp协议的移动互联网域名解析方法及dns服务器 |
Also Published As
Publication number | Publication date |
---|---|
CN103747005A (zh) | 2014-04-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN103747005B (zh) | Dns缓存投毒的防护方法和设备 | |
Gangan | A review of man-in-the-middle attacks | |
Tapsell et al. | An evaluation of the security of the bitcoin peer-to-peer network | |
Gilad et al. | Off-path hacking: The illusion of challenge-response authentication | |
Schmid | Thirty years of DNS insecurity: Current issues and perspectives | |
Lu et al. | An SDN‐based authentication mechanism for securing neighbor discovery protocol in IPv6 | |
Noborio et al. | A feasible motion-planning algorithm for a mobile robot based on a quadtree representation | |
Shulman et al. | Towards forensic analysis of attacks with DNSSEC | |
Hudaib et al. | DNS advanced attacks and analysis | |
Zou et al. | Survey on domain name system security | |
Alharbi et al. | DNS poisoning of operating system caches: Attacks and mitigations | |
Van Der Toorn et al. | Addressing the challenges of modern DNS a comprehensive tutorial | |
Ortega et al. | Preventing ARP cache poisoning attacks: A proof of concept using OpenWrt | |
Nasser et al. | Provably curb man-in-the-middle attack-based ARP spoofing in a local network | |
Hmood et al. | Adaptive caching approach to prevent DNS cache poisoning attack | |
Moonsamy et al. | Mitigating man-in-the-middle attacks on smartphones–a discussion of SSL pinning and DNSSec | |
Grothoff et al. | NSA’s MORECOWBELL: knell for DNS | |
LaCroix et al. | Cookies and sessions: a study of what they are, how they work and how they can be stolen | |
CN110401646A (zh) | IPv6安全邻居发现过渡环境中CGA参数探测方法及装置 | |
Hilton et al. | Beware of ips in sheep’s clothing: Measurement and disclosure of ip spoofing vulnerabilities | |
Hudák | Analysis of DNS in cybersecurity | |
Singh et al. | Two-phase validation scheme for detection and prevention of ARP cache poisoning | |
Alsmadi et al. | Network security | |
Shulman et al. | DNSSEC for cyber forensics | |
Rafiee et al. | A flexible framework for detecting ipv6 vulnerabilities |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant | ||
CP03 | Change of name, title or address | ||
CP03 | Change of name, title or address |
Address after: 215163 No. 181 Jingrun Road, Suzhou High-tech Zone, Jiangsu Province Patentee after: SHANSHI NETWORK COMMUNICATION TECHNOLOGY CO., LTD. Address before: 215163 3rd Floor, 7th Building, High-tech Software Park, 78 Keling Road, Suzhou Science and Technology City, Jiangsu Province Patentee before: HILLSTONE NETWORKS |