一种应对dns服务器反射放大攻击的解决方法

xiaoxiao2021-2-23  129

一种应对dns服务器反射放大攻击的解决方法
【技术领域】
[0001]本发明属于DNS安全防范技术领域,尤其涉及一种应对DNS服务器反射放大攻击的解决方法。
【背景技术】
[0002]DNS提供了互联网上的一个重要的服务。其本质是建立了人的名字世界和底层的二进制协议地址世界的桥梁。每次,当我们通过互联网开始任何的事务之前,一个DNS的查询过程首先要完成。所以一个轻量级的、快速响应的DNS协议是非常必要的,这样DNS查询过程可以对用户而言透明地完成。DNS解析框架使用UDP作为传输协议,并通过地理分布的具有缓存功能的递归解析器来实现。
[0003]同时在互联网发展过程中,传统的DNS协议也凸显了一些问题。随着互联网的发展,DNS记录的类型和数目逐渐增多,DNS协议逐渐变成了一个非对称的协议,DNS的应答包可能远远大于DNS请求包。这给予了恶意者通过递归解析器对受害者进行DNS放大攻击的机会。使用any类型的查询,攻击者可以通过伪造源地址,将一个DNS查询包经由递归解析器放大,造成受害者网络瘫痪。随着DNSSEC的部署,DNS应答包进一步变大,使得放大攻击的问题变得更为严重。经测试,这种放大攻击最大可以将攻击流放大32倍。
[0004]现有解析器一般有两种应对DNS放大攻击的方式。一种为手动限制解析器答复速率使得攻击者无法在短时间内造成极大的攻击流量以减缓DNS放大攻击。这种方式存在着只能减缓,无法阻止攻击的问题。另一种方式为向任何查询返回truncate使得递归解析器可以只给与真正的用户而非攻击者伪造的用户应答。这种方式的问题在于返回truncate要求用户回退至TCP进行请求,会影响用户正常进行DNS解析的效率。此外这两种方法还存在一个共同问题,只能在运营者发现被攻击时被动的启用防御,无法主动的提前预防攻击。
[0005]另一种能够主动预防DNS放大攻击的方案为DNScookie。其主要手段为使用cookie使得递归服务器可以区分攻击者和用户。具体方案为递归服务器发布一个公用的64位数字作为初始cookie。用户在第一次查询时附带初始cookie,随后的每次查询用户和服务器均随机生成一个64位数字的cookie并在报文内同时携带双方cookie。递归服务器通过校验cookie来识别真实用户。然而该方法存在着部署性差的问题,该方法未被全部部署时,如何处理不支持cookie的用户成为一个难题。如果正常应答,那么攻击者仍可以进行放大攻击。如果不应答,那么不支持cookie的用户将无法接受DNS解析服务。

【发明内容】

