CN102404317A - 一种防范dns缓存攻击的方法及装置 - Google Patents
一种防范dns缓存攻击的方法及装置 Download PDFInfo
- Publication number
- CN102404317A CN102404317A CN201110337372XA CN201110337372A CN102404317A CN 102404317 A CN102404317 A CN 102404317A CN 201110337372X A CN201110337372X A CN 201110337372XA CN 201110337372 A CN201110337372 A CN 201110337372A CN 102404317 A CN102404317 A CN 102404317A
- Authority
- CN
- China
- Prior art keywords
- dns
- message
- source port
- request message
- affairs
- 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
Images
Landscapes
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明提供一种防范DNS缓存攻击的装置,该装置包括:请求处理单元,用于对DNS请求报文的源端口和/或事务ID进行随机修改,然后针对修改后的请求报文保存相应的会话特征以及修改记录,并将修改后的请求报文发送给DNS服务器;响应处理单元,用于检查DNS服务器返回的响应报文是否能够匹配到所述会话特征,如果是,则根据修改记录将该响应报文的目的端口和/或事务ID还原为与原始请求报文源端口和/或事务ID一致,然后将还原后的响应报文发送给DNS请求者。本发明能显著提升本地DNS服务器防范缓存攻击的能力。
Description
技术领域
本发明涉及网络安全技术,尤其涉及一种防范DNS缓存攻击的方法及装置。
背景技术
DNS 是域名系统 (Domain Name System) 的缩写,它是由解析器和域名服务器组成的。域名服务器(DNS Server)是指保存有该网络中所有主机的域名和对应IP地址,并具有将域名转换为IP地址功能的服务器。请参考图1,一次正常的域名解析流程大体包括以下处理:
首先由客户端发起域名解析请求,本地DNS服务器收到客户端的域名请求后,会去查找自己的管辖域,如果请求的是自己管辖域的域名,就将结果返回给客户端;如果不是自己管辖域的,会在缓存中查找,若没有找到,则会向上一级DNS 服务器发起请求,上一级服务器将解析结果通过DNS Reply报文返回给本地DNS服务器,此时本地DNS服务器将解析结果存入缓存,以便以后再有请求解析该域名时,可以直接返回解析结果,同时会将解析结果返回给本次请求解析该域名的客户端。
近年来DNS攻击事件屡屡发生,比如此前暴风影音DNS遭遇攻击事件。目前针对DNS缓存进行攻击式攻击的行为非常常见。请参考图2以及图3,DNS 缓存攻击主要有两类:
第一类,DNS服务器会按照一定的机制对自己的缓存进行更新。缓存更新时,需要向上级服务器发送请求。而攻击者则向DNS 服务器发送精心构造的DNS reply报文。比如说,如果DNS 服务器更新www.google.com域名时,攻击者向DNS 服务器发送精心构造的DNS reply报文,就有可能攻击成功,将www.google.com域名对应的IP地址改成攻击者指定的IP地址。
第二类,攻击者刻意利用一个不存在的某个域名的二级域名来发送请求,这样DNS 服务器由于无法解析自然会向上级DNS服务器发送域名解析请求;这个时候,攻击者则向DNS 服务器发送精心构造的DNS reply报文,就有可能攻击成功。如攻击者想攻击www.google.com,它就可以发送aa.google.com(仅仅是示例,假设该域名并不存在)给DNS服务器,这个时候,攻击者发送精心构造的DNS reply 报文,此报文回复的内容是“aa.google.com域名不存在,但是其在附加资源里将www.google.com改成攻击者指定的IP”,这样一来DNS 缓存攻击成功。针对目前的两种DNS缓存攻击,业界还没有简单且行之有效的解决方案。
发明内容
有鉴于此,本发明提供一种防范DNS缓存攻击的装置,其应用于DNS安全设备中,该装置包括:
请求处理单元,用于对收到的DNS请求报文的源端口进行随机修改,然后针对修改后的请求报文保存相应的会话特征以及相应的修改记录,并将修改后的请求报文发送给DNS服务器;
响应处理单元,用于检查DNS服务器返回的响应报文是否能够匹配到所述会话特征,如果是,则根据修改记录将该响应报文的目的端口还原为与原始请求报文源端口一致,然后将还原后的响应报文发送给DNS请求者。
本发明还提供一种防范DNS缓存攻击的方法,其应用于DNS安全设备中,该方法包括:
A、对收到的DNS请求报文的源端口进行随机修改,然后针对修改后的请求报文保存相应的会话特征以及相应的修改记录,并将修改后的请求报文发送给DNS服务器;
B、检查DNS服务器返回的响应报文是否能够匹配到所述会话特征,如果是,则根据修改记录将该响应报文的目的端口还原为与原始请求报文源端口一致,然后将还原后的响应报文发送给DNS请求者。
本发明通过对DNS请求报文的源端口和/或事务ID进行随机性修改,显著提高了本地DNS服务防范缓存攻击的能力。
附图说明
图1典型的DNS请求的处理流程。
图2是一种DNS缓存攻击的原理示意图。
图3是另一种DNS缓存攻击的原理示意图。
图4是本发明防范DNS缓存攻击的流程图。
图5是本发明防范DNS缓存攻击装置的逻辑结构图。
具体实施方式
本发明旨在大幅度提高攻击者对DNS缓存进行攻击的难度,相应使得DNS服务在网络中处于更加安全的境地。通常来说,本地DNS服务器接收到上一级DNS服务器返回的响应报文(DNS reply)报文后会对报文做如下处理:
i.检查reply报文目的端口,在DNS 服务器发起的域名请求(DNS Request)中包含了它自身的UDP端口号,在收到上一级DNS 服务器回复的DNS reply报文后,它会检查端口号,如果不相等的话,就说明不是对DNS 服务器发起请求的响应,协议栈则会丢弃该数据报文。
ii. 检查reply报文问题域
DNS 服务器收到上一级DNS 服务器回复的DNS reply报文,会提取DNS reply报文中的问题域,然后和发起DNS 请求中的问题域比较,如果不一致,则会丢弃该数据报文。
iii. 检查Reply报文事务ID (TID)
在DNS 服务器发出的查询请求中会包含一个TID,用来标识某个查询,在收到的DNS 回复报中同样会包含TID,表示是对某个TID查询请求的结果的响应。DNS服务器会根据TID来判断是它发出的某个请求的响应,如果两个TID不相等的话,则会丢弃该数据报文。
iv. 检查授权域和附加域
授权域和附加域中的域名必须和问题域中的域名是同属于某个域名下的子域名。
如果上述所有条件都满足了,DNS域名服务器就会接受该响应数据包是对它发出的某个查询请求的响应,使用相应数据包中的数据,并缓存结果。综上所述,如果攻击者成功对DNS 服务器缓存攻击,必须要满足上面4个条件,缺一不可。而这个四个条件中,条件二reply 报文问题域和条件四授权域及附加域是很容易满足的,关键是在于满足条件i中的端口号和条件iii中的报文事务ID(TID)。
本申请发明人通过研究攻击行为发现:
DNS报文是基于UDP协议的一种应用。虽然理论上UDP端口号在理论上是16位,但是实际上只有一段很小取值范围的端口被用作UDP报文的源端口。在老式系统中的这个范围是1024/1025-4999/5000,不足4000个组合;在一些新的系统中这个范围是49151-65535,组合提高到约16000。而事务TID也只有16位,变化的组合最多也就只有65536次。而且以上所述仅仅是理论上的可能性,事实上DNS服务器并没有把这些组合的可能性利用起来。比如DNS服务器如果仅仅利用了更小范围的源端口,即随机性很低;而这个情况一旦被攻击者获知,攻击的难度进一步大幅度降低。而且TID的利用上也可能存在同样的问题,TID的随机性未必会完全被利用起来。
所以在现实的网络环境中,理论上以上两个条件组合在一起的可能性组合并不是很多,而实际网络应用中的可能性组合更低。这样一来,攻击都完全可以伪造DNS reply报文,进行穷举攻击. 穷举攻击响应可能在上级DNS响应到达之前到达本地DNS服务器。而通常DNS服务器只接受第一条符合要求的响应,而将后到的响应丢弃,攻击者的目的就达到了。
本发明利用位于DNS安全设备上的防范DNS缓存攻击的装置来大幅度提升攻击者的难度。所述DNS安全设备可以是网络安全设备,也可能是DNS服务器本身,这里仅仅是一个物理意义上的载体。防范DNS缓存攻击装置是一个逻辑意义上的软件和/或硬件装置,其可以前置在DNS服务处理之前的一种安全防护装置,也可以是一个位置部署不受限制的安全装置,其可以是软件实现(即通过CPU运行内存中的软件代码实现),也可以是硬件或者固件实现,或者软硬结合来实现。
请参考图4以及图5,本发明防范DNS缓存攻击装置包括:请求处理单元11、响应处理单元12以及报文检查单元13。该装置运行时执行如下处理流程。
步骤101,检查收到的报文是否为DNS请求或者响应报文,如果发现DNS请求报文,则转步骤102提交请求处理单元处理;如果发现是DNS响应报文,则转步骤103提交响应处理单元处理,本步骤由报文检查单元13执行。
以本发明运行在网络安全设备上为例,通常安全设备都有丰富的报文检查手段,针对各种应用进行安全检查。在进行检查之前通常需要区分报文到底属于哪种具体的应用,然后上送到相应的应用处理模块做处理。DNS是一种常见的应用,可以基于DNS应用的特征将报文过滤出来。而请求报文与响应报文在DNS协议中亦有规定有相应的识别标识。本步骤的实现可以参考现有技术。
进一步来说,本发明需要对本地DNS服务器发出DNS请求报文进行处理,因此可以进一步配置特定的过滤规则,比如根据报文的源IP地址或者MAC地址将本地DNS服务器发出的请求报文过滤出来送给请求处理单元处理;或者DNS服务器是从网络安全设备特定端口与上级服务器通信的,将该特定端口的报文都上送给本发明防范DNS缓存攻击装置就可以了,管理员仅仅需要配置一下ACL的报文上送规则即可。当然这一过滤并不是必须的,比如说本发明如果运行在DNS服务器上则并无此需求,因为DNS服务器本身发出的报文显然会全部经过本发明防范DNS缓存攻击装置。这种方式的好处是CPU负担比较轻,但需要用户配置,智能程度低一些。
更为通用的一种情况是,并不需要区分DNS请求到底是谁发出的,这样做的好处是对使用本发明DNS安全设备的用户而言非常简单,无需进行端口或者过滤的配置,也不需要用户过多地去考虑其组网问题,这种方式会让设备的CPU负担加重一些,因为要额外处理一些并不需要处理的任务。因此是否将属于本地DNS请求报文过滤出来有针对性进行修改,取决于用户的实际需求。
步骤102,对收到的DNS请求报文的源端口或事务ID进行随机修改,然后针对修改后的请求报文保存相应的会话特征以及相应的修改记录,并将修改后的请求报文发送给DNS服务器,其中所述会话特征包括修改后的源端口或事务ID。本步骤由请求处理单元11执行。
假设当前的DNS请求者就是本地DNS服务器向上级发出的(还可能是上网用户主机发出的,本发明可以采用相同流程进行处理),当收到DNS服务器发出的DNS请求报文时,这表明DNS服务器有可能需要更新内部的缓存,或者是DNS服务器遇到无法解析的域名需要上级的协助;这一时刻正是最容易被攻击者利用的时候。以修改源端口为例(事务ID的修改与还原的原理一致),本发明在此将DNS请求报文进行修改,使得其首先在源端口上呈现出更高的随机性。由于报文的源端口一共有16比特的长度,经过本发明的修改,其组合可能性一下子提升到了65535种可能;重要的是这一修改并不会影响正常的业务通信,因为本发明后续流程还会做还原操作。
在报文修改之后,需要将修改后的报文会话特征保存下来,并且保存该源端口的修改记录,然后再把修改后的请求报文发送给上级DNS服务器。会话特征通常是五元组(也可以是其他特征与源端口或事务ID的组合),其包括报文源IP地址、目的IP地址、源端口、目的端口以及协议类型。当响应报文返回的时候,会话特征可以帮助我们找到对应的会话。然后对进行各种检查确定响应报文是否合法。
进一步来说,考虑到有些DNS服务器可能没有对16比特的TID(报文事务ID)的随机性加以合理利用。本发明进一步可以对TID进行随机修改,并且将TID作为一个新的会话特征保存在存储单元(参考图5,未标号)中,在本实施方式中,会话特征就变成了六元组。请参考表1的示例:
源IP | 目的IP | 源端口 | 目的端口 | 协议类型 | TID | 原始源端口 | 原始TID |
1.1.1.1 | 2.2.2.2 | 123 | 456 | 11 | 789 | 111 | 222 |
……. | ……. | ……. | ……. | ……. | ……. | ……. | ……. |
……. | ……. | ……. | ……. | ……. | ……. | ……. | ……. |
表1
步骤103,检查DNS服务器返回的响应报文是否能够匹配到所述会话特征,如果是,则根据修改记录将该响应报文的目的端口还原为与原始请求报文源端口一致,然后将还原后的响应报文发送给DNS请求者;本步骤由响应处理单元12执行。
上级DNS服务器会对DNS服务器的请求进行响应。这个响应报文的目的端口与其收到的请求报文的源端口是一样的,也就是上述修改后的源端口(如表1中的123)。然而本发明防范DNS缓存攻击装置除了会收到上级DNS服务器返回的合法响应报文,还可能会收到攻击者构造的响应报文。因此本发明需要利用表1来去区分合法报文与非法攻击报文。如果报文的五元组(或者六元组)无法匹配,则说明其是非法的。在六元组的情况下,本发明将随机性提升到了65535*65535,这样的随机性被攻击的难度很高。
对于合法报文,显然需要根据表1中的记录将响应报文修改回来,主要是目的端口要修改为与原始的源端口一直,TID要修改会原始的TID。因为DNS服务器需要检查源端口以及TID,因此本发明需要通过再一次修改为DNS服务器还原出“正确”的合法响应报文。由此可见,其实本发明的修改和还原过程对于发出DNS请求的设备来说是透明的,请求者不会感知到这个过程,所以普通终端发出的DNS请求也可以被修改,而且不影响其使用;达到了防攻击的同时不影响上网用户使用,而且安全设备的管理员可以减少配置工作。步骤101中讨论了另一情况,即通过报文检查单元11将本地DNS服务器的请求报文过滤出来,因为普通上网用户的DNS请求并不需要进行修改和还原(虽然修改和还原对其使用也没有影响,但加重CPU负担),这是一种进一步针对减轻CPU负担进行的优化,如何设计取决于购买设备用户的需求。
请参考表1,极限情况下,假设DNS服务器根本未利用源端口以及TID的随机性,假设源端口固定为111,TID固定为222。在现有技术中,攻击者可以准确地构造出攻击报文,都完全不需要进行穷举攻击。而一旦运用了本发明,则攻击者就算知道DNS服务器源端口和TID是固定的,也是无济于事,因为本发明的修改机制让其随机性提升到最高65535*65535种可能,也就是说本发明可以让管理者无需关注DNS服务器自身源端口和/或TID的随机性,无论管理者如何配置和使用其DNS服务器,攻击者都可能需要面对最高65535*65535种可能性的强大障碍。即便对比于现有技术中安全措施较好的情况而言,本发明对DNS请求报文的随机性也有3-10倍的提升。
以上所描述的仅仅是本发明较佳的实现方式,并不用以限定本发明的保护范围,任何等同的变化和修改皆应涵盖在本发明的保护范围之内。
Claims (10)
1.一种防范DNS缓存攻击的装置,其应用于DNS安全设备中,其特征在于,该装置包括:
请求处理单元,用于对收到的DNS请求报文的源端口或事务ID进行随机修改,然后针对修改后的请求报文保存相应的会话特征以及相应的修改记录,并将修改后的请求报文发送给DNS服务器,其中所述会话特征包括修改后的源端口或事务ID;
响应处理单元,用于检查DNS服务器返回的响应报文是否能够匹配到所述会话特征,如果是,则根据修改记录将该响应报文的目的端口或事务ID还原为与原始请求报文源端口或事务ID一致,然后将还原后的响应报文发送给DNS请求者。
2.根据权利要求1所述的装置,其特征在于,所述请求处理单元进一步用于将所述DNS请求报文的源端口以及事务ID均进行随机修改。
3.根据权利要求1所述的装置,其特征在于,所述会话特征包括报文源IP地址、目的IP地址、源端口、目的端口以及协议类型。
4.根据权利要求1所述的装置,其特征在于,还包括:报文检查单元,检查收到的报文是否为DNS请求或者响应报文,如果发现DNS请求报文则提交给请求处理单元,如果发现DNS响应报文则提交响应处理单元。
5.根据权利要求4所述的装置,其特征在于,所述报文检查单元,进一步用于将属于本地DNS服务器发出的DNS请求报文过滤出来提交给请求处理单元。
6.一种防范DNS缓存攻击的方法,其应用于DNS安全设备中,其特征在于,该方法包括:
A、对收到的DNS请求报文的源端口或事务ID进行随机修改,然后针对修改后的请求报文保存相应的会话特征以及相应的修改记录,并将修改后的请求报文发送给DNS服务器,其中所述会话特征包括修改后的源端口或事务ID;
B、检查DNS服务器返回的响应报文是否能够匹配到所述会话特征,如果是,则根据修改记录将该响应报文的目的端口或事务ID还原为与原始请求报文源端口或事务ID一致,然后将还原后的响应报文发送给DNS请求者。
7.根据权利要求6所述的方法,其特征在于,步骤A进一步将所述DNS请求报文的源端口以及事务ID均进行随机修改。
8.根据权利要求6所述的方法,其特征在于,所述会话特征包括报文源IP地址、目的IP地址、源端口、目的端口以及协议类型。
9.根据权利要求6所述的方法,其特征在于,还包括:
C、检查收到的报文是否为DNS请求或者响应报文,如果发现DNS请求报文则转步骤A处理,如果发现DNS响应报文则转步骤B处理。
10.根据权利要求9所述的方法,其特征在于,所述步骤C进一步包括:将属于本地DNS服务器发出的DNS请求报文过滤出来,然后转步骤B。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201110337372XA CN102404317A (zh) | 2011-10-31 | 2011-10-31 | 一种防范dns缓存攻击的方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201110337372XA CN102404317A (zh) | 2011-10-31 | 2011-10-31 | 一种防范dns缓存攻击的方法及装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN102404317A true CN102404317A (zh) | 2012-04-04 |
Family
ID=45886103
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201110337372XA Pending CN102404317A (zh) | 2011-10-31 | 2011-10-31 | 一种防范dns缓存攻击的方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102404317A (zh) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104219200A (zh) * | 2013-05-30 | 2014-12-17 | 杭州迪普科技有限公司 | 一种防范dns缓存攻击的装置和方法 |
CN104836810A (zh) * | 2015-05-14 | 2015-08-12 | 江苏大学 | 一种ndn低速缓存污染攻击的协同检测方法 |
CN105939346A (zh) * | 2016-05-04 | 2016-09-14 | 杭州迪普科技有限公司 | 阻止dns缓存攻击方法及装置 |
CN106210173A (zh) * | 2016-07-29 | 2016-12-07 | 杭州迪普科技有限公司 | Dns回复报文的转发方法及装置 |
US20170264590A1 (en) * | 2016-03-09 | 2017-09-14 | Hangzhou Dptech Technologies Co., Ltd. | Preventing dns cache poisoning |
CN107241301A (zh) * | 2016-03-29 | 2017-10-10 | 阿里巴巴集团控股有限公司 | 防御反射攻击的方法、装置和系统 |
CN110401644A (zh) * | 2019-07-12 | 2019-11-01 | 杭州迪普科技股份有限公司 | 一种攻击防护方法及装置 |
CN112187902A (zh) * | 2020-09-21 | 2021-01-05 | 普联国际有限公司 | IPv6隧道模式下的DNS代理方法、装置、存储介质及终端设备 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102035809A (zh) * | 2009-09-29 | 2011-04-27 | 成都市华为赛门铁克科技有限公司 | 缓存中毒的防护方法和防护设备及防护系统 |
CN102111406A (zh) * | 2010-12-20 | 2011-06-29 | 杭州华三通信技术有限公司 | 一种认证方法、系统和dhcp代理服务器 |
WO2011089129A1 (fr) * | 2010-01-19 | 2011-07-28 | Alcatel Lucent | Procede et systeme de prevention d'empoisonnement de caches dns |
-
2011
- 2011-10-31 CN CN201110337372XA patent/CN102404317A/zh active Pending
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102035809A (zh) * | 2009-09-29 | 2011-04-27 | 成都市华为赛门铁克科技有限公司 | 缓存中毒的防护方法和防护设备及防护系统 |
WO2011089129A1 (fr) * | 2010-01-19 | 2011-07-28 | Alcatel Lucent | Procede et systeme de prevention d'empoisonnement de caches dns |
CN102111406A (zh) * | 2010-12-20 | 2011-06-29 | 杭州华三通信技术有限公司 | 一种认证方法、系统和dhcp代理服务器 |
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104219200B (zh) * | 2013-05-30 | 2017-10-17 | 杭州迪普科技股份有限公司 | 一种防范dns缓存攻击的装置和方法 |
CN104219200A (zh) * | 2013-05-30 | 2014-12-17 | 杭州迪普科技有限公司 | 一种防范dns缓存攻击的装置和方法 |
CN104836810A (zh) * | 2015-05-14 | 2015-08-12 | 江苏大学 | 一种ndn低速缓存污染攻击的协同检测方法 |
CN104836810B (zh) * | 2015-05-14 | 2017-11-03 | 江苏大学 | 一种ndn低速缓存污染攻击的协同检测方法 |
US10469532B2 (en) * | 2016-03-09 | 2019-11-05 | Hangzhou Dptech Technologies Co., Ltd. | Preventing DNS cache poisoning |
US20170264590A1 (en) * | 2016-03-09 | 2017-09-14 | Hangzhou Dptech Technologies Co., Ltd. | Preventing dns cache poisoning |
CN107241301A (zh) * | 2016-03-29 | 2017-10-10 | 阿里巴巴集团控股有限公司 | 防御反射攻击的方法、装置和系统 |
CN107241301B (zh) * | 2016-03-29 | 2021-01-29 | 阿里巴巴集团控股有限公司 | 防御反射攻击的方法、装置和系统 |
CN105939346A (zh) * | 2016-05-04 | 2016-09-14 | 杭州迪普科技有限公司 | 阻止dns缓存攻击方法及装置 |
CN106210173A (zh) * | 2016-07-29 | 2016-12-07 | 杭州迪普科技有限公司 | Dns回复报文的转发方法及装置 |
CN110401644A (zh) * | 2019-07-12 | 2019-11-01 | 杭州迪普科技股份有限公司 | 一种攻击防护方法及装置 |
CN112187902A (zh) * | 2020-09-21 | 2021-01-05 | 普联国际有限公司 | IPv6隧道模式下的DNS代理方法、装置、存储介质及终端设备 |
CN112187902B (zh) * | 2020-09-21 | 2023-10-17 | 普联国际有限公司 | IPv6隧道模式下的DNS代理方法、装置、存储介质及终端设备 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102404317A (zh) | 一种防范dns缓存攻击的方法及装置 | |
CN102404318A (zh) | 一种防范dns缓存攻击的方法及装置 | |
WO2018113594A1 (zh) | 防御dns攻击的方法、装置及存储介质 | |
US8495737B2 (en) | Systems and methods for detecting email spam and variants thereof | |
US10594728B2 (en) | Detection of domain name system hijacking | |
JP5624973B2 (ja) | フィルタリング装置 | |
US8949982B2 (en) | Method for administering a top-level domain | |
US8370407B1 (en) | Systems providing a network resource address reputation service | |
US8185510B2 (en) | Distributed security provisioning | |
US8413238B1 (en) | Monitoring darknet access to identify malicious activity | |
US20150319191A1 (en) | Anti-phishing domain advisor and method thereof | |
CN106559382A (zh) | 基于opc协议的安全网关防护系统访问控制方法 | |
US20160366176A1 (en) | High-level reputation scoring architecture | |
US11606385B2 (en) | Behavioral DNS tunneling identification | |
CN102685074B (zh) | 防御网络钓鱼的网络通信系统及方法 | |
CN102137111A (zh) | 一种防御cc攻击的方法、装置和内容分发网络服务器 | |
US20060272008A1 (en) | Method and security system for indentifying and blocking web attacks by enforcing read-only parameters | |
CN104396220A (zh) | 用于安全内容检索的方法和设备 | |
CN102291390A (zh) | 一种基于云计算平台的防御拒绝服务攻击的方法 | |
EP2680543A2 (en) | Improved secondary service updates into DNS system | |
CN105119930A (zh) | 基于OpenFlow协议的恶意网站防护方法 | |
CN108270778B (zh) | 一种dns域名异常访问检测方法及装置 | |
US20150312211A1 (en) | Method and system for generating durable host identifiers using network artifacts | |
KR20080026122A (ko) | 타겟 희생자 자체-식별 및 제어에 의해 ip네트워크들에서 서비스 거부 공격들에 대한 방어 방법 | |
CN106209852A (zh) | 一种基于dpdk的dns拒绝服务攻击防御方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20120404 |