西西河

主题:Google准备扯乎了,还要恶心一下中国. -- james

共:💬638 🌺1250 🌵26
全看分页树展 · 主题 跟帖
家园 关于“西厢计划”大家有何评价

*西厢计划* 提供一组工具,使得用户在一次设置之后,能够以普通程序直连目标网络,而避免GFW的大部分影响。其命

名是为了向中国古典文学史上翻墙的先驱者张某致敬。西厢计划现在已经达到alpha可用状态,在初步的测试中可以让用户以普通浏览器无障碍地直连Youtube。

特性

西厢计划要解决GFW造成的两个 方面的问题:TCP连接重置和DNS劫持(污染)。为此西厢计划提供了两种特性:

- TCP连

接混淆:在每次连接中,通过对GFW的入侵检测系统进行注入,混淆连接,使得GFW无法正确解析连接和检测关键词,从而在有关键词的情况下也避免连接重 置。

- 反DNS劫持:通过匹配GFW伪包的指纹并将其过滤,让用户以普通的客户端也能获得正确的解

析结果。(用户需要设置DNS为没有被污染的DNS,例如8.8.8.8等)

西厢计划不是代理,不是VPN,无需加密,使用时不需要第三方支援,不需要绕道,让用户能够以最优的性能直连目标,使用时不需要运行特别的程序。西厢计划利用现有工具,仅要求用户能够使用iptables进行快速配置,学习难度低。

西厢计划目前能够让用户直连 Youtube和其他Google服务,还有更多潜力可以发掘。

原理简介

西厢计划采取了T. Ptacek等在1998年的论文Insertion, Evasion, and Denial of Service: Eluding

Network Intrusion

Detection中提出规避入侵检测的注入方法。注入法是指发出特制报文,使得这些报文对对方没有效果,但是让IDS错误地分析协议,从而让IDS错误

地认为连接被提前终止了。由于GFW的TCP栈非常简陋,因此我们可以直接利用GFW的TCP栈的特性,对任何遵守RFC的目标主机都采取特定特殊措施,

让GFW无法正确解析TCP连接,从而避免关键词监测。

局限

西厢计划的连接混淆功能对于基于IP地址的封锁和其他无状态的封锁不能生效,因为它需要通过注入攻击改变GFW的连接状态,如果封锁

与连接状态无关便无法进行连接混淆。另外,连接混淆的实现假设连接双方遵守RFC。有一些目标主机或者防火墙不遵守RFC,可能导致正常不含关键词的连接

被对方终止或者忽略。因此我们特别使用ipset,把作用范围限制在需要的地址段(比如Google),以避免不必要的问题。

西厢计划目前依赖linux内核的netfilter功能,因此要求用户平台是linux,暂时没有移植。之前有一个基于

WinPcap的版本<http://code.google.com/p/scholarzhang/source/browse/branches/scholarz...>

可以在MinGW32环境下编译运行,实现了连接混淆的部分,未实现反DNS劫持的部分,用户仍然可以试用<http://scholarzhang.googlecode.com/files/scholarzhang-0.3.2-mingw32-a...>,但不再维护。

西厢计划所用的GFW伪包指纹可能在此项目发布之后被GFW更改,因此用户 可能需要使用最新的版本才能让功能生效。

报告问题

请到本项目的issue list <http://code.google.com/p/scholarzhang/issues/list>报告问题。

更多工作

- 更细致的测试

- 打包(deb、dkms、rpm)以提高可用性

- FreeBSD、Windows等系统的移植

希望感兴趣

的朋友参与帮助此项目的开发,特别是以上三项。可以直接向项目管理员发邮件或者在项目wiki页留言成为committer,也可以直接fork一个新项

目,都欢迎。

另外由于目前广泛应用的CDN系统是以支持GeoIP的DNS为基础的,这要求用户

使用的DNS服务器应当与自身所处网络尽可能近,否则用户上网会很缓慢。如果您愿意为突破GFW出一份力,欢迎在国内架设递归DNS服务器,此项目的反

DNS劫持模块可以使递归DNS服务器的缓存不被GFW投毒,从而国内用户可以在任何操作系统下,只需要将系统DNS设置为您的DNS服务器,不用任何其

它设置(用户不必使用本项目),就能得到即时、正确、最优的DNS返回。

“西厢计划”原理小解

文章分类:互联网

原文出处:http://blog.youxu.info/2010/03/14/west-chamber/,略有改动

待月西厢下,迎风户半开。隔墙花影动,疑是玉人来。

最近推上最流行的一个关键词是”西厢计划”,这个计划名字取得很浪漫,客户端叫做张生,对,就是西厢记里面那个翻_墙去见崔莺莺小姐的张生;显然,服务器端必然叫做崔莺莺。客户端的张生是最重要的部件,可以不依赖于服务端工作。因为西厢计划的作者只是简要的介绍了一下原理,其他报道又语焉不详,我当时就觉得很好奇,花了昨天一个晚上详细读了一下源代码,终于知道怎么回事了,觉得原理非常漂亮,所以写篇文章介绍总结一下。

