收藏 分销(赏)

IPv6网络DNS劫持问题研究 (1).pdf

上传人:自信****多点 文档编号:541183 上传时间:2023-11-27 格式:PDF 页数:7 大小:5.76MB
下载 相关 举报
IPv6网络DNS劫持问题研究 (1).pdf_第1页
第1页 / 共7页
IPv6网络DNS劫持问题研究 (1).pdf_第2页
第2页 / 共7页
IPv6网络DNS劫持问题研究 (1).pdf_第3页
第3页 / 共7页
亲,该文档总共7页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述

1、1032023.060 引言互联网的正常访问离不开域名系统(DNS,Domain Name System)提供的解析服务,DNS 将由中英文字符组成的域名解析成计算机所能识别的 IP 地址。一般的上网用户都使用运营商提供的默认的 DNS 服务器,运营商出于商业利益或者网络安全管理的考虑,会对用户的 DNS 解析数据进行监控和分析,甚至篡改解析结果,植入广告,侵犯了用户的个人隐私1。随着互联网用户安全意识的不断增强,越来越多的用户不再使用运营商自动分配的 DNS 服务器,转而使用知名的公共 DNS服务器。但是,运营商、硬件厂商以及服务厂商开始挖掘公共DNS的商业价值,对用户的DNS请求进行劫持(

2、Interception),让公共DNS的使用也变得缺乏安全2。网络中的中间设备(比如运营商的路由器)劫持了用户发送至公共 DNS 服务器的DNS 请求报文,将其转发给劫持者部署的其他解析服务器,劫持者不但窥探了用户访问的域名,还能任意更改解析结果,将用户重新定向到其他广告或恶意网站。劫持者伪装成公共DNS 服务器 IP 地址来应答用户的 DNS 请求,以此欺骗用户,因此,DNS 劫持通常不易被用户发现。由此可见,DNS 劫持给互联网用户带来了隐私和安全问题。越来越多的学者开始关注 DNS 劫持问题,Lan Wei 等4通过 hostname.bind 语句查询域名服务器的 Server ID

3、,以探测明显的 DNS 劫持;通过比较 DNS 查询延时与 ping 域名服务器的延时识别隐蔽的 DNS 劫持;通过 traceroute 域名服务器的倒数第二跳的 IP 地址,判断是否遭遇了任播(Anycast)方式部署的虚假域名服务器。Baojun Liu 等人5注册了一组域名,搭建了这些域名的权威域名服务器(Authoritative Nameserver),当一个终端向公共 DNS 服务器请求解析注册的指定域名时,研究者们检查访问权威服务器的源 IP 地址是否属于该公共 DNS 服务器,以此判断是否遭到了 DNS 劫持。Audrey Randall 等6提出了一种识别 DNS 劫持的三

4、步法:一是通过 id.server 查询语句识别是否存在 DNS 劫持;二是通过version.bind 查询语句识别是否被客户前置设备(比如家庭光纤 Modem 或无线路由器)所劫持;三是通过向私有(Bogon)IP 发送域名解析请求识别是否在运营商内部被劫持。B.Jones等7通过分析至根服务器的延时以及检查路由劫持来探测是否发生根服务器的篡改。上述的 DNS 劫持问题研究主要基于IPv4 网络,而对 IPv6 网络的 DNS 劫持问题研究较少。本文在 IPv6 网络中开展 DNS 劫持问题研究,发现 DNS劫持者通常只劫持 DNS 请求报文,而不劫持 ICMP 报文,也就无法通过 tra

5、ceroute 获取的网络传输路径判断数据包是否到达真正的 DNS 服务器,为此本文提出了一种基于 IPv6 报文头Hop Limit 识别 DNS 劫持的简单方法,通过比较 DNS 应答报文与 ping 公共域名服务器返回的 echo-reply 报文的 Hop Limit值,若两者不等则说明遭到了 DNS 劫持。1 研究背景IP 地址是互联网上计算机唯一识别的逻辑地址,IPv6 地址长度为 128 位,常用“冒号十六进制”来表示8,如 2001:4860:4860:8888(Google DNS),IP 地址没有意义,人们很难记忆。为此,人们又发展出了一种更易识别的符号化标识的域名,域名虽