[0006]为了防止DD0S放大攻击、保证用户的网络使用安全,同时不影响不支持cookie用户的DNS访问,本发明提出了一种应对DNS服务器反射放大攻击的解决方法,该方法基于TCP回退的DNS cookie,对不支持cookie的用户访问返回DNS truncate使得真实用户可以通过TCP协议进行DNS访问而攻击者无法利用递归服务器进行放大攻击。
[0007]本方法具体包括:
[0008]步骤1、在EDNSO的伪资源记录中加入cookie的字段,包括:为识别伪资源记录为DNS cook i e的唯一编号标识OPT 10N-C0DE、为伪资源记录的长度OPT 10N-LENGTH、由客户端通过自己的IP生成的Client Cookie、由递归服务器通过Client Cookie和自己的IP生成的Server Cookie,Server Cookie在初始阶段缺省;
[0009]步骤2、支持DNScookie的用户在发送每个递归服务器请求时会根据自己的IP生成一个8位的随机cookie,作为伪资源记录附加在DNS请求中;
[0010]步骤3、递归服务器收到用户DNS请求后首先检查用户DNS请求是否附带着cookie,如果不附带cookie,则返回truncate要求用户使用TCP进行重传;如果附带cookie则执行步骤4;
[0011]步骤4、递归服务器检查用户发送的DNS请求是否附带Server Cookie,如果不附带,则递归服务器将应答信息附加上用Client Cookie和自己的IP共同生成的ServerCookie以及Client Cookie返回给客户;如果已经附带了Server Cookie,则检查用户的Server Cookie是否与自己生成的一致,如果是,则将应答信息附上Cl ient Cookie和Server Cookie返回给用户,如否,贝lj返回truncate要求用户使用TCP重传;
[0012]步骤5、当收到递归服务器应答时,用户会核对递归服务器应答的伪资源记录中的Client Cookie是否与自己发送的随机cookie相同,如果相同,则接收此数据,如果不同,贝lj丢弃此数据;
[0013]步骤6、当用户发送下个请求时,用户除附上自己生成的Client Cookie之外,也将收到的应答中的Server Cookie加入到伪资源记录中;如果上次收到的应答因cookie错误被丢弃,则沿用之前的Server Cookie,如果不存在Server Cookie的缓存,则ServerCookie 缺省;
[OOM] 步骤7、不支持DNS cookie的用户发送DNS请求时,会收到truncate回复,随后通过TCP进行DNS协议的服务。
[0015]本发明的有益效果在于:采用本方法的递归服务器可以完全避免自己成为放大攻击的放大器,通过本方法,递归服务器可以将会对cookie不正确的用户或不携带cookie的用户返回truncate要求用户使用TCP进行重传。由于truncate应答的大小于DNS请求包的大小相似,使得攻击者无法通过递归侧进行放大攻击。
[0016]相比传统的手动限速和返回truncate,本方法的优势在于不需要运营者发现递归服务器收到攻击而临时修改配置。启用本方法后,递归服务器可以默认的主动防御放大攻击。与传统的DNS cookie相比,本方法通过对truncate的利用,解决了部署的问题,使得就算没有部署的DNS cookie的用户也可以访问递归服务器获得DNS解析服务。
【附图说明】
[0017]图1为正常情况下本发明中用户与递归服务器交互流程;
[0018]图2为异常(用户不支持cookiewookie错误)时本方法中用户与递归服务器的交互流程;
[0019]图3为未采用本方法时收到攻击者攻击的模式;
[0020]图4为采用本方法时中防止攻击的模式。
【具体实施方式】
[0021 ]下面结合附图,对实施例作详细说明。
[0022]本方法能够有效地防止攻击者利用采用了本方法的递归服务器成为放大攻击的放大器,用时通过TCP回退,保证了未支持cookie的用户对DNS服务的访问。关于实现本方法的技术细节,这里说明一下DD0S攻击,放大攻击,DNS cookie和TCP回退等。
[0023]DD0S(分布式拒绝服务)攻击指借助于客户/服务器技术,将多个计算器联合起来作为攻击平台,对一个或多个目标发动攻击,使得目标的有限资源(包括,磁盘,CPU,网络带宽等)耗尽,正常用户无法访问服务。
[0024]放大攻击指利用DNS协议的不对等性即DNS应答包大于DNS请求包的性质,利用递归服务器为杠杆放大自己的DD0S攻击。具体做法为伪造攻击目标的IP地址向递归服 务器发送特定的DNS请求,使得服务器将几倍于请求包大小的应答包发至受害者机器,耗尽受害者网络资源。随着DNSSEC的部署,DNS应答包进一步变大,使得攻击者甚至可以通过递归服务器将攻击放大十几倍。
[0025]预防放大攻击的关键为在递归服务器侧如何有效的区别攻击者伪造的用户和真正的用户,本方法使用DNS cookie来实现这一目标。由于传统的DNS协议已经没有足够的字段进行协议扩展,而EDNS0协议是一个向后兼容并支持DNS进一步扩展的协议。所以我们的扩展方法以H)NS0为基础,并在EDNS0之上增加一些新的字段来实现本方法。
[0026]步骤1、在EDNS0的伪资源记录中加入cookie的字段,包括:为识别伪资源记录为DNS cook i e的唯一编号标识OPT 10N-C0DE、为伪资源记录的长度OPT 10N-LENGTH、由客户端通过自己的IP生成的Client Cookie、由递归服务器通过Client Cookie和自己的IP生成的Server Cookie,Server Cookie在初始阶段缺省;
[0027]步骤2、支持DNScookie的用户在发送每个递归服务器请求时会根据自己的IP生成一个8位的随机cookie,作为伪资源记录附加在DNS请求中;
[0028]步骤3、递归服务器收到用户DNS请求后首先检查用户DNS请求是否附带着cookie,如果不附带cookie,则返回truncate要求用户使用TCP进行重传;如果附带cookie则执行步骤4;
[0029]步骤4、递归服务器检查用户发送的DNS请求是否附带Server Cookie,如果不附带,则递归服务器将应答信息附加上用Client Cookie和自己的IP共同生成的ServerCookie以及Client Cookie返回给客户;如果已经附带了Server Cookie,则检查用户的Server Cookie是否与自己生成的一致,如果是,则将应答信息附上Cl ient Cookie和Server Cookie返回给用户,如否,贝lj返回truncate要求用户使用TCP重传;
[0030]步骤5、当收到递归服务器应答时,用户会核对递归服务器应答的伪资源记录中的Client Cookie是否与自己发送的随机cookie相同,如果相同,则接收此数据,如果不同,贝lj丢弃此数据;
[0031]步骤6、当用户发送下个请求时,用户除附上自己生成的Client Cookie之外,也将收到的应答中的Server Cookie加入到伪资源记录中;如果上次收到的应答因cookie错误被丢弃,则沿用之前的Server Cookie,如果不存在Server Cookie的缓存,则ServerCookie 缺省;
[0032]步骤7、不支持DNS cookie的用户发送DNS请求时,会收到truncate回复,随后通过TCP进行DNS协议的服务。
[0033]以一次DNS反射放大攻击为例,说明本方法防范DNS反射攻击的工作过程:
[0034]攻击者通过伪造DNS请求中的源IP地址,将自己伪装成受害者向递归服务器请求特定域名。期望通过服务器返回很大的应答包给受害者,从而放大攻击流。经测试,在部署DNSSEC的情况下,攻击者可以用44M/S的流量创造出1440M/S的攻击流量。
[0035]递归服务器收到攻击者的请求后,校验cookie,并以client cookie和自己的IP为依据,生成Server cookie发给用户。用于次报文中不含DNS应答内容。DNS应答包与请求包大小大致相等,攻击流量无法被放大,攻击失败。
[0036]此实施例仅为本发明较佳的【具体实施方式】,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到的变化或替换,都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应该以权利要求的保护范围为准。
【主权项】
1.一种应对DNS服务器反射放大攻击的解决方法,其特征在于,包括: 步骤1、在EDNSO的伪资源记录中加入cookie的字段,包括:为识别伪资源记录为DNScookie的唯一编号标识0PT10N-C0DE、为伪资源记录的长度0PT10N-LENGTH、由客户端通过自己的IP生成的Client Cookie、由递归服务器通过Client Cookie和自己的IP生成的Server Cookie,Server Cookie在初始阶段缺省; 步骤2、支持DNS cookie的用户在发送每个递归服务器请求时会根据自己的IP生成一个8位的随机cookie,作为伪资源记录附加在DNS请求中; 步骤3、递归服务器收到用户DNS请求后首先检查用户DNS请求是否附带着cookie,如果不附带cookie,则返回truncate要求用户使用TCP进行重传;如果附带cookie则执行步骤4; 步骤4、递归服务器检查用户发送的DNS请求是否附带Server Cookie,如果不附带,则递归服务器将应答信息附加上用Client Cookie和自己的IP共同生成的Server Cookie以及Client Cookie返回给客户;如果已经附带了Server Cookie,则检查用户的ServerCookie是否与自己生成的一致,如果是,则将应答信息附上Client Cookie和ServerCookie返回给用户,如否,贝lj返回truncate要求用户使用TCP重传; 步骤5、当收到递归服务器应答时,用户会核对递归服务器应答的伪资源记录中的Client Cookie是否与自己发送的随机cookie相同,如果相同,则接收此数据,如果不同,贝lj丢弃此数据; 步骤6、当用户发送下个请求时,用户除附上自己生成的Client Cookie之外,也将收到的应答中的Server Cookie加入到伪资源记录中;如果上次收到的应答因cookie错误被丢弃,则沿用之前的Server Cookie,如果不存在Server Cookie的缓存,贝ijServer Cookie缺省; 步骤7、不支持DNS cookie的用户发送DNS请求时,会收到truncate回复,随后通过TCP进行DNS协议的服务。
【专利摘要】本发明属于DNS安全防范技术领域,尤其涉及一种应对DNS服务器反射放大攻击的解决方法,在EDNS0的伪资源记录中加入cookie的字段;用户在发送请求时会生成随机cookie,递归服务器收到请求后检查是否有cookie,如否,则返回truncate要求用户使用TCP进行重传;如是则检查是否附带Server?Cookie,如果否,则将其与Client?Cookie返回,如是,则检查用户的与自己是否一致,如果是,则返回给用户,如否,则返回truncate要求用户使用TCP重传;用户核对Client?Cookie是否与随机cookie相同,如是,则接收此数据,如否,则丢弃。
【IPC分类】H04L29/12, H04L29/06
【公开号】CN105491179
【申请号】CN201510818674
【发明人】万润夏, 宋林健, 刘 东, 余冬, 王爱民, 李凤民, 李震, 潘居臣, 龚道彪
【申请人】北京天地互连信息技术有限公司, 中国石油天然气股份有限公司华北油田分公司
【公开日】2016年4月13日
【申请日】2015年11月23日

最新回复(0)