? Editing: Post:21.body Save Delete Cancel
Content changed Sign & Publish new content

中囯网絡審查技術評論

總結:网絡審查主要是為了維穩(混淆視聽、拆散人心),而不是宣傳(臉上貼金)

Follow in NewsfeedFollowing

Latest comments:

Add new post

Title

21 hours ago · 2 min read·
3 comments
Body
Read more

Not found

深入理解 GFW:DNS污染

on Jun 03, 1989 · 5 min read

初识 DNS 污染

翻墙新手们往往遇到这样的问题:我明明已经设置了 socks 代理为 127.0.0.1:xxxx,为什么还是上不去 youtube?这时经验丰富的翻墙高手就会告诉你:firefox 需要设置 network.proxy.socks_remote_dns 为 true,也就是远程解析域名。这是怎样一回事呢?为什么要远程解析?这就涉及到了 GFW 的 DNS 污染技术。


DNS(Domain Name System)污染是 GFW 的一种让一般用户由于得到虚假目标主机 IP 而不能与其通信的方法,是一种 DNS 缓存投毒攻击DNS cache poisoning)。其工作方式是:对经过 GFW 的在 UDP 端口 53 上的 DNS 查询进行入侵检测,一经发现与关键词相匹配的请求则立即伪装成目标域名的解析服务器(NS,Name Server)给查询者返回虚假结果。由于通常的 DNS 查询没有任何认证机制,而且 DNS 查询通常基于的 UDP 是无连接不可靠的协议,查询者只能接受最先到达的格式正确结果,并丢弃之后的结果。对于不了解相关知识的网民来说也就是,由于系统默认使用的 ISP 提供的 NS 查询国外的权威服务器时被劫持,其缓存受到污染,因而默认情况下查询 ISP 的服务器就会获得虚假 IP;而用户直接查询境外 NS(比如 OpenDNS)又可能被 GFW 劫持,从而在没有防范机制的情况下仍然不能获得正确 IP。然而对这种攻击有着十分简单有效的应对方法:修改 Hosts 文件。但是 Hosts 文件的条目一般不能使用通配符(例如 *.blogspot.com),而 GFW 的 DNS 污染对域名匹配进行的是部分匹配不是精确匹配,因此 Hosts 文件也有一定的局限性,网民试图访问这类域名仍会遇到很大麻烦。

观测 DNS 污染

「知己知彼,百战不殆」。这一节我们需要用到前面提到的报文监听工具,以及参考其 DNS 劫持诊断一节。在 Wireshark 的 filter 一栏输入udp.port eq 53可以方便地过滤掉其他无关报文。为了进一步减少干扰,我们选择一个并没有提供域名解析服务的国外 IP 作为目标域名解析服务器,例如 129.42.17.103。运行命令nslookup -type=A www.youtube.com 129.42.17.103。如果有回答,只能说明这是 GFW 的伪造回答,也就是我们要观测和研究的对象。

伪包特征

经过一番紧密的查询,我们可以发现 GFW 返回的 IP 取自如下列表:

4.36.66.178203.161.230.171211.94.66.147202.181.7.85202.106.1.2209.145.54.50216.234.179.1364.33.88.161

关于这八个特殊 IP,鼓励读者对这样两个问题进行探究:1、为什么是特定的 IP 而不是随机 IP,固定 IP 和随机 IP 各自有什么坏处;2、为什么就是这 8 个 IP 不是别的 IP,这 8 个 IP 为什么倒了 GFW 的霉?关于搜索这类信息,除了 www.google.com 之外,www.bing.com 有专门的搜索 IP 对应网站的功能,使用方法是输入ip:<var>IP地址</var>搜索。www.robtex.com 则是一个专门收集域名解析信息的网站。欢迎读者留下自己的想法和发现: lol:。