6、然更易被用户所接受和使用,但计算机不能直接读取域名,这就需要将域名翻译成 IP 地址,而 DNS 域IPv6 网络 DNS 劫持问题研究刘永清1,21.东南大学网络空间安全学院;2.国家计算机网络应急技术处理协调中心江苏分中心摘要:越来越多的上网用户选择使用公共的 DNS 服务器,而不使用运营商分配的 DNS 服务器。不过 DNS 请求劫持事件时有发生,这带来了用户隐私和安全问题。劫持者通常伪造 IP 地址欺骗用户,所以 DNS 劫持问题不易被人察觉。本文针对 IPv6 网络进行了 DNS 劫持问题研究,提出了一种基于 IPv6 报文头 Hop Limit 的DNS 劫持检测方法,分别在国内三

7、大运营商网络中进行了测试,验证了检测方法的有效性。关键词:IPv6;DNS 劫持;Hop Limit1042023.06名解析承担了这种翻译工作。1.1 DNS 解析过程图 1 描述了 DNS 的解析过程5,下面以上网终端访问 为例,介绍一下,DNS 解析的详细过程。上网终端要访问 网址,它先检查浏览器中是否缓存有该域名对应的解析过的 IP 地址,以及 hosts 文件中是否手工配置了该域名对应的 IP,如果有缓存或配置有 IP地址,那么上网终端就可以直接访问 ,否则就向本地DNS服务器(Local Nameserver)发送一条DNS请求报文。上网用户可以从运营商自动获取本地 DNS 服务器

8、,也可以手工配置为公共 DNS,比如,国外的 Google DNS 服务器,国内的 114 DNS 服务器。本地 DNS 服务器收到用户的 解析请求后,如果本地 DNS 服务器有缓存的该域名的解析结果,那么本地 DNS 服务器就会跳过-步,直接向上网终端返回 DNS 解析应答报文。本地 DNS 服务器收到上网终端的 DNS 请求报文后,如果没有缓存 的解析结果,那么本地 DNS 服务器就会向根域名服务器发起 DNS 解析请求。根域名服务器收到本地 DNS 服务器的查询请求后,就返回一个顶级DNS服务器IP地址,如.com、.org、.edu、.net等,或其他如.cn 等国家代码的顶级域名服务

9、器 IP 地址。本例中就是返回.com 的 IP 地址。本地 DNS 服务器收到根域名服务器返回的 DNS 应答报文后,就会向顶级 DNS 服务器.com 发送 的解析请求。顶级 DNS 服务器.com 收到本地 DNS 服务器的查询请求后,顶级 DNS 服务器查找并返回 对应的二级域名服务器的 IP 地址,本例中就是返回 的 IP 地址。本地 DNS 服务器收到顶级域名服务器返回的 DNS 应答报文后,就会向二级 DNS 服务器 发送 的解析请求。二级 DNS 服务器 收到本地 DNS 服务器的查询请求后,二级 DNS 服务器查找并返回 对应的网站服务器的 IP 地址。本例中,这个二级 DN

10、S 服务器就是要访问的网站自建的或托管在域名服务提供商的域名服务器,又称为权威服务器。本地 DNS 服务器收到二级域名服务器返回的 DNS 应答报文后,确认已经解析到 ,于是生成 DNS 应答报文回复上网终端。1.2 根服务器的国内分布情况从上述的 DNS 解析过程可以看出,根服务器是 DNS 解析首次要查询的服务器,其重要性可见一斑。全球共有 13 个根服务器,分别为 a.root 至 m.root,但是没有一台根服务器部署在中国,这也是很多人所认为的中国互联网存在的安全隐患。为了提高网络访问性能,13 个根服务器在全球各地还部署了很多镜像节点,这些节点与根服务器通过任播共享同一个 IP 地

11、址,表 1 是作者在南京通过 ping 测得的到各个根服务器的往返时间(RTT,Round-Trip Time),从RTT的长短可以看出,很多根服务器在国内都部署有镜像节点。图 1 DNS 解析过程表 1 国内到 13 个根服务器的往返时间根服务器IPv4/IPv6RTT(ms)备注a.root-198.41.0.42582001:503:ba3e:2:30198b.root-199.9.14.2014382001:500:200:b4131052023.06根服务器IPv4/IPv6RTT(ms)备注c.root-192.33.4.122942001:500:2:c274d.root-199

12、.7.91.132282001:500:2d:d230e.root-192.203.230.1037国内有节点2001:500:a8:e37国内有节点f.root-192.5.5.24134国内有节点2001:500:2f:f25国内有节点g.root-192.112.36.4禁 ping2001:500:12:d0d禁 pingh.root-198.97.190.532032001:500:1:53266i.root-192.36.148.1737国内有节点2001:7fe:5332国内有节点j.root-192.58.128.3024国内有节点2001:503:c27:2:30禁 ping

