著录项信息
专利名称 | 查询请求报文处理方法、装置及系统 |
申请号 | CN200910236448.2 | 申请日期 | 2009-10-22 |
法律状态 | 暂无 | 申报国家 | 中国 |
公开/公告日 | 2011-05-04 | 公开/公告号 | CN102045331A |
优先权 | 暂无 | 优先权号 | 暂无 |
主分类号 | H04L29/06 | IPC分类号 | H;0;4;L;2;9;/;0;6;;;H;0;4;L;9;/;0;0查看分类表>
|
申请人 | 成都市华为赛门铁克科技有限公司 | 申请人地址 | 四川省成都市高新区西部园区清水河片区
变更
专利地址、主体等相关变化,请及时变更,防止失效 |
权利人 | 华为数字技术(成都)有限公司 | 当前权利人 | 华为数字技术(成都)有限公司 |
发明人 | 蒋武;杨莉 |
代理机构 | 北京同立钧成知识产权代理有限公司 | 代理人 | 刘芳 |
摘要
本发明实施例提供一种查询请求报文处理方法、装置及系统。该方法包括接收符合域名系统格式的查询请求报文;验证查询请求报文是否来源于真实的客户机;若验证获知查询请求报文来源于真实的客户机,则获取对应于查询请求报文请求访问的域名服务器的访问统计信息;根据访问统计信息和阈值对查询请求报文进行处理,阈值用于标识允许同时访问域名服务器的最大次数。本发明实施例中,网关在接收到符合域名系统格式、且来源于真实的客户机的查询请求报文后,根据阈值来限制真实客户机同时访问DNS服务器的最大次数,提高DNS服务器的工作稳定性,保障网络服务质量,增强了DNS系统中的网络安全防护性能。
1.一种查询请求报文处理方法,其特征在于,包括:
接收符合域名系统格式的查询请求报文;
验证所述查询请求报文是否来源于真实的客户机;
若验证获知所述查询请求报文来源于真实的客户机,则获取对应于所述查询请求报文请求访问的域名服务器的访问统计信息;
根据所述访问统计信息和阈值对所述查询请求报文进行处理,所述阈值用于标识允许同时访问所述域名服务器的最大次数;
其中,所述查询请求报文包括所述客户机所要访问的域名服务器的标识信息。
2.根据权利要求1所述的查询请求报文处理方法,其特征在于,所述根据所述访问统计信息和阈值对所述查询请求报文进行处理包括:
若所述访问统计信息小于所述阈值,则向所述域名服务器转发所述查询请求报文,并更新所述访问统计信息;或
若所述访问统计信息大于或等于所述阈值,则丢弃所述查询请求报文。
3.根据权利要求1或2所述的查询请求报文处理方法,其特征在于,所述验证所述查询请求报文是否来源于真实的客户机包括:
根据用于记录合法客户机的白名单中包括所述客户机的IP地址,验证所述查询请求报文是否来源于真实的客户机。
4.根据权利要求3所述的查询请求报文处理方法,其特征在于,所述方法还包括:
若用于记录合法客户机的白名单中不包括所述客户机的IP地址,则通过向所述客户机返回请求应答报文对所述客户机发起验证,所述请求应答报文中的TC字段表示该字段允许被截断;
当接收所述客户机根据所述应答报文发送的TCP连接请求时,通过与所述客户机进行三次握手连接建立与所述客户机之间的TCP连接,获知所述客户机为真实客户机,将所述客户机的IP地址加入所述白名单。
5.根据权利要求4所述的查询请求报文处理方法,其特征在于,还包括:
接收所述客户机通过所述TCP连接发送的第二查询请求报文;
获取对应于所述第二查询请求报文请求访问的域名服务器的访问统计信息;
当所述访问统计信息小于所述阈值时,将所述第二查询请求报文通过UDP协议发送给所述域名服务器;
当所述访问统计信息大于或等于所述阈值时,丢弃所述第二查询请求报文。
6.一种查询请求报文处理装置,其特征在于,包括:
接收模块,用于接收符合域名系统格式的查询请求报文;
验证模块,用于验证所述查询请求报文是否来源于真实的客户机;
获取模块,用于若通过所述验证模块验证获知所述查询请求报文来源于真实的客户机,则获取对应于所述查询请求报文请求访问的域名服务器的访问统计信息;
处理模块,用于根据所述访问统计信息和阈值对所述查询请求报文进行处理,所述阈值用于标识允许同时访问所述域名服务器的最大次数;
其中,所述查询请求报文包括客户机所要访问的域名服务器的标识信息。
7.根据权利要求6所述的查询请求报文处理装置,其特征在于,所述处理模块包括:
第一处理子模块,用于若所述访问统计信息小于所述阈值,则向所述域名服务器转发所述查询请求报文,并更新所述访问统计信息;
第二处理子模块,用于若所述访问统计信息大于或等于所述阈值,则丢弃所述查询请求报文。
8.根据权利要求7所述的查询请求报文处理装置,其特征在于,所述验证模块包括:
第一验证子模块,用于根据用于记录合法客户机的白名单中包括所述客户机的IP地址,验证所述查询请求报文是否来源于真实的客户机;
第二验证子模块,用于若用于记录合法客户机的白名单中不包括所述客户机的IP地址,则通过向所述客户机返回请求应答报文对所述客户机发起验证,所述请求应答报文中的TC字段表示该字段允许被截断。
9.根据权利要求8所述的查询请求报文处理装置,其特征在于,所述第二验证子模块还用于,当接收所述客户机根据所述应答报文发送的TCP连接请求时,通过与所述客户机进行三次握手连接建立与所述客户机之间的TCP连接,获知所述客户机为真实客户机,将所述客户机的IP地址加入所述白名单。
10.一种查询请求报文处理系统,包括用于发送查询请求报文的客户机,以及对应于所述查询请求报文请求访问的域名服务器,其特征在于,还包括如权利要求6至9任一权利要求所述的查询请求报文处理装置。
查询请求报文处理方法、装置及系统\n技术领域\n[0001] 本发明实施例涉及通信技术领域,特别涉及一种查询请求报文处理方法、装置及系统。\n背景技术\n[0002] 域名系统(Domain Name System,DNS)是一种以层次结构分布的命名系统。在如互联网Internet之类的传输控制协议/网间协议(TransmissionControl Protocol/Internet Protocol,TCP/IP)网络中,使用DNS名字来定位计算机,如果在应用程序中输入DNS名,就可以由DNS服务器中的数据库提供包括IP地址在内的与名称相关的信息。\n[0003] 客户端和域名服务器(DNS服务器)之间一般是使用用户数据报协议\n(UserDatagram Protocol,UDP)传输报文,在UDP传输方式下,客户端存在重传机制,在没有收到服务器的响应报文后会重复向DNS服务器发送报文。由于UDP方式不采用建立连接方式进行通信,也没有连接握手等机制,因此DNS服务器容易在网络上遭受攻击。现有技术中一般通过在DNS服务器和客户端之间设置防火墙进行安全防护,例如通过预先建立的攻击特征库,对访问DNS服务器的报文进行单包或多包特征匹配来进行防范,允许正常报文通过,并过滤掉攻击报文。\n[0004] 发明人在实现本发明的过程中发现,可能由于特殊原因,或是攻击,或者网络故障,会出现针对同一DNS服务器的大规模正常的、真实客户机的DNS爆发式请求,所述的正常的真实客户机的DNS请求为真实客户机发起的、并且是查询实际域名的DNS请求,在这些情况下,可能导致该DNS服务器堵塞,工作稳定性降低,甚至造成DNS服务器瘫痪,引发大规模的网络故障,导致网络服务质量下降。\n发明内容\n[0005] 本发明实施例提供一种查询请求报文处理方法、装置及系统,能够提高DNS服务器的工作稳定性,增强DNS系统中的网络安全防护性能。\n[0006] 本发明实施例提供一种查询请求报文处理方法,包括:\n[0007] 接收符合域名系统格式的查询请求报文;\n[0008] 验证所述查询请求报文是否来源于真实的客户机;\n[0009] 若验证获知所述查询请求报文来源于真实的客户机,则获取对应于所述查询请求报文请求访问的域名服务器的访问统计信息;\n[0010] 根据所述访问统计信息和阈值对所述查询请求报文进行处理,所述阈值用于标识允许同时访问所述域名服务器的最大次数。\n[0011] 本发明实施例提供一种查询请求报文处理装置,包括:\n[0012] 接收模块,用于接收符合域名系统格式的查询请求报文;\n[0013] 验证模块,用于验证所述查询请求报文是否来源于真实的客户机;\n[0014] 获取模块,用于若通过所述验证模块验证获知所述查询请求报文来源于真实的客户机,则获取对应于所述查询请求报文请求访问的域名服务器的访问统计信息;\n[0015] 处理模块,用于根据所述访问统计信息和阈值对所述查询请求报文进行处理,所述阈值用于标识允许同时访问所述域名服务器的最大次数。\n[0016] 本发明实施例提供一种查询请求报文处理系统,包括用于发送查询请求报文的客户机,以及对应于所述查询请求报文请求访问的域名服务器,还包括上述的查询请求报文处理装置。\n[0017] 本发明实施例提供的查询请求报文处理方法、装置及系统中,查询请求报文处理装置例如网关在接收到符合域名系统格式的查询请求报文后,通过验证获知所述查询请求报文是否来源于真实的客户机,再根据预设的阈值来限制真实客户机同时访问DNS服务器的最大次数,防止因同时出现大规模DNS请求而造成DNS服务器发生堵塞甚至瘫痪,提高了DNS服务器的工作稳定性,保障网络服务质量,增强了DNS系统中的网络安全防护性能。\n附图说明\n[0018] 为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。\n[0019] 图1为本发明查询请求报文处理方法实施例一流程图;\n[0020] 图2为本发明实施例中DNS协议定义的报文格式示意图;\n[0021] 图3为本发明实施例中DNS协议定义的报文中标志字段格式的示意图;\n[0022] 图4为本发明实施例中DNS协议定义的“QUESTION”部分格式示意图;\n[0023] 图5为本发明实施例中DNS协议定义的DNS资源记录部分格式示意图;\n[0024] 图6为本发明查询请求报文处理方法实施例二流程图;\n[0025] 图7为本发明查询请求报文处理装置实施例一结构示意图;\n[0026] 图8为本发明查询请求报文处理装置实施例二结构示意图;\n[0027] 图9为本发明查询请求报文处理系统实施例组成示意图。\n具体实施方式\n[0028] 本发明实施例针对现有技术中,在对同一DNS服务器的大规模正常的、真实客户机的DNS爆发式请求的情况下,导致该DNS服务器堵塞,工作稳定性降低等缺陷,提供一种解决方式即利用DNS的应用层分析来发现大规模请求异常,并采用动态策略来过滤异常流量从而保护后面的DNS服务器,所述的正常的真实客户机的DNS请求为真实客户机发起的、并且是查询实际域名的DNS请求。\n[0029] 具体可以是在DNS服务器前端,也就是在客户机与DNS服务器之间设置一分布式拒绝服务攻击防护装置,该分布式拒绝服务攻击防护装置可以为一个独立的设备,也可以设置在网关等设备上,通过该保护装置对客户机发送的查询请求报文的格式,以及该客户机是否为真实客户机进行验证,并在验证获知查询请求报文符合域名系统格式,并且来源于真实客户机后,通过预定的允许同时访问所述域名服务器的最大次数对同时访问同一DNS服务器的查询请求报文进行控制处理,完成DDOS防护功能。本发明实施例提供的解决方案不但可以对不符合域名系统格式和非真实客户机的查询请求报文,进行过滤处理,而且还可以对由符合域名系统格式、且来源于真实客户机的查询请求报文的洪水攻击进行处理,有效地实现对后续的DNS服务器的保护,克服了大规模正常DNS请求造成的DNS服务器瘫痪的缺陷,提高了DNS服务器的工作稳定性。\n[0030] 图1为本发明查询请求报文处理方法实施例一流程图,如图1所示,该方法包括:\n[0031] 步骤100,接收符合域名系统格式的查询请求报文;\n[0032] 设置于数个客户机和DNS服务器之间的查询请求报文处理装置即上述的分布式拒绝服务攻击防护装置,首先接收客户机发往DNS服务器的查询请求报文,然后对该查询请求报文的格式进行验证检验是否符合DNS格式,只有符合DNS格式的查询请求报文才被处理,这样可以避免一些随机的UDP洪水攻击。如果通过验证获知,该查询请求报文的格式不符合DNS格式,则可以直接丢弃该查询请求报文而不做其他处理,或者向发送该查询请求报文的客户机返回拒绝放行的应答报文等。\n[0033] 步骤101,验证所述查询请求报文是否来源于真实的客户机;\n[0034] 查询请求报文处理装置在验证获知客户机发送的查询请求报文的格式符合DNS格式后,还要继续验证该查询请求报文是否来源真实的客户机,而不是由一些非法的,伪造的客户机发送的,为了保证DNS服务器的安全,应仅对来至于真实客户机的询请求报文进行处理,对于那些由非法客户机发送的攻击报文应予以拒绝。\n[0035] 步骤102,若验证获知所述查询请求报文来源于真实的客户机,则获取对应于所述查询请求报文请求访问的域名服务器的访问统计信息;\n[0036] 查询请求报文处理装置通过上述的两步判断后,若获知接收到的查询请求报文符合NDS格式,且来源于真实客户机后,表明该查询请求报文可以被处理。这样便将不符合DNS格式,或者来源于非真实客户机的查询请求报文滤除掉了,实现了DNS服务器的初步保护。\n[0037] 为了进一步确保DNS服务器不受大规模正常的、真实客户机的DNS爆发式请求的攻击,本实施例中还要实施进一步的防护措施,具体可以是根据实际情况和经验值,预先在查询请求报文处理装置上设置一阈值,该阈值用于标识允许同时访问DNS服务器的最大次数,也就是说,该阈值限定了同时访问DNS服务器所允许的最大值,若同时访问的次数小于或等于该阈值,则可以保证该DNS服务器的正常工作;若同时访问的次数大于该阈值,则不能保证该DNS服务器的正常工作,有可能造成该DNS服务器的堵塞、瘫痪等,引发大规模的网络故障,导致网络服务质量下降。\n[0038] 具体的,每一个DNS服务器均可以对应有一个阈值,根据DNS服务器处理能力的不同,对应的阈值也可以不同。具体的,查询请求报文处理装置可以对访问同一DNS服务器的所有请求进行统计并记录,得到对应于每一个DNS服务器的访问统计信息。而且,每增加一次对该DNS服务器的访问,就要同步更新对应的访问统计信息例如作加一处理;当然当一次访问结束后,也要同步更新对应的访问统计信息例如作减一处理等。查询请求报文处理装置中记录的DNS服务器的访问统计信息,可以表明当前同时访问该DNS服务器的统计次数。\n[0039] 步骤103,根据所述访问统计信息和阈值对所述查询请求报文进行处理,所述阈值用于标识允许同时访问所述域名服务器的最大次数。\n[0040] 查询请求报文处理装置在获取到对应于接收到的查询请求报文的访问统计信息后,可以根据该访问统计信息和对应于该DNS服务器的阈值,对接收到的查询请求报文进行处理。\n[0041] 具体处理方式包括:若访问统计信息小于阈值,则向对应的DNS服务器转发该查询请求报文,并更新访问统计信息例如将访问统计信息中的次数加一等;若访问统计信息大于或等于阈值,则丢弃接收到的查询请求报文不做其他处理。这样便可以防止大规模正常的、真实客户机的DNS爆发式请求的攻击,进一步地保护了DNS服务器,保障DNS服务器的工作稳定性。\n[0042] 本发明实施例提供的查询请求报文处理方法中,查询请求报文处理装置在接收到符合域名系统格式的查询请求报文后,通过验证获知所述查询请求报文是否来源于真实的客户机,再根据预设的阈值来限制真实客户机同时访问DNS服务器的最大次数,防止因同时出现大规模DNS请求而造成DNS服务器发生堵塞甚至瘫痪,提高了DNS服务器的工作稳定性,保障网络服务质量,增强了DNS系统中的网络安全防护性能。\n[0043] 在上述方法实施例中,判断查询请求报文的格式是否符合DNS格式的具体判断方式可以通过如下方式进行判断,例如包括:\n[0044] 判断查询请求报文的报头格式是否符合DNS格式。\n[0045] 在DNS协议中,定义了查询报文和响应报文的格式,图2为本发明实施例中DNS协议定义的报文格式示意图,如图2所示,DNS报头一般为12字节,其中16位的“ID”字段表示标识可以由客户程序设置并通过服务器返回结果;客户程序可以通过“ID”字段确定响应与查询是否匹配。16位的标志(flags)字段,被划分为若干字段,图3为本发明实施例中DNS协议定义的报文中标志字段格式的示意图,如图3所示,“flags”字段中各位的含义为:\n[0046] “QR”:为0表示问题,为“1”表示回答;\n[0047] 请求码(opcode):为“0”表示标准请求,为“1”表示反向请求,为“2”表示服务器状态请求;\n[0048] “AA”:为“1”表示授权回答;\n[0049] “TC”:为“1”表示可以截断;\n[0050] “RD”:为“1”表示可以期望递归,查询中设置,应答中返回,表示必须处理;\n[0051] “RA”:为“1”表示可用递归,如果DNS服务器支持递归,则在应答中把其置1;\n[0052] 零位(zero):表示这3位必须是“0”;\n[0053] 差错码(rcode):为“0”表示无差错,为“3”表示名字差错。\n[0054] 根据DNS协议规定的报头格式,可以检查查询请求报文的报文头的格式是否符合DNS格式,例如:可以检查“opcode”字段是否为“0”、“1”或“2”,检查“TC”字段是否为“1”,检查“Zero”字段是否为“0”等。\n[0055] 上述各字段的数值可以由二进制码表示。\n[0056] 在上述方法实施例中,判断查询请求报文的格式是否符合DNS格式的具体判断方式还可以通过如下方式进行判断,例如包括:\n[0057] 判断查询请求报文中“QUESTION”部分的格式是否符合DNS格式。\n[0058] 图4为本发明实施例中DNS协议定义的“QUESTION”部分格式示意图,如图4所示,通常DNS协议中的“QUESTION”部分由三个部分组成:问题名(nameof the question)、问题类型(type of question)和查询类型(type of query)。其中,“name of the question”部分是要查找的名字,可以为一个或多个标识符的序列。每个标识符以首字节的计数值来说明随后标识符的字节长度,每个名字以最后字节为“0”结束,长度为“0”的标识符为根标识符。协议中规定每个标识符最大长度63,整个查询名不定长,不需填充字符。例如:“www.heike.com”的“name of the question”部分可以表达为:“[3|w|w|w|5|h|e|i|k|e|3|c|o|m|0]”。再例如:“44.33.88.123.in-addr.arpa”的“name of the question”部分可以表达为:“[2|4|4|2|3|3|2|8|8|3|1|2|3|7|i|n|-|a|d|d|r|4|a|r|p|a|0]”。\n[0059] 另外,常用的“type of question”部分为A类型即查询型,如果是反向查询,则可以填充为反向域名解析(PTR)型。\n[0060] “type of query”部分通常为“1”,表示互联网地址。\n[0061] 根据DNS协议规定的“QUESTION”部分的格式,可以检查查询请求报文中对应“QUESTION”部分是否符合DNS格式,例如:检查报文对应的“name of thequestion”部分的格式是否符合DNS格式,或“type of question”部分类型是否是A型或PTR型等,或检查“type of query”部分类型是否为“1”等。\n[0062] 判断查询请求报文的格式是否符合DNS格式的具体判断方式还可以通过如下方式进行判断,例如包括:\n[0063] 判断查询请求报文中DNS资源记录部分的格式是否符合DNS格式。\n[0064] 具体的,报文的DNS资源记录部分包括回答号(numbers of answer)字段、授权(number of RR authority)字段和附加信息(number ofsupplementary RR)字段三部分,并可以采用资源记录(Resource Record;简称:RR)的格式。图5为本发明实施例中DNS协议定义的DNS资源记录部分格式示意图,如图5所示,资源记录的域名(name of the domain)字段主要是记录资源数据对应的名字,格式可参照上述的“QUESTION”部分格式。\n类型(type)字段说明RR的类型码;生存时间(time to live;简称:TTL)字段是客户程序保存该记录的秒数,例如为2天;资源数据长度(resource datalength)字段说明资源数据的数量;资源数据(resource data)字段则是对应的查询结果,例如域名查询IP的该资源数据字段为4字节的IP地址。\n[0065] 通过上述判断方法,查询请求报文处理装置可以对接收到的查询请求报文的格式是否符合规定的DNS格式进行判断,防止一些随机的UDP洪水攻击。\n[0066] 图6为本发明查询请求报文处理方法实施例二流程图,本实施例将结合图6介绍判断查询请求报文是否来源于真实客户机的具体判断流程,如图6所示,\n[0067] 步骤200,查询请求报文处理装置接收客户机发送的UDP查询请求报文;\n[0068] 步骤201,查询请求报文处理装置判断该查询请求报文的格式是否符合DNS格式,符合则执行步骤202,否则丢弃该查询请求报文,流程结束;\n[0069] 步骤202,查询请求报文处理装置判断白名单中是否包含该客户机的IP地址,若包含,则执行步骤203;若不包含,则执行步骤205;\n[0070] 步骤203,查询请求报文处理装置获取对应于该查询请求报文请求访问的DNS服务器的访问统计信息,并判断是否超出了预设的阈值,若不超过,则执行步骤204;若超过,则丢弃该查询请求报文,流程结束;\n[0071] 查询请求报文处理装置在接收到符合DNS格式的查询请求报文后,根据用于记录合法客户机的白名单中包括客户机的IP地址,验证该查询请求报文是否来源于真实的客户机。其中,所述的白名单包括被允许与该DNS服务器建立连接的合法的IP地址,而且白名单中的IP地址具有老化时间即可以表明该记录可以保留的时间。当查询请求报文处理装置根据白名单判断出该查询请求报文来源的客户机的I P地址包含在白名单中后,可以进行后续处理即根据访问统计信息和阈值对该查询请求报文进行转发处理。\n[0072] 步骤204,查询请求报文处理装置将该查询请求报文转发给对应的DNS服务器,并更新对应的访问统计信息例如作加一处理,流程结束;\n[0073] 步骤205,查询请求报文处理装置向该客户机返回应答报文;\n[0074] 具体的,若查询请求报文处理装置根据白名单判断出该查询请求报文来源的客户机的IP地址不包含在白名单中,则通过向客户机返回请求应答报文对该客户机发起验证,具体包括向发送查询请求报文的客户机返回应答报文,所述的应答报文中的TC字段表示该字段被截断例如设置成“1”;如果接收到该客户机根据所述的应答报文发送的TCP连接请求时,通过与该客户机进行三次握手连接建立与该客户机之间的TCP连接,获知发送查询请求报文的客户机为真实客户机,进一步地,还可以将该客户机的IP地址加入到查询请求报文处理装置维护的白名单中;如果没有接收到该客户机根据所述的应答报文发送的TCP连接请求,则该客户机为非真实客户机,查询请求报文处理装置通过反弹应答报文的方式阻止了非真实客户机对DNS服务器的非法访问。\n[0075] 具体地,当发送查询请求报文的客户机的IP地址不包含在白名单中时,查询请求报文处理装置可以向该客户机返回一个应答报文,并且将该应答报文中的TC字段设置成表示该字段可以被截断的标识,例如设置为“1”,该应答报文的数据长度可以为512个字节。以下以接收到客户机根据所述的应答报文发送的TCP连接请求后,本发明实施例所述的查询请求报文处理装置的处理为例重点说明。\n[0076] 步骤206,查询请求报文处理装置接收该客户机发送的TCP连接请求;\n[0077] 步骤207,查询请求报文处理装置代替DNS服务器建立握手,并判断握手是否完成,若完成则执行步骤208;否则执行丢弃,流程结束;\n[0078] 步骤208,接收该客户机发送的第二查询请求报文;\n[0079] 具体的,具体的,由于查询请求报文处理装置对客户机发起验证时与客户机之间是TCP连接,因此在握手成功后,客户机是以TCP协议重新发送的查询请求报文,为了该客户机第一次通过UDP协议发送的查询请求报文相区别,此处将通过TCP协议发起的查询请求报文定义为第二查询请求报文。\n[0080] 步骤209,查询请求报文处理装置判断该第二查询请求报文的格式是否符合DNS格式以及判断对应的访问统计信息是否超出阈值,若通过,则执行步骤210;若不通过,则丢弃流程结束;\n[0081] 步骤210,查询请求报文处理装置对该第二查询请求报文的发送协议进行转换,通过UDP协议将第二查询请求报文发送给DNS服务器;\n[0082] 具体的,由于查询请求报文处理装置与DNS服务器之间是通过UDP协议传输的,因此查询请求报文处理装置将客户机通过TCP协议发送的第二查询请求报文通过UDP协议发送给DNS服务器。\n[0083] 步骤211,查询请求报文处理装置接收DNS服务器返回的UDP应答报文;\n[0084] 步骤212,查询请求报文处理装置将应答报文的发送协议进行转换,通过TCP协议将DNS服务器的应答报文发送给客户机;并可以同时将该客户机的IP存储到白名单中,并更新对应的访问统计信息例如作加一处理,流程结束。\n[0085] 在上述实施例中,客户机接收到该应答报文后,要根据应答报文向查询请求报文处理装置发送TCP连接请求;当查询请求报文处理装置接收到客户机发送的该TCP连接请求后,与该客户机进行三次握手连接以建立查询请求报文处理装置与该客户机之间的TCP连接,若握手成功则说明该客户机为真实的客户机,并建立会话(SESSION)表项,同时为了避免下次请求在进行重新握手流程,可以将该客户机的IP地址加入到白名单中,便于后续真实客户机的判断。\n[0086] 查询请求报文处理装置接收到客户机通过TCP连接发送的另一查询请求报文例如第二查询请求报文,获取对应于该第二查询请求报文请求访问的DNS服务器的访问统计信息;根据获得的访问统计信息和对应的阈值,对该第二查询请求报文进行处理,具体包括:当访问统计信息小于阈值时,将第二查询请求报文通过UDP协议发送给DNS服务器,查询请求报文处理装置对第二查询请求报文的发送协议进行转换,由TCP协议转为UDP协议;\n当访问统计信息大于或等于阈值时,丢弃该第二查询请求报文。\n[0087] 当该客户机后续再次向查询请求报文处理装置发送查询请求报文时,查询请求报文处理装置可以直接根据白名单对该客户机的五元组中的IP地址进行判断,直接判断出该客户机为真实客户机。\n[0088] 在上述过程中,若查询请求报文处理装置返回应答报文后,该客户机没有与查询请求报文处理装置进行后续的TCP连接,则说明该客户机为非法客户机。\n[0089] 通过上述判断方法,可以对发送查询请求报文的客户机的真实性进行验证,避免一些非法的客户机发送符合DNS格式的查询请求报文进行非法攻击,保证DNS服务器的工作稳定性和安全性。\n[0090] 在上述各实施例中所涉及到的访问统计信息,为查询请求报文处理装置对所有真实客户机发送符合DNS格式的查询请求报文进行统计获得的,在查询请求报文中包括客户机所要访问的DNS服务器的标识信息例如DNS域名等,用以指示查询请求报文处理装置将该查询请求报文转发给哪个具体地DNS服务器。由于所有的查询请求报文均要通过查询请求报文处理装置转发,因此查询请求报文处理装置能够对每一个DNS服务器的访问次数进行统计,以更新对应的访问统计信息。具体地为,查询请求报文处理装置可以对目标域名进行统计与跟踪,若统计结果超出阈值,则可以进行报警,并可以把过载的目标域名的事件进行汇报,形成日志。当然阈值也是可以动态更新的。\n[0091] 另外,查询请求报文处理装置还可以针对真实IP进行统计,若一客户机在短时间内连续发送超出数量合理范围的大量的查询请求报文,则可以判断该客户机为非法客户机,查询请求报文处理装置可以直接丢弃该客户机发送的查询请求报文。\n[0092] 本发明查询请求报文处理方法实施例中,如果接收到的查询请求报文的格式符合DNS协议格式,且发送查询请求报文的客户机为真实客户机,查询请求报文处理装置对查询请求报文对应的请求信息进行统计,当DNS服务器的请求访问次数超出设定阈值时,对当前的查询请求报文进行过滤;可以避免爆发式的DNS请求,防止大规模DNS请求同时访问同一DNS服务器,降低了DNS服务器瘫痪的概率。\n[0093] 图7为本发明查询请求报文处理装置实施例一结构示意图,该查询请求报文处理装置设置在客户机和DNS服务器之间,可以为单独的一个设备,也可以设置在网关设备上,以下实施例以查询请求报文处理装置为网关为例进行说明,如图7所示,该网关包括接收模块11、验证模块12、获取模块13和处理模块14,其中:\n[0094] 接收模块11,用于接收符合域名系统格式的查询请求报文;验证模块12用于验证查询请求报文是否来源于真实的客户机;\n[0095] 获取模块13,用于若通过验证模块验证获知查询请求报文来源于真实的客户机,则获取对应于查询请求报文请求访问的域名服务器的访问统计信息;\n[0096] 处理模块14,用于根据访问统计信息和阈值对查询请求报文进行处理,所述阈值用于标识允许同时访问域名服务器的最大次数。\n[0097] 具体地,网关中的接收模块11首先接收客户机发往DNS服务器的查询请求报文,然后由验证模块12对该查询请求报文的格式进行验证检验是否符合DNS格式,只有符合DNS格式的查询请求报文才被处理,如果通过验证获知该查询请求报文的格式不符合DNS格式,则可以直接丢弃该查询请求报文不做其他处理,或者向发送该查询请求报文的客户机返回拒绝放行的应答报文等。若验证获知该查询请求报文的格式符合DNS格式,则继续由验证模块12对该查询请求报文是否来源于真实的客户机进行判断。验证模块12对格式和真实客户机的验证方法可以参见前述的方法实施例,此处不再赘述。\n[0098] 网关通过验证模块12的上述的两步判断后,若获知接收到的查询请求报文符合NDS格式,且来源于真实客户机后,则再由获取模块13获取到该查询请求报文所要访问的DNS服务器所对应的访问统计信息,最后通过处理模块14根据访问统计信息和阈值对查询请求报文进行处理,该处理具体包括,若访问统计信息小于阈值,则向对应的DNS服务器转发该查询请求报文,并更新访问统计信息例如将访问统计信息中的次数加一等。若访问统计信息大于或等于阈值,则丢弃接收到的查询请求报文不做其他处理。\n[0099] 本发明实施例提供的查询请求报文处理装置在接收到符合域名系统格式的查询请求报文后,通过验证获知所述查询请求报文是否来源于真实的客户机,再根据预设的阈值来限制真实客户机同时访问DNS服务器的最大次数,防止因同时出现大规模DNS请求而造成DNS服务器发生堵塞甚至瘫痪,提高了DNS服务器的工作稳定性,保障网络服务质量,增强了DNS系统中的网络安全防护性能。\n[0100] 图8为本发明查询请求报文处理装置实施例二结构示意图,如图8所示,该网关包括接收模块11、验证模块12、获取模块13和处理模块14,在上述实施例的基础上,进一步地,处理模块14可以包括第一处理子模块141和第二处理子模块142分别进行转发和丢弃的处理,其中:\n[0101] 第一处理子模块141,用于在访问统计信息小于所述阈值的时候,向DNS服务器转发该查询请求报文,并更新对应的访问统计信息;\n[0102] 第二处理子模块142,用于在访问统计信息大于或等于阈值的时候,丢弃该查询请求报文。\n[0103] 进一步的,验证模块12包括第一验证子模块121和第二验证子模块122,其中:\n[0104] 第一验证子模块121,用于根据用于记录合法客户机的白名单中包括客户机的IP地址,验证查询请求报文是否来源于真实的客户机;\n[0105] 第二验证子模块122,用于若用于记录合法客户机的白名单中不包括客户机的IP地址,则通过向客户机返回请求应答报文对客户机发起验证,所述的请求应答报文中的TC字段表示该字段允许被截断。\n[0106] 对应地,若网关通过第二验证子模块122向客户机发送应答报文后,网关要接收该客户机发送的TCP连接请求并与该客户机进行是那次握手连接以建立网关与客户机之间的TCP连接。第二验证子模块122还用于当接收客户机根据应答报文发送的TCP连接请求时,通过与客户机进行三次握手连接建立与客户机之间的TCP连接,获知客户机为真实客户机,并将客户机的IP地址加入所述白名单。\n[0107] 网关还可以通过设在其内的一个存储模块对上述的白名单进行存储维护。\n[0108] 本发明实施例提供的查询请求报文处理装置,如果接收到的查询请求报文的格式符合DNS协议格式,且发送查询请求报文的客户机为真实客户机,查询请求报文处理装置对查询请求报文对应的请求信息进行统计,当DNS服务器的请求访问次数超出设定阈值时,对当前的查询请求报文进行过滤;可以避免爆发式的DNS请求,防止大规模DNS请求同时访问同一DNS服务器,降低了DNS服务器瘫痪的概率,提高工作稳定性。\n[0109] 图9为本发明查询请求报文处理系统实施例组成示意图,如图9所示,包括客户机\n2,该客户机2至少为一个,以及对应于该查询请求报文请求访问的DNS服务器3,还包括设置在客户机2与DNS服务器3之间的查询请求报文处理装置例如网关1,其中,客户机2用于发送查询请求报文,网关1用于对客户机2所发送的查询请求报文的报文格式、客户机2的真实性进行判断,并且在获知接收到的查询请求报文符合NDS格式,且来源于真实客户机后,根据预设的于标识允许同时访问域名服务器的最大次数的阈值,以及动态更新的访问统计信息,对该客户机所发送的查询请求报文进行处理,具体包括,若访问统计信息小于阈值,则向对应的DNS服务器转发该查询请求报文,并更新访问统计信息例如将访问统计信息中的次数加一等。若访问统计信息大于或等于阈值,则丢弃接收到的查询请求报文不做其他处理。\n[0110] 本系统实施例中的涉及的网关1可以采用上述方法和装置实施例中提供的查询请求报文处理装置,其具体的结构和功能此处不再赘述。\n[0111] 本发明实施例提供的查询请求报文处理系统中,网关在接收到符合域名系统格式的查询请求报文后,通过验证获知所述查询请求报文是否来源于真实的客户机,再根据预设的阈值来限制真实客户机同时访问DNS服务器的最大次数,防止因同时出现大规模DNS请求而造成DNS服务器发生堵塞甚至瘫痪,提高了DNS服务器的工作稳定性,保障网络服务质量,增强了DNS系统中的网络安全防护性能。\n[0112] 本领域普通技术人员可以理解:实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成,前述的程序可以存储于一计算机可读取存储介质中,该程序在执行时,执行包括上述方法实施例的步骤;而前述的存储介质包括:ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。\n[0113] 最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。
法律信息
- 2022-09-16
专利权的转移
登记生效日: 2022.09.05
专利权人由华为数字技术(成都)有限公司变更为成都华为技术有限公司
地址由611731 四川省成都市高新区西部园区清水河片区变更为610041 四川省成都市高新区(西区)西源大道1899号
- 2015-03-11
专利权人的姓名或者名称、地址的变更
专利权人由成都市华为赛门铁克科技有限公司变更为华为数字技术(成都)有限公司
地址由611731 四川省成都市高新区西部园区清水河片区变更为611731 四川省成都市高新区西部园区清水河片区
- 2014-01-22
- 2011-06-15
实质审查的生效
IPC(主分类): H04L 29/06
专利申请号: 200910236448.2
申请日: 2009.10.22
- 2011-05-04
引用专利(该专利引用了哪些专利)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 |
1
| |
2008-12-10
|
2008-06-28
| | |
2
| |
2005-11-16
|
2004-05-13
| | |
3
| | 暂无 |
2008-04-11
| | |
被引用专利(该专利被哪些专利引用)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 | 该专利没有被任何外部专利所引用! |