从 Wireshark 收集到的结果分析(实际上更好的办法是,将结果保存为 pcap 文件,或者直接使用 tcpdump,由 tcpdump 显示成文本再自行提取数据得到统计),我们将 GFW 发送的 DNS 污染包在 IP 头部的指纹特征分为两类:

  • 一型:

  • ipid == _(是一个固定的数,具体数值的查找留作习题)。

  • 没有设置「不分片」选项。

  • 没有设置服务类型。

  • 对同一对源 IP、目标 IP,GFW 返回的污染 IP 在上述 8 个中按照给出的顺序循环。与源端口无关、与源 IP 目标 IP 对相关。

  • TTL 返回值比较固定。TTL 为 IP 头部的「Time to Live」值,每经过一层路由器这个值会减 1,TTL 为 1 的 IP 包路由器将不再转发,多数路由器会返回源 IP 一条「ICMP time to live exceed in transit」消息。

  • 二型:

  • 每个包重复发送 3 次。

  • 没有设置「不分片」选项。

  • 设置了「保障高流量」服务类型。

  • (ipid + ? _13 + 1) % 65536 == 0,其中? 为一个 * 有趣的未知数__。ip_id 在同一个源 IP、目标 IP 对的连续查询之间以 13 为单位递减、观测到的 ip_id 的最小值和最大值分别为 65525(即 - 11,溢出了!)和 65535。

  • 对同一对源 IP、目标 IP,GFW 返回的污染 IP 在上述 8 个中按照给出的顺序循环。与源端口无关、与源 IP 目标 IP 对相关。

  • 对同一对源 IP、目标 IP,TTL 返回值时序以 1 为单位递增。TTL 在 GFW 发送时的取值有 64 种。注:源 IP 接收到的包的 TTL 被路由修改过,所以用户观测到的 TTL 不一定只有 64 种取值,这是由于网络拓扑变化的原因导致的。一型中的「比较固定」的「比较」二字也是考虑到网络拓扑偶尔的变化而添加的,也许可以认为 GFW 发送时的初始值是恒定的。

(以上结果仅保证真实性,不保证时效性,GFW 的特征随时有可能改变,尤其是时序特征与传输层特征相关性方面。最近半年 GFW 的特征在很多方面的变化越来越频繁,在将来介绍 TCP 阻断时我们会提到。)

还可以进行的实验有:由于当前二型的 TTL 变化范围是 IP 个数的整数倍,通过控制 DNS 查询的 TTL 使得恰好有 GFW 的返回(避免动态路由造成的接收者观察到的 TTL 不规律变化),观察 IP 和 TTL 除以 8 的余数是否有对应关系,在更改源 IP、目标 IP 对之后这个关系是否仍然成立。这关系到的 GFW 负载平衡算法及响应计数器(hit counter)的独立性和一致性。事实上对 GFW 进行穷举给出所有关于 GFW 的结果也缺乏意义,这里只是提出这样的研究方法,如果读者感兴趣可以继续探究。

每次查询通常会得到一个一型包和三个完全相同的二型包。更换查询命令中type=Atype=MX或者type=AAAA或者其它类型,可以看到 nslookup 提示收到了损坏的回复包。这是因为 GFW 的 DNS 污染模块做得十分粗制滥造。GFW 伪造的 DNS 应答的 ANSWER 部分通常只有一个 RR 组成(即一条记录),这个记录的 RDATA 部分为那 8 个污染 IP 之一。对于二型,RR 记录的 TYPE 值是从用户查询之中直接复制的。于是用户就收到了如此奇特的损坏包。DNS 响应包的 UDP 荷载内容特征:

  • 一型

  • DNS 应答包的 ANSWER 部分的 RR 记录中的域名部分由 0xc00c 指代被查询域名。

  • RR 记录中的 TTL 设置为 5 分钟。

  • 无论用户查询的 TYPE 是什么,应答包的 TYPE 总是设置为 A(IPv4 地址的意思)、CLASS 总是设置为 IN。

  • 二型

  • DNS 应答包的 ANSWER 部分的 RR 记录中的域名部分是被查询域名的全文。

  • RR 记录中的 TTL 设置为 1 天。

  • RR 记录中的 TYPE 和 CLASS 值是从源 IP 发送的查询复制的。

其中的术语解释:RR = Resource Record:dns 数据包中的一条记录;RDATA = Resource Data:一条记录的数据部分;TYPE:查询的类型,有 A、AAAA、MX、NS 等;CLASS:一般为 IN[ternet]。

触发条件

实际上 DNS 还有 TCP 协议部分,实验发现,GFW 还没有对 TCP 协议上的 DNS 查询进行劫持和污染。匹配规则方面,GFW 进行的是子串匹配而不是精确匹配,并且 GFW 实际上是先将域名转换为字符串进行匹配的。这一点值得特殊说明的原因是,DNS 中域名是这样表示的:一个整数 n1 代表以「.」作分割最前面的部分的长度,之后 n1 个字母,之后又是一个数字,若干字母,直到某次的数字为 0 结束。例如www.youtube.com则是"\x03www\x07youtube\x03com\x00"。因此,事实上就可以观察到,对 www.youtube.coma 的查询也被劫持了。