13、k.root-193.0.14.1292802001:7fd:146国内有节点l.root-199.7.83.4218国内有节点2001:500:9f:4221国内有节点m.root-202.12.27.33712001:dc3:3538国内有节点1.3 DNS 劫持分类DNS 报文通常是通过 UDP 报文传输,端口号为 53,封装在 UDP 中的 DNS 报文长度不能超过 512 字节。如果 DNS 报文长度超过 512 字节,那么就得通过 TCP 报文进行传输,端口号仍为 53。无论是 UDP 还是 TCP 封装的 DNS 报文,数据都是明文传输的,极易被人窥探和劫持。从图 1 的 DNS

14、 解析过程可以看出,本地域名服务器与上网终端、根域名服务器、顶级域名服务器以及二级域名服务器之间任意一个环节都可能发生 DNS 劫持。文献 5 研究发现,基于 UDP 的 DNS 报文被劫持率为 27.9%,而以 TCP 承载的 DNS 报文被劫持率却只有 7.3%,该文将 DNS 正常解析和异常解析共分为 4 类,如图 2 所示。文献 5 的研究者们注册了一组域名,搭建了自己的权威域名服务器,测试上网终端向本地域名服务器发送实验注册域名的 DNS 请求报文,通过观察权威域名服务器收到 DNS 请求报文的源 IP 地址识别发生了何种 DNS 劫持。(a)如果权威域名服务器收到的 DNS 请求报

15、文的源 IP 就是测试上网终端所指定的域名服务器的 IP,那么这是正常的 DNS 解析过程,未出现 DNS 劫持。(b)如果权威域名服务器收到的 DNS 请求报文的源 IP 不是测试上网终端所指定的域名服务器的 IP,1062023.06那么说明出现了 DNS 请求重定向类型的劫持。(c)如果权威域名服务器收到 2 份 DNS 请求报文,其中一个源 IP 是测试上网终端所指定的域名服务器的 IP,而另一个不是,那么说明发生 DNS 请求复制类型的劫持。(d)如果权威域名服务器未收到任何 DNS 请求报文,而测试上网终端却收到了 DNS 应答报文,那么说明发生了 DNS 直接响应类型的劫持。图

16、2 DNS 正常及异常解析分类文献 5 虽然能够较好地探测出 DNS 劫持,但是要注册域名、搭建权威域名服务器,检测环境太过复杂。文献 6 通过 id.server 查询语句,将应答报文与未受到 DNS 劫持的应答报文作比较,若报文一致,则说明未受到 DNS 劫持,否则说明受到了 DNS 劫持。很明显,该方法仅适用于图 2(d)所示的 DNS 直接响应类型的劫持。本文对 DNS 劫持开展了进一步研究,提出了一种基于 Hop Limit 的 DNS 劫持检测方法。2 基 于 Hop Limit 的 DNS 劫 持检测方法2.1 方法原理DNS 报文封装在 UDP 或 TCP 中,再进一步封装在

17、IP 报文中,IPv6 报文头中 Hop Limit 值(IPv4 报文为 TTL)指明了数据报从源节点最多允许经过多少跳(Hop)到达终点,Hop Limit 值由发起者指定,每经过一个路由节点,其值被减 1,如果 Hop Limit 值为 0,那么该包就会被丢弃,这就避免了路由环路。因此,可以通过对比 DNS 应答报文中的 IPv6 层 Hop Limit 值与 ping 应答报文中的 Hop Limit 值,来验证两者是否经过相同的传输路径。由于劫持 ICMP 报文很容易被用户发现,所以劫持者通常只劫持 DNS 报文,劫持者虽然可以假冒用户指定的域名服务器的 IP 地址,但是很难伪造 H

18、op Limit 值,一是劫持者不知道本地域名服务器设置的初始 Hop Limit 值;二是劫持者也不知道本地域名服务器至上网终端之间经历多少个路由节点。如图 3 所示,假设本地域名服务器设置的初始 Hop Limit 值为m,用户指定的本地域名服务器至上网终端之间有 n 跳,那么上网终端正常收到的 DNS 应答报文 IP 层的 Hop Limit 值就为m-n,该值理论上应该也与 ping 用户指定的本地域名服务器获得的 Hop Limit 值一致。劫持者不知道 m 和 n,就无法伪造正常的 Hop Limit 值。因此,只要比较 DNS 应答报文中的 IPv6层 Hop Limit 值与

