CN105939337B - Dns缓存投毒的防护方法及装置 - Google Patents
Dns缓存投毒的防护方法及装置 Download PDFInfo
- Publication number
- CN105939337B CN105939337B CN201610134542.7A CN201610134542A CN105939337B CN 105939337 B CN105939337 B CN 105939337B CN 201610134542 A CN201610134542 A CN 201610134542A CN 105939337 B CN105939337 B CN 105939337B
- Authority
- CN
- China
- Prior art keywords
- dns
- message
- cache
- replys
- 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
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
- H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
- H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/58—Caching of addresses or names
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
- H04L63/1416—Event detection, e.g. attack signature detection
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
- H04L63/1483—Countermeasures against malicious traffic service impersonation, e.g. phishing, pharming or web spoofing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/12—Detection or prevention of fraud
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
- H04L2463/145—Detection or countermeasures against cache poisoning
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本申请提供一种DNS缓存投毒的防护方法及装置,所述方法包括:将DNS服务器发送的第一DNS查询请求报文转发至权威DNS服务器;当根据所接收到的第一DNS回复报文的信息特征,确定发生DNS缓存投毒攻击时,构造携带所述目标域名的第二DNS查询请求报文,向预设的其他权威DNS服务器发送所述第二DNS查询请求报文;并根据所接收到的第二DNS回复报文的信息特征,选择未发生DNS缓存投毒攻击的第二DNS回复报文;根据所述第二DNS回复报文,向所述DNS服务器反馈DNS回复报文。从而实现了安全可靠的预防DNS缓存投毒,且提高了DNS缓存投毒的防护方法的适用性,降低了对DNS服务器配置的依赖。
Description
技术领域
本申请涉及网络通信技术领域,尤其涉及DNS缓存投毒的防护方法及装置。
背景技术
DNS(Domain Names System,域名系统)服务器的基本功能是完成域名解析,即提供IP地址与域名之间的映射关系。一台DNS服务器上可以只记录本地终端或服务器的IP地址与域名之间的映射关系,若通过该DNS服务器向权威DNS服务器请求获取非本地终端或服务器的IP地址与域名之间的映射关系时,该DNS服务器可以将权威DNS服务器返回的内容进行保存,从而构成了DNS缓存。然而,该DNS缓存易于受到DNS缓存投毒攻击,所述DNS缓存投毒的原理是攻击服务器通过使用虚假IP地址替换权威DNS服务器返回的真实IP地址,从而使DNS缓存中的信息为虚假信息。
为了预防DNS缓存投毒,现有技术中可以采用多种方式,比如,DNS服务器可以随机生成DNS请求报文的源端口和DNS请求ID,使得攻击者需要多次尝试匹配这些参数,从而增大了攻击者投毒成功的难度,但是,采用这种方式时,如果攻击者多次尝试,仍有很大的成功几率,因此,该种方式的可靠性低。又比如,还可以通过使用DNSSEC(Domain Name SystemSecurity Extensions,域名系统安全扩展)技术对DNS缓存进行加密,或者在DNS服务器上开启TCP(Transmission Control Protocol传输控制协议)功能,但是这些方式都需要调整DNS服务器的配置,依赖DNS服务器本身的功能和协议,而现有的大多数DNS服务器并不支持DNSSEC协议或者关闭了TCP功能,使得这些方式的局限性太强。
发明内容
有鉴于此,本申请提供一种DNS缓存投毒的防护方法及装置,目的是实现安全可靠的预防DNS缓存投毒,且提高DNS缓存投毒的防护方法的适用性,降低对DNS服务器配置的依赖。
具体地,本申请是通过如下技术方案实现的:
根据本申请实施例的第一方面,提供一种DNS缓存投毒的防护方法,所述方法包括:
将DNS服务器发送的第一DNS查询请求报文转发至权威DNS服务器,所述第一DNS查询请求报文包括请求进行域名解析的目标域名;
当根据所接收到的第一DNS回复报文的信息特征,确定发生DNS缓存投毒攻击时,构造携带所述目标域名的第二DNS查询请求报文,向预设的其他权威DNS服务器发送所述第二DNS查询请求报文;并根据所接收到的第二DNS回复报文的信息特征,选择未发生DNS缓存投毒攻击的第二DNS回复报文,所述第二DNS回复报文包括所述目标域名对应的IP地址;
根据所述第二DNS回复报文,向所述DNS服务器反馈DNS回复报文,所述DNS回复报文携带所述IP地址。
在一实施例中,所述根据所接收到的所述第一DNS回复报文的信息特征,确定发生DNS缓存投毒攻击,包括:
在预设时间内,接收到的所述第一DNS回复报文的数量超过1,且所述第一DNS回复报文中的目的端口与DNS请求ID不相同,则确定发生DNS缓存投毒攻击。
在另一实施例中,所述向预设的其他权威DNS服务器发送所述第二DNS查询请求报文;并根据所接收到的第二DNS回复报文的信息特征,选择未发生DNS缓存投毒攻击的第二DNS回复报文,包括:
向另一权威DNS服务器发送所述第二DNS查询请求报文;
若根据所接收到的第二DNS回复报文的信息特征,确定仍发生DNS缓存投毒攻击时,则再次构造携带所述目标域名的第二DNS查询请求报文,向又一权威DNS服务器发送所述第二DNS查询请求报文,直至只接收到一个第二DNS回复报文。
在另一实施例中,所述方法还包括:在接收到所述第一DNS查询请求报文时记录报文信息,所述报文信息包括:权威DNS服务器的IP地址、源端口、DNS请求ID;
所述根据所述第二DNS回复报文,向所述DNS服务器反馈DNS回复报文,包括:
将所述第二DNS回复报文的源IP地址修改为所述报文信息中的权威服务器的IP地址,目的IP地址修改为所述DNS服务器的IP地址,且将所述第二DNS回复报文的目的端口修改为所述报文信息中的源端口,将所述第二DNS回复报文的DNS请求ID修改为所述报文信息中的DNS请求ID;
将所述修改后的第二DNS回复报文作为DNS回复报文发送至DNS服务器。
在另一实施例中,所述方法还包括:
保存所接收到的第一个第一DNS回复报文;
若已向所有的其他权威DNS服务器发送过第二DNS查询请求报文后,仍确定发生DNS缓存投毒攻击,则将所述第一个第一DNS回复报文发送至DNS服务器,以使所述DNS服务器接收到所述目标域名对应的IP地址;并发送用于提示存在DNS缓存投毒风险的告警信息。
根据本申请实施例的第二方面,提供一种DNS缓存投毒的防护装置,其特征在于,所述装置包括:
转发单元,用于将DNS服务器发送的第一DNS查询请求报文转发至权威DNS服务器,所述第一DNS查询请求报文包括请求进行域名解析的目标域名;
处理单元,用于当根据所接收到的第一DNS回复报文的信息特征,确定发生DNS缓存投毒攻击时,构造携带所述目标域名的第二DNS查询请求报文,向预设的其他权威DNS服务器发送所述第二DNS查询请求报文;并根据所接收到的第二DNS回复报文的信息特征,选择未发生DNS缓存投毒攻击的第二DNS回复报文,所述第二DNS回复报文包括所述目标域名对应的IP地址;
第一回复单元,用于根据所述第二DNS回复报文,向所述DNS服务器反馈DNS回复报文,所述DNS回复报文携带所述IP地址。
在一实施例中,所述处理单元包括:
确定子单元,用于在预设时间内,若接收到的所述第一DNS回复报文的数量超过1,且所述第一DNS回复报文中的目的端口与DNS请求ID不相同,则确定发生DNS缓存投毒攻击。
在另一实施例中,所述处理单元包括:
发送子单元,用于向另一权威DNS服务器发送所述第二DNS查询请求报文;
处理子单元,用于若根据所接收到的第二DNS回复报文的信息特征,确定仍发生DNS缓存投毒攻击时,则再次构造携带所述目标域名的第二DNS查询请求报文,向又一权威DNS服务器发送所述第二DNS查询请求报文,直至只接收到一个第二DNS回复报文。
在另一实施例中,所述装置还包括:
记录单元,用于在接收到所述第一DNS查询请求报文时记录报文信息,所述报文信息包括:权威DNS服务器的IP地址、源端口、DNS请求ID;
所述第一回复单元包括:
修改子单元,用于将所述第二DNS回复报文的源IP地址修改为所述报文信息中的权威服务器的IP地址,目的IP地址修改为所述DNS服务器的IP地址,且将所述第二DNS回复报文的目的端口修改为所述报文信息中的源端口,将所述第二DNS回复报文的DNS请求ID修改为所述报文信息中的DNS请求ID;
回复子单元,用于将所述修改后的第二DNS回复报文作为DNS回复报文发送至DNS服务器。
在另一实施例中,所述装置还包括:
保存单元,用于保存所接收到的第一个第一DNS回复报文;
第二回复单元,用于若已向所有的其他权威DNS服务器发送过第二DNS查询请求报文后,仍确定发生DNS缓存投毒攻击,则将所述第一个第一DNS回复报文发送至DNS服务器,以使所述DNS服务器接收到所述目标域名对应的IP地址;并发送用于提示存在DNS缓存投毒风险的告警信息。
应用本实施例DNS缓存投毒的防护的方法,通过在确定发生DNS缓存投毒攻击时,向其他权威DNS服务器继续发送DNS查询请求报文,由于攻击服务器不会轻易获知防护设备会向哪个其他权威DNS服务器发送DNS查询请求报文,则攻击服务器不会轻易构造出可以通过匹配检查的DNS回复报文,从而使得攻击服务器实现DNS缓存投毒的概率大大降低;并且,该方法不需要对DNS服务器进行配置,因此适用性好,部署简单。
附图说明
图1为本申请实施例实现DNS缓存投毒的防护方法的应用场景示意图。
图2示例了本申请DNS缓存投毒的防护方法的一个实施例流程图。
图3示例了本申请DNS缓存投毒的防护方法的另一个实施例流程图。
图4为本申请DNS缓存投毒的防护装置所在设备的一种硬件结构图。
图5示例了本申请DNS缓存投毒的防护装置的一个实施例框图。
图6示例了本申请DNS缓存投毒的防护装置的另一个实施例框图。
具体实施方式
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
在本申请使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解,尽管在本申请可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本申请范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
DNS是一套分布式的域名服务系统,每个DNS服务器上都可以存放大量的域名与IP地址的映射关系,并且是可以动态更新的,例如,在DNS服务器中新增某个域名与IP地址的映射关系。但一台DNS服务器上,通常只记录本地所有终端或服务器的IP地址与域名的映射关系,当终端所请求进行域名解析的目标域名,与IP地址的映射关系未存在于DNS服务器中时,该DNS服务器可以向权威DNS服务器发送DNS查询请求报文,该DNS查询请求报文中可以携带该目标域名,该权威DNS服务上可以存放着所有域名与IP地址的映射关系。
该DNS查询请求报文的源IP地址为DNS服务器的IP地址,目的IP地址即为权威DNS服务器的IP地址,目的端口可以为固定端口,例如53端口,那么,该DNS查询请求报文的源IP地址、目的IP地址、目的端口这三项数据,通常可以是固定不变的,即DNS服务器向权威DNS服务器所发送的所有DNS查询请求报文中所携带的该三项数据都相同。另外,该DNS查询请求报文的源端口是可以随机选择的,例如,源端口为端口1234(当然,有些DNS服务器不支持随机选择源端口功能,那么,在该情况下,不同DNS查询请求报文的源IP地址、目的IP地址、源端口、目的端口是相同的);此外,该DNS查询请求报文中还包括DNS请求ID,该DNS请求ID则可以是随机生成的,例如为4321。
当权威DNS服务器接收到该DNS查询请求报文后,向DNS服务器发送携带该目标域名对应的IP地址的DNS回复报文。此时,DNS服务器可以采用简单信任机制,即仅对该DNS回复报文的源IP地址、目的端口、DNS请求ID进行匹配检查,例如,匹配检查该DNS回复报文的源IP地址、目的端口、DNS请求ID是否分别与之前发送的DNS查询请求报文的目的IP地址、源端口、DNS请求ID相同。若均相同,则可以认为检查通过,从而,DNS服务器可以通过该DNS回复报文获取目标域名对应的IP地址,并可以将该目标域名与IP地址的对应关系保存在本地缓存中,以形成DNS缓存,方便之后的查询。
然而,攻击者可以通过技术手段,实施DNS缓存投毒,即实现在权威服务器所发送的正常的DNS回复报文到达DNS服务器之前,使得虚假DNS回复报文到达DNS服务器,并通过匹配检查,以使DNS服务器保存错误的域名与IP地址的映射关系。例如将某个域名对应的IP地址替换为恶意网址,当用户访问该域名时,将被引导至该恶意网址,对用户体验造成影响,甚至影响用户的安全。
为了防护DNS缓存投毒,本申请提供了DNS缓存投毒的防护方法及装置。如下的图1所示,为本申请实施例实现DNS缓存投毒的防护方法的应用场景示意图。
图1中,包括DNS服务器11、防护设备12、权威DNS服务器13、攻击服务器14和其他权威DNS服务器(如图1中所示的权威DNS服务器15至权威DNS服务器1n)。其中防护设备12位于权威DNS服务器13,以及权威DNS服务器15至权威DNS服务器1n与DNS服务器11的连接之间,即每个权威DNS服务器向DNS服务器11发送的DNS回复报文,都将先传输至防护设备12;并且,攻击服务器14所发送的虚假DNS回复报文,也将先传输至防护设备12。此外,在本申请中,权威DNS服务器15至权威DNS服务器1n所保存的域名与IP地址的映射关系均与权威DNS服务器13所保存的域名与IP地址的映射关系相同。
防护设备12可以执行本申请DNS缓存投毒的防护方法,对接收到的DNS回复报文进行检查,识别到未发生DNS缓存投毒攻击的DNS回复报文后,才将该DNS回复报文发送至DNS服务器11,从而实现安全可靠的预防DNS缓存投毒,且提高DNS缓存投毒的防护方法的适用性,降低对DNS服务器配置的依赖。
为了详细的说明本申请是如何实现DNS缓存投毒的防护方法的,结合图1所示的应用场景示意图,如下图2,示例了本申请DNS缓存投毒的防护方法的一个实施例流程图,以防护设备12,执行该方法为例,包括以下步骤:
步骤S201:将DNS服务器发送的第一DNS查询请求报文转发至权威DNS服务器,所述第一DNS查询请求报文包括请求进行域名解析的目标域名。
本申请实施例中,当DNS服务器11中不存在客户端所请求进行域名解析的目标域名所对应的IP地址时,DNS服务器11可以向权威DNS服务器13发送携带该目标域名的第一DNS查询请求报文,以向权威DNS服务器13请求查询该目标域名对应的IP地址。如图1所示,该第一DNS查询请求报文先传输至防护设备12,再由防护设备12将该第一DNS查询请求报文转发至权威DNS服务器13。
该第一DNS查询请求报文所包括的源IP地址、目的IP地址、源端口、目的端口、DNS请求ID的相关介绍可以参见上述相关描述,在此不再详细赘述。
步骤S202:当根据所接收到的第一DNS回复报文的信息特征,确定发生DNS缓存投毒攻击时,构造携带所述目标域名的第二DNS查询请求报文,向预设的其他权威DNS服务器发送所述第二DNS查询请求报文,并根据所接收到的第二DNS回复报文的参数特征,选择未发生DNS缓存投毒攻击的第二DNS回复报文,所述第二DNS回复报文包括所述目标域名对应的IP地址。
由图1所示,权威DNS服务器13和攻击服务器14所反馈的DNS回复报文和虚假DNS回复报文都可以先传输至防护设备12,由防护设备12对所接收到的DNS回复报文进行检查。为了描述方便,本申请实施例中,将防护设备在向权威DNS服务器13发送第一DNS查询请求报文后,所接收到的所有DNS回复报文,统一描述为第一DNS回复报文。
攻击服务器14若想实现DNS缓存投毒攻击,可以发送大量的虚假DNS回复报文,以携带不同的目的端口与DNS请求ID,试图尝试使得虚假DNS回复报文可以通过匹配检查。本实施例中,防护设备12可以根据所接收到的第一DNS回复报文的信息特征进行检查,例如,该信息特征可以包括所接收到的第一DNS回复报文的数量,以及第一DNS回复报文的目的端口和DNS请求ID。例如,防护设备12在预设的时间内,例如3秒内,接收到多个第一DNS回复报文,且这些第一DNS回复报文的目的端口、DNS请求ID不相同时,则防护设备12可以确定发生DNS缓存投毒。
为了实现防护DNS缓存投毒,本实施例中,防护设备12可以构造携带所述目标域名的第二DNS查询请求报文,并向其他权威DNS服务器(如图1中所示的权威DNS服务器15至权威DNS服务器1n中的一台权威DNS服务器),例如权威DNS服务器15,发送该第二DNS查询请求报文,以获取目标域名对应的IP地址。
之后,防护设备12可以接收到权威DNS服务器15反馈的DNS回复报文,当然,攻击服务器14仍可以继续发送虚假DNS回复报文,为了描述方便,本申请实施例中,将防护设备12在向其他权威DNS服务器发送第二DNS查询请求报文后,所接收到的DNS回复报文称为第二DNS回复报文。防护设备12可以继续根据所接收到的第二DNS回复报文的信息特征进行检查,最终选择未发生DNS缓存投毒攻击的第二DNS回复报文,例如,选择所接收到的唯一的一个第二DNS回复报文。
步骤S203:根据所述第二DNS回复报文,向所述DNS服务器反馈DNS回复报文,所述DNS回复报文携带所述IP地址。
当执行完步骤S202,防护设备12选择出未发生DNS缓存投毒攻击的第二DNS回复报文后,可以根据该第二DNS回复报文,向DNS服务器11反馈DNS回复报文,以告知DNS服务器11所请求进行域名解析的目标域名所对应的IP地址。
应用本实施例DNS缓存投毒的防护的方法,通过在确定发生DNS缓存投毒攻击时,向其他权威DNS服务器继续发送DNS查询请求报文,由于攻击服务器不会轻易获知防护设备会向哪个其他权威DNS服务器发送DNS查询请求报文,则攻击服务器不会轻易构造出可以通过匹配检查的DNS回复报文,从而使得攻击服务器实现DNS缓存投毒的概率大大降低;并且,该方法不需要对DNS服务器进行配置,因此适用性好,部署简单。
为了更详细的说明本申请是如何实现DNS缓存投毒的防护方法的,在上述图2所示的实施例的基础上,做进一步的详细说明。如下的图3,示例了本申请DNS缓存投毒的防护方法的另一个实施例流程图,仍以防护设备12,执行该方法为例,包括以下步骤:
步骤S301:将DNS服务器发送的第一DNS查询请求报文转发至权威DNS服务器,所述第一DNS查询请求报文包括请求进行域名解析的目标域名。
本步骤的相关描述可以参见上述实施例中步骤S201中的描述,在此不再详细赘述。
此外,在本实施例中,防护设备12在接收到DNS服务器11所发送的第一DNS查询请求报文时,可以记录下该第一DNS查询请求报文的报文信息,例如,该报文信息可以包括目的IP地址,例如权威DNS服务器13的IP地址,源端口,例如1234,以及DNS请求ID,例如4321,以方便之后的操作。记录该报文信息的具体用途参见下述描述,在此先不做详述。
步骤S302:在预设时间内,若接收到的第一DNS回复报文的数量超过1,且所述第一DNS回复报文中的目的端口与DNS请求ID不相同,则确定发生DNS缓存投毒。
本步骤的相关描述可以参见上述实施例中步骤S202中的描述,在此不再详细赘述。
步骤S303:构造携带所述目标域名的第二DNS查询请求报文,向另一权威DNS服务器发送所述第二DNS查询请求报文。
在本实施例中,当执行完步骤S302,确定发生DNS缓存投毒后,防护设备12可以构造一个第二DNS查询请求报文,且该第二DNS查询请求报文携带所述目标域名,防护设备12可以选择一个其他权威DNS服务器,即未向其发送过第二DNS查询请求报文的权威DNS服务器,并向该其他权威DNS服务器发送该第二DNS查询请求报文。
该第二DNS查询请求报文的目的地址即为所选择的其他权威DNS服务器的IP地址,该第二DNS查询请求报文的源端口与DNS请求ID,则可以是随机选择的,例如,该第二DNS查询请求报文的源端口为2222,DNS请求ID为4444。
在一个例子中,如图1所示,权威DNS服务器15至权威DNS服务器1n均保存有与权威DNS服务器13相同的域名与IP地址的映射关系。可以预先设置一个权威DNS服务器的顺序表,该顺序表中保存有权威DNS服务器的名称与对应的标识,该标识用以表示是否已向该权威DNS服务器发送过第二DNS查询请求报文,例如,当标识为“0”时,表示未向该权威DNS服务器发送过第二DNS查询请求报文,当标识为“1”时,表示已向该权威DNS服务器发送过第二DNS查询请求报文。
如下表1所示,为该顺序表的一种示例:
表1
权威DNS服务器名称 | 标识 |
权威DNS服务器15 | 0 |
权威DNS服务器16 | 0 |
权威DNS服务器17 | 0 |
… | 0 |
防护设备12选择其他权威DNS服务器时,可以遍历上述表1所示的顺序表,当所遍历到的标识为“0”时,则选择该标识所对应的权威DNS服务器,例如,所选择的为权威DNS服务器15,则向权威DNS服务器15发送该第二DNS查询请求报文,以查询该目标域名对应的IP地址。之后,防护设备12还可以在上表1所示的顺序表中,将权威DNS服务器15所对应的标识设置为“1”,以表示已向权威DNS服务器15发送过第二DNS查询请求报文。
在另一个例子中,防护设备12选择其他权威DNS服务器时,可以随机选择一个权威DNS服务器,并确定未向该权威DNS服务器发送过第二DNS查询请求报文时,例如,可以根据上述顺序表确定该权威DNS服务器对应的标识为“0”,向该权威DNS服务器发送该第二DNS查询请求报文,以查询该目标域名对应的IP地址。之后,防护设备12还可以标识该权威DNS服务器已被选择过,例如,在上述表1所示的顺序表中,将该权威DNS服务器所对应的标识设置为“1”。
步骤S304:若根据所接收到的第二DNS回复报文的信息特征,确定仍发生DNS缓存投毒攻击时,则再次构造携带所述目标域名的第二DNS查询请求报文,向又一权威DNS服务器发送所述第二DNS查询请求报文,直至只接收到一个第二DNS回复报文。
在本步骤中,例如,若执行完步骤S303,向权威DNS服务器15发送第二DNS查询请求报文后,根据所接收到的第二DNS回复报文的信息特征,确定仍发生DNS缓存投毒攻击时,则防护设备12可以如步骤S303中所描述的,再次构造一个第二DNS查询请求报文,该再次构造的第二DNS查询请求报文仍携带请求进行域名解析的目标域名,且该第二DNS查询请求报文的源端口与DNS请求ID为重新生成的,例如,源端口为3333,DNS请求ID为6666;防护设备12可以如步骤S303中所描述的,选择又一个权威DNS服务器,例如,选择权威DNS服务器16,向权威DNS服务器16发送该再次构造的第二DNS查询请求报文。
直至在预设的时间内,例如,3秒内,防护设备12只接收到一个第二DNS回复报文时,可以认为攻击服务器14未发送大量虚假DNS回复报文,即可以认为未发生DNS缓存投毒攻击。
步骤S305:根据所述第二DNS回复报文,向所述DNS服务器反馈DNS回复报文。
由于该第二DNS回复报文是由其他权威DNS服务器所反馈的,虽然可以认为其不存在DNS缓存投毒攻击,但该第二DNS回复报文的源IP地址、目的端口以及DNS请求ID仍不能通过DNS服务器的匹配检查,且该第二DNS回复报文最终应发送至DNS服务器11。因此,防护设备12在确认正确的第二DNS回复报文后,可以对其进行修改,将修改后的第二DNS回复报文作为DNS回复报文,反馈至DNS服务器11,以使该DNS回复报文可以被发送至DNS服务器11,且可以通过DNS服务器11的匹配检查。
例如,假设步骤S304中,在向权威DNS服务器16发送第二DNS查询请求报文后,根据所接收到的唯一的一个第二DNS回复报文确定未发生DNS缓存投毒攻击后,将该第二DNS回复报文的源IP地址修改为步骤S301中所记录的第一DNS查询请求报文的目的IP地址,例如,将其源IP地址由权威DNS服务器16的IP地址修改为权威DNS服务器13的IP地址;将其目的IP地址由防护设备12的IP地址修改该DNS服务器11的IP地址;将其所包括的目的端口修改为步骤S301中所记录的第一DNS查询请求报文的源端口,例如,将其目的端口由端口3333修改为端口1234;将其所包括的DNS请求ID修改为步骤S301中所记录的第一DNS查询请求报文的DNS请求ID,例如,将其DNS请求ID由6666修改为4321。将修改后的第二DNS回复报文作为DNS回复报文,并将该DNS回复报文反馈至DNS服务器,以使DNS服务器获取请求查询的目标域名所对应的IP地址。
此外,在本实施例中,当防护设备12接收到第一个第一DNS回复报文时,可以保存该第一DNS回复报文。之后,当防护设备12已向所有的其他权威服务器发送过第二DNS查询请求报文后,仍确定发生DNS缓存投毒攻击,则可以将该第一DNS回复报文反馈至DNS服务器11,以使DNS服务器11能够获得一个IP地址。当然,该第一DNS回复报文有可能为攻击服务器14所发送的虚假DNS回复报文,此时,防护设备还可以向网络管理者发送告警信息,以提示网络管理者存在发生DNS缓存投毒攻击的风险。
在一个例子中,该告警信息中,可以携带目标域名,以及第一DNS回复报文中所携带的该目标域名对应的IP地址,以使网络管理者可以根据该告警信息进行分析,得出存在DNS缓存投毒攻击风险的域名以及IP地址,避免用户访问该域名时,被引导至恶意网址,对用户体验造成影响,甚至影响用户的安全。
此外,在本实施例中,由上述描述可知,防护设备12可以根据第二DNS回复报文或者第一DNS回复报文,向DNS服务器11回复DNS回复报文。当防护设备12根据第二DNS回复报文向DNS服务器11回复DNS回复报文时,也可以向网络管理者发送提示信息,用于提示网络管理者DNS缓存投毒防护成功,而当防护设备12根据第一DNS回复报文向DNS服务器11回复DNS回复报文时,可以向网络管理者发送另一提示信息,即告警信息,用于提示网络管理者存在发生DNS缓存投毒的风险。例如,防护设备12上具有信息提示灯,该信息提示灯显示红色时,表示存在发生DNS缓存投毒的风险,该信息提示灯显示绿色时,表示DNS缓存投毒防护成功。
应用本实施例DNS缓存投毒的防护方法,通过在接收到DNS回复报文时,根据其数量超过1个,以及其目的端口和DNS请求ID不相同,可以确定发生DNS缓存投毒攻击,并选择一个其他权威DNS服务器,向该其他权威DNS服务器继续发送DNS查询请求报文,直至只接收到一个DNS回复报文时,确认该唯一的DNS回复报文不存在DNS缓存投毒攻击。由于攻击服务器不会轻易获知防护设备会向哪个其他权威DNS服务器发送DNS查询请求报文,则攻击服务器不会轻易构造出可以通过匹配检查的DNS回复报文,从而使得攻击服务器实现DNS缓存投毒的概率大大降低;并且,该方法不需要对DNS服务器进行配置,因此适用性好,部署简单。
与前述DNS缓存投毒的防护方法的实施例相对应,本申请还提供了DNS缓存投毒的防护装置的实施例。
本申请DNS缓存投毒的防护装置的实施例可以应用在防护设备上,可以理解的是,本申请DNS缓存投毒的防护装置的实施例也可以应用在其他网络设备上,本申请对此不做限制。装置实施例可以通过软件实现,也可以通过硬件或者软硬件结合的方式实现。以软件实现为例,作为一个逻辑意义上的装置,是通过其所在设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言,如图4所示,为本申请DNS缓存投毒的防护装置所在设备的一种硬件结构图,除了图4所示的处理器41、内存42、网络接口43、以及非易失性存储器44之外,实施例中装置所在的设备通常根据该设备的实际功能,还可以包括其他硬件,对此不再赘述。
请参考图5,示例了本申请DNS缓存投毒的防护装置的一个实施例框图,所述装置可以包括:转发单元51、处理单元52、第一回复单元53。
其中,所述转发单元51,可以用于将DNS服务器发送的第一DNS查询请求报文转发至权威DNS服务器,所述第一DNS查询请求报文包括请求进行域名解析的目标域名;
所述处理单元52,可以用于当根据所接收到的第一DNS回复报文的信息特征,确定发生DNS缓存投毒攻击时,构造携带所述目标域名的第二DNS查询请求报文,向预设的其他权威DNS服务器发送所述第二DNS查询请求报文;并根据所接收到的第二DNS回复报文的信息特征,选择未发生DNS缓存投毒攻击的第二DNS回复报文,所述第二DNS回复报文包括所述目标域名对应的IP地址;
所述第一回复单元53,可以用于根据所述第二DNS回复报文,向所述DNS服务器反馈DNS回复报文,所述DNS回复报文携带所述IP地址。
请参考图6,示例了本申请DNS缓存投毒的防护装置的另一个实施例框图,该实施例在上述图5所示装置的基础上,其中所述装置可以包括:处理单元52,可以包括:确定子单元521、发送子单元522、处理子单元523。
所述确定子单元521,可以用于在预设时间内,若接收到的所述第一DNS回复报文的数量超过1,且所述第一DNS回复报文中的目的端口与DNS请求ID不相同,则确定发生DNS缓存投毒攻击。
所述发送子单元522,可以用于向另一权威DNS服务器发送所述第二DNS查询请求报文;
所述处理子单元523,可以用于若根据所接收到的第二DNS回复报文的信息特征,确定仍发生DNS缓存投毒攻击时,则再次构造携带所述目标域名的第二DNS查询请求报文,向又一权威DNS服务器发送所述第二DNS查询请求报文,直至只接收到一个第二DNS回复报文。
所述装置还可以包括:记录单元54。
所述记录单元54,可以用于在接收到所述第一DNS查询请求报文时记录报文信息,所述报文信息包括:权威DNS服务器的IP地址、源端口、DNS请求ID;
所述第一回复单元53,可以包括:修改子单元531、回复子单元532。
其中,所述修改子单元531,可以用于将所述第二DNS回复报文的源IP地址修改为所述报文信息中的权威服务器的IP地址,目的IP地址修改为所述DNS服务器的IP地址,且将所述第二DNS回复报文的目的端口修改为所述报文信息中的源端口,将所述第二DNS回复报文的DNS请求ID修改为所述报文信息中的DNS请求ID;
所述回复子单元532,可以用于将所述修改后的第二DNS回复报文作为DNS回复报文发送至DNS服务器。
所述装置还可以包括:保存单元55、第二回复单元56。
其中,所述保存单元55,可以用于保存所接收到的第一个第一DNS回复报文;
所述第二回复单元56,可以用于若已向所有的其他权威DNS服务器发送过第二DNS查询请求报文后,仍确定发生DNS缓存投毒攻击,则将所述第一个第一DNS回复报文发送至DNS服务器,以使所述DNS服务器接收到所述目标域名对应的IP地址;并发送用于提示存在DNS缓存投毒风险的告警信息。
上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程,在此不再赘述。
对于装置实施例而言,由于其基本对应于方法实施例,所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
以上所述仅为本申请的较佳实施例而已,并不用以限制本申请,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请保护的范围之内。
Claims (10)
1.一种DNS缓存投毒的防护方法,其特征在于,所述方法包括:
将第一域名系统DNS服务器发送的第一DNS查询请求报文转发至权威DNS服务器,所述第一DNS查询请求报文包括请求进行域名解析的目标域名;
当根据所接收到的第一DNS回复报文的信息特征,确定发生DNS缓存投毒攻击时,构造携带所述目标域名的第二DNS查询请求报文,逐一向预设的其他权威DNS服务器发送所述第二DNS查询请求报文直至只接收到唯一的第二DNS回复报文;将所述唯一的第二DNS回复报文作为未发生DNS缓存投毒攻击的第二DNS回复报文,所述未发生DNS缓存投毒攻击的第二DNS回复报文包括所述目标域名对应的IP地址;
根据所述未发生DNS缓存投毒攻击的第二DNS回复报文,向所述第一DNS服务器反馈第三DNS回复报文,所述第三DNS回复报文携带所述IP地址。
2.根据权利要求1所述的方法,其特征在于,所述根据所接收到的所述第一DNS回复报文的信息特征,确定发生DNS缓存投毒攻击,包括:
在预设时间内,接收到的所述第一DNS回复报文的数量超过1,且所述第一DNS回复报文的目的端口不相同,并且所述第一DNS回复报文的DNS请求ID不相同,则确定发生DNS缓存投毒攻击。
3.根据权利要求1所述的方法,其特征在于,所述逐一向预设的其他权威DNS服务器发送所述第二DNS查询请求报文直至只接收到唯一的第二DNS回复报文;将所述唯一的第二DNS回复报文作为未发生DNS缓存投毒攻击的第二DNS回复报文,包括:
向另一权威DNS服务器发送所述第二DNS查询请求报文;
若根据所接收到的第二DNS回复报文的信息特征,确定仍发生DNS缓存投毒攻击时,则再次构造携带所述目标域名的第二DNS查询请求报文,向又一权威DNS服务器发送所述第二DNS查询请求报文,直至只接收到一个第二DNS回复报文。
4.根据权利要求1所述的方法,其特征在于,所述方法还包括:在接收到所述第一DNS查询请求报文时记录报文信息,所述报文信息包括:权威DNS服务器的IP地址、源端口、DNS请求ID;
所述根据所述未发生DNS缓存投毒攻击的第二DNS回复报文,向所述第一DNS服务器反馈第三DNS回复报文,包括:
将所述未发生DNS缓存投毒攻击的第二DNS回复报文的源IP地址修改为所述报文信息中的权威服务器的IP地址,目的IP地址修改为所述第一DNS服务器的IP地址,且将所述未发生DNS缓存投毒攻击的第二DNS回复报文的目的端口修改为所述报文信息中的源端口,将所述未发生DNS缓存投毒攻击的第二DNS回复报文的DNS请求ID修改为所述报文信息中的DNS请求ID;
将所述修改后的未发生DNS缓存投毒攻击的第二DNS回复报文作为第三DNS回复报文发送至所述第一DNS服务器。
5.根据权利要求1所述的方法,其特征在于,所述方法还包括:
保存所接收到的第一个第一DNS回复报文;
若已向所有的其他权威DNS服务器发送过第二DNS查询请求报文后,仍确定发生DNS缓存投毒攻击,则将所述第一个第一DNS回复报文发送至所述第一DNS服务器,以使所述第一DNS服务器接收到所述目标域名对应的IP地址;并发送用于提示存在DNS缓存投毒风险的告警信息。
6.一种DNS缓存投毒的防护装置,其特征在于,所述装置包括:
转发单元,用于将第一DNS服务器发送的第一DNS查询请求报文转发至权威DNS服务器,所述第一DNS查询请求报文包括请求进行域名解析的目标域名;
处理单元,用于当根据所接收到的第一DNS回复报文的信息特征,确定发生DNS缓存投毒攻击时,构造携带所述目标域名的第二DNS查询请求报文,逐一向预设的其他权威DNS服务器发送所述第二DNS查询请求报文直至只接收到唯一的第二DNS回复报文;将所述唯一的第二DNS回复报文作为未发生DNS缓存投毒攻击的第二DNS回复报文,所述未发生DNS缓存投毒攻击的第二DNS回复报文包括所述目标域名对应的IP地址;
第一回复单元,用于根据所述未发生DNS缓存投毒攻击的第二DNS回复报文,向所述第一DNS服务器反馈第三DNS回复报文,所述第三DNS回复报文携带所述IP地址。
7.根据权利要求6所述的装置,其特征在于,所述处理单元包括:
确定子单元,用于在预设时间内,若接收到的所述第一DNS回复报文的数量超过1,且所述第一DNS回复报文的目的端口不相同,并且所述第一DNS回复报文的DNS请求ID不相同,则确定发生DNS缓存投毒攻击。
8.根据权利要求6所述的装置,其特征在于,所述处理单元包括:
发送子单元,用于向另一权威DNS服务器发送所述第二DNS查询请求报文;
处理子单元,用于若根据所接收到的第二DNS回复报文的信息特征,确定仍发生DNS缓存投毒攻击时,则再次构造携带所述目标域名的第二DNS查询请求报文,向又一权威DNS服务器发送所述第二DNS查询请求报文,直至只接收到一个第二DNS回复报文。
9.根据权利要求6所述的装置,其特征在于,所述装置还包括:
记录单元,用于在接收到所述第一DNS查询请求报文时记录报文信息,所述报文信息包括:权威DNS服务器的IP地址、源端口、DNS请求ID;
所述第一回复单元包括:
修改子单元,用于将所述未发生DNS缓存投毒攻击的第二DNS回复报文的源IP地址修改为所述报文信息中的权威服务器的IP地址,目的IP地址修改为所述第一DNS服务器的IP地址,且将所述未发生DNS缓存投毒攻击的第二DNS回复报文的目的端口修改为所述报文信息中的源端口,将所述未发生DNS缓存投毒攻击的第二DNS回复报文的DNS请求ID修改为所述报文信息中的DNS请求ID;
回复子单元,用于将所述修改后的未发生DNS缓存投毒攻击的第二DNS回复报文作为第三DNS回复报文发送至所述第一DNS服务器。
10.根据权利要求6所述的装置,其特征在于,所述装置还包括:
保存单元,用于保存所接收到的第一个第一DNS回复报文;
第二回复单元,用于若已向所有的其他权威DNS服务器发送过第二DNS查询请求报文后,仍确定发生DNS缓存投毒攻击,则将所述第一个第一DNS回复报文发送至所述第一DNS服务器,以使所述第一DNS服务器接收到所述目标域名对应的IP地址;并发送用于提示存在DNS缓存投毒风险的告警信息。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610134542.7A CN105939337B (zh) | 2016-03-09 | 2016-03-09 | Dns缓存投毒的防护方法及装置 |
US15/413,194 US10469532B2 (en) | 2016-03-09 | 2017-01-23 | Preventing DNS cache poisoning |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610134542.7A CN105939337B (zh) | 2016-03-09 | 2016-03-09 | Dns缓存投毒的防护方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN105939337A CN105939337A (zh) | 2016-09-14 |
CN105939337B true CN105939337B (zh) | 2019-08-06 |
Family
ID=57152025
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201610134542.7A Active CN105939337B (zh) | 2016-03-09 | 2016-03-09 | Dns缓存投毒的防护方法及装置 |
Country Status (2)
Country | Link |
---|---|
US (1) | US10469532B2 (zh) |
CN (1) | CN105939337B (zh) |
Families Citing this family (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10305934B2 (en) * | 2016-05-26 | 2019-05-28 | Cisco Technology, Inc. | Identity based domain name system (DNS) caching with security as a service (SecaaS) |
CN108667799B (zh) * | 2018-03-28 | 2021-01-15 | 中国科学院信息工程研究所 | 一种针对浏览器缓存投毒的防御方法及系统 |
CN109462582B (zh) * | 2018-10-30 | 2020-11-20 | 腾讯科技(深圳)有限公司 | 文本识别方法、装置、服务器及存储介质 |
CN109660425B (zh) * | 2018-12-13 | 2021-05-18 | 网宿科技股份有限公司 | 一种监控方法、确定方法、监控设备及存储介质 |
US11201853B2 (en) * | 2019-01-10 | 2021-12-14 | Vmware, Inc. | DNS cache protection |
CN110401644A (zh) * | 2019-07-12 | 2019-11-01 | 杭州迪普科技股份有限公司 | 一种攻击防护方法及装置 |
US11277373B2 (en) | 2019-07-24 | 2022-03-15 | Lookout, Inc. | Security during domain name resolution and browsing |
US10855644B1 (en) | 2019-09-09 | 2020-12-01 | Vmware, Inc. | Address resolution protocol entry verification |
CN110769004B (zh) * | 2019-11-05 | 2020-07-14 | 中国人民解放军国防科技大学 | 在dns客户端或代理服务器使用的dns防污染方法 |
CN111200667B (zh) * | 2019-12-18 | 2021-08-10 | 网宿科技股份有限公司 | 一种域名解析方法、权威域名服务器和本地域名服务器 |
US11575646B2 (en) | 2020-03-12 | 2023-02-07 | Vmware, Inc. | Domain name service (DNS) server cache table validation |
US11271894B1 (en) * | 2021-03-10 | 2022-03-08 | Accenture Global Solutions Limited | Systems, devices, and methods for private query and exchange of domain information |
CN114124887B (zh) * | 2021-11-29 | 2023-09-05 | 牙木科技股份有限公司 | Dns服务器的视图查询方法、dns服务器及可读存储介质 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101827136A (zh) * | 2010-03-30 | 2010-09-08 | 联想网御科技(北京)有限公司 | 域名系统服务器缓存感染的防御方法和网络出口设备 |
CN102035809A (zh) * | 2009-09-29 | 2011-04-27 | 成都市华为赛门铁克科技有限公司 | 缓存中毒的防护方法和防护设备及防护系统 |
CN103685168A (zh) * | 2012-09-07 | 2014-03-26 | 中国科学院计算机网络信息中心 | 一种dns递归服务器的查询请求服务方法 |
CN103747005A (zh) * | 2014-01-17 | 2014-04-23 | 山石网科通信技术有限公司 | Dns缓存投毒的防护方法和设备 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7930428B2 (en) * | 2008-11-11 | 2011-04-19 | Barracuda Networks Inc | Verification of DNS accuracy in cache poisoning |
FR2955405B1 (fr) * | 2010-01-19 | 2015-08-21 | Alcatel Lucent | Procede et systeme de prevention d'empoisonnement des caches dns |
TW201230741A (en) * | 2011-01-07 | 2012-07-16 | Nat Univ Tsing Hua | Method and system for preventing domain name system cache poisoning attacks |
CN102404317A (zh) * | 2011-10-31 | 2012-04-04 | 杭州迪普科技有限公司 | 一种防范dns缓存攻击的方法及装置 |
-
2016
- 2016-03-09 CN CN201610134542.7A patent/CN105939337B/zh active Active
-
2017
- 2017-01-23 US US15/413,194 patent/US10469532B2/en active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102035809A (zh) * | 2009-09-29 | 2011-04-27 | 成都市华为赛门铁克科技有限公司 | 缓存中毒的防护方法和防护设备及防护系统 |
CN101827136A (zh) * | 2010-03-30 | 2010-09-08 | 联想网御科技(北京)有限公司 | 域名系统服务器缓存感染的防御方法和网络出口设备 |
CN103685168A (zh) * | 2012-09-07 | 2014-03-26 | 中国科学院计算机网络信息中心 | 一种dns递归服务器的查询请求服务方法 |
CN103747005A (zh) * | 2014-01-17 | 2014-04-23 | 山石网科通信技术有限公司 | Dns缓存投毒的防护方法和设备 |
Also Published As
Publication number | Publication date |
---|---|
US20170264590A1 (en) | 2017-09-14 |
US10469532B2 (en) | 2019-11-05 |
CN105939337A (zh) | 2016-09-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN105939337B (zh) | Dns缓存投毒的防护方法及装置 | |
US10491561B2 (en) | Equipment for offering domain-name resolution services | |
KR101217647B1 (ko) | 특정 소스/목적지 ip 어드레스 쌍들에 기초한 ip 네트워크들에서 서비스 거부 공격들에 대한 방어 방법 및 장치 | |
US10135785B2 (en) | Network security system to intercept inline domain name system requests | |
CN105939347B (zh) | 防御域名攻击的方法及装置 | |
US9264440B1 (en) | Parallel detection of updates to a domain name system record system using a common filter | |
JP6460112B2 (ja) | セキュリティシステム、セキュリティ方法およびプログラム | |
US9350754B2 (en) | Mitigating a cyber-security attack by changing a network address of a system under attack | |
WO2016189843A1 (ja) | セキュリティシステム、セキュリティ方法、及びプログラムを記憶する記録媒体 | |
KR20080026122A (ko) | 타겟 희생자 자체-식별 및 제어에 의해 ip네트워크들에서 서비스 거부 공격들에 대한 방어 방법 | |
CN112688900B (zh) | 一种防御arp欺骗和网络扫描的局域网安全防护系统及方法 | |
CN105100048A (zh) | WiFi网络安全鉴定方法、服务器、客户端装置和系统 | |
JPWO2016189841A1 (ja) | セキュリティシステム、セキュリティ方法、及びプログラムを記憶する記録媒体 | |
US20170041297A1 (en) | Unified source user checking of tcp data packets for network data leakage prevention | |
US9762542B2 (en) | Parallel detection of updates to a domain name system record system using a common filter | |
CN110401644A (zh) | 一种攻击防护方法及装置 | |
US9385993B1 (en) | Media for detecting common suspicious activity occurring on a computer network using firewall data and reports from a network filter device | |
CN103747005A (zh) | Dns缓存投毒的防护方法和设备 | |
KR101522139B1 (ko) | DNS 서버 선별 차단 및 Proxy를 이용한 DNS 주소 변경 방법 | |
CN106888192A (zh) | 一种抵抗dns攻击的方法及装置 | |
US20210136030A1 (en) | Method for Sending an Information Item and for Receiving an Information Item for the Reputation Management of an IP Resource | |
US8001243B2 (en) | Distributed denial of service deterrence using outbound packet rewriting | |
CN113206852B (zh) | 一种安全防护方法、装置、设备及存储介质 | |
EP3989509A1 (en) | Method for realizing network dynamics, system, terminal device and storage medium | |
US10320751B2 (en) | DNS server selective block and DNS address modification method using proxy |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
CB02 | Change of applicant information | ||
CB02 | Change of applicant information |
Address after: Binjiang District and Hangzhou city in Zhejiang Province Road 310051 No. 68 in the 6 storey building Applicant after: Hangzhou Dipu Polytron Technologies Inc Address before: Binjiang District and Hangzhou city in Zhejiang Province Road 310051 No. 68 in the 6 storey building Applicant before: Hangzhou Dipu Technology Co., Ltd. |
|
GR01 | Patent grant | ||
GR01 | Patent grant |