现状分析

  • 4.36.66.178,关键词。whois:Level 3 Communications, Inc. 位于 Broomfield, CO, U.S.

  • 203.161.230.171,关键词。whois:POWERBASE-HK 位于 Hong Kong, HK.

  • 211.94.66.147,whois:China United Network Communications Corporation Limited 位于 Beijing, P.R. China.

  • 202.181.7.85,关键词。whois:First Link Internet Services Pty Ltd. 位于 North Rocks, AU.

  • 202.106.1.2,whois:China Unicom Beijing province network 位于 Beijing, CN.

  • 209.145.54.50,反向解析为 dns1.gapp.gov.cn,新闻出版总署的域名解析服务器?目前 dns1.gapp.gov.cn 现在是 219.141.187.13 在 bjtelecom。whois:World Internet Services 位于 San Marcos, CA, US.

  • 216.234.179.13,关键词。反向解析为 IP-216-234-179-13.tera-byte.com。whois:Tera-byte Dot Com Inc. 位于 Edmonton, AB, CA.

  • 64.33.88.161,反向解析为 tonycastro.org.ez-site.net, tonycastro.com, tonycastro.net, thepetclubfl.net。whois:OLM,LLC 位于 Lisle, IL, U.S.

可见上面的 IP 大多数并不是中国的。如果有网站架设到了这个 IP 上,全中国的 Twitter、Facebook 请求都会被定向到这里——好在 GFW 还有 HTTP URL 关键词的 TCP 阻断——HTTPS 的请求才构成对目标 IP 的实际压力,相当于中国网民对这个 IP 发起 DDoS 攻击,不知道受害网站、ISP 是否有索赔的打算?

我们尝试用 bing.com 的 ip 反向搜索功能搜索上面那些 DNS 污染专用 IP,发现了一些有趣的域名。显然,这些域名都是 DNS 污染的受害域名。

  • 例如倒霉的 edoors.cn.china.cn,宁波中国门业网,其实是因为 edoors.cn 被 dns 污染。一起受害的还有 chasedoors.cn.china.cn,美国蔡斯门业(深圳)有限公司。

  • 还有 *.sf520.com,似乎是一个国内的游戏私服网站。www.sf520.com 也是一个私服网站。可见国内行政体系官商勾结之严重,一个「国家信息安全基础设施」竟然还会用来保护一些网游公司的利益。

  • 此外还有一些个人 blog。www.99tw.net 也是一个游戏网站。

  • 还有 www.why.com.cn,名字起得好。

  • 还有 www.999sw.com 广东上九生物降解塑料有限公司生物降解树脂 | 增粘母料 | 高效保水济 | 防洪 邮编: 523128...... 这又是怎么一回事呢?不像是被什么反动网站连坐的。还有人问怎么回事怎么会有那么多 IP 结果。

  • www.facebook.comwww.xiaonei.com,怎么回事呢?其实是因为有人不小心把两个地址连起来了,搜索引擎以为这是一个链接,其实这个域名不存在,但是解析的时候遭到了污染,就以为存在这个域名了。

  • 倒霉的 www.xinsheng.net.cn——武汉市新胜电脑有限公司,因为 www.xinsheng.net 被连坐。

DNS 劫持的防范和利用

之前我们已经谈到,GFW 是一套入侵检测系统,仅对流量进行监控,暂没有能力切断网络传输,其「阻断」也只是利用网络协议容易被会话劫持Session hijacking)的弱点来进行的。使用无连接 UDP 的 DNS 查询只是被 GFW 抢答了,真正的答案就跟在后面。于是应对 GFW 这种攻击很自然的想法就是:

根据时序特性判断真伪,忽略过早的回复。