19、ping 应答报文中的 Hop Limit 值是否相同,就可以判断是否发生了 DNS 劫持。图 3 报文 Hop Limit 值生成示意图1072023.062.2 实验结果对于本文提出的基于 Hop Limit 的 DNS 劫持检测方法,分别在国内三大运营商的 IPv6 网络中进行了测试,方法如下:在测试电脑上通过 dig 工具向知名的公共 DNS 服务器发送解析 网站 AAAA 记录的请求,并且在测试电脑上使用 Wireshark 进行抓包,获取 DNS 应答报文中 IPv6 层的 Hop Limit 值;然后 ping 该公共 DNS 服务器,也获得另一个 Hop Limit 值;比较两

20、个 Hop Limit 值,如果值相同,那么图 4 Google DNS 应答及 Ping 报文截图1082023.06就判定未受到 DNS 劫持,否则就判断受到了 DNS 劫持。本次共测试了 4 个知名的公共 DNS 服务器:Google DNS,Quad9 DNS,Cloudflare DNS,CFIEC DNS(国内)。针对 Google DNS,在国内三大运营商网络中测试过程的截图见图 4,所有的测试结果汇总至表 2,其中 DNS-Hop 表示 DNS 应答报文承载的 IPv6 层的 Hop Limit 值;DNS-RTT 表示从发出 DNS 查询请求到收到 DNS 应答报文的时间间隔

21、,单位为 ms;Ping-Hop 和 Ping-RTT 的意义类似;RTT 增长率=(DNS-RTT-Ping-RTT)/Ping-RTT。表 2 橙色标注的测试结果表示检测到 DNS 劫持,从实验结果可以看出,对于 Quad9 DNS,Cloudflare DNS,CFIEC DNS,在国内三大运营商网络中,测得的 DNS-Hop 和 Ping-Hop 都完全相等,可以判定这三个 DNS 均未被劫持。对于Google DNS,在某些运营商网络中,测得的 DNS-Hop 和 Ping-Hop 不等;而在其他网络中,测得的 DNS-Hop 和 Ping-Hop 相等,说明 Google DNS

22、在某些运营商网络中被劫持。DNS-RTT 值受域名服务器是否有缓存影响,其值变化较大,实验采用多次实验取最小值的方法。由于劫持者通常只劫持 DNS 请求报文而不劫持 ICMP 报文,因而 DNS 解析和Ping DNS 服务器的数据包的传输路径是不同的,导致两者的往返时间 RTT 也不相同;而未发生 DNS 劫持时,DNS 解析和 Ping DNS 服务器的 RTT 通常是比较接近的。实验结果确实显示,当 DNS-Hop 和 Ping-Hop 相同时,DNS-RTT 与 Ping-RTT 一般也很接近,因此,也可以用 RTT 增长率来辅助验证是否发生了 DNS 劫持。表 2 公共 DNS 应答