先说大方向。大家都知道,连接被重置的本质,是因为收到了破坏连接的一个TCP Reset 包。以前剑桥大学有人实验过,客户端和服务器都忽略 Reset,则通信可以不受影响。但是这个方法其实只有理论价值,因为绝大多数服务器都不可能忽略 Reset 的 (比如 Linux,需要 root 权限配置iptables,而且这本身也把正常的 Reset 给忽略了)。只要服务器不忽略 Reset,客户端再怎么弄都没用,因为服务器会停止发送数据,重置这条连接。所以,很多报道说西厢计划是忽略 Reset,我从源代码来看应该不是这样。在我看来,西厢计划是利用了墙的一个可能的弱点–墙只在连接发起的时候把一个 TCP 连接加入监听序列,如果墙认为这个连接终止了,就会从监听序列中去掉这条记录,这样,这条连接上后续的包就不会被监听。西厢计划就是让墙“认为”这个连接终止的一个绝妙的方法。只要墙认为这个连接两端都是死老虎,墙就不会触发关键词检测,其后所有的数据,都不存在连接被重置的问题了。

如何让一个连接置之死地而后生,就是西厢计划那帮黑客神奇的地方了。这也不是一日之功。 首先,这帮牛人发现,墙实际是一个入侵检测系统,把含有关键字的包当成一种“入侵”来对待。采取这种设计有很多好处,但缺点是入侵检测系统可能具有的问题,墙都可能有。西厢计划主页上那篇著名的论文就是讲这些七七八八的漏洞的。可以说处理这些七七八八的漏洞是非常困难的,迫使墙的设计者“拆东墙,补西墙”。这样补来补去,外表看起来好像很牛逼的墙,其实有很多本质上无法简单修补的漏洞,其中有一个致命的,就是 TCP 连接状态的判定问题。 出于入侵检测系统这种设计的局限,墙没有,也没办法准确判定一条 TCP 连接的状态,而只是根据两边收到的数据来“推测”连接的状态。而所有的关键词检测功能,都是基于“连接还活着”的这个推测的结果的。因为墙的规则是在连接发起的时候开始对这条连接的检测,在连接终止的时候停止对这条连接的检测,所以,一旦对连接的状态推测错误,把还活着的连接当成已经关闭的连接,墙就会放弃对这条连接上随后所有的包的检测,他们都会都透明的穿过墙的入侵检测。

上面只是想法,具体到 TCP 协议实现这一层,就要只迷惑墙,还不能触及我要通信的服务器。最理想的情况下,在任何有效通信之前,就能让墙出现错误判断,这些,就需要对 TCP 协议有深刻理解了。西厢计划的那帮黑客,居然真的去读 TCP 几百页的 RFC,还居然就发现了方法(这里我假设读者都知道 TCP 的三次握手过程和序列号每次加一的规则)。 我们都知道,三次握手的时候,在收到服务器的 SYN/ACK 的时候,客户端如果发送 ACK 并且序列号+1 就算建立连接了,但是客户端如果发送一个序列号没 +1 的 FIN (表示连接终止,但是服务器知道,这时候连接还没建立呢, FIN 这个包状态是错的,加上序列号也是错的,服务器自己一判断,就知道这个包是坏包,按照标准协议,服务器随手丢弃了这个包),但这个包,过墙的时候,在墙看来,是表示连接终止的(墙是中国制造的,是比较山寨的,不维护连接状态,并且,墙并没有记下刚才服务器出去的 SYN/ACK 的序列号,所以墙不知道序列号错了)。所以,墙很高兴的理解为连接终止,舒了一口气去重置其他连接了, 而这个连接,就成了僵尸,墙不管你客户端了,而这时候,好戏才刚刚开始。

事实上,墙是双向检测的(或者说对每个包都检测的),因此,对服务器和客户端实现相同的对待方法,所以,墙不管客户端还不行,假如服务端有关键词传给客户端,墙还是有可能要发飙的(这里说有可能,因为我也不知道)。所以,最好的办法就是,让服务端也给墙一个终止连接的标志就好了。可是这个说起来简单,做起来难,怎么能让不受自己控制的服务器发一个自己想要的包呢? 西厢计划的那帮黑客,再次去读几百页的 RFC,令人惊讶的发现,他们居然在 RFC 上发现了一个可以用的特性。我们上面说了,三次握手的时候,在收到 SYN/ACK 后,客户端要给服务器发送一个序列号+1 的ACK,可是,假如我不+1呢,直接发 ACK 包给服务器。 墙已经认为你客户端是死老虎了,不理你了,不知道你搞什么飞机,让这个 ACK 过了。可是服务器一看,不对啊,你给我的不是我期待的那个序列号, RFC 上说了,TCP 包如果序列号错了的话,就回复一个 Reset. 所以,服务器就回复了一个 Reset。这个 Reset 过墙的时候,墙一看乐了,服务器也终止连接了,好吧,两边都是死老虎了,我就不监听这条连接了。而至于客户端,这个服务器过来的 Reset 非常好识别,忽略就是。随后,客户端开始正确的发送 ACK,至此,三次握手成功,真正的好戏开始,而墙则认为客户端和服务器都是死老虎,直接放过。所以,张生就这样透明的过了墙。 至于过墙以后所有的事情,《西厢记》里面都有记载,各位读者自行买书学习。

现在的西厢计划客户端,即“张生”模块的防连接重置的原理就是这样,服务器端,即莺莺模块的实现也是类似的。防DNS那个,不懂 DNS 协议,所以看不懂。我猜想,因为开发人员都是黑客,所以自然喜欢用最经得起折腾和高度定制的 Linux 开发。 现在看西厢计划的实现,因为依赖于 Linux 内核模块 netfilter,在 Linux 上如鱼得水,但往其他平台的移植可能是个亟待解决的问题。 我觉得,在其他平台上,可以通过 libpcap 和 libnet ,在用户态实现相同的功能,就是有点麻烦而已,有兴趣的懂网络的可以照西厢计划原理,在家自行做出此功能;当然,全中国人民都用 Linux 最好。

全看分页树展 · 主题 跟帖


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河