通常情况对于分别处于 GFW 两端的 IP,其 RTT(Round-trip time,往返延迟)要大于源 IP 到 GFW 的 RTT,可以设法统计出这两个 RTT 的合适的均值作为判断真伪的标准。另外由于 GFW 对基于 TCP 的 DNS 请求没有作处理,于是可以指定使用 TCP 而不是 UDP 解析域名。也可以通过没有部署 GFW 的线路没有被 DNS 污染的 NS 进行查询,例如文章一开始提到的「远程解析」。但黑体字标出的两个条件缺一不可,例如网上广为流传的 OpenDNS 可以反 DNS 劫持的说法是以讹传讹,因为到 OpenDNS 服务器的线路上是经由 GFW 的。

本质的解决办法是给 DNS 协议增加验证机制,例如 DNSSEC(Domain Name System Security Extensions),客户端进行递归查询(Recursive Query)而不查询已经被污染了的递归解析服务器(Recursive/caching name server)。然而缺点是目前并非所有的权威域名解析服务器(Authoritative name server)都支持了 DNSSEC。Unbound 提供了一个这样的带 DNSSEC 验证机制的递归解析程序。

另外 GFW 的 DNS 劫持还可能被黑客利用、带来对国际国内互联网的严重破坏。一方面,GFW 可能在一些紧急时刻按照「国家安全」的需要对所有 DNS 查询都进行污染,且可能指定污染后的 IP 为某个特定 IP,使得全球网络流量的一部分直接转移到目标网络,使得目标网络立刻瘫痪。当然我们伟大的祖国郑重承诺「不率先使用核武器」... 另一方面,GFW 将伪造的 DNS 返回包要发送给源 IP 地址的源端口,如果攻击者伪造源 IP,会怎样呢?将会导致著名的增幅攻击:十倍于攻击者发送 DNS 查询的流量将会返回给伪源 IP,如果伪源 IP 的端口上没有开启任何服务,很多安全配置不严的系统就需要返回一条 ICMP Port Unreachable 消息,并且将收到的信息附加到这条 ICMP 信息之后;如果伪源 IP 的端口上开启了服务,大量的非法 UDP 数据涌入将使得伪源 IP 该端口提供的服务瘫痪。如果攻击者以 1Gbps 的速度进行查询,一个小型 IDC(DNSpod 被攻击事件)甚至一个地域的 ISP 也会因此瘫痪(暴风影音事件)。攻击者还可能设置 TTL 使得这些流量恰好通过 GFW 产生劫持响应,并在到达实际目标之前被路由丢弃,实现流量「空对空不落地」。攻击者还可能将攻击流量的目标 IP 设置伪造成与伪源 IP 有正常通信或者其他关联的 IP,更难以识别。这样实际上就将一个国家级防火墙变成了一个国家级反射放大式拒绝服务攻击跳板

最为严重的是,这种攻击入门难度极低,任何一个会使用 C 语言编程的人只要稍微阅读 libnet 或者 libpcap 的文档,就可能在几天之内写出这样的程序。而 GFW 作为一套入侵防御系统,注定缺乏专门防范这种攻击的能力,因为如果 GFW 选择性忽略一些 DNS 查询不进行劫持,网民就有机可乘利用流量掩护来保证真正的 DNS 通信不被 GFW 污染。尤其是 UDP 这样一种无连接的协议,GFW 更加难以分析应对。「反者道之动,弱者道之用。」

参考文献

  1. 闫伯儒, 方滨兴, 李斌, 王垚. "DNS 欺骗攻击的检测和防范". 计算机工程, 32(21):130-132,135. 2006-11.

  2. Graham Lowe, Patrick Winters, Michael L. Marcus. The Great DNS Wall of China. 注:这篇文章虽然试图通过统计特性了解 GFW,但由于实验条件控制不佳、实验结果观察不细致,加上缺乏对 GFW 的整体观,故没有提供什么有意义的结论。然而美国同学的这种科学态度与实验精神值得我们学习和思考。事实上,这篇文章仍然提供了珍贵的历史资料,读者不妨按照本文逻辑来分析这篇参考文献。阅读过这篇文献的敏感的读者还将在我们后续的文章中看到熟悉的数字。

  3. KLZ 毕业. 入侵防御系统的评测和问题. 注:本文对 DNS 污染包的分类就是从这篇文章的分类继承而来。

0 Comments:

user_name1 day ago
Reply
Body
本站唯一地址:12ddrrRKkABAWTU48ZL3THfypHtVJ3aVF5
域名短网址(可能會被篡改):ChineseCensorship.bit
This page is a snapshot of ZeroNet. Start your own ZeroNet for complete experience. Learn More