23、及 Ping 报文对比表测试网络公共 DNSDNS-HopPing-HopDNS-RTTPing-RTTRTT 增长率运营商 1Google DNS(2001:4860:4860:8888)118115537129316%Quad9 DNS(2620:fe:fe)54542522367%Cloudflare DNS(2606:4700:4700:1111)54542132016%CFIEC DNS(240C:6666)585845442%运营商 2Google DNS(2001:4860:4860:8888)535315851210%Quad9 DNS(2620:fe:fe5353340183

24、86%Cloudflare DNS(2606:4700:4700:1111)5252189192-2%CFIEC DNS(240C:6666)565619186%运营商 3Google DNS(2001:4860:4860:8888)11511233685295%Quad9 DNS(2620:fe:fe)494929724820%Cloudflare DNS(2606:4700:4700:1111)49492182104%CFIEC DNS(240C:6666)5555653586%(下转第112页)1122023.06实体身份证,简单“碰一碰”,即可实现身份信息无接触认证。二是建立安全机制,

25、保障身份数据安全、通信安全和流程安全。三是建立安全技术架构,保障身份证数据存储安全、数据传输安全、与各个平台之间的通信安全等。四是建立访问控制机制,包括系统对数字身份操作的访问控制、数字身份 SDK 对 App的访问控制、服务器与数字身份 SDK 之间的访问控制等。4 结束语基于“卡码照”三合一的新型可信数字身份认证产品“SIM数字身份”,是将用户的个人身份证信息以加密形式存储在超级 SIM 卡的安全区域。在身份信息读取及核验的传输过程中使用国密算法进行加密处理,从而确保身份核验与认证的权威、真实、有效。目前该应用已在营业厅业务办理场景、智能楼宇门禁管理场景、南京老门东文旅场景、南京江北新小区

26、智慧社区场景等投入使用,便利人民群众日常生活的同时,也为其他行业的电子证照应用提供了新的思路和解决方案。作者简介:袁媛(1983),女,江苏扬州人,工程师,硕士;研究方向:超级 SIM 卡应用。(收稿日期:2022-12-21;责任编辑:王红)实验还对 IPv4 网络进行了类似测试,比较的参数则是IPv4 报文头的 TTL 值。对比测试发现,IPv4 的 DNS 劫持率较IPv6 高很多,这与文献 6 的研究结果一致。3 结束语现有的 DNS 劫持检测方法存在手段过于复杂或者检测范围狭窄等问题,为此本文提出了一种 IPv6 网络中基于 Hop Limit 的 DNS 劫持检测方法,由于劫持者通

27、常仅劫持 DNS 报文,而不劫持 ICMP 报文,因此通过在上网终端上抓包分析,对比 DNS 应答报文的 Hop Limit 与 Ping 本地域名服务器的应答报文的 Hop Limit 值,如果两者不同,则判定 DNS 报文受到了劫持。该方法在国内三大运营商网络中分别对 Google,Quad9,Cloudflare等DNS进行了实验。测试发现,IPv6网络中,Google DNS 在某些运营商网络中存在 DNS 劫持;对于其他的公共 DNS 服务器,均未发生 DNS 劫持。实验也对 IPv4 网络进行了类似的测试,发现 IPv4 网络的 DNS 劫持率远高于 IPv6网络。参考文献:1CH

28、UNG,T.,CHOFFNES,D.,AND MISLOVE,A.Tunneling for transparency:A large-scale analysis of end-to-end violations in the internetC.In Proceedings of the 2016 ACM on Internet Measurement Conference,ACM,2016:199-213.2 张涛.恶意网址劫持技术的应用研究 J.通信技术,2020,53(03):728-732.3Tom Creighton,Chris Griffiths,Jason Livingood

29、,Ralf Weber.2010.DNS Redirect Use by Service ProvidersJ.Internet Draft:draft-livingood-dns-redirect-03,1997.4Lan Wei,John Heidemann.Whac-A-Mole:Six Years of DNS SpoofingJ.2020.DOI:10.48550/arXiv.2011.12978.5Liu Baojun,Lu Chaoyi,Duan Haixin,Liu Ying,Li Zhou,Hao Shuang,Yang Min.2018.Who is Answering M

30、y Queries:Understanding and Characterizing Interception of the DNS Resolution PathC.Proceedings of the Applied Networking Research Workshop.ACM,2019:1113-1128.6Audrey Randall,Enze Liu,Ramakrishna Padmanabhan,et al.2021.Home is Where the Hijacking is:Understanding DNS Interception by Residential Rout

31、ersC.Internet Measurement Conference,New York,USA:IMC,2021:390-397.7B.Jones,N.Feamster,V.Paxson,N.Weaver,M.Allman.Detecting dns root manipulationC.International Conference on Passive and Active Network Measurement,2016:276288.8R.Hinden,S.Deering.IP Version 6 Addressing ArchitectureS.RFC 8291,IETF,2006.https:/www.rfc-editor.org/rfc/pdfrfc/rfc4291.txt.pdf.作者简介:刘永清(1979),男,安徽天长人,高级工程师,博士研究生;研究方向:网络安全,IPv6 网络。(收稿日期:2023-02-15;责任编辑:王红)(上接第108页)

展开阅读全文
相似文档                                   自信AI助手自信AI助手
猜你喜欢                                   自信AI导航自信AI导航
搜索标签

当前位置:首页 > 学术论文 > 论文指导/设计

移动网页_全站_页脚广告1

关于我们      便捷服务       自信AI       AI导航        获赠5币

©2010-2024 宁波自信网络信息技术有限公司  版权所有

客服电话:4008-655-100  投诉/维权电话:4009-655-100

gongan.png浙公网安备33021202000488号   

icp.png浙ICP备2021020529号-1  |  浙B2-20240490  

关注我们 :gzh.png    weibo.png    LOFTER.png 

客服